Lowering AIX Support

Since we do not sell enough of them on-line to warrant putting them on-line every year,
we are dropping the AIX version of DRGFilt. We are still able to produce the product, so
we will be making it an on-demand item for at least the coming year. If you want to purchase
the AIX DRGFilt, you will have to send us an email, probably via this tech blog.

Please note that it may take us up to 5 business days to compile, validate and ship the item after we receive payment for an on-line invoice.

While we are on the topic, we can build DRGFilt for many more Unix systems than we do. Currently we do not charge extra for custom requests, but we reserve the right to do so.

Bug Fix For DRGFilt

When validating some of our other software, we discovered a long-standing bug in our DRGFilt product which supports ICD10 codes, both the Linux and Windows implementations. This bug is in versions v33, v34 and v34a, v35 and v35a, v36 and v37.

The patched versions are as follows:

• v33a
• v34b
• v35b
• v36a
• v37a

The bug does not affect DRG assignment; it only affects reporting of the DRG weight. Specifically, unpatched executables  report the DRG weight as 10 times greater than it is. Thus 1.2345 was reported as 12.3450.

The good news is that if you are using the weights for their usual purpose, predicting relative resource consumption, you code worked because all the weights were increased by the same factor.

The bad news is that the weights were wrong.

Here are the steps we have taken to correct this issue:

1. We have patched the sources and built new DRGFilt executables: v33a, v34b, v35a, v36a and v37a.
2. We have sent updated versions to any and all clients who purchased the buggy products.
3. We have updated our on-line store with the new executables.
4. We have posted this message on our Tech Blog
5. We are updating our QA process to make sure that we do not have weight reporting problems ever again.

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.

V34 Initial Implmentation Is Done

We have a DRG Assignment Engine (DAE) which supports v34, the version which was released three days ago. Last night we completed our initial implementation (Linux) and validated it with DRGFilt10 on the CMS data set in fixed-width mode, in CSV mode and in CGI mode.

Now we are hard at work creating versions of our products based on this DAE. We expect to have them for sale by the end of today (3-Oct-2016) or sometime tomorrow at the latest, barred any technical difficulties.

While we code off of the CMS pseudo-code logic definition, we validate against their data set. We are a bit perturbed about having to deviate from the logic version in the following ways in order to correctly group their data set:

• relax the Invalid Sex check for MDC 25 and MDC 8
• assume a Principal Dx is invalid if there is no MDC and no Dx category

However, since we can group their data set correctly, we are moving on with our process. If you have an interesting test cases which address the above topics, or any comments on them, please submit them below.

Web Services and Web Resources

We are frequently asked about DRG assignment as a web service or a web resource.

Our standard response is that you could easily make your own DRG assigning web service or web resource using either DRGFilt or one of our embeddable DRG Assignment Engines (DAEs).

We have not ever published such a thing because we assumed that our clients would want control over the details. However we have some proof-of-concept projects which we may be making into projects over the next few months or years.

WEB HELPER
A web helper is an app which provides functionality to a particular CGI script or dynamic web page. We confirmed that DRGFilt works as a helper when we wrapped DRGFilt in a perl script to create our on-line demo, which is accessible here.

WEB RESOURCE
 A web resource is an app which can be accessed by any CGI script or dynamic web page using HTTP; the caller then processes the output as required. We are playing with the following API to access a thin wrapper on DRGFilt, with the output coming back as XML:

http://yourhost/cgi-bin/daeres.cgi?sex=1&age=55&ds=1&exempt=Z&dxs=B5881,I1201&poas=Y,&procs=0210093,02UG3JZ

<drggrouping>
  <grc>0</grc>
  <drg>231</drg>
  <mdc>5</drg>
  <morp>P</morp>
  <desc>CORONARY BYPASS W PTCA W MC</desc>
  <weight>78.0560</weight>
  <gmlos>9.90</gmlos>
  <version>33</version>
</drggrouping>

WEB SERVICE
A web service i a web app which follows input and output standards to ensure interoperability. We are looking at SOAP and company to try out a DRG assigning service and using this tutorial as a guide:

http://www.w3schools.com/xml/xml_services.asp

Support for 32-bit Linux in V33

In the Windows world we ship 32-bit DLLs because we count on "thunking" to allow this code to run in either 64-bit or 32-bit environments. But we do plan on upgrading our Windows development environment to 64-bit in the next four years.

In the Linux world we planned to drop 32-bit support with v33 (Oct-2015) but found that too many people still run 32-bit Linux, so we added 32-bit versions to all of our programmer tools:

• our PHP module (phpdrgv33_32bit.so)
• our Perl module (perldrgv33_32bit.so)
• our C-callable object (libdrgv33_32bit.so)
• DRGFilt (drgfiltv33_32bit)

We named the 32-bit versions by adding "_32bit" to the end of the file name and therefore before the extension. If you buy any of these modules, you get both the 32-bit and 64-bit versions. If you are in a 32-bit environment, you can either rename the object or call the 32-bit version explicitly.

New DRGFilt Control File

Now that our validation is over, we are publishing the DRGFilt control file we used with the CMS test data set so you can see a real world example of all the new features in action:

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

;---------------
; this group is to process the standard fixed-width input file from CMS
;---------------
[fixed]
format = fixed          ; input file format
verbose = 0             ; no debugging information
blip = 1000             ; give progress report every 1,000 records
batchver = 33           ; assign version 33 DRGs to this batch
maskdir = .             ; directory in which to find drgmasks.v33

; 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

;---------------
; this group is to validate date-handling of a CSV
;---------------
[csv-adt]
format = csv (,)        ; separator character is in parens
base = 0                ; field indices are zero-based, as opposed to 1-based, etc
inheaders = 1           ; 1=input column headers, 0=no input column headers
outheaders = 1          ; 1=want column headers, 0=no column headers
crlf = 0                ; type of end-of-line: 0=crlf (DOS), 1=lf (Unix)
blip = 1000             ; give progress report every 1,000 records
maskdir = .             ; directory in which to find drgmasks.v33
batchver = 33           ; the DRG version to apply to this entire batch
infile = adt.csv        ; input file name
outfile = x.csv         ; output file name
;outfile = blank file.csv
verbose = 1             ; give debugging output
; input variables: name = index
inid = 0
bdt =  1
sex = 2
exmp = 3
ds =  4
; these there keywords are allowed to have lists as parameters.
; lists can contain single entries, ranges, or both. for example
; 1,2,7-22,50
dx = 5-29
poa = 30-54
surg= 55-79
adt = 80
; calcver gives the index of a field to be used as the date from which
; we calculate the appropriate DRG version. If any record's calculated
; DRG version does not match the batchver, we skip that record
calcver = 80            ; NOTE: same index as "adt" because we are using the same field

; these are written out by DRGFilt
outid = 0               ; patient ID from input, whatever inid pointed to
rc  = 1
mdc = 2
drg = 3
desc = 4
weight = 5
morp = 6
outver = 7

;---------------
; this group is to process the CSV we created from the standard fixed-width input file from CMS
;---------------
[csv]
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 = 1 ; 1=want column headers, 0=no headers
crlf = 0 ; type of end-of-line: either crlf or lf
blip = 1000
batchver = 33
maskdir = .
infile = testdbv33.csv
outfile = testdb.out.csv

; 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
rc  = 1
mdc = 2
drg = 3
desc = 4
weight = 5
morp = 6
outver = 7

;---------------
; this group is to process the CSV we created from the standard fixed-width input file from CMS
;---------------
[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 = 33
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 = 33
infile = testdbv33.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

; eof



We hope this answers any questions about how to use the new control file features.

V33 DRGFilt for AIX

We just validated our DRGFilt for AIX so we are good to go for Big Endian environments with our new code base.

You can buy DRGFiltv33 for AIX in our on-line store at drggroupers.nethttp://drggroupers.net

Present On Admission (POA) Flags

Starting with version 33 and ICD10 support, diagnosis codes are supposed to have Present On Admission (POA) flags.

(Unless the institution or patient encounter is "exempt" which would be indicated by the POA Logic Indicator which we call "the exempt flag." The POA Logic Indicator gets its own post to keep confusion to a minimum.)

Here are the CMS definitions of the legal values for this single character flag:

Flag	Meaning
Y	Yes, present at the time of inpatient admission
N	No, not present at the time of inpatient admission
U	Insufficient documentation to determine if present on admission
W	Clinically unable to determine if present at time of admission
1	Code is exempt from POA reporting (Used on 4010 form)
Blank	Code is exempt from POA reporting (Used on 5010 form, effective 01/01/2011)

Many of our APIs have a "Have POA" flag which is something different: the "Have POA" flag is a record-level indication of whether or not there are POA flags in the submitted diagnosis data. The "Have POA" flag is either "y" for yes or "n" for no.

The POA flags are single-character fields at the individual diagnosis code level. There are up to 25 diagnosis codes accepted for DRG assignment and if you are using POA flags, every code should have one.

In their test data set,CMS passes the POA flag to its grouper as the last character of a fixed-width field. We support that methodology in our DRGFilt product's fixed-with mode and in our C-callable DLL as these are environments in which appending an indicator is relatively easy.

We also support passing in separate POA flag fields in our DRGFilt product's CSV mode and in our VB-callable DLL as there environments generally have better support for separate fields than for character manipulation.

DRGFilt10 New Control File Format, part 3

Today we validated group handling in our new DRGFilt Control File; the group name is given in square brackets and every configuration item until the next group is part of the current group.

DRGFilt10 now only processes the configuration information in the active group. The default active group is "drgfilt".  You can either specify an active group on the command line or let the default active group be used.

Therefore the new DRGFilt10 syntax is this:

drgfilt10 {ini-file-name} [group-name]

For example, we are validating with a control file called "v33.ini". That control file defines several jobs:

• "fixed" defines the job to process the standard CMS test data set
• "csv" defines the job to process the CSV we created from the CMS file
• "csv-validate" defines the job which creates output for our validator

When we want to run the job to process the standard CMS test data set, we run this command:

drgfilt10 v33.ini fixed < TESTDB > output.fixed 

We choose to use the Unix-style filter feature of DRGFilt, but the new control file allows us to specify an input file, an output file, or both or neither.

Here is a sample DRGFilt control file which documents all the currently supported features:

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

;---------------
; this group is to process the standard fixed-width input file from CMS
;---------------
[fixed]
format = fixed          ; input file format
verbose = 0             ; no debugging information
blip = 1000             ; give progress report every 1,000 records
batchver = 33           ; assign version 33 DRGs to this batch
maskdir = .             ; directory in which to find drgmasks.v33

; 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

;---------------
; this group is to validate date-handling of a CSV
;---------------
[csv-adt]
format = csv (,)        ; separator character is in parens
base = 0                ; field indices are zero-based, as opposed to 1-based, etc
headers = 1             ; 1=want column headers, 0=no headers
crlf = 0                ; type of end-of-line: 0=crlf (DOS), 1=lf (Unix)
blip = 1000             ; give progress report every 1,000 records
maskdir = .             ; directory in which to find drgmasks.v33
batchver = 33           ; the DRG version to apply to this entire batch
infile = adt.csv        ; input file name
outfile = x.csv         ; output file name
;outfile = blank file.csv
verbose = 1             ; give debugging output

; input variables: name = index
inid = 0
bdt =  1
sex = 2
exmp = 3
ds =  4
; these there keywords are allowed to have lists as parameters.
; lists can contain single entries, ranges, or both. for example
; 1,2,7-22,50
dx = 5-29
poa = 30-54
surg= 55-79
adt = 80
; calcver gives the index of a field to be used as the date from which
; we calculate the appropriate DRG version. If any record's calculated
; DRG version does not match the batchver, we skip that record
calcver = 80            ; NOTE: same index as "adt" because we are using the same field

; these are written out by DRGFilt
outid = 0               ; patient ID from input, whatever inid pointed to
rc  = 1
mdc = 2
drg = 3
desc = 4
weight = 5
morp = 6
outver = 7

;---------------
; this group is to process the CSV we created from the standard fixed-width input file from CMS
;---------------
[csv]
format = csv (,) ; separator character is in parens
base = 0 ; indices are zero-based
;base = 1 ; indices are one-based
headers = 1 ; 1=want column headers, 0=no headers
crlf = 0 ; type of end-of-line: either crlf or lf
blip = 1000
batchver = 33
maskdir = .
infile = testdbv33.csv
outfile = testdb.out.csv

; 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
rc  = 1
mdc = 2
drg = 3
desc = 4
weight = 5
morp = 6
outver = 7

;---------------
; this group is to process the CSV we created from the standard fixed-width input file from CMS
;---------------
[csv-validate]
format = csv (,) ; separator character is in parens
base = 0 ; indices are zero-based
;base = 1 ; indices are one-based
headers = 0 ; 1=want column headers, 0=no headers
crlf = 0 ; type of end-of-line: either crlf or lf
blip = 1000
maskdir = .
batchver = 33
infile = testdbv33.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

; eof

DRGFilt10 New Control File Format, part 2

We have completed and validated CSV support for both input and output for DRGFilt10, the ICD10-based version of DRGFilt. The CSV version of the control file looks like this:

; control file for new DRG filt -- CSV version
[drgfilt]
format = csv (,) ; separator character is in parens
base = 0 ; indices are zero-based
;base = 1 ; indices are one-based
headers = 1 ; 1=want column headers, 0=no headers
crlf = 0 ; type of end-of-line: either crlf or lf
blip = 1000

; 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
rc  = 1
mdc = 2
drg = 3
desc = 4
weight = 5
morp = 6

We hope that this upgrade fills many of the requests we have gotten over the years for extensions to the control file format.

DRGFilt10 New Control File Format

The version of DRGFilt which supports ICD10-based DRG assignment is called DRGFilt10. Since we are overhauling our product line, we decided to knock a very long-standing item off the list: the DRGFilt control file format.

The control file tells DRGFilt how to parse the incoming data records to pick out the data elements needed to assign a DRG:

1. patient age
2. patient sex
3. patient discharge status
4. list of diagnoses
5. list of procedures

The control file also tells DRGFilt where to put its output:

1. Grouper Return Code (GRC) -- what, if anything, went wrong
2. Major Diagnostic Category (MDC)
3. Diagnosis Related Group (DRG)

The original control file format was based on the old IBM punch cards (!) so it was definitely time to ditch the 1960s. For our first upgrade, we decided to move on up to the 1990s by supporting a .INI-like format.

Our first step along the moderization path is Specifically, this is the control file we are using to validate the new DRGFilt against the CMS test data set:

; control file for new DRG filt
[drgfilt]
format = fixed
; 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 incomin 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

; eof


We hope to roll out the long-awaited CSV support very soon.

DRGFilt Control File Change for V30: dxc & sgc

The ancient and venerable DRGFilt control file syntax has changed slightly for v30, released in October of 2012. The change is the addition of two new keywords, "dxc" and "sgc" and they stand for "diagnosis count" and "surgery/procedure count" respectively.

The problem they solve are records with 15 dx or 15 procedures. Since drgfilt's cntl file mechanism only has a two-digit length, it cannot directly specify all 15 when they are spaced as on these test records.

When these values are present, they are multiplied in drgfilt by the dxl and/or sgl and override the lengths on the dx and sg cards.

For example, our internal control file to process the Federal test data now looks like this:

age  000 03
sex  003 01
ds   004 02
dxl  000 08
dxc  000 15
poa  000 07
dx   023 96
sgl  000 07
sgc  000 15
surg 223 98
#drg  603 03
#mdc  600 02
#rc   598 02
exmp 006 01
# these are written out by us
drg  607 03
mdc  610 02
rc   612 02
dflg 614 15
sflg 629 15

F29 Release: AIX Support

We have just released DRGFilt for AIX.

The version of AIX under which we built and tested this executable is this:

AIX host-name 1 6 00C1FB204C00

We can build any of our Unix-based products for AIX, but DRGFilt is the only one popular enough to be in the on-line store: all others are built on-demand.

F29 Release: When AIX Support?

QUESTION

When will the DRG for AIX be available for version 29?  I didn't see
anything on the tech blog about an ETA.

ANSWER

Excellent question, it should be available in about two hours (ie, about Noon Eastern Time today). Sorry for the poor communication.

F29 Release: Windows Validation

Win32 DRGFilt...Passed
Win32 C-callable DLL...Passed
Win32 VB-callable DLL...Passed
Win32 VB-DRG / VB-callable DLL compatibility...Passed
Win32 CGI-DRG...Passed
Win32 F29 ICD9 table...Passed
Win32 ICD labeling DLL...Passed

Win32 F29 masks installer...Passed
Win32 C-callable DLL installer...Passed
Win32 VB-callable DLL installer...Passed

Our windows product line is validated and ready for shipping.

F29 Release: Linux Validation

F29 Linux Product Validation Log

Masks for F29...Passed
DAE Regression Test...Passed
Linux DRGFilt for F29...Passed
Demo Linux version of DRGFilt...Passed
Linux C Shared Object for F29...Passed
Linux Perl Shared Object for F29...Passed
Linux PHP Shared Object for F29...Passed
Linux CGI-DRG for F29...Passed

Details

Masks for F29...Passed
Validated the masks file against official list, which we found here. Not that some MS-DRGs are not defined, such as 9, 18, 19, etc.

DAE Regression Test...Passed
Ran the latest DAE through our regression testing suite.

[Tue Oct 11 16:33:41 2011]     | --------SUMMARY-----------
[Tue Oct 11 16:33:41 2011]     |   v29: Ok
[Tue Oct 11 16:33:41 2011]     |   v28: Ok
[Tue Oct 11 16:33:41 2011]     |   v27(poa): Ok
[Tue Oct 11 16:33:41 2011]     |   v27: Ok
[Tue Oct 11 16:33:41 2011]     |   v26(poa): Ok
[Tue Oct 11 16:33:41 2011]     |   v26: Ok
[Tue Oct 11 16:33:41 2011]     |   v25: Ok
[Tue Oct 11 16:33:41 2011]     |   v24: Ok
[Tue Oct 11 16:33:41 2011]     |   v23: Ok
[Tue Oct 11 16:33:41 2011]     |   v22: Ok
[Tue Oct 11 16:33:41 2011]     |   v21: Ok
[Tue Oct 11 16:33:41 2011]     |   v20: Ok
[Tue Oct 11 16:33:41 2011]     |   v19: Ok
[Tue Oct 11 16:33:41 2011]     |   v18: Ok
[Tue Oct 11 16:33:41 2011]     |   v17: Ok
[Tue Oct 11 16:33:41 2011]     |   v16: Ok
[Tue Oct 11 16:33:41 2011]     |   v15: Ok
[Tue Oct 11 16:33:41 2011]     |   v14: Ok
[Tue Oct 11 16:33:41 2011]     |   v13: Ok
[Tue Oct 11 16:33:41 2011]     |   v12: Ok




Linux DRGFilt for F29...Passed
Validated the DAE with DRGFilt against the test data set with this control file:

age  000 03
sex  003 01
ds   004 02
dxl  000 08
poa  000 07
dx   023 96
sgl  000 07
surg 223 98
exmp 006 01
# these are written out by us
drg  607 03
mdc  610 02
rc   612 02
dflg 614 15
sflg 629 15

Using our validation script, we compare the incoming DRG at offset 603 to our DRG at offset 607, the incoming MDC at 600 with ours at 610, the incoming RC at offset 598 with ours at 612.

Demo Linux version of DRGFilt...Passed
This free version only does F10. Validated it against our internal F10 dataset of 35,451 records.

Interactive Test Cases
We don't run the entire test dataset through our interactive UIs because it would be too much work for too little gain. Once we validate the core DAE, we validate the UIs with a sample of the official test dataset. This year that sample looks like this:

-------------------------------------------
   Age: 049
   Sex: F
  Disp: 01
   MDC: 21
   DRG: 908
  DX's:  Code :E:P where E=exempt flag P=present on admission flag
  DX01: 99679 : :
  DX02: 25041 : :
  DX03: 5859  : :
  DX04: 2767  : :
  DX05: 25051 : :
  DX06: 36904 : :
  DX07: 25061 : :
  DX08: 3371  : :
  DX09: 40290 : :
  DX10: 2859::

Proc's:  Code
  SG01: 3942  
  SG02: 3993  
  SG03: 3995
-------------------------------------------
   Age: 059
   Sex: M
  Disp: 01
   MDC: 01
   DRG: 074
  DX's:  Code :E:P where E=exempt flag P=present on admission flag
  DX01: 3564  : :
  DX02: 2639  : :
  DX03: 311   : :
  DX04: 2761  : :
  DX05: 5601  : :
  DX06: 5180::

Proc's:  Code
  SG01: 9383  
  SG02: 9339

-------------------------------------------
   Age: 050
   Sex: M
  Disp: 01
   MDC: 04
   DRG: 182
  DX's:  Code :E:P where E=exempt flag P=present on admission flag
  DX01: 1628::

Proc's:  Code
  SG01: 324   
  SG02: 3409  
  SG03: 8965  
  SG04: 9396

-------------------------------------------
   Age: 077
   Sex: F
  Disp: 03
   MDC: 08
   DRG: 563
  DX's:  Code :E:P where E=exempt flag P=present on admission flag
  DX01: 81611 : :
  DX02: 25081 : :
  DX03: 2512  : :
  DX04: E8849 : :
  DX05: 3319  : :
  DX06: 04110 : :
  DX07: 8831::

Proc's:  Code
  SG01: 7904  
  SG02: 9659  
  SG03: 8659

-------------------------------------------
   Age: 081
   Sex: F
  Disp: 01
   MDC: 02
   DRG: 117
  DX's:  Code :E:P where E=exempt flag P=present on admission flag
  DX01: 3659::

Proc's:  Code
  SG01: 1279

Linux C Shared Object for F29...Passed
Validated the Linux C shared object with this test case, to also confirm that the used codes bit flag handling is now correct:

-------------------------------------------
   Age: 055
   Sex: F
  Disp: 01
   MDC: 08
   DRG: 455
  DX's:  Code :E:P where E=exempt flag P=present on admission flag
  DX01: 71500 : :Y

Proc's:  Code
  SG01: 8134  
  SG02: 8135


Raw return value from mhdrg:
0^8^455^29^5.6449^0.00^ ^COMBINED ANTERIOR/POSTERIOR SPINAL FUSION W/O CC/MCC                  ^1^11

Deconstructed return value from mhdrg:
rc=0, mdc=8, drg=455, ovn=29, weight=5.6449, mean=0.00, porm=
desc=COMBINED ANTERIOR/POSTERIOR SPINAL FUSION W/O CC/MCC                 
dx flags:1, px flags: 11

Expected result: RC: 0 MDC: 08 DRG: 455

Significant ICD codes:
 * DX code  1 was used
 * Proc code  1 was used
 * Proc code  2 was used

Linux Perl Shared Object for F29...Passed
Validated the Perl shared object against the same test case as C shared object.

THIS YEAR, WE WILL HAVE TO CHANGE OUR PROCESS TO HANDLE THE 5.8 VS POST-5.8 DIVIDE, AS WELL AS MULT-THREADED VS NOT-MULTI-THREADED.


Linux PHP Shared Object for F29...Passed
Validated the Perl shared object against the same test case as C shared object.

Linux CGI-DRG for F29...Passed
Validated the Linux CGI-DRG against same test case as C shared object.

How Does Access-DRG Work?

QUESTION

How does the Access front-end work? (ie. Can I link into a SQL Server dataset (as an input) and have the Access-DRG spit out the results into a SQL Server dataset?

ANSWER

Access-DRG is not really a front end, it is a self-contained app. You load data into it, you call its DRG Assignment function (which, in turn, calls our VB-callable DLL) and it does in-place DRG assignment.

If you want to read data from a database server, assign a DRG and put the results back onto the database server, you probably want to get our VB-callable DLL and write your own simple program to read, call and write. Or you can use DRGFilt and the import/assign a DRG/write method described in a DRGFilt posting.

Version NN Invalid

QUESTION

We executed an  unix command from PL/SQL stored procedure and got the 'Version 27 Invalid' message from DRGFilt, but executed the same command directly from unix box in putty, everything was fine. The following is the command:

'/u01/app/oracle/product/11.2.0/dbhome_1/bin/drgfilt_lnx_64 -0 f27 drgmasks.f27 /home/mhuang/DRGFilt_control.txt </home/mhuang/DRGFilt_input.txt >/home/mhuang/output.txt'
 
What does the 'version 27 Invalid' mean to DRGFilt?  Also can we add our custom keyword in the control file? We plan add more fields into the control file.

ANSWER

re: "Version 27 Invalid"
This means that version 27 could not be initialized. Usually, this means that the drg masks file could not be found or could not be read.

re: custom keywords
No, DRGFilt does not allow custom keywords; however, you can put line comments into the file so long as those comments are preceded by a sharp sign, like this:

sex 156 1
# this is a line comment
#mykey=5

Grouping Data in Oracle

QUESTION

I am interested in running a DRG grouper against large (over a million records) data sets.  My Oracle data warehouse sits on a Solaris box, but I also have windows and linux servers if needed.

I simply want to assign DRGs to my data set.  So, I'm interested in information on how to do this and what product would be right.  It'd also like to get something in house to to ensure that we can actually use it.

ANSWER

If you are not a programmer, then the way to do this would be with DRGFilt:

1. Export your data as fixed-width text
2. Create a DRGFilt control file to match your export
3. Run your text file through DRGFilt
4. Import the DRGFilt output

DRGFilt outputs all the input data, plus the DRG (and MDC and whatever else you configured), so you can import the DRGFilt and do whatever you like with it.

If you are a programmer, you can get an embeddable DRG Assignment product and call it from a program. Supported environments are Windows or most Unixoid systems. Supported runtime environments are Perl, Visual BASIC, PHP and C. A typical program will do the following:

1. Select rows out of your database
2. Process each row one at a time
3. Extract the DAE inputs from the row
4. Call the DAE
5. Parse out the DAE outputs from the call
6. Either update the original row or create a new row

Finally, if you do not want to do the work yourself, or do not want to deal with the version question (ie, which version DRGs do I use for this given record?) you can use our DRG Assignment Service (DAS) to do the work. In that case, the steps are these:

1. Extract your data, without PHI
2. Send us the extract, along with your preferences for the returned data set
3. Usually in one, but sometimes in up to three business days, you get the data
4. Import or process the data set returned by us