Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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.

Important segments are-
MSH
PID
PVI
ORC
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>C</PT.2>
        </MSH.11>
        <MSH.12>
            <VID.1>2.5</VID.1>
            <VID.2>
                <CE.1>RWA</CE.1>
            </VID.2>
        </MSH.12>
    </MSH>

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.3>     <!-- PID.3 segments 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 segments 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>

The PV1 segment

The PV1 Segment contains information on patient visits

<PV1>
                    <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>

Next come the ORC, OBR and OBX segments.
One ORU_R01 mesage can contain only a single ORC segment.
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 -

<ORC> <!-- One ORC segment per each ORU_R01 -->
<OBR> <!-- OBR for the obs grouping -- >
   <OBX> <!-- two obs which belong to the Obs group -->
   <OBR>

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>
                    </OBX.6>
                    <OBX.14>
                        <TS.1>20120627013717</TS.1>
                    </OBX.14>
                </OBX>
  • No labels