F31 Non-Linux Unix Ports

We have just finished creating the AIX and SPARC versions of our products. As we do not run these platforms in-house, we rely on a porting lab to provide those platforms and that porting lab is Ready-to-Run, http://www.rtr.com

Our current AIX platform is this:

OS:                 AIX 5.3.0
RTR Platform Type:  RS6000-6
Hardware:           PowerPC
Vendor:             IBM
GNU C Compiler:     gcc 3.2
System C Compiler:  /usr/vac/bin/xlc

Our current SPARC platform is this:

OS:                 Solaris 2.9 (Sparc)
RTR Platform Type:  SSol2
Hardware:           UltraSparc Enterprise
Vendor:             Sun
GNU C Compiler:     gcc version 2.95.3

F31 Windows Issue

In validating our Windows product line, we found an issue with file I/O and struct padding. The cycle-saving of yesterday is the misaligned data structure of today.

The good news is that QA came up with a patch which we are submitting to R&D. The bad news is that validation has to start again with the patched sources.

F31 Windows Support

We have gone through windows development environments at a frightening pace this past year.

First, our move to virtual 64 bit Windows 7 was problematic for our C compiler even before Superstorm Sandy took out the power and the Virtual machine with it.

Then we tried physical 64 bit Windows 7 but ultimately our testers were not happy with the hassle of having to match the software (64 bit or 32 bit) with their hardware (64 bit or 32 bit).

Thanks to WoW64 (see http://www.pugetsystems.com/blog/2011/01/13/windows-7-64-bit-running-32-bit-applications/) our classic Win32 .EXEs seem to run everywhere, so we took a 32 bit Windows XP machine out of mothballs and configured it as a development environment and then tested its output on a variety of Windows boxes: success!

F31 Regression Test Passed

We just got a patch from R&D and now our Linux 64 bit version, our reference version, passes all its tests, hurray! On to porting.

F31 Middleware Issue

We discovered and fixed an issue with our middleware, the glue between the DRG Assignment Engine and the DLL and other interfaces: any non-digit Sex cde was tested as M or F and taken as F in the default case. So the CMS test data set's entries whose Sex code was '-', which were supposed to bomb with Invalid Sex, were grouped.

This fix has been propagated for all the products depending on this middleware.

F31 New ICD9 Codes

Probably also because of the impending switch from ICD9 to ICD10, there
was little change in the ICD9 codes: no changes to diagnosis codes
and only four new procedure codes:

00.96   COAG FACTOR TRANSFUSION
14.81   IMP EPIRETINAL PROSTH
14.82   REM EPIRETINAL PROSTH
14.83   REV/REPL EPIRETINAL PROS

For details, visit the CMS site:

https://www.cms.gov/Medicare/Coding/ICD9ProviderDiagnosticCodes/

F31 Regression Test Issue

Our F31 grouper works for F31, but we always test versions F12 through present and we found that our F31 grouper does not handle F30 properly.

So we are clearing it for internal use for F31 and our DRG Assignment Service, but not for release as a product line.

CGI-DRG Issue

We do not think that this is an F31-specific issue, but in validating F31 we found an undesirable behavior in CGI-DRG:

1. Enter a valid case and assign a DRG to it.
2. Toggle the "exempt" flag ON and assign the DRG.
3. Toggle the "exempt" flag OFF and assign the DRG
1. the POA flag will be appended to the DX code as data
2. this will cause an "Invalid Prin DX" error

Fix: after toggling the exempt flag, manually remove the POA flag from the end of any DX codes so affected.

We do not have time to address this  issue directly, but we hope to release an upgrade when the dust settles on F31.

F31 DRG Description Issue

When validating the supporting information (title, weight, etc), we hit this error:

DRG 65 desc differs:
our=(INTRACRANIAL HEMORRHAGE OR CEREBRAL INFARCTION W CC OR TPA IN 24 HRS)
cms=(INTRACRANIAL HEMORRHAGE OR CEREBRAL INFARCTION W CC)


Our R&D group claims that either description is acceptable, so we are going with the original version.

F31 Released by R&D

Today, September 29th, 2013, R&D released the F31 ICD9 software to us for validation. We are on track to release on or around October 1st this year, if all goes smoothly.

CGI-DRG on A PC (VB-DRG Replacement)

We are discontinuing VB-DRG (details here) which means that we do not have a simple desktop DRG assigning solution--or do we?

One of our developers pointed out that he runs CGI-DRG on his Windows 7 PC and that others could as well.

Our customer service head was doubtful that this is a solution for most users, since it requires installing a web server on the PC first. But we let the developer write up his solution so we could post it in case it is more widely interesting than Customer Service thinks. This is the tech blog after all.

To run CGI-DRG on a PC, you need to do three things:

1. install a web server on the PC (just do this once)
2. install CGI-DRG (need a new one every year)
3. install MASKS (need a new one every year)

INSTALL THE WEB SERVER (ONE TIME)

If you have IT support, perhaps they can put a "personal web server" (PWS) on your PC for you; just remember that your PWS has to be able to run CGI scripts.

(A PWS should not be too much of a security issue since it should be configured to only provide service to the PC itself, not over the network.)

If you have to install it yourself, it isn't too big a deal. I choose the Abyss Web Server from Aprelium because it is highly reviewed, it is free and it worked the first time: http://www.aprelium.com/abyssws/

In order to write these instructions, I started with a fresh Windows 7 machine and did the following:

1. Download the free PWS installation appropriate to your O/S from here: http://www.aprelium.com/abyssws/download.php (I chose the Windows link, the first one.) This downloaded abwsx1.exe, which contained both 32-bit and 64-bit versions. Not sure which one you need? Don't panic, Microsoft tells you how to find out here: http://support.microsoft.com/kb/827218 But it did not matter for me, the installer correctly chose 32-bit automatically.
2. Run the installer (abwsx1.exe) and take all the defaults. I chose to have the web server start on user login because I don't want to have to start it up myself when I need it, but I am irrationally afraid of making it a windows service. Do whatever makes sense to you.
3. The Windows 7 firewall complained about something. I agreed to the default and most strict option.
4. I confirmed that the Abyss Web Server was up and running by entering http://127.0.0.1/ into my local browser; 127.0.0.1 is the IP address of the local machine. I got back the default Abyss Web Server web page, so I knew that all was well.
5. Now we need to allow this PWS to run CGI scripts; first, we create the directory in which to put the CGI scripts: c:\Abyss Web Server\htdocs\cgi-bin". In other words, you are adding a subdirectory "cgi-bin" to the existing directory "c:\Abyss Web Server\htdocs".
6. Now the only slightly tricky part: giving this directory permission to run scripts. You go to this URL and follow the prompts: http://127.0.0.1:9999
1. choose a language (English, French or Arabic)
2. set up web server credentials
3. use the web server credentials to log in 
4. hit the "configure" button in the blue "Hosts" box
5. choose Aliases, then Add
6. Virtual path="/cgi-bin", Real path="C:\Abyss Web Server\htdocs\cgi-bin"
7. hit OK
8. choose Scripting Parameters add a new script path for "/cgi-bin"
9. hit Restart and wait until the console returns

INSTALL CGI-DRG (EVERY YEAR)

I am not sure how customers get CGI-DRG: I get it as cgi-drg.exe. I put that file into c:\Abyss Web Server\htdocs\cgi-bin; I like to use the command line like this:

c>\users\dev> copy cgi-drg.exe "c:\Abyss Web Server\htdocs\cgi-bin"

but you can use the Windows Explorer or whatever you want to put cgi-drg.exe into that directory.


INSTALL THE MASKS (EVERY YEAR)

You can use the standard DRGGroupers.com installer to install the masks file, in which case if you take the default, it (they) will go into "c:\program files\mandh\masks" so I will assume that did that or copied the masks file into that directory.


RUN CGI-DRG (WHENEVER YOU WANT)

Once all three installs are done, to run CGI-DRG you enter the following URL into the browser of your choice:

http://127.0.0.1/cgi-bin/cgi-drg.exe/program%20files/mandh/masks

Note that CGI-DRG automatically detects all the versions that you have bought and will give you the ability to choose which one you want for any individual DRG assignment session.

What could be simpler?

SCREEN SHOT

Almost forgot, here is what it looks like:

Issue with Access-DRG and Weights

BUG REPORT

Access-DRG is showing the decimal point in the wrong place for DRG weights, eg Access-DRG reports the weight for DRG 2 as 1.1754 instead of 11.7540.


INVESTIGATION

We confirmed the issue on our Windows validation platform. We confirmed that
this bug did NOT exist on our reference platform. We checked our records and found that our initial drgmasks.f27 file had the decimal place in the wrong place for some weights which was detected as part of quality control. However, we failed to update the canonical image with the corrected file, resulting in at least some customers getting the bad masks file.


RESOLUTION

We confirmed that running the newly updated installer for the f27 masks file corrects the problem. We are sending the bug reporting customer an update right away and working to update our site as soon as possible.

Do not run the masks file "uninstall" as we have an open ticket in which a user claims that running the masks file uninstall removes all masks files, not just the one you want to remove.

If you are not sure if your installation is correct, please run the following test case through our system and see what is returned as the DRG weight; alternately, you can simply download either the Windows installer or masks file directly below.

• Link to the raw masks file for Unix users:https://www.dropbox.com/s/sqyq12ju34b18oa/drgmasks.f27
• Link to the Windows installer:https://www.dropbox.com/s/p2pspwh307fshi3/mhmasksf27.exe
• Test case

   Age: 074
   Sex: M
  Disp: 01
   MDC: 05
   DRG: 002
  DX's: Code :E:P E=exempt flag P=present on admission flag
  DX01: 4280::

Proc's: Code
  SG01: 3764  
  SG02: 3765


MD5 digest of the bad file and the good file:

2f35a9084f929e0075bcddc8d1bcaa35 badweights.drgmasks.f27

7fb9267df1268ab182126ce67700da64 drgmasks.f27

MD5 digest of the bad installer and the good installer:

7b30bb3e24904a7d04d86b4bec60e146 badweights.mhmasksf27.exe

d0995cf7d3174f01425b2fba5e6320c7 mhmasksf27.exe

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"

VB-DRG Discontinued

As of February 1st, 2013, VB-DRG will be discontinued. It will disappear without a trace from our catalogue and from our retail web site.

We have long felt that our Windows Visual BASIC app needed to be either brought up to current VB standards or retired. In our annual internal review, we decided that retirement was the best course.

We intend to replace it as soon as possible. However, we have decided that our stand-alone, interactive DRG assignment solution should be multi-platform, so we are looking into replacing VB-DRG with a Java app which would run under many environments.

DLL Return Code of 9

QUESTION

What does a return code of 9 from the VB-Callable DLL mean?

ANSWER

This return code comes from the DRG Assignment Engine (DAE) and is common across all of our products.

This return code means "input record has Present-on-Admission (POA) violations and the institution is not exempt from HAC processing."

For more about HAC and POA support, please visit this blog entry: How To Use POA

UPDATE: if you append an 'e' to the version number, the DAE assumes that the hospital(s) are exempt and HAC checking is not done at all.