- This topic has 9 replies, 6 voices, and was last updated 4 years, 8 months ago by
.
-
Topic
-
Our ADT feed has different ADT message types coming through. I have a translation for the OB route. I am seeing allot of translations warnings due to the message format specified for the translation being different than the incoming ADT message. How do you prevent these warnings when a translation is applied to a feed with many different message types?
[msg :RecP:WARN/0:prod_adt_xlate:01/30/2020 15:01:12] [0.0.67292] The # 96 segment encountered ‘DRG’ is out of order when parsing hl7 (2.4 {}) for message type ‘ADT_A03_ADT_A03’ during the translation(edie_ob.xlt). Segment ignored.
-
Replies
-
-
Example message?
-
These are PROD messages so I can’t post examples. However, these are a couple of different types and warnings that I continue to see. I have the translation set to HL7 2.4/ADT_A03
ADT^A03^ADT_A03
ADT^A08^ADT_A01
[msg :RecP:WARN/0:prod_adt_xlate:01/30/2020 14:59:08] [0.0.66680] The # 184 segment encountered ‘DG1’ is out of order when parsing hl7 (2.4 {}) for message type ‘ADT_A03_ADT_A03’ during the translation(edie_ob.xlt). Segment ignored.
[msg :RecP:WARN/0:prod_adt_xlate:01/30/2020 14:59:08] [0.0.66680] The # 185 segment encountered ‘DG1’ is out of order when parsing hl7 (2.4 {}) for message type ‘ADT_A03_ADT_A03’ during the translation(edie_ob.xlt). Segment ignored.
[msg :RecP:WARN/0:prod_adt_xlate:01/30/2020 14:59:08] [0.0.66680] The # 186 segment encountered ‘DG1’ is out of order when parsing hl7 (2.4 {}) for message type ‘ADT_A03_ADT_A03’ during the translation(edie_ob.xlt). Segment ignored.
[msg :RecP:WARN/0:prod_adt_xlate:01/30/2020 14:59:08] [0.0.66680] The # 187 segment encountered ‘DG1’ is out of order when parsing hl7 (2.4 {}) for message type ‘ADT_A03_ADT_A03’ during the translation(edie_ob.xlt). Segment ignored.
-
For our site, some of the messages have different segment order depending on the message type. For example, the A08 messages have an OBX segment in a different location than the A03 message which makes the grouping different for any segment that follows the OBX. What you need to do is have a different translate for those message types (A03) that specifically uses the A03 variant, and other translates can use the A08 variant. What this ends up looking like is that the A03, A17/A40, and I’m sure some others I can’t think of right now have their own translate, and everything else has a “generic” translate. The naming convention we use for translates is SourceVendorMessageType_DestinitationVendorMessageType.xlt, using Axx as the message type in the name for the generic translate. i.e. EpicA03_GEMuseA03.xlt would be for the Epic A03 messages sent to GEMuse, and EpicAxx_GEMuseAxx.xlt would be the generic translate for the messages that follow the same pattern.
Paul Bishop
Carle Foundation Hospital
Urbana, IL -
You have to perform an analysis on all of the different ADT message types coming out of your EMR and determine which segments come out for each message type and identify the order in which they come out . Plot this all out on a spreadsheet so you can visually identify the patterns and the exceptions.
I only have experience with two EMRs. With each, the kind of segments and their order were the same for most message types. Lets call that the ‘standard layout’. The exceptions were Bed Swaps, Merges and Person Updates. We found that the default A08 was the closest match to the ‘standard layout’ but was still not quite workable as-is. We created a variant, and updated the A08 – adding a few segments, making some optional, some repeatable – and kept working and re-working it until we got it to match for all types except the swaps, merges and person updates. So we have one route detail for the ‘A08’ and additional route details for each of the exceptions, and these exception route details use different translates which reference different (or specific) message type formats.
This A08 variant does a lot of work to ‘streamline’ the HL7 content. It removes most of the clutter – which most of the downstream apps require ( to be removed) anyway, so we do it once up front, instead of doing it 40 different times for each ancillary. We still need separate translates for each ancillary, but those are much simpler, because they work with simpler input.
This work was tedious and took months, but looking back after three years, I can easily say it was worth it. And we don’t get those error messages.
Peter Heggie
-
Just send the segment headers in the order that they’re in the message.
-
-
We follow the same strategy as Peter explained, maybe even a bit further.
We made a separate message called ADT which can handle all ADT messages coming in. So we only need one translation for all ADT messages. Most segments are optional; for example the MRG segment will only be used by ADT^A18 or ADT^A40.
Also remember that after translation, the resulting message will be validated against the defined variant and message. So if you use message ADT as inbound and outbound and with this create an ADT^A03, the resulting message will be validated against the definition of ADT_A03.Zuyderland Medisch Centrum; Heerlen/Sittard; The Netherlands
-
Of course you can always have one Xlate for each of the ADT Message/Event Types. Each Xlate appropriately pointing to the proper Message/Event type in their respective variants.
So the Sending System has a variant and the receiving system has a variant. Inside those variants are the respective Message/Event Types (HL/7).
Let’s say the variants are called sys1 and sys2.
Assuming 2 Message/Event Types (ADT^A01 and ADT^A08) there would be 2 Xlates.
The ADT^A01 Xlate would pint to sys1 variant IB and the sys2 variant OB each selecting the ADT^A01 Message/Event Type.
The same would be true for the ADT^A08.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
-
- You must be logged in to reply to this topic.
