Seimens and OBX-5

This topic has 10 replies, 4 voices, and was last updated 12 years, 6 months ago by Mike Shoemaker.

Creator

Topic
April 19, 2012 at 12:53 am #53052
Mike Shoemaker
Participant
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
Creator

Topic

Viewing 9 reply threads

Author

Replies
- April 19, 2012 at 1:50 am #76374
  Jim Kosloskey
  Participant
  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.
- April 19, 2012 at 11:52 am #76375
  Mike Shoemaker
  Participant
  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
- April 19, 2012 at 3:50 pm #76376
  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|…
- April 19, 2012 at 4:24 pm #76377
  Jim Kosloskey
  Participant
  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.
- April 19, 2012 at 5:38 pm #76378
  Anonymous
  Agreed, but
- April 19, 2012 at 5:58 pm #76379
  Mike Shoemaker
  Participant
  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.
- April 19, 2012 at 6:08 pm #76380
  Jim Kosloskey
  Participant
  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.
- April 19, 2012 at 6:36 pm #76381
  Mike Shoemaker
  Participant
  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.
- June 19, 2012 at 6:01 pm #76382
  Ruth Berge
  Participant
  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.
- June 19, 2012 at 7:37 pm #76383
  Mike Shoemaker
  Participant
  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

Viewing 9 reply threads

The forum ‘General’ is closed to new topics and replies.