Sunday, September 30, 2018

V36 Validation

Looks like 460 cases fail, with 57 underlying DRGs. That should not be too bad.

Update Sun Sep 30 7:11pm Eastern: we are close, but not close enough to pull the trigger tonight. We are expecting to finish validation and do the release by the end of business tomorrow.

Update Mon Oct 1 7:04pm Eastern: we are down to two DRG definitions which have issues; we ran into issues interpreting the specs for some of the pseudo-code, requiring us to slog through the IBM 360 assembler version. But we are now very confident that we will finish validation early tomorrow and do the release tomorrow afternoon.

Update Tue Oct 2 11:22am Eastern: the official test data set passes through our DRG engine without any issues, so QA is done and we are starting the release process.

Update Wed Oct 3 2:11pm Eastern: our usual 32 bit Linux environment is out of action and we have to move to the backup environment which is taking some time. It is not clear how many more 32 bit Linux releases we will do.

Update Wed Oct 3 8:34pm Eastern: our back up 32 bit Linux environment has been configured and our development system ported to it and now we have 32 bit Linux executables again.

Saturday, September 29, 2018

V36 Masks & Weights

The V36 masks and weights file has been built and validated. The logic module is still under construction. This year's differences from last year are pretty massive. Validation is going to be epic this year.

Friday, September 28, 2018

V36 Begins

We have downloaded the latest files from CMS and have begun the development process. Sadly for us, the logic file has been formatted in such a way as to make discerning differences from the previous version rather painful, but as soon as we have a sense of what we are dealing with, we will update this blog with an expected release date.

Monday, May 21, 2018

Backward Compatibility in ICD10 Versions

QUESTION:

Hello, we have used your grouper for several years now, but v35 is the first one that hasn't seemed to be backward compatible to old masks. It groups fine under 35, but if we try to use the 34 mask with the cdrgv35a binary it doesn't return anything. Is this a known issue or something others have dealt with?

ANSWER:

Alas, this is a feature: starting with v32 (our first ICD10-based production release), we gave up backward compatibility for the logic component.

(Note that versions which begin with 'f' are ICD9-based while those that begin with 'v' are ICD10-based. Those that begin with 'x' are experimental.)

The CMS release process changed dramatically, so our release process had to change dramatically as well. In order to assign v34 DRGs you will need the v34 DLL.

Tuesday, April 3, 2018

Release v35a

Executive Summary

On March 30th, 2018 we re-released v35 as v35a to fix a couple of issues. We are sending our free uploads to all the customers who purchased v35  products.

1. The descriptions of ten DRGs (out of the 754) were truncated in the DRG masks file which was part of our initial v35 release;

2. The mean attribute of 73 DRGs were wrong due to a difference in the CMS input files;

3. The mean attribute was not handled correctly by our helper app interface, which affected DLLs, libraries and shared objects (but NOT DRGFilt);

This issues did not impair the ability of our software to assign version35 DRGs, or the weights returned for any DRG assigned. But ten of the descriptions were truncated and 73 of the means were wrong in the reference file and some of the software mishandled the number decimal places in the Geometric Mean Length of Stay (GMLOS).

So DRGFilt customers need only use the new drgmasks.v35 file that comes with the v35a release.

Here is how to know if you have the right masks file: we use the MD 5 Sum:

(https://en.wikipedia.org/wiki/Md5sum)

9117f5ff47cc11df5ef4dfc7c195c30f  v35/drgmasks.v35
7ce8af1b3a9aa50f605de3f2dabe4ae3  v35a/drgmasks.v35

Details

A client reported that a DRG description was wrong, which we quickly  confirmed. Confirming the problem led us to review our mask file creation process and to build a new validation process. We found that the input file from CMS had changed slightly and caused two problems:

1. The DRG description lengths were sometimes much longer than they used to be, so our current maximum of 72 characters was too short for these DRGs: 23, 61, 62, 246, 248, 469, 470, 829, 830

2. The DRG means were imported with the wrong number of implied decimal places for means which were whole numbers, 4.0 became 0.4.

3. For the interface to the DLL, shared objects and libraries, someone fixed the decimal point handling for the part of system, which is why the masks file passed the old validation process.

Going forward we expect the new validation process to catch any future issues with the masks files.

As for the descriptions, we had two choices: (a) to try to edit the descriptions to fit in the current space or (b) to expand the length of the DRG description field in the masks file.

For this year, we decided to go for option (a) to minimize disruption with our software and with our customer's software. The choices we made, which we ran by an outside Medical Records expert before releasing, are listed below.

But as we underestimated the difficulty with shortening the descriptions so starting next year we expect to simply size the DRG description field to accomodate the longest DRG description for any given version.

The descriptions are given below: first the CMS long description and our modified, shortened version.

DRG 023
------------------------------------------------------------------------
CRANIOTOMY W MAJOR DEVICE IMPLANT OR ACUTE CNS PDX W MCC OR CHEMOTHERAPY IMPLANT OR EPILEPSY W NEUROSTIMULATOR
CRANIOTOMY W MAJOR DEVICE IMPLANT OR ACUTE CNS PDX W MCC OR CHEMOTHERAPY

DRG 061
------------------------------------------------------------------------
ISCHEMIC STROKE, PRECEREBRAL OCCLUSION OR TRANSIENT ISCHEMIA W THROMBOLYTIC AGENT W MCC
ISCHEMIC STROKE, PRECEREBRAL OCCLUSION OR TRANSIENT ISCHEMIA W THROMBOLY

DRG 062
------------------------------------------------------------------------
ISCHEMIC STROKE, PRECEREBRAL OCCLUSION OR TRANSIENT ISCHEMIA W THROMBOLYTIC AGENT W CC
ISCHEMIC STROKE, PRECEREBRAL OCCLUSION OR TRANSIENT ISCHEMIA W THROMBOLY

DRG 246
------------------------------------------------------------------------
PERCUTANEOUS CARDIOVASCULAR PROCEDURES W DRUG-ELUTING STENT W MCC OR 4+ ARTERIES OR STENTS
PERCUTANEOUS CARDIOVASCULAR PROCEDURES W DRUG-ELUTING STENT W MCC OR 4+

DRG 248
------------------------------------------------------------------------
PERCUTANEOUS CARDIOVASCULAR PROCEDURES W NON-DRUG-ELUTING STENT W MCC OR 4+ ARTERIES OR STENTS
PERCUTANEOUS CARDIOVASCULAR PROCEDURES W NON-DRUG-ELUTING STENT W MCC OR

DRG 469
------------------------------------------------------------------------
MAJOR HIP AND KNEE JOINT REPLACEMENT OR REATTACHMENT OF LOWER EXTREMITY W MCC OR TOTAL ANKLE REPLACEMENT
MAJOR HIP AND KNEE JOINT REPLACEMENT OR REATTACHMENT OF LOWER EXTREMITY

DRG 470
------------------------------------------------------------------------
MAJOR HIP AND KNEE JOINT REPLACEMENT OR REATTACHMENT OF LOWER EXTREMITY W/O MCC
MAJOR HIP AND KNEE JOINT REPLACEMENT OR REATTACHMENT OF LOWER EXTREMITY

DRG 829
------------------------------------------------------------------------
MYELOPROLIFERATIVE DISORDERS OR POORLY DIFFERENTIATED NEOPLASMS W OTHER  PROCEDURE W CC/MCC
MYELOPROLIFERATIVE DISORDERS OR POORLY DIFFERENTIATED NEOPLASMS W OTHER

DRG 830
------------------------------------------------------------------------
MYELOPROLIFERATIVE DISORDERS OR POORLY DIFFERENTIATED NEOPLASMS W OTHER  PROCEDURE W/O CC/MCC
MYELOPROLIFERATIVE DISORDERS OR POORLY DIFFERENTIATED NEOPLASMS W OTHER

Tuesday, December 5, 2017

How Indicate Exemption When Calling Our Software

QUESTION
Please, can you tell me which are the valid values for variable “Exempt” for version 34? I was not able to find anything in the grouper documentation.
 
ANSWER

When the Hospital Acquired Condition (HAC) rules were introduced, some organizations were exempt from them. This meant that our APIs to our DRG Assignment Engine (DAE) had to expanded to accommodate this concept.

As laid out in this post here, there are three different levels of exempt:
  1.  Organization (batch) level: put the exempt flag in the version and all the records will be assumed to be exempt.
  2. Record level: put the exempt flag in the record sent to the DAE and that particular record will be exempt.
  3. Diagnosis level: make the PoA flag for a given Dx code the "exempt" value and that particular Dx code will be exempt.
To send the exempt flag at the batch level, append a lowercase 'e' to the version number, eg '33e'.

To send the record level flag to any API which allows it, pass Exempt flag parameter as nothing (not exempt) or as X. To send the record level flag to DRGFilt, set the "exmp" flag to either X or 1.

To send the exempt flag at the code level, check out this post here.

Monday, December 4, 2017

DRG Return Code of 9

QUESTION

I have a doubt with the return code “9”, whose description in the manual says “means that the DRG to be labelled is too high for the specified DRG version or that there was a HAC violation”, while in the web grouper the description is “ERROR: Grouper error 9 (DRG number too high)”. I don’t know exactly how to understand this description. I made some tests and found that sometimes the problem is with the POA not informed, but this is not always the explanation. I’m working with version 34.


ANSWER

The short answer is that the description of return code 9 that you are getting is out of date. Starting with our support of ICD10 (v33), the description should be the one you see below:

    "Bad principal diagnosis.",         /* 1 */
    "Bad prin dx for MDC ....",         /* 2 */
    "Invalid age ............",         /* 3 */
    "Invalid sex ............",         /* 4 */
    "Invalid discharge status",         /* 5 */
    "Unspecified DRG error...",         /* 6 */
    "Invalid prin diagnosis..",         /* 7 */
    "No DRG file this version",         /* 8 */
    "HAC POA invalid.........",         /* 9 */
    "DRG number too high.....",         /* 10 */
    "Error in DRG file ......"          /* 11 */


HAC stands for Hospital-Acquired Condition and POA stands for Present on Admission. So an RC of 9 means that you wanted HAC processing (ie you did not specify that the organization is "exempt") but there was something wrong with the POA flag (either missing or an illegal value or was presented in a way which our DRG Assignment Engine could not parse).