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


Wednesday, November 1, 2017

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

Tuesday, October 31, 2017

V35 Released!

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

http://www.drggroupers.net/

Monday, October 30, 2017

Sunday, October 22, 2017

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.

Wednesday, October 18, 2017

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.

Thursday, October 12, 2017

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.

Tuesday, October 10, 2017

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.

Monday, October 9, 2017

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.

Thursday, April 27, 2017

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.