ORU_R01 Specification for the hL7output Module

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>^~\&amp;</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 -

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 -

A sample OBX segment is as follows,

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