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
ORC PV1
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)
...
| Code Block | ||
|---|---|---|
| ||
<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 <PT.2>C</PT.2>recommendation -->
</MSH.11>
<MSH.12>
<VID.1>2.5</VID.1>
<VID.2>
<CE.1>RWA</CE.1>/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)
| Code Block | ||
|---|---|---|
| ||
<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 --> 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
| Code Block | ||
|---|---|---|
| ||
<PV1></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
| Code Block | ||
|---|---|---|
| ||
<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 -
...
the following structure -
| Code Block |
|---|
<!-- 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 -
...
| Code Block | ||
|---|---|---|
| ||
<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>
<TS.1>20120627013717</TS.1></OBX.14>
</OBX.14>
</OBX>
|
Grahame's comments:
...
</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