...
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 --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 |
...
| 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>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>
|
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.3> <!-- PID.3 segmentsfields 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 segmentsfields 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
| Code Block | ||
|---|---|---|
| ||
<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>
|
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.
...
| Code Block |
|---|
<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</CE.3> </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"