Codes Used in DRG Assignment, Continued

QUESTION

This is a follow-up to an earlier question.

When I use this.......
---------------------------------------------
$retval = mhdrgc::mhdrg(
         #'f26p',                        # which DRG version you want
         'f28',                        # which DRG version you want
         '/home/programmer/grouper',        # path to masks files
         '1',                        # discharge status (home)
        '72',                        # patient age on admission
        '2',                        # patient sex (1=male, 2=female)
        # ICD DX codes
         '3313    3312    Y49320  Y5990   N7812   Y3051   Y73300  Y3004   Y3320   Y71598  Y412    ',
        # ICD procedure codes
        '0331            ',
        '8',                        # length of each ICD DX code
        '7',                       # length of each ICD procedure code
     );
------------------------------------------------------------------
I'm putting in 11 DX codes and 1 procedure code.

What I get back is this...
---------------------------------------------
0^1^57^28^0.9350^0.00^ ^DEGENERATIVE NERVOUS SYSTEM DISORDERS W/O MCC                         ^1^0


The blog states ...
"The strings are positional: 1001 means that the first code was used, codes two and three were not but code four was. "

Shouldn't the output be more like 
0^1^57^28^0.9350^0.00^ ^DEGENERATIVE NERVOUS SYSTEM DISORDERS W/O MCC                         ^10000000000^0

That is, 3313 was used, but the other ten weren't?

ANSWER

You are referring to the bitstrings of which diagnoses or procedures that were used in the DRG assignment. For the DRGFilt product, these are sflg and dflg keywords.

You are correct, there is a bug in the interface routine. What we see at the lowest level, when we run your example through our testbed, is this:

Diagnosis flags=(100000000000000000000000000000)
Procedure flags=(000000000000000)

So somewhere between the DAE and the Perl interface,the output is being stripped of trailing zeroes, which is not what we want in this case.

We have opened an internal bug and expect to have this fixed in the upcoming release.