Please check the FAQ first, it really is a list of answers to our most frequently-asked questions.
Sunday, September 29, 2013
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.
Friday, February 8, 2013
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:
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:
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:
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:
- install a web server on the PC (just do this once)
- install CGI-DRG (need a new one every year)
- 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:
- 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.
- 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.
- The Windows 7 firewall complained about something. I agreed to the default and most strict option.
- 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.
- 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".
- 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
- choose a language (English, French or Arabic)
- set up web server credentials
- use the web server credentials to log in
- hit the "configure" button in the blue "Hosts" box
- choose Aliases, then Add
- Virtual path="/cgi-bin", Real path="C:\Abyss Web Server\htdocs\cgi-bin"
- hit OK
- choose Scripting Parameters add a new script path for "/cgi-bin"
- 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:
Monday, February 4, 2013
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.
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:
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
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
Friday, January 25, 2013
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:
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)
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.
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:
- we use the text file as-is to validate DRGFilt
- we extract & pretty-print random cases to validate our interactive products
- CGI-DRG under Windows
- CGI-DRG under Linux
- Access-DRG under Windows
- C-callable DLL under Windows
- Linux DLL under Linux
- PHP shared object under Linux
- Perl shared object under Linux
- C shared object under Linux
- we reformat the text file as a CSV in order to validate Excel-DRG
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)
- give your CSV the ".txt" extension, eg "testdb.txt" and NOT "testdb.csv"
- use the Excel Data->Import->text file function
- choose your text file from the list of available files
- in the import dialogue, specify that the delimiter is comma
- at step three, highlight any ICD9 or ICD10 columns and specify that the format is "Text"
- 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"
Monday, January 21, 2013
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.
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.
Tuesday, January 15, 2013
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.
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.
Tuesday, December 4, 2012
"Expired" Bug: CGI-DRG, VB-DRG, Access-DRG
A customer recently reported a bug to us which we have tracked down and are in the process of fixing.
The bug is this: if one used "Expired" as a discharge status in VB-DRG, Access-DRG or CGI-DRG, with the case described below, a bogus error was returned: code 5, "invalid discharge status."
Test case: primary diagnosis of 41071 and a discharge status of Expired.
Obviously, Expired is a valid discharge status: we had a bug in handling it. For some reason our mapping of Expired was explicitly not done for versions higher than 25.
We have fixed the bug and expect a re-release of version 30 by February 4th, 2013.
In order to validate our product, we used a DRG assignment app from another organization:
http://cs1.claimshop.net/grouper_demo/grouper_main.aspx
The bug is this: if one used "Expired" as a discharge status in VB-DRG, Access-DRG or CGI-DRG, with the case described below, a bogus error was returned: code 5, "invalid discharge status."
Test case: primary diagnosis of 41071 and a discharge status of Expired.
Obviously, Expired is a valid discharge status: we had a bug in handling it. For some reason our mapping of Expired was explicitly not done for versions higher than 25.
We have fixed the bug and expect a re-release of version 30 by February 4th, 2013.
In order to validate our product, we used a DRG assignment app from another organization:
http://cs1.claimshop.net/grouper_demo/grouper_main.aspx
Subscribe to:
Posts (Atom)
