Leading whitspace in NTE segments

[mnowlin]

Running into a problem (Mirth 1.0.3) in NTE segments....

Our LIS sends certain results (microbiology) as NTE messages somewhat formatted as "ready to print in a monospaced font". Problem is they use leading spaces in NTE lines to space things out, and either Mirth or HAPI removes these leading spaces from the message.

End result - column headers are left-justified instead of being over the column data.

Any idea how to turn off this behaviour?

thanks - mike

[chrisl]

Re: Leading whitspace in NTE segments

I believe this was fixed in 1.1. There is an option in HAPI to trim or ignore whitespace on NTE segments which we set to preserve.

-Chris

[mnowlin]

Re: Leading whitspace in NTE segments

I'll give a try - thanks.

[mnowlin]

Re: Leading whitspace in NTE segments

Switched over to 1.1.0 last night, but the problem still exists.

Sent by LIS:
NTE|1|L| Source: Urine|N

Stored in Mirth:
NTE|1|L|Source: Urine|N

Ideas?

thanks - mike

[chrisl]

Re: Leading whitspace in NTE segments

Hmm, we have code specifically to prevent this:

			logger.debug("encoding XML message to ER7:\n" + message);
			xmlParser.setKeepAsOriginalNodes(new String[]{"NTE.3", "OBX.5"});
			Message messagex = xmlParser.parse(message);
			return pipeParser.encode(messagex);

I'm guessing that you are grabbing the ER7 from a different part of the system which doesn't pass through this step. This is a problem on our part, as no conversion should remove whitespace.

What is the design of your channel, and where are you getting the HL7 from within Mirth?

Thanks,
-Chris

[mnowlin]

Re: Leading whitspace in NTE segments

Source is an LLP listener with default options (except address/port). Goes to two destinations - each has a filter to handle either ADT or ORU records - the ORU one is the one breaking. (LIS isn't sending ADT records yet.)

ORU filter:

var rv = false;
// return true if this is an ORU message
if (msg['MSH']['MSH.9']['CM_MSG.1'] == 'ORU&#039 {
rv = true;
}
return rv;

The ORU transformer has one Javascript step (step 0) that looks through the HL7 and defines a few variables in localMap, and steps 1-7 are simple Mappers. I don't do anything with NTE segments here - basically just loop through OBRs, count things, and pull out a few values.

Connector type is Database Writer, going to Postgres. Nothing fancy here - just a pair of INSERTs.

INSERT IGNORE INTO slab_hl7results (acn, recline, csid) VALUES (${Accession}, ${HL7 ER7}, ${ControlSequence});
INSERT IGNORE INTO pendingreports (acn, cli, lastname, firstname, testcount, finalrpt, ordphysln, ordphysfn, ordphysupin, testlist, lvorderid) VALUES (${Accession}, ${Client}, ${LastName}, ${FirstName}, ${count}, ${testResult}, ${OrdPhysLastName}, ${OrdPhysFirstName}, ${OrdPhysUPIN}, ${TestList}, ${LVorderID});


I see the trimmed NTEs under View Messages from the status screen, and in the stored HL7 ER7 record in Postgres.

I suppose it's possible that the LIS is doing the trimming - I'll run Ethereal and prove/disprove this. They have a "view sent HL7" thing that does show the records correctly, but....

Let me know if you want me to export/sanitize the entire channel definition and post it.

mike

[mnowlin]

Re: Leading whitspace in NTE segments

Just captured a transaction - Ethereal shows that the LIS is not trimming leading white space... Eliminates one possibility...

mike

[chrisl]

Re: Leading whitspace in NTE segments

Thanks Mike, the info you provided is great, we now know where to look. If you could send a sanitized sample message (with the whitespace intact), I can take a look at this first thing Monday morning.

Thanks,
-Chris

[mnowlin]

Re: Leading whitspace in NTE segments

Here ya go...

MSH|^~\&|XYZ|Acme Lab and Bait Shop|Outreach|Acme Lab and Bait Shop|200610140904||ORU^R01||P|2.3|
PID|1|30002464855|30002464855|A1234567|PATIENT^TEST^||19710305|F||||||||||XYZ|
Z01|LV2006-10-13-76631|
PV1||2430-0|O|
ORC|RE||A1234567||CM|||||||A11111|
OBR|1|A1234567|A1234567|450100^Protime (including INR)|||200610140425|||||||200610140820||A11111^Quack^Ima^^^^^^^^^A11111||||||200610140904|||F|
OBX|1|NM|45010^Protime Control||10.1|sec|||||F|||200610140903||USER^User^Joe^|
OBX|2|NM|45020^Protime Patient Time||28.6|sec|10.0-13.5|H|||F|||200610140903||USER^User^Joe^|
OBX|3|NM|45030^INR||3.0||||||F|||200610140903||USER^User^Joe^|
NTE|1|L|============== Recommended INR Ranges ==============||
NTE|2|L|Pre-op oral anticoagulant||
NTE|3|L|     Not hip surgery:                      1.5 - 2.0||
NTE|4|L|     Hip surgery:                          2.0 - 3.0||
NTE|5|L|Prevention of venous thrombosis:           2.0 - 3.0||
NTE|6|L|Recurrent venous thrombosis:               2.5 - 4.0||
NTE|7|L|Prevention of arterial thrombo-embolism:   3.0 - 4.0||
NTE|8|L|     (Includes patients with mechanical heart valve)||
NTE|9|L|====================================================||

Also can be found at http://www.argos.org/hl7msg1.txt

thanks - mike

[mnowlin]

Re: Leading whitspace in NTE segments

Chris - any news on this? Not trying to be pushy... (I have a meeting tomorrow, and I know somebody's going to ask.)

Thanks for the help.

mike

[chrisl]

Re: Leading whitspace in NTE segments

Mike,

We're looking to include a fix for 1.2 (due Wednesday night)

-Chris

[mnowlin]

Re: Leading whitspace in NTE segments

Thanks for the update - will pass out the news.

mike

[chrisl]

Re: Leading whitspace in NTE segments

In 1.2 you can use messageObject.getRawData() which returns the exact message received.

The issue is with the XML parser used in HAPI which automatically removes whitespaces when encoding to XML. In 1.0 and 1.1 we re-encode the XML to ER7 to populate the HL7 ER7 variable. 1.2 allows you to access the raw data directly.

Does this help?

-Chris