Does anyone know whether it is common to see values in the OBR segment not match the values from similar concepts in the ORC segment for laboratory diagnostic result HL7 ORU messages?
For example:
ORC.7.6 - Priority
OBR.27.6 - Priority
Can it be possible that the ORC shows "routine", but one of the OBR values underneath that shows "stat" for one of a few tests ordered? (So that parsing logic needs to look at OBR first, OCR second to be accurate?)
Similarly, can this same phenomenon happen with the ordering provider?
ORC.12 - Ordering Provider
OBR.16 - Ordering Provider
For example, if a physician orders a Hep B test that comes back as positive, and the lab's middleware has rules that order a reflux test for Surface B antigen or something else automatically, then the original ordering physician isn't who technically placed the reflux order, but the middleware rule. How is this usually expressed between the ORC.12 and OBR.16 segments corresponding to the ordering provider?
(Don't think it's relevant, but we're reading HL7 v2.5.1 ORU messages)
The ORC is Common Order Segment. The OBR is Observation Request Segment.
The data in those respective segments is related to that specific segment. It may or may not be same.
Related
I am processing HL7 message. OBX-4field gives containment hierarchy.I see different dotted hierarchy in the message.
is there any standard for containment hierarchy dotted number?
For below example. will first dotted 1 always mean MDC_DEV_MON_PHYSIO_MULTI_PARAM_MDS and 2nd dot 5-always mean MDC_DEV_ECG_VMD.
are these number configurable in the medical device.I want to store data uniquely based using MDS/VMD/CHAN.
Right now I am getting HL7 from one source..will these hierarchy will always be same for that source.
is this would be valid if i get hl7 message from other source.
MDC_DEV_MON_PHYSIO_MULTI_PARAM_MDS/MDC_DEV_ECG_VMD/MDC_ECG_HEART_RATE
to Acehive
1.5.0.1
1-MDC_DEV_MON_PHYSIO_MULTI_PARAM_MDS
5-MDC_DEV_ECG_VMD
13-MDC_DEV_METER_PRESS_BLD_VMD
1-MDC_DEV_METER_PRESS_BLD_CHAN
OBX|1||69965^MDC_DEV_MON_PHYSIO_MULTI_PARAM_MDS^MDC|1.0.0.0|||||||X
OBX|2||69798^MDC_DEV_ECG_VMD^MDC|1.5.0.0|||||||X
OBX|3|NM|147842^MDC_ECG_HEART_RATE^MDC|1.5.0.1|88|{beat}/min^{beat}/min^UCUM|||||R|||20200508051804.8340+0530||||DFG~01^^Y71A57FFFE6188F3^EUI-64
OBX|4|NM|148066^MDC_ECG_V_P_C_RATE^MDC|1.5.0.2|7|{beat}/min^{beat}/min^UCUM|||||R|||20200508051804.8340+0530||||DFG~01^^Y71A57FFFE6188F3^EUI-64
OBX|17||69854^MDC_DEV_METER_PRESS_BLD_VMD^MDC|1.13.0.0|||||||X
OBX|18||69855^MDC_DEV_METER_PRESS_BLD_CHAN^MDC|1.13.1.0|||||||X OBX|19|NM|150018^MDC_PRESS_BLD_DIA^MDC|1.13.1.15|68|mm[Hg]^mm[Hg]^UCUM|||||X|||20200508051804.8340+0530||||DFG~01^^Y71A57FFFE6188F3^EUI-64||unknow
This particular HL7 ORU example is a more strict protocol within the HL7 format. It is defined by IHE, and the message type of this example is PCD (Patient Care Device) You can start searching for details of this message format here: https://wiki.ihe.net/index.php/Patient_Care_Device
You'll need to consider things:
HL7 event type of the message, found in MSH.9
If you have the specs of HL7 v2, then you can check on what the segments are usually use and the hierarchy of it.
If you don't have the HL7 spec directly from HL7.org, you'll need to ask the client sending the HL7 message their own spec. Their spec will guide you on how they structured their message. What are repeating, required and optional fields.
HL7 is a loose standard, some organizations don't strictly implement directly what the HL7 spec has, instead they repurpose some of the segments and fields, so it's best to have the client's own HL7 spec. That means other sources of HL7 may have a different approach.
I usually use this link to check on the HL7 definitions: https://hl7-definition.caristix.com/v2/HL7v2.5.1
Based from my experience, OBX segments are repeating and are usually under the OBR segment as child nodes. OBX.2 is the index, which is odd in your message since I see index 4 is followed by index 17.
So far after exploration i understood that those dotted numbers are not standard.Below is IHE documents.
Probably it depends on the profile. which can be different at different point.
https://www.hl7.org/documentcenter/public/wg/healthcaredevices/N0262_WG7_RCH.1g.pdf
I marking it is as answer. I will change this if something better explanation comes.
I'm trying to parse an HL7 message file which is of version 2.3.1. OBX segment is coming as null when the message is parsed.
If I don't have OBR segment in HL7 message, Terser is failing to fetch the OBX segment values (it's returning null values), so is OBR segment mandatory to view OBX attachments in an HL7 message?
The OBX segment mainly carry clinical report data. It is mainly used in ORU message and rarely with ORM, ADT and other. This segment is optional and can be repeated in message.
The OBR segment mainly carry placer and filler order numbers (used as identifiers), exam information etc. This segment is mandatory.
ORU (Observation Result) messages should contain the OBR segment followed by the OBX segment for each observation.
About its usage in ORM message:
Usage in the ORM Message
In an ORM message, the OBR segment is part of an optional group that provides details about the order. When the order placer creates the ORM message, they will include the Placer Order Number in the OBR-2 and/or ORC-2 fields. These two fields should contain the same information, and at least one of the two must contain the placer order number. The message may contain multiple orders for which the rules still apply.
About its usage in ORU message:
Usage in the ORU Message
In an ORU message, the OBR segment is used as a report header and contains important information about the order being fulfilled (i.e. order number, request date/time, observation date/time, ordering provider, etc.). It is part of a group that can be used more than once for each observation result that is reported in the message.
When the filler creates the ORU message, they will include the Filler Order Number (such as an accession number) in the OBR-3 and/or ORC-3 fields. If the filler order number is not present in the ORC-3, it must be present in the OBR-3 because the ORC segment is optional in the ORU message.
Considering this, OBR is mandatory segment in both the ORU and ORM (optional group) messages. This is irrespective of dependency of OBX segment on OBR segment.
To answer your comment, I never used REF message. But, first google search gave me this. It look that OBR is mandatory in those messages.
While the OBR segment is stated as mandatory in the HL7 standards for most messages the parser software you are using may allow you to set it as optional.
Deciding to do this though should be considered only if there is a good reason why the sending system cannot or will not include the OBR segment in the message.
I know that the order of fields and components matter, but what about the order of segments in an HL7 message?
They all obviously have to have the MSH at the beginning, but is there anything in the HL7 guides that explicitly state that hl7 Segments must be in a particular order.
Certainly, the documentation lists segments in a certain order when describing a message type, but isn't that just the order it was written down? Do you need to have your messages in the same order (other than the grouped items)?
I would have thought that the PID-1 would be irrelevant if the order was set by the order in the message.
I'm keen to hear any opinions, but I would particularly like to hear from someone that can reference some documentation that specifies this.
Yes it does matter -
There is a specific requirement that a required segment be in between two identical segments.
From version 2.5.1 chapter 2:
A named segment X may occur more than once in an abstract message
syntax. This differs from repetition described earlier in this
section.
When this occurs, the following rules must be adhered to:
If, within an abstract message syntax, a named segment X appears in two
individual or group locations, and a) Either appearance is optional or
repeating in an individual location; b) or, either appearance is
optional or repeating, in a group location then, the occurrences of
segment X must be separated by at least one required segment of a
different name so that no ambiguity can exist as to the individual or
group location of any occurrence of segment X in a message instance.
A real world example of this is ROL segments in ADT^A02, one follows PD1, and one follows PV2, but PV1 is required in between the two.
If you're writing some kind of parser though, I would be wary of anyone actually respecting this rule.
Absolutely. The order of segments is defined in the HL7 standard.
For example (I'm using version 2.4 International) section 4.4.1 ORM ‑ general order message (event O01) regarding Order Entry shows the following as the structure of an ORM order message (formatting is not ideal)
ORM^O01^ORM_O01
MSH
[{NTE}]
[
PID
[PD1]
[{NTE}]
[
PV1
[PV2]]
[{IN1
[IN2]
[IN3]
}]
[GT1]
[{AL1}]
]
{
ORC
[
<OBR|RQD|RQ1| RXO|ODS|ODT>
[{NTE}]
[CTD]
[{DG1}]
[{
OBX
[{NTE}]
}]
]
[{FT1}]
[{CTI}]
[BLG]
}
The square brackets indicate possible repetitions, and the curly brackets that segments are optional (for example directly after the MSH you could have 0, 1 or n NTE segments.)
To be a valid ORM message, an OBR segment should come after an ORC segment that itself should come after a PID etc. An OBR segment is thus for example not allowed to be sent before a PID segment (see this as a layer structure, the Observation Request comes under an Order Common segment that itself is related to a Patient Visit that is specific to a Patient.)
The PID-1 field you mentioned is not a good example, as most messages will only have one PID segment, and PID-1 thus be 1. (I'm not aware of messages containing more than one PID segment, please add to the comments if anyone knows concrete examples from the HL7 specs). But if you look at for example OBR-1, there can be multiple Observervation Requests in the same Order message, for example an order for a Kalium and a Natrium, there would thus be a sequence number sent in OBR-1 to ensure data from the different orders are not mixed up, e.g.:
ORC|...
OBR|1|12345||KA^Kalium|...
OBR|2|12346||NA^Natrium|...
I've found several references to SAD/AD/XAD data types in the HL7 spec, but don't see anything about this info being used to describe facilities, such as those described in the AIL segment (e.g. "2^BLUE HILL FACILITY"). But where, if anywhere, can I expect to get data about that facility, such as name, street address, etc.?
In the PV1 segment definition for HL7 2.x there isn't a dedicated field for Facility Address specifically. If you are the receiving system in this case, you may have to request that data be sent or added in from the sending system. This could be as simple as placing it in the PV1-5.X field (X being whatever subfield the sending system decides on), or adding in a custom Z segment (ZPV for example) to have this data transmitted.
Since there is no standard field for this kind of data in the PV1 segment though, you will have to confirm that the sending system can in fact send this data.
The facility name will be in a separate field. It varies from segment to segment. You just have to read the segment definition and pick the right field.
Even though loops are kind of a logical concept in X12 (not directly physically represented in the text), every transaction set defines a set of loops that it can contain, including identifiers for the loops and an ordering for them. My question is, what is the rule for sorting loops, generically? Is there a concise set of rules that can be expressed in some code that should be able to take a collection of loops (with known identifiers such as 1000A, 2300BB, etc) and properly sort them?
The context of my question is that I'm working on a general-purpose library that applications will use to construct a model of an X12 document/transaction-set (and write out the text such a model represents). It has objects to represent Elements, Segments, and Loops. Ordering of Segments in a particular Loop is easy, they're dictated by the Implementation Guides. But I'm trying to get Loop ordering (within a Transaction Set) to work generically; that's what I'm asking about
It seems that the general rule is that Loops are ordered based on their identifiers using the numeric portion as the primary sort key, with the alpha portion as the secondary sort key. Of course hierarchical loops contained in others will be placed before and loops following the parent in that sort order (eg: 1000A, 2000A, 2010A, 2010B, 2100, 2300 - where 2010A and 2010B are children of 2000A).
I understand that the spec and Implementation Guides contain all of this info; I'm looking for the all-encompassing rule about loop ordering (not Segment ordering). Is there any concise way to express the rule algorithmically? Is there even a hard-and-fast rule at all?
As I mentioned in my comments, the standard has a loop value. Take a look at my screenshot of the Liaison Dictionary Viewer. The CLM segment has a LOOP value of 100. The segments underneath are children of the CLM segment (extended tag). Any "order" can be defined arbitrarily by the partner, or can be in any (undefined) order provided the data is qualified. But that loop can occur 100 times max and can have repeating segments inside the loop value.
The implementation guide will give you the correct order your partner wants them in. It seems like you're writing your own syntax validation engine though.