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
Please check the FAQ first, it really is a list of answers to our most frequently-asked questions.
Thursday, October 24, 2013
Thursday, October 17, 2013
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.
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!
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.
Tuesday, October 15, 2013
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.
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/
Sunday, October 6, 2013
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.
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:
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.
- Enter a valid case and assign a DRG to it.
- Toggle the "exempt" flag ON and assign the DRG.
- Toggle the "exempt" flag OFF and assign the DRG
- the POA flag will be appended to the DX code as data
- 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.
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.
Subscribe to:
Posts (Atom)