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.

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).

V35 Test Data Set

We have put up the V35 test data on our etail site: http://www.drggroupers.net/about/ as a free download in case you need the data to debug any of our products.

Specifically, we offer testdbv35.zip which contains our catalog, the CMS data set in the original fixed-width format (testdbv35.txt) and also in comma-separated value (CSV) format.

Archive:  testdbv35.zip
  Length     Date   Time    Name
 --------    ----   ----    ----
   169339  10-30-17 12:52   drgmanv35.pdf
 13407058  10-30-17 12:52   testdbv35.txt
  1055839  10-30-17 12:52   testdbv35.csv
 --------                   -------
 14632236                   3 files

The DRGFilt .INI file groups which correspond to these files are these:

[fixed]

format = fixed          ; input file format

verbose = 0             ; 0 = no debugging information, 1 = debugging information

blip = 1000             ; give progress report every 1,000 records

blipeol = 0             ; 1=newline for progress report, 0=carriage return

batchver = 35           ; assign version 35 DRGs to this batch

maskdir = .             ; directory in which to find drgmasks.v35

; fixed-width input variables: name = length@offset

age =   3@0

sex = 1@3

ds =  2@4

dxl=8           ; dx length does not require an offset

poa= 7

dx = 200@23

mnh@jackal-n2:/drbd/mnh/src/drgs/v35/src$ cat v35.ini

; new format DRGFilt control file, with different groups for different purposes

; Tue Oct 11 09:52:42 EDT 2016 BFH change path in [cgi] to match new server

; Sun Oct  2 10:19:10 EDT 2016 BFH set to v34

; Thu Oct 12 11:34:36 EDT 2017 BFH set to v35

;---------------

; this group is to process the standard fixed-width input file from CMS

;---------------

[fixed]

format = fixed          ; input file format

verbose = 0             ; 0 = no debugging information, 1 = debugging information

blip = 1000             ; give progress report every 1,000 records

blipeol = 0             ; 1=newline for progress report, 0=carriage return

batchver = 35           ; assign version 35 DRGs to this batch

maskdir = .             ; directory in which to find drgmasks.v35

; fixed-width input variables: name = length@offset

age =   3@0

sex = 1@3

ds =  2@4

dxl=8           ; dx length does not require an offset

poa= 7

dx = 200@23

sgl=7@0         ; pr length, offset is optional & ignored

surg= 175@223

exmp = 1@6

; -----

; these are already present from the CMS grouper:

; you could overwrite the incoming values if you wanted to

; drg = 3@603

; mdc = 2@600

; rc = 2@598

; -----

; these are written out by DRGFilt

rc  = 2@1760

mdc = 2@1762

drg = 3@1764

[csv-validate]

format = csv (,) ; separator character is in parens

base = 0 ; indices are zero-based

;base = 1 ; indices are one-based

inheaders = 1           ; 1=input column headers, 0=no input column headers

outheaders = 0 ; 1=want column headers, 0=no headers

crlf = 0 ; type of end-of-line: either crlf or lf

blip = 1000

blipeol = 0 ; 1=newline for progress report, 0=carriage return

maskdir = .

batchver = 35

infile = testdbv35.csv

outfile = testdb.validate.csv

verbose = 1

; input variables: name = index

inid = 0

age =  1

sex = 2

exmp = 3

ds =  4

dx = 5-29

poa = 30-54

surg= 55-79

; these are written out by DRGFilt

outid = 0 ; patient ID from input

drg = 1

V35 Released!

Our etail site is now live with the v35 versions of all our products.

http://www.drggroupers.net/

V35 AIX Port

Our v35 AIX port is done and validated.

V35 Windows Products Validated

Our Windows-based products passed validation. The only issue was the ever-annoying leading zeroes problem in MS-Excel. We find that importing the test database CSV always raises this issue: if imported as a CSV, leading zeroes are stripped from procedure codes which mangles those procedure codes.

V35 Linux Products Validated

The v35 Linux products, both 32-bit and 64-bit, have passed validation. On to the Windows products.

V35 Basic Validation Done

Our DRG Assignment Engine (DAE) has passed validation.

We found our bug: handling a few of the new attributes was buggy. Specifically attributes in byte 27 and above.

So now our basic v35 engine works and we are busy embedding it in all our products.

V35 Validation Hiccup

We have hit a snag validating our v35 implementation. We have a single case in the test database which does not group correctly. We are doing a deep dive into our implementation.

V35 Changes Are Modest

We have reviewed the v35 version and compared  v35 to v34 and found some modest logic changes and several new attributes for diagnoses and procedures. So we are hoping that implementing v35 will go quickly and smoothly.

Finally Found The CMS Distribution

Our attempts to get the CMS distribution on which we base our upgrade finally paid off.

For years now we found the CMS distribution on the NTIS (National Technical Information Service) web site but this year we could not find it.

Finally, today, we found the CMS distribution on the CMS web site in this file:  MS-DRG-MCE-Software-2017.zip.

So we are finally off to the races.

V35 Manual

This is where you will find the technical documentation for the v35 versions of our products: [link]

C# Note

One of our customers had an issue integrating our C-callable DLL into a Windows C# app. The first call to mhdrg1() worked but subsequent calls fails with memory corruption. After some back and forth, during which we suspected memory allocation (which turned not to be the culprit), our client resolved the issue themselves and were kind enough to follow up with a note which we reproduce here in case it is helpful to future C# integrators:

After further tests, I concluded that the form of the data being PASSED IN as StringBuilders is the correct/best way. PInvoke marshalling handles the nitty-gritty.
Ref: https://msdn.microsoft.com/en-us/library/e8w969hb.aspx  and  https://msdn.microsoft.com/en-us/library/fzhhdwae.aspx

Declaring the function (actually a delegate in its current test state) as returning "void" and calling it results in no problems/corruptions/errors. Thus corruption was occurring when trying to get a return value. So, I changed the return type to IntPtr on each function delegate and used marshaling to retrieve an ANSI string from the pointer. Viola! It works perfectly.