Seimens and OBX-5

[Mike Shoemaker]

Hi. I was wondering if anyone here could provide some insight into the magic of the OBX-5 field. I’m working with Seimens on an outbound result from their EDM product (enterprise document management). These are HL7 2.3 ORU messages and are essentially dictated results. They will be sent to a number of EMRs. The main problem is they do not support ORUs outbound from EDM and we’re working to assist them with creating the message. An example OBX segment looks like this

OBX|4|FT|OR0050^eOperative Report^Siemens EDM||Siemens EDM^text/plain^TXT^^Encounter Number: 020000052140||||||

My question revolves around these mysterious sub-components of the OBX-5  field.  I have never encountered sub-components in an OBX-5 field before. After discussing with Seimens, they claim they are offering a “robust interpretation of the HL7 spec”.  Aside from giving them points for offering up one of the most creative reasons for deviating from a standard i’ve ever heard, I’m kind of missing how they are making this “interpretation”. Don’t get me wrong, I’m all for “robust” interfaces, but this is going to complicate several translation files I’m using, meaning I’m going to have to edit LOTS of files for a simple mapping change (OBX-5 to OBX-5.4) that I don’t think I should even have to make.  They are telling me this is so that the “receiving system knows whether or not it’s a base-64 encoded and what format the thing is (CDA, PDF, or TXT)” … which would be awesome if I was ever expecting the possibility of a CDA or a PDF via this interface (i’m only expecting textual dictations).

Has anyone dealt with sub-components within the OBX-5 field simply to explain the format of the value, which should be in OBX-2 anyway?

Thanks!

Mike

Topic

[Jim Kosloskey]

Mike,

There is a Data Type for that for the OBX – it is called the ED Data Type and indeed it uses multiple components.

Just as a refresher, the OBX-5 field has no set Data Type associated with it. Rather the contents of the OBX-2 field has to contain the Data Type of the OBX-5 field for the OBX.

In this case OBX-2 has the value FT but the actual content of OBX-5 is definitely not FT.

It appears they want to have their cake and eat it. They want the OBX-5 to either be FT or ED but I am guessing only use FT. The FT Data Type does not have components by definition I believe.

The FT in OBX-2 tells the receiving system what is in OBX-5 is not encoded (base-64 or whatever) and is text. So one would not expect any components in OBX-5.

When they actually do send a PDF or whatever other than plain text then the OBX-2 would have an ED and OBX-5 would have proper use of the components allocated to the ED Data type.

As for the Xlate, you can still use component notation for OBX-5 as long as they always put the actual data in the same component.

Just to be safe though (since they are apparently not properly utilizing OBX-2) I would check the component they say indicates the type of data (txt, pdf, etc.) and the component that is supposed to indicate type of encoding to make sure you ar only passing unencoded actual textual data.

Again another gross misinterpretation of the standard – why can’t any of these guys even read?

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Mike Shoemaker]

Hey Jim,

Yup, the FT data does not specify multiple components, I’ve been staring at it for the past week trying to figure out how it could be misinterpreted (or shall I say, robustly interpreted?) But I was very short-sighted and never thought about peeking at the other data types, in my defense, when they say data type FT, why would I look for data type ED 🙂 As you explained below, that appears to be what they are doing. I’m sure once I point this out, they’ll change OBX-2 to ED and tell me to use Openlink to make it work. I’ll probably end up with some sort of scrub of the data on the Inbound and thank them for being so thoughtful in their interpretations 😉 As usual, I appreciate your insights 😉

Thanks,

Mike

[Anonymous]

Or, OBX:2 = CE (Coded element) might be more accurate.  Here is an examples with CE from the HL7 2.4 spec.

OBX|1|CE|710120&IMP^CXR|1|428.0^CONGESTIVE HEART FAILURE^I9C~^MASSIVE HEART|…

[Jim Kosloskey]

David,

Yep except they are ‘claiming’ the format is supposed to support the concept of the ED Data Type so the Data Type in OBX-2 should be accurate.

However, normally for non-encoded text data (formatted or not) one does not expect to use the ED data type or any component structure so when it is just text the OBX-2 should have FT or ST.

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Anonymous]

Agreed, but

[Mike Shoemaker]

This isn’t a huge ordeal for me, I can map my way around this, but I’m basically just looking for clarification and Jim certainly pointed me in the right direction. The ED data type makes perfect sense looking at the spec but not by looking at the message.  I never considered anything aside from the FT data type because I wasn’t expecting any sort of encoded data, only text. And why would I when OBX:2 says otherwise? They keep talking about their “style-sheets” so part of me thinks they have some sort of template style-sheet with a hard-coded OBX segment.  On a side note, with regard to the encoding characters in the MSH, I always assumed they do a similar thing with their encoding characters in the MSH … they never respect the escaping because they never respect the idea behind stating the encoding characters in the MSH, they just present them in the field as hard coded value and move along (not the first vendor to that either) But I think I won this battle. I have them working on providing the OBX-5 value as text along with the appropriate type in OBX:2…I hope.

[Jim Kosloskey]

Mike,

I suspect the data is in XML format in the Siemens system and they are using XSLT stylesheets to convert to an HL/7 format.

So I am guessing that is what they mean by stylesheet.

I am not convinced this is the best way to do this but it is their system – as long as they produce a usable HL/7 message they could use FORTRAN or ASSEMBLER.

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Mike Shoemaker]

That’s exactly what they are doing. And they just informed me, they can not remove the “Siemens EDM^text/plain^TXT^^Patient Name: Not specified” from the OBX-5 but they offered to try to use Openlink as an intermediary step. I guess Openlink is much more Robust at misinterpreting HL7.

[Ruth Berge]

The support for many of the multi component values including the mime type in OBX-5 is only in HL7 v 2.6.   I’m not looking it up right now mind you but if you are strictly looking for correct HL7 then I do not believe that even the ED datatype can be used as described here unless they are declaring the higher version.  If the interface is 2.3.1 then the correct interpretation would be to ignore those sub-components.

[Mike Shoemaker]

Unfortunately, in this case, they are sending 2.3 but sprinkling in a little 2.6 just for fun. They have since fixed the situation.

MSH|^~&|Siemens_EDM|1AZ0|||201206140243||ORU^R01|TX20120614024322000|P|2.3|||AL|NE|USA

[Author]

Replies