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.

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.

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.

Norton Flagging Our Windows Installers

We create installers for our windows products because that makes life easier for our customers.

Over the years, we have found that Norton Anti-Virus has become more and more aggressive in its suspicion of installers which do not come from large companies.

Specifically, Norton is prone to throw a "WS.Reputation.1" error, which basically means "Norton does not specially know about this installer, so Norton cannot say that it is OK." See this Norton link for details: http://community.norton.com/forums/clarification-wsreputation1-detection

We try to maintain a variety of "common" Windows installations in-house. On some of our validation machines we run Norton AV ourselves, so our in-house testers have reported this issue as well. But our in-house testers only had to respond to a dialogue box from Norton AV in order to allow our installers to finish. Customer Service declared this to be irritating, but not a deal-breaker.

Then one of our customers claimed that Norton simply deleted the file and would not allow them to run the installer at all. Since they are a programming shop, they did not really need the installer, so we sent them the component files and they installed them by hand. So in that case the situation was merely annoying, but we realize that other shops might not be so comfortable installing software by themselves.

This issue is not unique to us: here is another frustrated small vendor's rant about this: https://www.codeandweb.com/blog/2012/06/23/how-symantec-ruins-independent-developers

While we are generally big fans of firewall and anti-virus software, and understand why our customers might be unhappy to have our installer quarantined by Norton, we are not happy that Norton is willing to be so aggressive with so little data. And it is not clear what we can do differently: the DRG market is a niche market and we will never have the volume numbers required to get Norton's attention.

So for now we feel that the best we can do is to happily provide the component files and installation instructions as an alternative if you cannot run our installer on your system. Just send us email at our tech support email box.

PS We use Nullsoft to build our installers. For more information on them, visit their wiki here: http://nsis.sourceforge.net/Main_Page

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.

New C-Callable API (both Windows DLL and Linux SO)

In keeping with our philosophy that working code is the most trust-worthy documentation, here is the new mhdrg1() call from our validation C program which we compile and run under either Windows 7 or Linux:


 #define DRGVER "v33"
 
// expected = "DRG: 614        MDC: 10         GRC: 00";

/* call the grouper, store results in retval */
retval = mhdrg1(
    DRGVER,                 /* which DRG version you want */
    "/drbd/mnh/src/SWIG",   /* path to masks files */
    "1",                    /* discharge status */
    "55",                   /* patient age on admission */
    "1",                    /* patient sex (1=male, 2=female) */
    /* ICD DX codes */
    "D352   YE2740  NN390   YE871   NF05    NR630   NR110   YR0602  YD649    ",
    /* ICD procedure codes */
    "0GB00ZZ0YUY47Z02HR30Z0L8S3ZZ0P5N0ZZ0RJP0ZZ",
    8,                      /* length of each ICD DX code */
    7,                      /* len of each ICD procedure code */
    "y",                    /* are there POA indicators? */
    "X"                     /* is this case exempt from HAC? */
    );

This is an actual case from the CMS test data set. This is an actual call to mhdrg1(), which replaces mhdrg() as the entry point in the DLL.

We changed the name to make it possible to have a single program call either the ICD9-based version or the new ICD10-based version.

The API is only slightly different: there are two new arguments at the end of the argument list:

• The POA indicator: are there POA flags appended to the DX codes? This argument is always a character pointer (char *) but can be either "1" (yes there are) or "0" (no there are not), or "y" (yes there are) or "n" (no there are not).
• The POA Logic indicator: this is also a character pointer and represents the HAC exempt status of the patient encounter:
• NULL means there is no exempt flag or encounter is not exempt
• "X" or "1" means that this encounter is exempt
• "Z" means that this encounter is not exempt
• any other value is not allowed and will result in throwing an HAC error if there is a dx code with a CC exclusion of either kind.

V33 C-Callable DLL Validated

We have just finished validation of our new C-callable DLL for Windows, which we are calling cdrgv33.dll. It should be available for purchase next week.