- This topic has 10 replies, 4 voices, and was last updated 12 years, 2 months ago by .
-
Topic
-
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
- The forum ‘General’ is closed to new topics and replies.