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.

V34 Errata From NTIS (our version v34a, their v34 release 3)

Today is Tuesday, November 15th, 2016. Last Friday, an unexpected delivery from NTIS (who distribute the office US Federal DRG implementation on which we base our implementation) showed up in our mail.

This delivery contained a disc we had not ordered and a notice from NTIS that the official V34 R2 (release 2) had issues and so there was an R3. Here is alink to the official Errata documents: https://www.cms.gov/Medicare/Medicare-Fee-for-Service-Payment/AcuteInpatientPPS/Downloads/FY2017-CMS-1655-FR-MS-DRG.zip

We spent the weekend reviewing the changes and deciding what we should do. Given what we found (logic and code attribute changes), here is our plan:

(a) Do a re-release as quickly as possible, offering a free upgrade to all customers who bought the initial release.

(b) Accept that the "v34" as version tag is associated with the initial, erroneous release.

(c) Use "v34a" in software version tags and in the executable file names and distribution files which supercede the initial release and so users can more easily tell if they have the corrected software (we realize that this may also cause users to have to change configuration scripts, etc, but we felt that certainty about having the corrected version was paramount). NOTE: We are not changing configuration file names as such v34.ini for DRGFilt as there is no need.

(d) Try to keep our grumbling about what a pain in the neck this is to ourselves as much as possible. Suffice it to say we know this is a drag for those of you who bought the initial release and we feel your pain.

We spent yesterday, Monday, figuring out how to schedule this internally and what, exactly, needs to be revisited.

Today the real work starts. We hope to have a new release live on the Website by the close of business tomorrow, Wednesday and to be re-filling already-filled orders on Thursday and Friday.

V34 Deployment Set For This PM

Our automated download creator and validator is done. All of our downloads have been created and validated. We are on schedule to update our on-line etail site this evening.

Antivirus (AV) False Positives

Our windows products come with installers, as it expected.

We use Nullsoft  Scriptable Install System (NSIS) to create our installers (see http://nsis.sourceforge.net/Main_Page for details).

Sometimes Antivirus software, such as Norton AV (now branded as Symantec) incorrectly flag our installers as containing viruses.

In order to try to keep current and keep ahead of Antivirus (AV) false positives, we upgraded to the latest version of NSIS this year, which should make for better Windows 10 support and a lower chance of false flagging by AV software.

When we want to assess the status of our installers, we use this very hand (and free) site: https://www.virustotal.com/

V34 Deployment Delayed Until Monday, October 10, 2016

Last year was the first IC10-based version and we had to dramatically change our venerable processes to put out the new product line. Thus we were weeks later than we would have liked and the process was largely manual.

This year we are automating the process to improve quality and consistency. We underestimated the level of effort required and so were not able to make yesterday's deadline. We have decided to take the entire weekend in order to make sure that everything is right, so we are now expecting to have our v34 products on-line for sale by first thing Monday morning.

V34 32-bit PHP Version: Entry Point Now "mhdrg1_v34"

This applies ONLY to our 32 bit Linux PHP Module

In our 32 bit Linux environment there is apparently only one PHP name space for modules. Our ICD10-based DRG Assignment Engine (DAE) only handles one version while our ICD9-based version handled previous versions.

This means while our ICD9-based PHP module had a single entry point, mhdrg(), our ICD10-based PHP needs a unique entry point for every version. We had hoped to have a single entry point, mhdrg1(), but that won't work. So instead we will have an entry point named for the version starting with v34: mhdrg1_{ver}(). So the entry point for v34 PHP is mhdrg1_v34, like this:

<?php
    # tryit.php (c) 2002 M+H Consulting, LLC MH DRG test script

    printf("tryit.php (c) 2002-2016 M+H Consulting, LLC: MH DRG test script");
    $ver = "v34p";

    if (!extension_loaded('phpdrgv34')) {
    printf("<h1>ERROR</h1><p>phpdrgv34 is not loaded...</p>");
        /* exit; -- comment out because we want to see the error */
    }

    # call grouper, store results in $retval
    $retval = mhdrg1_v34(
        $ver,            # which DRG version you want
    "{wherever-you-keep them}",    # path to masks files
        "1",            # discharge status */
    "55",            # patient age on admission */
    "2",            # 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,               # length of each ICD procedure code */
    "Y",            # are there POA indicators?
    "n"            # is this case exempt?
    );

    # if there was an error, alert the user
    if ($retval == '') {
    $error = errdesc();
        print("Error: $error<br>");
        exit;
    }

    # show the raw return value
    printf("Raw return value from mhdrg1_v34:<br>%s<br><br>",$retval);

    # deconstruct return from mhdrg1_v34()
    list($rc,$mdc,$drg,$ovn,$weight,$mean,$porm,$desc) = explode("^",$retval,-1);
    print("Deconstructed return value from mhdrg1_v34:<br>");
    print("rc=$rc, mdc=$mdc, drg=$drg, ovn=$ovn, weight=");
    print("$weight, mean=$mean, porm=$porm<br>desc=$desc<br>");
    print(" EXPECTED: RC: 0 MDC: 10 DRG: 614<br>");
    exit;
   
    ?>

In order to pass validation with the command-line PHP, we had to force the loading of v34 module, like this:

php5 -dextension=phpdrgv34.so -f tryit.php

V34 Windows Products Are Done

As of end-of-day yesterday, our Windows v34 products passed validation, so we are packaging them up today and updating our on-line store.

V34 Linux Products Are Done

As of last night our 64 bit and 32 bit Linux v34 products all passed validation.

Today we expect to finish with our Windows v34 products and we hope that tonight or early tomorrow our web site and on-line store will be updated to offer both Linux and Windows products for sale.

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.