MQSeries.net :: View topic - TDS field re-ordering

bbakerman · Posted: Thu Aug 11, 2005 3:18 am Post subject:

In the MRM we have a TDS definitions for a HL7 messages. I give the PV2 segment as an example (there are tens of more segements in HL7)

NOTE : The field naming convention is segment.fieldindex.fieldname but it might just be fieldname and most fields are optional.

The group "type" is Its defined as a "sequence" and we use Content Validation of "Closed". The group inidicators is "PV2" the delimeter is "|" and the group end indicator is <CR> and Supress Absent Element Delimiter is "End Of Message"

All fields are xsd:strings with no lengths.

So the TDS definition is :
=================
PV2
PV2.1.PriorPendingLocation
PV2.2.AccomodationCode
PV2.3.AdmitReason
PV2.4.TransferReason
PV2.5.PatientValuables
PV2.6.PatientValuablesLocation
...
...
PV2.10.EstimatedLengthofInpatientStay
...
...
PV2.16.PurgeStatusCode
PV2.17.PurgeStatusDate
...
PV2.24.PatienStatusCode
PV2.25.VisitPriorityCode
...
PV2.47.ExpectedLOAReturnDateTime
==============

If we have an input message like this :

PV2||SIN|^TEST||N^NC|||||0|||||||||||||^^2

Then we get a logical tree definition of

InputRoot
MRM
PV2
PV2.2.AccomodationCode = 'SIN'
PV2.3.AdmitReason = '^TEST'
PV2.5.PatientValuables = 'N^NC'
PV2.10.EstimatedLengthofInpatientStay = '0'
PV2.24.PatienStatusCode = '^^2'

So far so good. The TDS only shows fields that are present.

The problem occurs when you set a field that is not present on input but is logically before the "last present" field in the message. For example say
the business rule is that if TransferReason is not set, it must be default to a value of 'None'.

In our compute node or mapping node we do this

set OutputRoot = InputRoot.
if InputRoot.MRM.PV2."PV2.4.TransferReason" is null then
set OutputtRoot.MRM.PV2."PV2.4.TransferReason" = 'None';
end if
...

This ends up with a logcal message tree like this :

InputRoot
MRM
PV2
PV2.2.AccomodationCode = 'SIN'
PV2.3.AdmitReason = '^TEST'
PV2.5.PatientValuables = 'N^NC'
PV2.10.EstimatedLengthofInpatientStay = '0'
PV2.24.PatienStatusCode = '^^2'
PV2.4.TransferReason = 'None'

When this is written out to a message (via output parsing by the TDS) I get a messgae that looks like this :

PV2||SIN|^TEST||N^NC|||||0|||||||||||||^^2|None

The TDS parser is not smart enough to know field 4 should be "re-ordered" back in the fourth spot. It blindly whacks in on the end of the data.

For the record it does to the right thing for fields that are not there but are "greater" than the last encountered field. For example if you set the 47th field and its not present, then the TDS parser does put in the required amount of empty delimiters up the the 47th field. So thats reassuring.

What we are after is a way for the TDs parser to to one of this things:

A. Know how to re-order the field by name so we get the expected output.

B. "Expand" the whole message tree on input so we get all possible fields with "blanks" or "empty string" for fields that are not present.

Option A is the best option as it requires the least parsing and works inteligently. But maybe the TDs parser can do this for valid reasons (such as repeating sequence handling etc...)

Option B is the next best solution because fields cannot get out of order because thery are all present. Eg if you set field index 4 then it s there and hence in order still. The downside is that you get more memory usage than you otherwise would but is prevents bad output.

We have considered some HACKS but they all SMELL VERY BAD.

For example we could "know" what fields come before what field and do an create field as sibling but the sematics and coding of this are just AWFUL. And I dont want to have to put all the knowledge of the message structure in EQSL code. This is what the MRM is for.

I have played with default values and Encoding Null options to no avail. I cant seem to make the TDS parser "auto expand" the input message tree or have it "re-order" the messages tree elements on output.

Does anyone have some suggestions on how to approach this.