An ORU_R01 message is responsible for transmitting patient results.
In OpenMRS, A ORU_R01 message will model one or many encounters, each which may contain one or many Observations (results)
An ORu_r01 message may contain the following segments (Refer http://www.corepointhealth.com/resource-center/hl7-resources/hl7-oru-message)
SEGMENT/GROUP |
NAME |
OPTIONAL/REPEATABLE? |
MSH |
Message header Required |
|
ResultsGroup – Repeatable group, includes groups that follow (unless otherwise noted): |
|
|
PatientGroup – Optional group |
|
|
PID |
Patient identification |
Required |
PID1 |
Patient demographics |
Optional |
NTE |
Notes and comments |
Optional, Repeatable |
PatientVisitGroup – Optional group, part of PatientGroup |
|
|
PV1 |
Patient visit |
Required |
PV2 |
Patient visit – additional info |
Optional |
OrderGroup – Repeatable group |
|
|
ORC |
Common order |
Optional |
OBR |
Observation request |
Required |
NTE-1 |
Notes and comments |
Optional, Repeatable |
ObservationGroup --Repeatable group, part of OrderGroup |
|
|
OBX |
Observation Optional |
|
NTE-2 |
Notes and comments |
Optional, Repeatable |
OrderGroup continued |
|
|
CTI |
Clinical trial identification |
Optional, Repeatable |
Additional segment, not part of a group: |
|
|
DSC |
Continuation pointer segment |
Optional |
However, not all of these segments are importaint.
Based on Grahame Grieve's recommendation, important segments for our messages would be-
MSH
PID
PV1
OBR, (OBX)* )*
The MSH segment
The MSH Segment transmits the message’s source, purpose, destination, and certain syntax specifics.
It does not contain any patient centric data.
For a more detailed description, see here (http://www.corepointhealth.com/resource-center/hl7-resources/hl7-msh-message-header)
A sample MSH segment may look as follows :
<MSH>
<MSH.1>|</MSH.1>
<MSH.2>^~\&</MSH.2>
<MSH.3>
Sending Application
</MSH.3>
<MSH.4>
<HD.1>Sending Facility</HD.1>
</MSH.4>
<MSH.5>
Receiving Application
</MSH.5>
<MSH.6>
<HD.1>Receiving Facility</HD.1>
</MSH.6>
<MSH.7>
<TS.1>Date/Time of Message</TS.1>
</MSH.7>
<MSH.9>
<MSG.1>ORU</MSG.1>
<MSG.2>R01</MSG.2>
<MSG.3>ORU_R01</MSG.3>
</MSH.9>
<MSH.10>Message Control Id</MSH.10>
<MSH.11>
<PT.1>D</PT.1>
<PT.2></PT.2> <!-- original value 'C' removed based on Grahame's recommendation -->
</MSH.11>
<MSH.12>
<VID.1>2.5</VID.1>
<VID.2>
<CE.1>RWA</CE.1>
<CE.2>HL70399</CE.2> <!-- Added on Grahame's recommendation -->
</VID.2>
</MSH.12>
</MSH>
Comments from Grahame Grieve:
- MSH.11.2: "C" is not valid - "T" would be valid but it's more usual to leave it blank
- MSH.11.1: "D" for debugging - sure?
- MSH.12.2: CE.2 should have value HL70399 in this case.
- It's hard to tell which are fixed values, and which are meant to vary. it would be easy to miss that RWA is Rwanda
The PID Segment
The PID (patient identification) segment contains a host of patient information such as patient ID number, patient sex, address, marital status and citizenship.
For a more detailed description, see here (http://www.corepointhealth.com/resource-center/hl7-resources/hl7-pid-segment)
<PID>
<PID.1>1</PID.1> <!-- Added on Grahame's recommendation -->
<PID.3> <!-- PID.3 fields can be repeated. They represent patient identifier and identifier type pairs -->
<CX.1>1234</CX.1>
<CX.5>ECID</CX.5>
</PID.3>
<PID.3>
<CX.1>1235</CX.1>
<CX.5>PID</CX.5>
</PID.3>
<PID.5> <!-- PID.5 fields can be repeated. They represent patient names. Since each patient can have many names, each PID.5 segment can contain one of these -->
<XPN.1>
<FN.1>Patient</FN.1>
</XPN.1>
<XPN.2>John</XPN.2>
</PID.5>
<!-- PID.6 Date of birth -->
<!-- PID.7 Patients sex -->
<!-- PID.11 Patient address -->
</PID>
Grahame's comments:
- The two provided codes for CX.5 are not legal
- it's usual, and good, when repeating PID.5, to provide codes so that receiving systems can figure out why more than one name is provided, and which to use for a particular purpose
- PID-1 value should be "1" (it's not actually required, but it's good practice)
- Address - there's more to say about this?
The PV1 segment
The PV1 Segment contains information on patient visits
<PV1>
<PID.1>1</PID.1> <!-- Added on Grahame's recomendation -->
<PV1.2>0</PV1.2>
<PV1.3>
<PL.1>1</PL.1>
<PL.4>
<HD.1>Unknown Location</HD.1>
</PL.4>
</PV1.3>
<PV1.4>ADULTINITIAL</PV1.4>
<PV1.7>
<XCN.1>2</XCN.1>
<XCN.2>
<FN.1>Hornblower</FN.1>
</XCN.2>
<XCN.3>Horatio</XCN.3>
</PV1.7>
<PV1.44>
<TS.1>201206270137</TS.1>
</PV1.44>
</PV1>
Grahame's comments:
- PV1-1 - also good to have the value "1"
- PV1-2 - "0" is not a valid value. I/E/O are the common values for inpatient/outpatient/emergency, thought the notion of emergency as distinct to inpatient is variable around the world
- PV1-3 - that's weird. location is "1", which is unknown? still, it's valid, but the PV1-3-4 HD feels wrong shouldn't this be PV1-9?
Next come the ORC, OBR and OBX segments.
One ORU_R01 mesage can contain only a single ORC segment. (Grahame, umm, no, not according to HL7)
An OBX segment represents a single Observation.
OBR segments can be used to group observations.
Therefore, an ORU_R01 message which contains an encounter with two grouped observations can be represented with the following structure -
<!-- Updated Structure --> <ORC> <!-- One ORC segment per each ORU_R01 --> <OBR> <!-- OBR for the obs grouping -- > <OBX> <!-- two obs which belong to the Obs group --> <OBR>
Grahame - no, OBR cannot contain an OBR. technically, this structure and the next one are valid, but that's because an OBR doesn't have to have an OBX after it. The structures are misleading because the interpretation is wrong - there should only be two OBRs in the next example
An Encounter with two pairs of Observation groupings can be represented as follows -
<ORC> <OBR> <OBX> <OBR> <OBR> <OBX> <OBR>
A sample OBX segment is as follows,
<OBX>
<OBX.1>6</OBX.1>
<OBX.2>NM</OBX.2>
<OBX.3>
<CE.1>1234</CE.1>
<CE.2>NEUTROPHILS</CE.2>
<CE.3>LOCAL</CE.3>
</OBX.3>
<OBX.5>45.0</OBX.5>
<OBX.6>
<CE.1>%</CE.1>
<CE.3>UCUM</CE.3> <!-- Updated value -->
</OBX.6>
<OBX.14>
<TS.1>20120627013717</TS.1>
</OBX.14>
</OBX>
Grahame's comments:
- OBX-3-5 should be "L" not "local"
- OBX-6-3 should be "UCUM" not "ucum"
Suranga's comments:
- In this case, 'LOCAL' and 'ucum' are both user inputs. 'ucum' is the 'unit' entered when creating an Observation, while 'LOCAL' is the concept mapping name
the ID {belongs to. These values will depend sorely on what the user inputs when creating an Obs