Page Comparison

An ORU_R01 message is responsible for transmitting patient results.

...

However, not all of these segments are importaint.

Important segments areBased on Grahame Grieve's recommendation, important segments for our messages would be-
MSH
PID
PVI PV1
ORC
OBR
OBX, (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)

...

<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  <PT.2>C</PT.2>recommendation -->
        </MSH.11>
        <MSH.12>
            <VID.1>2.5</VID.1>
            <VID.2>
                <CE.1>RWA</CE.1>.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-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

...

...

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 -

...

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