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.

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

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.

POA Logic Indicator (Exempt Flag)

With the introduction of the Present On Admission concept came three distinct data elements:

• POA Logic Indicator / Exempt flag: an official grouper parameter which is a record-level flag which tells the grouper whether  or not POA logic (including the Hospital Acquired Condition rules, or HAC);
• POA Flag: an official grouper parameter which is a diagnosis-level flag which tells the group how to process this code against the HAC rules
• Have POA Flag: a DRGGroupers software parameters which, when part of our API, tells our software whether or not to look for POA flags

(Since POA comes up in so many contexts, we prefer to call the "POA Logic Indicator" something else: "the exempt-from-HAC flag" or simply "the exempt flag." Be advised that this is not how CMS refers to this data element.)

There are only two legal values for this flag:


X - Exempt from POA reporting
Z - Requires POA reporting

Note that "2" seems to be used by the grouper folks to means "throw me an error if there is HAC rule processing to do."

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.

I10 Progress Report #8: V33 Support Validated

Hurray, our DRG Assignment Engine (DAE) correctly handles the CMS test set with ICD10 codes and v33 code attributes and logic.

Now we just have to roll out the DAE into our pared-down product catalog and overhaul our web sit and on-line store and we will be all set.

Next stop: CSV support for the new DRGFilt.

I10 Progress Report #8: Masks File Has Been Built

We have built and validated the v33 masks file, so we are ready for integrated testing as soon as the logic module has been updated. We expect the logic upgrade to be done by midday tomorrow.

I10 Progress eport #7: So Far, So Good

We have finished our assessment of the v33 upgrade and we have started the work:

• the attributes seem to be only minor different between v32 and v33
• the logic seems somewhat different between v32 and v33

We expect to have have masks file built first thing tomorrow, so that when the software update is done mid-day tomorrow, validation can begin.

Currently, our goal is to have our DRG Assignment Engine (DAE) will be upgraded to support v33 by end the of the day on October 1, 2015.

I10 Progress Report #6: on to V33

We are hard at work on support for v33, which currently is moving along three different tracks:

DRGFilt Upgrade
We are upgrading DRGFilt to handle CSVs as well as fixed-width input. (We may also get to adding support for the very simple equation format: one line per column, each line of the form "col_name=value")

V33 Masks File
To support v33, we need to support logic and the ICD10 code attributes, which we call "the masks" and some people call "the tables." We encode the logice in our software and we create a database of attributes which we call "the masks file." We are hard at work creating the masks file.

V33 Logic Support
Of course we are upgrading our logic module to match the v33 logic module so that our software can work in conjunction with the v33 attributes to assign v33 DRGs.

I10 Progress Report #5: Success

At last, x32 has been validated, confirming that our new ICD10-based development path is working:

Processing version X32...ICD10 config
9187 records read with 0 errors.
All done.

So we are immediately starting work on v33, which will be our first production version for ICD10.

We are also changing our DRGFilt control file from its very 1980s fixed-width format to a very 1990s .INI file. (We hope to have support for a very 2000s XML format very soon.)

I10 Progress Report #4

Yesterday we finished porting the attributes handling subsystem to our new development environment. We validated x32 against the CMS test data and x32 matches 97% of the time.

We are chasing that 3% but since I10 v32 was not an official release, we think that some of the discrepancy is due to last-minute changes. We are looking into running the official Grouper software so we can confirm their results.

We expect to be done with x32 no later than the end of the week and to start v33 Monday.

I10 Product Catalog

We are overhauling our operations as part of the switch from ICD9cm to ICD10 and one of the areas we are overhauling is our product catalogue.

Many of our products are holdovers from when our customers were mostly information system developers who wanted software development tools, such as shared objects and hash table look-ups.

In recent years we find that fewer and fewer of our customers are programmers and more and more of our customers are analysts or end-users.

We plan to continue to support developers, but on a custom and case-by-case basis: there is no longer any need to clutter our catalogue with estoteric items.

Our ICD9cm catalogue had 30 items and we wanted to get down to 10 items. We think that we have done it; here is our proposed catalogue so we can get your feedback before we make the final decisions.

Items We Plan to Keep

SKU	Description	Status
AIXFILT	DRGFilt for AIX	y
CDLL	Visual C-callable DLL	y
DASJUMBO	DRG Assignment Jumbo Data set"	y
DASLARGE	DRG Assignment Large Data set"	y
DASMEDIUM	DRG Assignment Medium Data set"	y
LINUXFILT64	64 bit Linux DRGFilt	y
MASKS	DRG Masks	y
VBDLL	VB-callable grouper DLL	y
WINFILT	DRGFilt for 32 bit Windows	y
WMASKS	Win32 DRG Masks	y

 
Items We Plan to Retire

SKU	Description	Status
CICD	ICD9 Name-finding C-callable DLL	n
COBJ32SO	32 bit C-callable shared object	n
DASSMALL	DRG Assignment Small Data set"	n
ICDTAB	ICD9cm short file	n
ICLUP	ICL Run-time Environment Upgrade	n
LINUX32CGIDRG	32 bit Linux CGI DRG Assigner	n
LINUXFILT32	32 bit Linux DRGFilt	n
PERL32SO	32 bit Perl-callable shared object	n
PERL64SO	Perl-callable shared object	n
PHP32SO	32 bit PHP-callable shared object	n
PHP64SO	64 bit PHP-callable shared object	n
SPARCFILT	DRGFilt for Sun SPARC	n
VBICD	ICD9cm Name VB-callable DLL	n
W32CGIDRG	32 bit Windows CGI DRG Assigner	n
WICDTAB	Win32 ICD9cm short file	n
XLDRG	MS-Excel DRG Assigning spreadsheet	n

Items We Are Considering Keeping

SKU	Description	Status
ACCESSDRG03	MS-Access	?
ACCESSDRG07	MS-Access	?
COBJ64SO	64 bit C-callable shared object	?
LINUX64CGIDRG	64 bit Linux CGI DRG Assigner	?

I10 Progress Report #3

We almost got the code attribute data file building process ported from our old environment to our new one.

We are grateful to have our out-going guru's help today and we are confident that he will be able to get us over the final hump: if not today, then tomorrow.

I10 Progress Report #2

We did not quite meet our goal of building x32 yesterday; we completed the logic part but not the code attribute part (which we call "the masks" and which many other organizations call "the tables").

We expect to finish the basic x32 DRG Assignment Engine (DAE) today, build DRGFilt x32 on top of the DAE and then start on v33.

I10 Progress Report #1

Many of you have enquired about the status of our support for the upcoming grouper release. This post is intended to answer those questions.

This coming October 1st we are due to release v33, which will be the first version which is only ICD10 (i10). Starting with v33, we will no longer provide ICD9-based (i9-based) grouping support, so v33 is our first non-experimental release which is i10-based.

Up to now, our versions have all been i9-based except for the experimental i10-based products. We designated the experimental versions with an 'x' instead of a 'v', so v31 was the i9-based grouper and x31 was the i10-based grouper.

Last year's grouper was the last grouper with both, so v32 is the last i9-based grouper and x32 is the last time that i10-based grouping is considered 'experimental.'

On top of the very large shift from i9-based to i10-based grouping, our in-house grouper guru retired, which forced us to revamp our development process.

This is our plan to migrate us from the i9-based to i10-based development:

1. Technology turn over from departing guru to new team
2. Re-create x31 with the new process and new team
3. Create x32 with the new process and new team
4. Create v33 with the new process and new team

We are happy to report the step (1) was completed in early June and that step (2) was completed yesterday.

We expect to complete step (3) today and have an x32 DRGFilt available for evaluation by first thing Monday morning.

Currently, we feel that we are on track to be ready to provide our DRG Assignment Service for v33 on October 1st.

We are currently reviewing our product line to see which products we want to port from i9 to i10. As soon as we can we will put up an on-line survey to allow our customers to weigh in on which products to keep and which to leave behind.

ICD10 Support in 2015

2015 should be a banner year for DRG Groupers; we are taking advantage of the impending shift to ICD10 to knock some items off of our to-do list:

• We are going to change our web site to improve the on-line shopping experience.
  
• We changed our URL to DRGGroupers.net to go with our web site overhaul.
  
  
• We are going to try to streamline our upload and download pathways for our DRG Assignment Service (DAS).
  
• We are going to review our product definitions to make sure that we are offering what people want to buy.
  
• We are trying out a streamlined development process by creating an ICD10 version of v32 DRGs--and we are looking for beta testers.

This is an ambitious slate to get done by the end of the year, but so far we are on track and appreciate your patience with any issues that arise.

ICD Codes & MS-Excel (Leading Zeroes)

Each year CMS publishes a data set to help users validate their DRG assignments for that year's DRG version.

We use the official CMS test data set to confirm that our DRG assignments are correct. The data set arrives as a text file which we use in a variety of ways:

1. we use the text file as-is to validate DRGFilt
2. we extract & pretty-print random cases to validate our interactive products
1. CGI-DRG under Windows
2. CGI-DRG under Linux
3. Access-DRG under Windows
4. C-callable DLL under Windows
5. Linux DLL under Linux
6. PHP shared object under Linux
7. Perl shared object under Linux
8. C shared object under Linux
3. we reformat the text file as a CSV in order to validate Excel-DRG

(Many of these exercises are being done twice as we validate our ICD10-based code base.)

It is item 3 that gave us fits this for a long-standing reason: MS-Excel's CSV import insists on stripping leading zeroes for values it imports if those values are all-numeric. This wreaks havoc on ICD9 or ICD10 codes, either of which can start with one or more zeroes and be all digits for the rest of the code.

There are tricks for formatting the code so that it appears to have its leading zeroes, but that does not help, because the actual data remains the stripped version, which is just plain wrong.

We have painfully rediscovered the only way we know of to fix this (although we welcome suggestions of better ways to do this)

1. give your CSV the ".txt" extension, eg "testdb.txt" and NOT "testdb.csv"
2. use the Excel Data->Import->text file function
3. choose your text file from the list of available files
4. in the import dialogue, specify that the delimiter is comma
5. at step three, highlight any ICD9 or ICD10 columns and specify that the format is "Text"
6. import and confirm

TECHNIQUES WHICH DO NOT WORK

If you are trying to use the native Excel Import function on a file with the CSV extension, eg "testdb.csv", we tried the following ideas without success. Most of these ideas were found on the Internet, free and worth every penny.

• Encasing the data in double-quotes, eg "0016071"
• Using a single-quote at the start of the code, eg '0016071
• Making the value into a formula, eg ="0016071"
• Using a leading blank and double-quotes, eg " 0016071"