This page contains definitions for the Smile CDR HL7 v2.x segments.
Seq / Field | Opt | Card | DT | Len | Table | Description | Sample | |
---|---|---|---|---|---|---|---|---|
MSH-1 | R | 1..1 | ST | 1 | Field Separator | | | ||
MSH-2 | R | 1..1 | ST | 4 | Encoding Characters | ^~\& | ||
MSH-3 | O | 0..1 | HD | Sending Application | ACME | |||
MSH-4 | O | 0..1 | HD | Sending System | ACME FACILITY | |||
MSH-5 | O | 0..1 | HD | Receiving Application | Smile CDR | |||
MSH-6 | O | 0..1 | HD | Receiving System | FOO FACILITY | |||
MSH-9 | R | 1..1 | MSG | 15 | Message Type | ADT^A01^ADT_A01^ADT_A01 | ||
MSH-10 | R | 1..1 | ST | 50 | Control ID | 00001 | ||
MSH-12 | R | 1..1 | VID | Version ID | 2.5 |
For an outbound message being generated by Smile CDR, this field can be sourced from MessageHeader.source.name
. See Using Persisted MessageHeader Resources for more information.
For an inbound message being consumed by Smile CDR, this field will be placed in MessageHeader.sender.identifier
.
For an outbound message being generated by Smile CDR, this field can be sourced from MessageHeader.sender.identifier
. See Using Persisted MessageHeader Resources for more information.
For an outbound message being generated by Smile CDR, this field can be sourced from MessageHeader.destination.name
. See Using Persisted MessageHeader Resources for more information.
For an outbound message being generated by Smile CDR, this field can be sourced from MessageHeader.receiver.identifier
. See Using Persisted MessageHeader Resources for more information.
The message control ID will be used to track the progress of a message through the system, and should be unique per message. It does not need to be unique between systems.
When processing inbound HL7 v2.x messages, if Create MessageHeader for Each Message is enabled, the MSH-10 Control ID value will be placed in the MessageHeader resource in an extension with the following URL: https://smilecdr.com/fhir/ns/StructureDefinition/messageheader-source-message-id
Seq / Field | Opt | Card | DT | Len | Table | Description | Sample | |
---|---|---|---|---|---|---|---|---|
PID-3 | R | 1..* | CX | Patient Business Identifier List | 7000135^^^http://acme.org/mrns^MR | |||
PID-3.1 | R | ST | 200 | Identifier Value | 7000135 | |||
PID-3.4 | R | HD | 200 | Identifier System | http://acme.org/mrns | |||
PID-3.5 | R | ID | 200 | 0203 | Identifier Type | MR | ||
PID-5 | O | 0..* | XPN | Patient Name List | Smith^John^Q^^^^L | |||
PID-5.1.1 | O | ST | Family Name | |||||
PID-5.2 | O | ST | Given Name | |||||
PID-5.3 | O | ST | Middle Name | |||||
PID-5.4 | O | ST | Suffix | |||||
PID-5.5 | O | ST | Prefix | |||||
PID-5.6 | O | ST | Degree | |||||
PID-5.7 | O | ID | 0200 | Name Type | L (official) | |||
PID-6 | O | 0..* | XPN | Mother's Maiden Name | Smythe^Jane^K^^^^ | |||
PID-6.1.1 | O | ST | Family Name | |||||
PID-6.2 | O | ST | Given Name | |||||
PID-6.3 | O | ST | Middle Name | |||||
PID-6.4 | O | ST | Suffix | |||||
PID-6.5 | O | ST | Prefix | |||||
PID-6.6 | O | ST | Degree | |||||
PID-6.7 | O | ID | 0200 | Name Type | D (usual) | |||
PID-7 | O | 0..1 | TS | DateTime of Birth | ||||
PID-8 | O | 0..1 | ID | 0001 | Administrative Sex | M (male) | ||
PID-9 | O | 0..* | XPN | Patient Alias List | Smith^John^Q^^^^L | |||
PID-9.1.1 | O | ST | Family Name | |||||
PID-9.2 | O | ST | Given Name | |||||
PID-9.3 | O | ST | Middle Name | |||||
PID-9.4 | O | ST | Suffix | |||||
PID-9.5 | O | ST | Prefix | |||||
PID-9.6 | O | ST | Degree | |||||
PID-9.7 | O | ID | 0200 | Name Type | L (official) | |||
PID-10 | O | 0..* | CE | Race | See description below | |||
PID-10.1 | O | ST | Code | |||||
PID-10.2 | O | ST | Display | |||||
PID-10.3 | O | ID | System | |||||
PID-11 | O | 0..* | XAD | Patient Address List | 342 Evergreen Terrace^^Springfield^NI^00000^USA^H | |||
PID-11.1.1 | O | ST | Street Address | |||||
PID-11.2 | O | ST | Street Address (Line 2) | |||||
PID-11.3 | O | ST | City | |||||
PID-11.4 | O | ST | State/Province | |||||
PID-11.5 | O | ST | Zip/Postal Code | |||||
PID-11.6 | O | ST | Country | |||||
PID-11.7 | O | ID | 0190 | Address Type | ||||
PID-11.9 | O | IS | County/Parish Code | |||||
PID-13 | O | 0..* | XTN | Phone/Telecom List - Home | 1(305)555-1212^PRN^PH | |||
PID-13.1 | O | ST | Telephone Number / email / etc | |||||
PID-13.2 | O | ID | 0201 | Telecom Use | ||||
PID-13.3 | O | ID | 0202 | Equipment Type | ||||
PID-14 | O | 0..* | XTN | Phone/Telecom List - Work | 1(305)555-1212^WPN^PH | |||
PID-14.1 | O | ST | Telephone Number / email / etc | |||||
PID-14.2 | O | ID | 0201 | Telecom Use | ||||
PID-14.3 | O | ID | 0202 | Equipment Type | ||||
PID-15 | O | 0..1 | CE | Primary Language | ENG^English^http://acme.org/primarylanguage | |||
PID-15.1 | O | ST | Identifier | |||||
PID-15.2 | O | ST | Display | |||||
PID-15.3 | O | ID | System | |||||
PID-16 | O | 0..1 | CE | Marital Status | L^Legally Separated^http://acme.org/maritalstatus | |||
PID-16.1 | O | ST | 0002 | Identifier | ||||
PID-16.2 | O | ST | Display | |||||
PID-16.3 | O | ID | System | |||||
PID-17 | O | 0..1 | CE | Religion | AGN^Agnostic^http://acme.org/religion | |||
PID-17.1 | O | ST | Code | |||||
PID-17.2 | O | ST | Display | |||||
PID-17.3 | O | ID | System | |||||
PID-18 | O | 0..1 | CX | Patient Account Number | 7000135^^^http://acme.org/patientAccountNumbers^AN | |||
PID-18.1 | O | ST | 200 | Identifier Value | 7000135 | |||
PID-18.4.1 | O | ST | 200 | Identifier System | http://acme.org/patientAccountNumbers | |||
PID-18.5 | O | ID | 200 | 0203 | Identifier Type | AN | ||
PID-19 | O | 0..1 | ST | Social Security Number | 000-11-2222 | |||
PID-22 | O | 0..* | CE | Ethnic Group | 2^Hispanic of Latino^http://acme.org/ethnicgroup | |||
PID-22.1 | O | ST | Code | |||||
PID-22.2 | O | ST | Display | |||||
PID-22.3 | O | ID | System | |||||
PID-27 | O | 0..* | CE | Veterans Military Status | N^Not a Veteran^http://acme.org/vetstatus | |||
PID-27.1 | O | ST | Code | |||||
PID-27.2 | O | ST | Display | |||||
PID-27.3 | O | ID | System | |||||
PID-28 | O | 0..* | CE | Nationality | 1^Canadian^http://acme.org/nationality | |||
PID-28.1 | O | ST | Code | |||||
PID-28.2 | O | ST | Display | |||||
PID-28.3 | O | ID | System | |||||
PID-29 | O | 0..1 | TS | Patient Death Timestamp | 20110422113332-0400 | |||
PID-30 | O | 0..1 | ID | 0136 | Patient Death Indicator | N |
Patients are required to have at least one repetition of PID-3
, and the first repetition must have an identifier type code (PID-3.5
) of MR
. This will be used as the primary business identifier upon which other processing decisions will be made.
Patients may have an unlimited number of other identifiers as well.
Identifiers in this field must be globally unique, and must never be reused.
PID-5.3
(Middle Name) may contain multiple space-separated names. Each name will be separated into an individual repetition of the FHIR Patient.name.given
.
Repetitions of this field are mapped to mothersMaidenName extensions on the Patient.
PID-6.3
(Middle Name) may contain multiple space-separated names. Each name will be separated into an individual repetition of the FHIR extension('http://hl7.org/fhir/StructureDefinition/patient-mothersMaidenName').valueHumanName.given.
PID-10
contains a coded race. While this field has a location in the HL7 v2.x specification, there is no equivalent element in the FHIR specification.
Race is therefore mapped to an extension in the Patient resource. There is not currently a standard extension in the FHIR specification for this concept, although the US Core Implementation Guide does define such an extension (reference).
As such, the PID-10
field is overloaded to provide both the race code, code system, and display name, but also the extension URL used to store this element.
The following is a sample value for this field. Note that for readability, repetitions of the field are shown on separate lines. In a real message these would be joined within the field.
2054-5^Black or African American^urn:oid:2.16.840.1.113883.6.238^^^^http://hl7.org/fhir/us/core/StructureDefinition/us-core-race^ombCategory~
2056-0^Black^urn:oid:2.16.840.1.113883.6.238^^^^http://hl7.org/fhir/us/core/StructureDefinition/us-core-race^detailed
The format for this field is as follows:
The following is an example of the corresponding extension:
"extension": [
{
"url": "http://hl7.org/fhir/us/core/StructureDefinition/us-core-race",
"extension": [
{
"url": "ombCategory",
"valueCoding": {
"system": "urn:oid:2.16.840.1.113883.6.238",
"code": "2054-5",
"display": "Black or African American"
}
},
{
"url": "detailed",
"valueCoding": {
"system": "urn:oid:2.16.840.1.113883.6.238",
"code": "2056-0",
"display": "Black"
}
}
]
}
]
Note that when converting FHIR to HL7 v2.x, if the race extension has only one child (i.e. a category but not a detailed value, or vice-versa), CE.7 and CE.8 will not be populated in the generated PID segment in order to avoid clutter which can be confusing to HL7 v2.x systems.
PID-13.2
(Telecom Use) will be assumed to be PRN
(Home) if not present.
PID-14.2
(Telecom Use) will be assumed to be PRN
(Work) if not present.
Note that this field is not currently populated for outbound interfaces.
Patient Account Number is mapped to a contained Account resource on the Encounter.
PID-22
contains a coded ethnicity. While this field has a location in the HL7 v2.x specification, there is no equivalent element in the FHIR specification.
Ethnicity is therefore mapped to an extension in the Patient resource. There is not currently a standard extension in the FHIR specification for this concept, although the US Core Implementation Guide does define such an extension (reference).
As such, the PID-22
field is overloaded to provide both the ethnicity code, code system, and display name, but also the extension URL used to store this element.
The following is a sample value for this field. Note that for readability, repetitions of the field are shown on separate lines. In a real message these would be joined within the field.
2135-2^Hispanic or Latino^urn:oid:2.16.840.1.113883.6.238^^^^http://hl7.org/fhir/us/core/StructureDefinition/us-core-race^ombCategory~
2148-5^Mexican^urn:oid:2.16.840.1.113883.6.238^^^^http://hl7.org/fhir/us/core/StructureDefinition/us-core-race^detailed
The format for this field is as follows:
The following is an example of the corresponding extension:
"extension": [
{
"url": "http://hl7.org/fhir/us/core/StructureDefinition/us-core-ethnicity",
"extension": [
{
"url": "ombCategory",
"valueCoding": {
"system": "urn:oid:2.16.840.1.113883.6.238",
"code": "2135-2",
"display": "Hispanic or Latino"
}
},
{
"url": "detailed",
"valueCoding": {
"system": "urn:oid:2.16.840.1.113883.6.238",
"code": "2148-5",
"display": "Mexican"
}
}
]
}
]
Note that when converting FHIR to HL7 v2.x, if the ethnicity extension has only one child (i.e. a category but not a detailed value, or vice-versa), CE.7 and CE.8 will not be populated in the generated PID segment in order to avoid clutter which can be confusing to HL7 v2.x systems.
Note that this field is not currently populated for outbound interfaces.
Note that this field is not currently populated for outbound interfaces.
The following CE fields (Coded Elements) are converted into FHIR-equivalent extensions with optional nested extensions:
Please note: A given CE field will only be converted if all three of the following are populated:
Identifier
in first component CE.1
;Name of Coding System
in third component CE.3
; andExtension URL
in first extra component CE.7
.Optionally, the following may be included:
Text
in second component CE.2
; and/orNested Extension URL
in second extra component CE.8
.A new extension is created for each CE field.
A Mapper Bean Type can be implemented to ensure these components are appropriately populated for an incoming HL7 v2.x feed prior to converting its messages to FHIR.
Seq / Field | Opt | Card | DT | Len | Table | Description | Sample | |
---|---|---|---|---|---|---|---|---|
PV1-2 | O | 0..1 | IS | 0004 | Patient Class | E (Emergency) | ||
PV1-3 | O | 0..1 | PL | Assigned Patient Location | ||||
PV1-3.1 | C | IS | Ward | |||||
PV1-3.2 | C | IS | Room | |||||
PV1-3.3 | C | IS | Bed | |||||
PV1-3.4.1 | C | ST | Facility Identifier Value | |||||
PV1-3.9 | O | ST | Location/Ward Description | |||||
PV1-3.10.1 | O | ST | Location/Ward Identifier Value | |||||
PV1-3.10.2 | O | ST | Location/Ward Identifier System | |||||
PV1-3.11.1 | O | ST | Assigning Authority for Location | |||||
PV1-3.12 | O | ST | Facility Identifier System | |||||
PV1-3.13 | O | ST | Room Description | |||||
PV1-3.14 | O | ST | Room Identifier Value | |||||
PV1-3.15 | O | ST | Room Identifier System | |||||
PV1-3.16 | O | ST | Bed Description | |||||
PV1-3.17 | O | ST | Bed Identifier Value | |||||
PV1-3.18 | O | ST | Bed Identifier System | |||||
PV1-6 | O | 0..1 | PL | Prior Patient Location | ||||
PV1-6.1 | C | IS | Ward | |||||
PV1-6.2 | C | IS | Room | |||||
PV1-6.3 | C | IS | Bed | |||||
PV1-6.4.1 | C | ST | Facility Identifier Value | |||||
PV1-6.9 | O | ST | Location/Ward Description | |||||
PV1-6.10.1 | O | ST | Location/Ward Identifier Value | |||||
PV1-6.10.2 | O | ST | Location/Ward Identifier System | |||||
PV1-6.11.1 | O | ST | Assigning Authority for Location | |||||
PV1-6.12 | O | ST | Facility Identifier System | |||||
PV1-6.13 | O | ST | Room Description | |||||
PV1-6.14 | O | ST | Room Identifier Value | |||||
PV1-6.15 | O | ST | Room Identifier System | |||||
PV1-6.16 | O | ST | Bed Description | |||||
PV1-6.17 | O | ST | Bed Identifier Value | |||||
PV1-6.18 | O | ST | Bed Identifier System | |||||
PV1-14 | O | 0..1 | IS | Admit Source | ||||
PV1-19 | R | 1..1 | CX | Encounter Business Identifier | 7000135^^^http://acme.org/visitNumbers^VN | |||
PV1-19.1 | R | ST | 200 | Identifier Value | 7000135 | |||
PV1-19.4.1 | R | ST | 200 | Identifier System | http://acme.org/visitNumbers | |||
PV1-19.5 | R | ID | 200 | 0203 | Identifier Type | VN | ||
PV1-36 | O | 0..1 | IS | Discharge Disposition | ||||
PV1-39 | O | 0..1 | IS | Servicing Facility | ||||
PV1-44 | O | 0..1 | TS | Start Time | 201608161155-0400 | |||
PV1-45 | O | 0..1 | TS | End Time | 201608161155-0400 |
By default, we treat each of PL.1
, PL.2
, and PL.3
as distinct locations (e.g. ward, room, bed). Traditionally, sending systems will populate each of these components with a name for the respective level of the hierarchy (ward -> room -> bed).
When converting to FHIR it is desirable for each location to be treated as a distinct Location resource. This is a challenge as the PL datatype does not have a spot to hold three separate identifiers.
There are several strategies that can be used when supplying location information in HL7 v2.x messages.
If PL.10.1
/PL.10.2
, PL.14
/PL.15
, PL.17
/PL.18
, and PL.11.1
are not populated, Locations will be created but they will be created as contained resources.
Component | Mapping | Usage |
---|---|---|
PL.1 | Location.name | Ward Name |
PL.2 | Location.name | Room Name |
PL.3 | Location.name | Bed Name |
Example:
The following example shows PV1-3
(other fields have been omitted for clarity) with a 3-level hierarchy and no identifiers. This will result in three distinct contained Location resources (i.e. one ward, one room, and one bed).
PV1|||Acme Hospital^3rd Floor Room 124^Bed 13||||
The PL.10.1
/PL.10.2
, PL.14
/PL.15
, and PL.17
/PL.18
component pairs may be used to store location identifiers. If these pairs of components are populated, Location resources will be created as standalone (non-contained) resources, using the identifiers provided as the resource primary identifiers.
Note that this approach takes advantage of extra components, meaning that it uses non-standard components that are added to the end of the regular components. PL typically only has 11 components but here we extend it to have 18 components (i.e. 7 extra components).
Component | Mapping | Usage |
---|---|---|
PL.1 | Location.name | Ward Name |
PL.2 | Location.name | Room Name |
PL.3 | Location.name | Bed Name |
PL.4.1 | Location.managingOrganization | Facility Identifier Value |
PL.9 | Location.description | Location/Ward Description |
PL.10.1 | Location.identifier.value | Location/Ward Identifier Value |
PL.10.2 | Location.identifier.system | Location/Ward Identifier System |
PL.11.1 | Location.identifier.system | Assigning Authority for Location |
PL.12 | Location.managingOrganization | Facility Identifier System |
PL.13 | Location.description | Room Description |
PL.14 | Location.identifier.system | Room Identifier Value |
PL.15 | Location.identifier.value | Room Identifier System |
PL.16 | Location.description | Bed Description |
PL.17 | Location.identifier.system | Bed Identifier Value |
PL.18 | Location.identifier.value | Bed Identifier System |
Example:
The following example shows PV1-3
(other fields have been omitted for clarity) with a 3-level hierarchy and identifiers stored in PL.10
. This will result in three distinct standalone Location resources (i.e. one ward, one room, and one bed), each with their own identifiers.
PV1|||Acme Hospital^3rd Floor Room 124^Bed 13^^^^^^^acme&https://acme.org/sites^^^^3fl124^https://acme.org/rooms^^3fl124b13^https://acme.org/beds||||
The PL.11.1
sub-component may be used to provide an identifier system. In this case, standalone Location resources will be created. These resources will have a primary identifier where:
PL.11.1
PL.1
, PL.2
, or PL.3
This technique is simpler than the previous technique, but it comes with an important caveat: Location names (PL.1
, PL.2
, and PL.3
) must be unique across the entire system. For example, if a bed is named "Bed 13" this is not likely to be sufficiently unique since there may be multiple locations with this same name.
Component | Mapping | Usage |
---|---|---|
PL.1 | Location.name Location.identifier.value | Ward Name Ward Identifier Value |
PL.2 | Location.name Location.identifier.value | Room Name Room Identifier Value |
PL.3 | Location.name Location.identifier.value | Bed Name Bed Identifier Value |
PL.11.1 | Location.identifier.system | Ward Identifier System Room Identifier System Bed Identifier System |
Example:
The following example shows PV1-3
(other fields have been omitted for clarity) with a 3-level hierarchy and an identifier system stored in PL.11.1
. This will result in three distinct standalone Location resources (i.e. one ward, one room, and one bed), each with their own identifiers. The identifier system for each of these locations will be the same.
PV1|||Acme Hospital^3rd Floor Room 124^3rd Floor Room 124 Bed 13^^^^^^^^https://acme.org/location||||
PV1-3
can potentially result in as many as three different related Location resources: one for the ward; one for the room; and one for the bed. This is accomplished using various extra components.
If PV1-3.1
is populated, the following will occur:
PL.1
will be stored in Location.name
.Location.type
will indicate a hospital unit.Location.physicalType
will indicate a ward.PL.9
will be stored in Location.description
.PL.10.1
and PL.10.2
are populated, they will be stored in Location.identifier.value
and Location.identifier.system
, and the Location resource will be persisted as a distinct top-level resource. If no identifier is present, the Location will be added as a contained resource on the Encounter.If PV1-3.2
is populated, the following will occur:
PL.2
will be stored in Location.name
.Location.physicalType
will indicate a room.PL.13
will be stored in Location.description
.PL.14
and PL.15
are populated, they will be stored in Location.identifier.value
and Location.identifier.system
, and the Location resource will be persisted as a distinct top-level resource. If no identifier is present, the Location will be added as a contained resource on the Encounter.Location.partOf
will reference the Location resource associated with PL.1
(Ward).If PV1-3.3
is populated, the following will occur:
PL.3
will be stored in Location.name
.Location.physicalType
will indicate a bed.PL.16
will be stored in Location.description
.PL.17
and PL.18
are populated, they will be stored in Location.identifier.value
and Location.identifier.system
, and the Location resource will be persisted as a distinct top-level resource. If no identifier is present, the Location will be added as a contained resource on the Encounter.Location.partOf
will reference the Location resource associated with PL.2
(Room).If both PL.4.1
and PL.12
are populated, they will constitute Organization.identifier.value
and Organization.identifier.system
respectively for the Organization to be referenced in Location.managingOrganization
.
PV1-6
is processed similarly to PV1-3
with one addition:
Encounter.location.status
will indicate a status of completed
.Alternatively, we may treat all of PL.1
, PL.2
, and PL.3
as a single atomic location (e.g. ward-room-bed). Processing the PL in this way will result in a single Location resource. This occurs when the hl7v2_fhir_mapper_pv1.treat_pv1_3_and_6_patient_locations_as_atomic property is enabled.
Location.physicalType
will be set in light of the specificity provided (i.e. when PL.3
is populated, Location.physicalType
will be set to bd
for bed whereas if PL.3
isn't populated but a value exists for PL.2
then Location.physicalType
will be set to ro
for room, and so on).
Where no suitable identifier is provided, a given Location is contained on the Encounter; otherwise this processing will result in a discrete Location resource.
PV1-3
will result in a single atomic Location resource.
If PV1-3.3
is populated, the following will occur:
PL.3
will be stored in Location.name
.Location.physicalType
will indicate a bed.PL.9
will be stored in Location.description
.PL.10.1
and PL.10.2
are populated, they will be stored in Location.identifier.value
and Location.identifier.system
, and the Location resource will be persisted as a distinct top-level resource. If no identifier is present, the Location will be added as a contained resource on the Encounter.Otherwise if PV1-3.2
is populated, the following will occur:
PL.2
will be stored in Location.name
.Location.physicalType
will indicate a room.PL.9
will be stored in Location.description
.PL.10.1
and PL.10.2
are populated, they will be stored in Location.identifier.value
and Location.identifier.system
, and the Location resource will be persisted as a distinct top-level resource. If no identifier is present, the Location will be added as a contained resource on the Encounter.Otherwise if PV1-3.1
is populated, the following will occur:
PL.1
will be stored in Location.name
.Location.type
will indicate a hospital unit.Location.physicalType
will indicate a ward.PL.9
will be stored in Location.description
.PL.10.1
and PL.10.2
are populated, they will be stored in Location.identifier.value
and Location.identifier.system
, and the Location resource will be persisted as a distinct top-level resource. If no identifier is present, the Location will be added as a contained resource on the Encounter.If both PL.4.1
and PL.12
are populated, they will constitute Organization.identifier.value
and Organization.identifier.system
respectively for the Organization to be referenced in Location.managingOrganization
.
PV1-6
is processed similarly to PV1-3
with one addition:
Encounter.location.status
will indicate a status of completed
.This field maps to Encounter.hospitalization.admitSource
. If only a single component is provided, its value will be stored in Encounter.hospitalization.admitSource.text
.
This field can also be overloaded such that its value will be treated as a coded value. If both a code is provided in PV1-14.1
and a code system is provided in PV1-14.3
then these values will be stored in Encounter.hospitalization.admitSource.coding
. Optionally, PV1-14.2
may be populated to provide a display name.
The format for this overloaded field is as follows:
This field maps to Encounter.hospitalization.dischargeDisposition
. If only a single component is provided, its value will be stored in Encounter.hospitalization.dischargeDisposition.text
.
This field can also be overloaded such that its value will be treated as a coded value. If both a code is provided in PV1-36.1
and a code system is provided in PV1-36.3
then these values will be stored in Encounter.hospitalization.dischargeDisposition.coding
. Optionally, PV1-36.2
may be populated to provide a display name.
The format for this overloaded field is as follows:
This field must contain an identifier that is used as the primary business identifier for the visit/encounter.
Identifiers in this field must be globally unique, and must never be reused.
This field can be overloaded such that if both PV1-39.1
and PV1-39.2
are populated, they will constitute Organization.identifier.value
and Organization.identifier.system
respectively for the Organization to be referenced in Encounter.serviceProvider
.
Seq / Field | Opt | Card | DT | Len | Table | Description | Sample | |
---|---|---|---|---|---|---|---|---|
ROL-3 | C | 0..1 | CE | Role | ADM^http://hl7.org/fhir/v3/ParticipationType^admitter | |||
ROL-3.1 | R | 1..1 | ST | Role Code | ||||
ROL-3.2 | O | 0..1 | ST | Role Code Display | ||||
ROL-3.3 | R | 1..1 | ID | Role Code System | ||||
ROL-4 | R | 1..1 | XCN | Role Person | ||||
ROL-4.1 | C | ST | Identifier Value | |||||
ROL-4.2.1 | C | ST | Family Name | |||||
ROL-4.3 | C | ST | Given Name | |||||
ROL-4.4 | O | ST | Middle Name | |||||
ROL-4.5 | O | ST | Suffix | |||||
ROL-4.6 | O | ST | Prefix | |||||
ROL-4.7 | O | ST | Degree | |||||
ROL-4.9.1 | C | IS | Identifier System | |||||
ROL-11 | O | 0..* | XAD | Address List | 342 Evergreen Terrace^^Springfield^NI^00000^USA^H | |||
ROL-11.1.1 | O | ST | Street Address | |||||
ROL-11.2 | O | ST | Street Address (Line 2) | |||||
ROL-11.3 | O | ST | City | |||||
ROL-11.4 | O | ST | State/Province | |||||
ROL-11.5 | O | ST | Zip/Postal Code | |||||
ROL-11.6 | O | ST | Country | |||||
ROL-11.7 | O | ID | 0190 | Address Type | ||||
ROL-12 | O | 0..* | XTN | Phone/Telecom List | 1(305)555-1212^WPN^PH | |||
ROL-12.1 | O | ST | Telephone Number / email / etc | |||||
ROL-12.2 | O | ID | 0201 | Telecom Use | ||||
ROL-12.3 | O | ID | 0202 | Equipment Type |
This field is required when mapping a role associated with an encounter but is ignored when mapping a role associated with a patient.
This field will be mapped directly to the Encounter.participant.type
, which uses an extensible binding. You may use your own codes but it is recommended to use codes drawn from the FHIR Encounter Participant Type ValueSet.
This field must contain at least ((ROL-4.1
and ROL-4.9.1
) or (ROL-4.2.1
and ROL-4.3
)). In other words, the role must contain at least an identifier or a name, although it is better if both are present.
If an identifier is present, the role will be mapped to a standalone Practitioner resource. If only a name is present, the role will be mapped to a contained resource instead.
ROL-12.2
(Telecom Use) will be assumed to be WPN
(Work) if not present.
Seq / Field | Opt | Card | DT | Len | Table | Description | Sample | |
---|---|---|---|---|---|---|---|---|
DG1-3 | R | 1..1 | CE | Diagnosis Code | 425363002^Smiling^http://snomed.info/sct | |||
DG1-3.1 | R | ST | Code | |||||
DG1-3.2 | O | ST | Display | |||||
DG1-3.3 | R | ID | System | |||||
DG1-4 | O | 0..1 | ST | Diagnosis Description | ||||
DG1-5 | O | 0..1 | TS | Diagnosis Date/Time | 200101010700-0400 | |||
DG1-6 | O | 0..1 | CWE | 0052 | Diagnosis Type | F | ||
DG1-15 | O | 0..1 | ID | Diagnosis Priority | 1 | |||
DG1-16 | O | 0..1 | XCN | Diagnosing Clinician | ||||
DG1-20 | O | 0..1 | EI | Diagnosis Identifier | 12345-6789^http://acme.org/diagnosisIdentifiers | |||
DG1-20.1 | O | ST | Identifier | |||||
DG1-20.2 | O | IS | Namespace |
If at least both DG1-3.1
and DG1-3.3
are populated, an appropriate Coding will be created within Condition.code
of a Condition resource that is referenced by Encounter.diagnosis
.
If DG1-3.3
is not populated, the code or display (as available) will be stored in Condition.code.text
.
This field can be overloaded such that DG1-3.7
and DG1-3.8
can be used to create an extension within an Encounter instead of a Condition. This is convenient when an inbound feed includes Diagnosis Related Group information in a DG1 segment.
This field is only mapped if DG1-3-2
(Diagnosis Code Text) is not present.
The value of DG1-5
will be mapped to Condition.assertedDate
.
If this field is not populated, the diagnosis will be mapped to Encounter.reason
. This is an imprecise mapping as Encounter.diagnosis
could also be used; however, this requires a reference to a separate resource and there is insufficient information in most HL7 v2.x messages to adequately identify a standalone Condition resource.
If this field is populated, its value will be mapped to Encounter.diagnosis.role
, and the diagnosis will be mapped to a Condition resource that is referenced by Encounter.diagnosis
.
Note that Smile CDR supports this field as both IS
(v2.5) and CWE
(v2.8) datatypes.
If this field is populated, its value will be mapped to Encounter.diagnosis.rank
. Ideally, multiple DG1 segments in a given message should appear in order, grouped by diagnosis type, and starting with 1
.
If this field is populated, its value will be mapped to a Practitioner resource that is referenced by Condition.asserter
.
If DG1-20.1
is populated with a unique identifier and DG1-20.2
is populated with a namespace or system, this field can be used as an identifier for a standalone Condition resource.
The following CE fields (Coded Elements) are converted into FHIR-equivalent extensions with optional nested extensions:
Please note: A given CE field will only be converted if all three of the following are populated:
Identifier
in first component CE.1
;Name of Coding System
in third component CE.3
; andExtension URL
in first extra component CE.7
.Optionally, the following may be included:
Text
in second component CE.2
; and/orNested Extension URL
in second extra component CE.8
.A new extension is created for each CE field.
A Mapper Bean Type can be implemented to ensure these components are appropriately populated for an incoming HL7 v2.x feed prior to converting its messages to FHIR.
Seq / Field | Opt | Card | DT | Len | Table | Description | Sample | |
---|---|---|---|---|---|---|---|---|
PR1-1 | O | 0..1 | SI | Set ID - PR1 | 1 | |||
PR1-3 | R | 1..1 | CE | Procedure Code | 2W53XYZ^Removal of Other Device on Abdominal Wall^ICD-10-PCS | |||
PR1-3.1 | R | ST | Code | |||||
PR1-3.2 | O | ST | Display | |||||
PR1-3.3 | R | ID | System | |||||
PR1-4 | O | 0..1 | ST | Procedure Description | ||||
PR1-5 | O | 0..1 | TS | Procedure Date/Time | 200101010700-0400 | |||
PR1-6 | O | 0..1 | IS | Procedure Functional Type | ||||
PR1-19 | O | 0..1 | EI | Procedure Identifier | 12345-6789^http://acme.org/procedureIdentifiers | |||
PR1-19.1 | R | ST | Identifier | |||||
PR1-19.2 | R | IS | Namespace |
If PR1-1
is populated, the value will be stored within a procedure-sequence
extension at the root of the resulting Procedure resource.
If at least both PR1-3.1
and PR1-3.3
are populated, an appropriate Coding will be created within Procedure.code
of a Procedure resource.
The field PR1-5
is a DTM datatype. If DTM.1
is populated, its value will be mapped to Procedure.performedDateTime
.
If PR1-19.1
is populated with a unique identifier and PR1-19.2
is populated with a namespace or system, this field can be used as an identifier for a standalone Procedure resource. If these fields are not populated, there will be no resulting Procedure.
If PR1-5
is populated, the unique identifier in PR1-19.1
will be concatenated with a hyphen and the value of PR1-5
(e.g. 12345-6789-200101010700-0400
).
Seq / Field | Opt | Card | DT | Len | Table | Description | Sample | |
---|---|---|---|---|---|---|---|---|
MRG-1 | R | 1..* | CX | Prior Patient Identifier List | 7000135^^^http://acme.org/mrns^MR | |||
MRG-1.1 | R | ST | 200 | Identifier Value | 7000135 | |||
MRG-1.4 | R | HD | 200 | Identifier System | http://acme.org/mrns | |||
MRG-1.5 | R | ID | 200 | Identifier Type | MR | |||
MRG-3 | O | 0..1 | CX | Prior Patient Account Number | 7000135^^^http://acme.org/patientAccountNumbers^AN | |||
MRG-3.1 | O | ST | 200 | Identifier Value | 7000135 | |||
MRG-3.4 | O | HD | 200 | Identifier System | http://acme.org/patientAccountNumbers | |||
MRG-3.5 | O | ID | 200 | Identifier Type | AN | |||
MRG-5 | O | 0..1 | CX | Prior Visit Number | 7000135^^^http://acme.org/visitNumbers^VN | |||
MRG-5.1 | O | ST | 200 | Identifier Value | 7000135 | |||
MRG-5.4 | O | ST | 200 | Identifier System | http://acme.org/visitNumbers | |||
MRG-5.5 | O | ID | 200 | Identifier Type | VN | |||
MRG-7 | O | 0..* | XPN | Patient Name List | Smith^John^Q^^^^L | |||
MRG-7.1.1 | O | ST | Family Name | |||||
MRG-7.2 | O | ST | Given Name | |||||
MRG-7.3 | O | ST | Middle Name | |||||
MRG-7.4 | O | ST | Suffix | |||||
MRG-7.5 | O | ST | Prefix | |||||
MRG-7.6 | O | ST | Degree | |||||
MRG-7.7 | O | ID | 0200 | Name Type | L (official) |
Seq / Field | Opt | Card | DT | Len | Table | Description | Sample | |
---|---|---|---|---|---|---|---|---|
GT1-2 | R | 1..* | CX | Guarantor Number | http://acme.org/guarantors^12345 | |||
GT1-2.1 | R | ST | Identifier | |||||
GT1-2.2 | R | IS | Namespace | |||||
GT1-3 | O | 0..* | XPN | Patient Name List | Smith^John^Q^^^^L | |||
GT1-3.1.1 | O | ST | Family Name | |||||
GT1-3.2 | O | ST | Given Name | |||||
GT1-3.3 | O | ST | Middle Name | |||||
GT1-3.4 | O | ST | Suffix | |||||
GT1-3.5 | O | ST | Prefix | |||||
GT1-3.6 | O | ST | Degree | |||||
GT1-3.7 | O | ID | 0200 | Name Type | L (official) | |||
GT1-5 | O | 0..* | XAD | Guarantor Address List | 342 Evergreen Terrace^^Springfield^NI^00000^USA^H | |||
GT1-5.1.1 | O | ST | Street Address | |||||
GT1-5.2 | O | ST | Street Address (Line 2) | |||||
GT1-5.3 | O | ST | City | |||||
GT1-5.4 | O | ST | State/Province | |||||
GT1-5.5 | O | ST | Zip/Postal Code | |||||
GT1-5.6 | O | ST | Country | |||||
GT1-5.7 | O | ID | 0190 | Address Type | ||||
GT1-6 | O | 0..* | XTN | Phone/Telecom List - Home | 1(305)555-1212^PRN^PH | |||
GT1-6.1 | O | ST | Telephone Number / email / etc | |||||
GT1-6.2 | O | ID | 0201 | Telecom Use | ||||
GT1-6.3 | O | ID | 0202 | Equipment Type | ||||
GT1-7 | O | 0..* | XTN | Phone/Telecom List - Work | 1(305)555-1212^WPN^PH | |||
GT1-7.1 | O | ST | Telephone Number / email / etc | |||||
GT1-7.2 | O | ID | 0201 | Telecom Use | ||||
GT1-7.3 | O | ID | 0202 | Equipment Type | ||||
GT1-8 | O | 0..1 | TS | DateTime of Birth | ||||
GT1-9 | O | 0..1 | ID | 0001 | Administrative Sex | M (male) |
GT1-6.2
(Telecom Use) will be assumed to be PRN
(Home) if not present.
GT1-7.2
(Telecom Use) will be assumed to be WPN
(Work) if not present.
Seq / Field | Opt | Card | DT | Len | Table | Description | Sample | |
---|---|---|---|---|---|---|---|---|
IN1-2 | R | 1..1 | CE | Health Plan ID | 12345^^http://acme.org/insurancePlanIds | |||
IN1-2.1 | R | ST | Identifier | |||||
IN1-2.2 | R | ST | Text | |||||
IN1-2.3 | R | ID | System | |||||
IN1-3 | O | 0..* | CX | Insurance Company Identifier List | 33745^^^http://acme.org/insurerIds | |||
IN1-3.1 | R | ST | Identifier Value | 33745 | ||||
IN1-3.4 | R | HD | Identifier System | http://acme.org/insurerIds | ||||
IN1-3.5 | R | ID | 0203 | Identifier Type | MR | |||
IN1-4 | O | 0..1 | XON | Insurance Company Name | InsuranceCo | |||
IN1-4.1 | R | ST | Name | |||||
IN1-5 | O | 0..* | XAD | Insurance Company Address | 342 Evergreen Terrace^^Springfield^NI^00000^USA^H | |||
IN1-5.1.1 | O | ST | Street Address | |||||
IN1-5.2 | O | ST | Street Address (Line 2) | |||||
IN1-5.3 | O | ST | City | |||||
IN1-5.4 | O | ST | State/Province | |||||
IN1-5.5 | O | ST | Zip/Postal Code | |||||
IN1-5.6 | O | ST | Country | |||||
IN1-5.7 | O | ID | 0190 | Address Type | ||||
IN1-7 | O | 0..* | XTN | Insurance Co Phone/Telecom List | 1(305)555-1212^WPN^PH | |||
IN1-7.1 | O | ST | Telephone Number / email / etc | |||||
IN1-7.2 | O | ID | 0201 | Telecom Use | ||||
IN1-7.3 | O | ID | 0202 | Equipment Type | ||||
IN1-12 | O | 0..1 | DT | Plan Effective Date | 20150101 | |||
IN1-13 | O | 0..1 | DT | Plan Expiration Date | 20251231 | |||
IN1-16 | O | 0..* | XPN | Name of Insured List | Smith^John^Q^^^^L | |||
IN1-16.1.1 | O | ST | Family Name | |||||
IN1-16.2 | O | ST | Given Name | |||||
IN1-16.3 | O | ST | Middle Name | |||||
IN1-16.4 | O | ST | Suffix | |||||
IN1-16.5 | O | ST | Prefix | |||||
IN1-16.6 | O | ST | Degree | |||||
IN1-16.7 | O | ID | 0200 | Name Type | L (official) |
Smile CDR will use this field to uniquely identify a Coverage resource, which describes an instance of coverage for an individual (i.e. an individual's policy). This means that the value supplied in IN1-2 must be an identifier that is unique to the individual, as opposed to being unique to the insurer.
IN1-7.2
(Telecom Use) will be assumed to be WPN
(Work) if not present.
Seq / Field | Opt | Card | DT | Len | Table | Description | Sample | |
---|---|---|---|---|---|---|---|---|
IN2-14 | O | 0..1 | IS | Military Service | ARMY | |||
IN2-15 | O | 0..1 | IS | Military Rank / Grade | MG | |||
IN2-16 | O | 0..1 | IS | Military Status | RETIRED | |||
IN2-63 | O | 0..* | XTN | Insured's Phone/Telecom List | 1(305)555-1212^PRN^PH | |||
IN2-63.1 | O | ST | Telephone Number / email / etc | |||||
IN2-63.2 | O | ID | 0201 | Telecom Use | ||||
IN2-63.3 | O | ID | 0202 | Equipment Type | ||||
IN2-64 | O | 0..* | XTN | Insured's Employer Phone/Telecom List | 1(305)555-1212^WPN^PH | |||
IN2-64.1 | O | ST | Telephone Number / email / etc | |||||
IN2-64.2 | O | ID | 0201 | Telecom Use | ||||
IN2-64.3 | O | ID | 0202 | Equipment Type |
Military Service is mapped to an extension in Patient.
Military Rank / Grade is mapped to an extension in Patient.
Military Status is mapped to an extension in Patient.
The following IS fields (Coded Value for User-Defined Tables) are converted into FHIR-equivalent extensions with optional nested extensions:
Please note: A given IS field will only be converted if all three of the following are populated:
Identifier
in first component IS.1
;Name of Coding System
in second extra component IS.3
; andExtension URL
in third extra component IS.4
.Optionally, the following may be included:
Text
in first extra component IS.2
; and/orNested Extension URL
in fourth extra component IS.5
.A new extension is created for each IS field.
A Mapper Bean Type can be implemented to ensure these components are appropriately populated for an incoming HL7 v2.x feed prior to converting its messages to FHIR.
IN2-63.2
(Telecom Use) will be assumed to be PRN
(Home) if not present.
IN2-64.2
(Telecom Use) will be assumed to be WPN
(Work) if not present.
Seq / Field | Opt | Card | DT | Len | Table | Description | Sample | |
---|---|---|---|---|---|---|---|---|
ORC-1 | C | 0..1 | ID | 0119 | Order Control | NW | ||
ORC-2 | C | 1..1 | EI | Placer Order Number | 12345^http://acme.org/orderNumbers | |||
ORC-2.1 | R | ST | Identifier | |||||
ORC-2.2 | R | IS | Namespace | |||||
ORC-3 | O | 0..1 | EI | Filler Order Number | 12345^http://acme.org/orderNumbers | |||
ORC-3.1 | R | ST | Identifier | |||||
ORC-3.2 | R | IS | Namespace | |||||
ORC-4 | O | 0..1 | EI | Placer Group Number | 12345^http://acme.org/groupNumbers | |||
ORC-4.1 | R | ST | Identifier | |||||
ORC-4.2 | R | IS | Namespace | |||||
ORC-5 | O | 0..1 | ID | 0038 | Order Status | |||
ORC-7 | O | 0..1 | TQ | Quantity/Timing | ||||
ORC-7.4 | O | 0..1 | TS | Start Date/Time | ||||
ORC-12 | O | 0..1 | XCN | Ordering Provider | ||||
ORC-12.1 | C | ST | Identifier Value | |||||
ORC-12.2.1 | C | ST | Family Name | |||||
ORC-12.3 | C | ST | Given Name | |||||
ORC-12.4 | O | ST | Middle Name | |||||
ORC-12.5 | O | ST | Suffix | |||||
ORC-12.6 | O | ST | Prefix | |||||
ORC-12.7 | O | ST | Degree | |||||
ORC-12.9.1 | C | IS | Identifier System |
This field is required to be present for RDE (Pharmacy Order) messages but optional for ORU (Result) messages.
If this field is populated with a value of NW
(New Order), the order is considered to be new – and a new DiagnosticRequest resource will be created.
This field is conditionally required.
When mapping an RDE_O11 message, this field must contain a value that will be treated as the primary identifier for the resulting order resource (i.e. MedicationRequest).
When mapping an ORU_R01 message, this may contain a value that will be treated as the primary identifier for the resulting order resource (i.e. ProcedureRequest or ServiceRequest depending on the version of FHIR being targeted). If ORC-2
is not populated then processing will not result in a ProcedureRequest or ServiceRequest.
Identifiers in this field must be globally unique, and must never be reused.
For FHIR R3, this field is mapped to ProcedureRequest.occurrenceDateTime
.
For FHIR R4+, this field is mapped to ServiceRequest.occurrenceDateTime
.
Seq / Field | Opt | Card | DT | Len | Table | Description | Sample | |
---|---|---|---|---|---|---|---|---|
OBR-2 | O | 0..1 | CX | Placer Order Number | 12345^http://acme.org/orderNumbers | |||
OBR-2.1 | R | ST | Identifier | |||||
OBR-2.2 | R | IS | Namespace | |||||
OBR-3 | O | 0..1 | CX | Filler Order Number | 12345^http://acme.org/orderNumbers | |||
OBR-3.1 | R | ST | Identifier | |||||
OBR-3.2 | R | IS | Namespace | |||||
OBR-4 | O | 0..1 | CE | Universal Service Identifier | ||||
OBR-4.1 | R | ST | 200 | Code | ||||
OBR-4.2 | O | ST | 200 | Display | ||||
OBR-4.3 | R | ID | 200 | System | ||||
OBR-7 | O | 0..1 | TS | Observation Date/Time | ||||
OBR-8 | O | 0..1 | TS | Observation End Date/Time | ||||
OBR-22 | O | 0..1 | DTM | Status Change Time | ||||
OBR-24 | O | 0..1 | ID | 0074 | Diagnostic Service Section ID | |||
OBR-25 | R | 1..1 | ID | 0271 | Result Status | |||
OBR-27 | O | 0..1 | TQ | Quantity/Timing | ||||
OBR-27.6 | R | ST | 6 | Priority |
This field should generally contain at least one repetition, and the first repetition will be treated as the primary identifier for the DiagnosticReport (Order) resource associated with the message being processed.
Note that if no value is present for this field, a value must be provided in OBR-3
(Filler Order Number).
Identifiers in this field must be globally unique, and must never be reused.
Note that the hl7v2_fhir_mapper_obr.use_obr2_placer_order_number_as_primary configuration property can be used to ensure OBR-2
is used as the primary identifier for the DiagnosticReport. At least one of OBR-2
or OBR-3
must be enabled for use as the primary identifier. It is also acceptable to select both, in which case updates will affect any existing DiagnosticReport that has either identifier.
If OBR-2
does not contain a value then this field must contain a value, and the value provided in this field will be used as the primary identifier for the DiagnosticReport.
Note that the hl7v2_fhir_mapper_obr.use_obr3_filler_order_number_as_primary configuration property can be used to ensure OBR-3
is used as the primary identifier for the DiagnosticReport. At least one of OBR-2
or OBR-3
must be enabled for use as the primary identifier. It is also acceptable to select both, in which case updates will affect any existing DiagnosticReport that has either identifier.
For R3, this field is mapped to both ProcedureRequest.code
and DiagnosticReport.code
in FHIR.
For R4+, this field is mapped to both ServiceRequest.code
and DiagnosticReport.code
in FHIR.
This field will be treated as the Observation.effective[x]
(Effective Time) of the observation. If OBR-8
is not present, the time is treated as a single point in time. If OBR-8
is present, the time is treated as a period.
This field is treated as the DiagnosticReport.issued
value when mapping to FHIR.
This field is treated as the DiagnosticReport.category
value when mapping to FHIR.
This field is mapped only for OBR-27.6 (Priority). For FHIR R3, this field is mapped to ProcedureRequest.priority
in cases where the ProcedureRequest resource is being mapped. This field must contain a valid FHIR priority value from the following list:
routine
urgent
asap
stat
For R4+, this field is mapped to ServiceRequest.priority
.
Seq / Field | Opt | Card | DT | Len | Table | Description | Sample | |
---|---|---|---|---|---|---|---|---|
OBX-2 | R | 1..1 | ID | 0125 | Observation Value Type | |||
OBX-3 | O | 0..* | CE | Observation Identifier (Code) | ||||
OBX-3.1 | R | ST | 200 | Code | ||||
OBX-3.2 | O | ST | 200 | Display | ||||
OBX-3.3 | R | ID | 200 | System | ||||
OBX-5 | O | 0..* | * | Value | ||||
OBX-6 | O | 0..1 | CE | Observation Units | ||||
OBX-6.1 | O | ST | 200 | Code | ||||
OBX-6.2 | O | ST | 200 | Display | ||||
OBX-6.3 | O | ID | 200 | System | ||||
OBX-7 | O | 0..1 | ST | Reference Range | 0.6-2.2 | |||
OBX-8 | O | 0..1 | CE | 0078 | Interpretation | HH | ||
OBX-11 | O | 0..1 | ID | 0085 | Observation Status | |||
OBX-14 | O | 0..1 | TS | Observation DateTime | ||||
OBX-15 | O | 0..1 | CE | Producer's ID | 3141592^^http://acme.org/facility | |||
OBX-16 | O | 0..1 | XCN | Responsible Observer | ||||
OBX-19 | O | 0..1 | XCN | Date/Time of Analysis | ||||
OBX-23 | O | 0..1 | XON | Performing Organization Name | Acme Facility | |||
OBX-24 | O | 0..1 | XAD | Performing Organization Address | 342 Evergreen Terrace^^Springfield^NI^00000^USA^B | |||
OBX-24.1.1 | O | ST | Street Address | |||||
OBX-24.2 | O | ST | Street Address (Line 2) | |||||
OBX-24.3 | O | ST | City | |||||
OBX-24.4 | O | ST | State/Province | |||||
OBX-24.5 | O | ST | Zip/Postal Code | |||||
OBX-24.6 | O | ST | Country | |||||
OBX-24.7 | O | ID | 0190 | Address Type | ||||
OBX-24.9 | O | IS | County/Parish Code |
OBX segments may have any of the following value types:
It is common practice in HL7 v2.x messaging to transmit multiline textual reports using OBX segments with a textual datatype (ST, FT, TX), and then place each line of the report in either a repetition of OBX-5
or in repetitions of the OBX segment itself with each line placed in OBX-5
.
In either of these cases, these will be converted to a single FHIR Observation resource with the lines joined into a single string.
Note that in the case of multiple OBX segments being used to denote repeating lines, the lines will only be joined into a single report if the OBX-3
field contains the same code, and no NTE segments are present between OBX repetitions.
Numeric HL7 v2.x observations will be converted into FHIR Observation resources with a value type of Quantity.
Although the HL7 v2.x specification defines the NM datatype as containing only whole and non-whole numbers, Smile CDR will also accept several common comparators in this field. Acceptable values include:
15
15.300
-22.3
>15.3
, <15.3
, >=15.3
, <=15.3
>
All of the above values will be converted into FHIR Quantity when processing inbound HL7 v2.x messages.
The FHIR Range, Ratio, and Quantity (with comparator) datatypes will be mapped to the HL7 v2.x SN datatype.
Quantity With Comparator
FHIR Quantities often do not have a comparator (e.g. <
or >=
). These values will be mapped to/from the HL7 v2.x NM (numeric) datatype. However, a Quantity with a comparator will be mapped to/from the HL7 v2.x SN (structured numeric) datatype.
The following is an example of a Quantity with a comparator in a FHIR Observation resource.
"valueQuantity": {
"value": 1.002,
"comparator": ">",
"unit": "mg",
"system": "http://unitsofmeasure.org",
"code": "mg"
}
This range corresponds to the following (partial) OBX segment: OBX|1|SN|||>^1.002|mg^mg^http://unitsofmeasure.org|
Ranges
The following is an example of a Range in a FHIR Observation resource.
"valueRange": {
"low": {
"value": 0.01,
"system": "http://unitsofmeasure.org",
"unit": "mg"
"code": "mg"
},
"high": {
"value": 0.02,
"system": "http://unitsofmeasure.org",
"unit": "mg"
"code": "mg"
}
}
This range corresponds to the following (partial) OBX segment: OBX|1|SN|||^0.01^-^0.02|mg^mg^http://unitsofmeasure.org|
Ratios
The following is an example of a Ratio in a FHIR Observation resource.
"valueRatio": {
"numerator": {
"value": 0.01,
"system": "http://unitsofmeasure.org",
"unit": "mg"
"code": "mg"
},
"denominator": {
"value": 0.02
"system": "http://unitsofmeasure.org",
"unit": "mg"
"code": "mg"
}
}
This ratio corresponds to the following (partial) OBX segment: OBX|1|SN|||^0.01^:^0.02|mg^^http://unitsofmeasure.org|
The HL7 v2.x standard does not have a datatype for the concept of boolean. When converting a FHIR Resource into an HL7 v2.x segment, if a FHIR Boolean datatype is found it will be converted into a ST (String) datatype with a value of true
or false
.
Values for this field may take one of the following forms:
0.2-2.2
) – if the value of this field is two numbers with a -
between them, the value is taken to be a numeric range, and the values are assumed to be inclusive. If the value of OBX-5
is of a datatype that has units, the units are assumed to be the same.If this field is not present, when mapping OBX segments to Observation
resources, the Observation.status
field value will be mapped from the OBR-25
(Result Status) fields by default. If this field is present, the value in OBX-11
will be used instead.
If this field is not present, when mapping OBX segments to Observation
resources, the Observation.effective[x]
field value will be mapped from the OBR-7
and OBR-8
fields by default. If this field is present, the value in OBX-14
will be used instead.
If both OBX-15.1 and OBX-15.3 are populated, they will constitute Organization.identifier.value
and Organization.identifier.system
respectively for the Organization to be referenced in Observation.performer
.
This field is mapped to Observation.issued
. This mapping is not completely semantically identical, but it is still considered a useful mapping.
Seq / Field | Opt | Card | DT | Len | Table | Description | Sample | |
---|---|---|---|---|---|---|---|---|
NK1-2 | O | 0..1 | XPN | Name | ||||
NK1-3 | O | 0..1 | CE | 0063 | Relationship | EMR^Employer^http://hl7.org/fhir/v2/0063 | ||
NK1-4 | O | 0..1 | XAD | Address | ||||
NK1-5 | O | 0..* | XTN | Phone/Telecom List - Home | 1(305)555-1212^PRN^PH | |||
NK1-5.1 | O | ST | Telephone Number / email / etc | |||||
NK1-5.2 | O | ID | 0201 | Telecom Use | ||||
NK1-5.3 | O | ID | 0202 | Equipment Type | ||||
NK1-6 | O | 0..* | XTN | Phone/Telecom List - Work | 1(305)555-1212^WPN^PH | |||
NK1-6.1 | O | ST | Telephone Number / email / etc | |||||
NK1-6.2 | O | ID | 0201 | Telecom Use | ||||
NK1-6.3 | O | ID | 0202 | Equipment Type | ||||
NK1-7 | O | 0..1 | CE | 0131 | Contact Role | E^Employer^http://hl7.org/fhir/v2/0131 | ||
NK1-13 | O | 0..1 | XON | Organization Name | ||||
NK1-15 | O | 0..1 | IS | Administrative Sex | ||||
NK1-33 | O | 0..1 | CX | Next of Kin/Associated Party's Identifiers | 0123456789^^^http://acme.org/organization |
These fields are mapped to Patient.contact.relationship
.
NK1-5.1
(Telecom Use) will be assumed to be PRN
(Home) if not present.
NK1-6.2
(Telecom Use) will be assumed to be WPN
(Work) if not present.
If either of these fields are present, a contained Organization resource will be added to the Patient.
Seq / Field | Opt | Card | DT | Len | Table | Description | Sample | |
---|---|---|---|---|---|---|---|---|
NTE-3 | R | 1..* | FT | Note Text |
Seq / Field | Opt | Card | DT | Len | Table | Description | Sample | |
---|---|---|---|---|---|---|---|---|
RXA-2 | R | 1..1 | NM | Administration Sub-ID Counter | ||||
RXA-3 | R | 1..1 | TS | Date/Time of Start of Administration | ||||
RXA-4 | O | 0..1 | TS | Date/Time of End of Administration | ||||
RXA-5 | O | 0..1 | CE | Administered Code | ||||
RXA-6 | O | 0..1 | NM | Administered Amount | ||||
RXA-7 | O | 0..1 | CE | Administered Units | ||||
RXA-8 | O | 0..1 | CE | Administered Dosage Form | ||||
RXA-9 | O | 0..* | CE | Administration Notes | ^Given after lunch | |||
RXA-9.1 | X | ST | Identifier (not used) | |||||
RXA-9.2 | R | ST | Text | |||||
RXA-9.3 | X | ID | System (not used) | |||||
RXA-10 | O | 0..* | XCN | Administering Provider | ||||
RXA-10.1 | C | ST | Identifier Value | |||||
RXA-10.2.1 | C | ST | Family Name | |||||
RXA-10.3 | C | ST | Given Name | |||||
RXA-10.4 | O | ST | Middle Name | |||||
RXA-10.5 | O | ST | Suffix | |||||
RXA-10.6 | O | ST | Prefix | |||||
RXA-10.7 | O | ST | Degree | |||||
RXA-10.9.1 | C | IS | Identifier System | |||||
RXA-12 | O | 0..1 | ST | Administered Per (Time Unit) | ||||
RXA-20 | O | 0..1 | ID | 0322 | Completion Status |
This field is used to build a consistent identifier for the mapped MedicationAdministration resource. A value for MedicationAdministration is created using the system and identifier in ORC-2(0).2
and ORC-2(0).1
respectively, with -[sub ID]
appended to the value. As a result, MedicationAdministration.identifier.system
will be populated with the same value as the corresponding MedicationRequest.identifier.system
.
Alternatively, RXA-2
can be overloaded to declare a different identifier system. If the first extra component of RXA-2
is populated, its value will be stored in MedicationAdministration.identifier.system
.
This field is mapped to MedicationAdministration.dosage.rateRatio.denominator.unit
. A value of 1
is mapped to MedicationAdministration.dosage.rateRatio.denominator.value
. The numerator is populated using the values of RXA-6
(Administered Amount) and RXA-7
(Administered Units).
Seq / Field | Opt | Card | DT | Len | Table | Description | Sample | |
---|---|---|---|---|---|---|---|---|
RXC-1 | O | 0..1 | ID | 0166 | RX Component Type | |||
RXC-2 | R | 1..1 | CE | Component Code | ||||
RXC-3 | O | 0..1 | NM | Component Amount | ||||
RXC-4 | O | 0..1 | CE | Component Units |
These fields are mapped to an extension on the Medication resource. We store these values in an extension to mirror Medication.amount
in FHIR R4.
One or more of this optional non-standard segment can be included in the ADMINISTRATION group of an RAS_O17 message.
This segment uses the RXC (Pharmacy Component) segment definition.
Seq / Field | Opt | Card | DT | Len | Table | Description | Sample | |
---|---|---|---|---|---|---|---|---|
RXE-1 | O | 0..1 | TQ | Quantity Timing | ||||
RXE-1.2.1 | O | ST | Repeat Pattern | 2 times daily | ||||
RXE-1.2.2 | O | ST | Repeat Interval | 09:00, 18:00 | ||||
RXE-1.4 | O | TS | Start Date/Time | |||||
RXE-1.5 | O | TS | End Date/Time | |||||
RXE-2 | R | 1..1 | CE | Give Code | 02713^morphine injection 2 mg^http://acme.org/drugs | |||
RXE-3 | O | 0..1 | NM | Give Minimum | ||||
RXE-4 | O | 0..1 | NM | Give Maximum | ||||
RXE-5 | O | 0..1 | CE | Give Units | ||||
RXE-6 | O | 0..1 | CE | Dosage Form | ||||
RXE-7 | O | 0..* | CE | Administration Instructions | ||||
RXE-7.1 | O | ST | 200 | Code | ||||
RXE-7.2 | O | ST | 200 | Display | ||||
RXE-7.3 | O | ID | 200 | System | ||||
RXE-10 | O | 0..1 | NM | Dispense Amount | ||||
RXE-11 | O | 0..1 | CE | Dispense Units | ||||
RXE-23 | O | 0..1 | ST | Give Rate Amount | ||||
RXE-24 | O | 0..1 | CE | Give Rate Units |
This field is used only to supply a text version of the timing information for this order. If either of the components RXE-1.2.1
(Repeat Pattern) and RXE-1.2.2
(Repeat Interval) are populated, they will be mapped as a textual version of the timing string. If both are populated, they will be joined as [pattern] @ [interval]
.
If populated, these will be treated as the start and end dates that the patient should be taking this medication.
This field contains the identifier of the actual medication being ordered. It must contain a value.
If this field contains only a display value (CE.2
) the medication will be stored as a simple text string. If this field contains a code (CE.1
and CE.3
) then a Medication resource will be stored using the given code as the primary identifier.
If CE.9
(Original Text) is populated, it will be stored in Medication.code.text
.
Note that if any RXC (Pharmacy Component) segments are found, the components will be added to this Medication as ingredients.
For repetitions where RXE-7.1
and RXE-7.3
are both populated, this field is mapped to MedicationRequest.dosageInstruction.patientInstruction
. For repetitions where only RXE-7.2
is populated, this field is mapped to MedicationRequest.dosageInstruction.text
.
If populated, these fields will be mapped to MedicationRequest.dosagaInstruction.rate[x]
. They will be mapped to one of rateQuantity
, rateRange
, or rateRatio
as appropriate.
Seq / Field | Opt | Card | DT | Len | Table | Description | Sample | |
---|---|---|---|---|---|---|---|---|
RXR-1 | O | 0..1 | CE | Route | ||||
RXR-2 | O | 0..1 | CE | Administration Site |
Seq / Field | Opt | Card | DT | Len | Table | Description | Sample | |
---|---|---|---|---|---|---|---|---|
IAM-2 | O | 0..1 | CE | 0127 | Allergen Type Code | FA^Food allergy^http://hl7.org/fhir/v2/0127 | ||
IAM-2.1 | R | 1..1 | ST | Allergen Type Code | ||||
IAM-2.3 | R | 1..1 | ID | Allergen Type Code System | ||||
IAM-3 | R | 1..1 | CE | Allergen Code | 256259004^Pollen (Substance)^http://snomed.info/sct | |||
IAM-3.1 | R | 1..1 | ST | Allergen Code | ||||
IAM-3.2 | O | 0..1 | ST | Allergen Code Display | ||||
IAM-3.3 | R | 1..1 | ID | Allergen Code System | ||||
IAM-4 | O | 0..1 | CE | 0128 | Severity Code | SV^^http://hl7.org/fhir/v2/0128 (Severe) | ||
IAM-4.1 | R | 1..1 | ST | Severity Code | ||||
IAM-4.2 | O | 0..1 | ST | Severity Code Display | ||||
IAM-4.3 | R | 1..1 | ID | Severity Code System | ||||
IAM-5 | O | 0..* | ST | Reaction | Wheezing | |||
IAM-7 | O | 0..1 | EI | Allergy Unique Identifier | http://acme.org/allergies^12345 | |||
IAM-7.1 | R | 1..1 | ST | Identifier | ||||
IAM-7.2 | O | 0..1 | ST | Namespace | ||||
IAM-11 | O | 0..1 | TS | Onset Date | ||||
IAM-13 | O | 0..1 | TS | Asserted Date/Time | ||||
IAM-17 | O | 0..1 | CE | 0438 | Clinical Status | C^^http://hl7.org/fhir/v2/0438 (Confirmed) | ||
IAM-17.1 | R | 1..1 | ST | Clinical Status Code | ||||
IAM-17.3 | R | 1..1 | ID | Clinical Status Display |
Values for this field should be in HL7 v2.x table 0438. Values in this field are mapped to two separate fields in the FHIR AllergyIntolerance resource:
clinicalStatus
verificationStatus
Seq / Field | Opt | Card | DT | Len | Table | Description | Sample | |
---|---|---|---|---|---|---|---|---|
SPM-2 | O | 0..1 | EIP | Specimen ID | 3245&http://acme.org/spm/placer^1232&http://acme.org/spm/filler | |||
SPM-2.1 | O | 0..1 | EI | Specimen Placer ID | ||||
SPM-2.1.1 | R | 1..1 | ST | Specimen Placer ID - ID | ||||
SPM-2.1.2 | R | 1..1 | IS | Specimen Placer ID - System | ||||
SPM-2.2 | O | 0..1 | EI | Specimen Filler ID | ||||
SPM-2.2.1 | R | 1..1 | ST | Specimen Filler ID - ID | ||||
SPM-2.2.2 | R | 1..1 | IS | Specimen Filler ID - System | ||||
SPM-4 | O | 0..1 | CWE | Specimen Type | ||||
SPM-7 | O | 0..1 | CWE | Specimen Collection Method | ||||
SPM-8 | O | 0..1 | CWE | Specimen Source Site | ||||
SPM-17 | O | 0..1 | DR | Specimen Collection Date/Time | 201701021200-0500 | |||
SPM-17.1 | R | 1..1 | DTM | Range Start | ||||
SPM-17.2 | O | 0..1 | DTM | Range End | ||||
SPM-18 | O | 0..1 | DTM | Specimen Received Date/Time | 201701021200-0500 |
If the Specimen contains a placer and/or filler ID, these IDs will be used as primary identifiers for the creation of a Specimen resource. If no Specimen ID is present but other details about the specimen are found in the message, the specimen details will be placed in a contained resource.
One or more of this optional non-standard segment can be appended to any message structure.
Seq / Field | Opt | Card | DT | Len | Table | Description | Sample | |
---|---|---|---|---|---|---|---|---|
ZXT-2 | R | 1..1 | ID | 0125 | Value Type | CWE | ||
ZXT-3 | R | 1..1 | * | Value | ACES^Aces!^http://acme.org/codes | |||
ZXT-4 | R | 1..1 | ST | Path | Encounter.extension('http://acme.org/extension').valueCoding |
This field identifies the value type in ZXT-3
.
ZXT segments may have any of the following value types:
If there is a value type that you would like to see supported, let us know!
A coded element corresponds to a fixed set of codes with required binding. For example in FHIR R3, ProcedureRequest.intent
can only be assigned a code defined in code system http://hl7.org/fhir/request-intent
. A ZXT segment can be used to populate such a field as follows:
ZXT||CE|filler-order|ProcedureRequest.intent
If targeting FHIR R4+, the equivalent ZXT segment would appear as follows: ZXT||CE|filler-order|ServiceRequest.intent
In such cases, only CE.1
is necessary. The display in CE.2
and the code system in CE.3
will not be evaluated; instead these will be handled automatically based on the path provided.
Note that Smile CDR does not presently validate the value in ZXT-3
in light of the path provided in ZXT-4
.
A coded value with exceptions is stored as either a Coding or CodeableConcept. This depends on the path declared in ZXT-4
.
CWE.1
provides the code, CWE.2
provides the display, and CWE.3
provides the code system. For example:
ZXT||CWE|ACES^Aces!^http://acme.org/codes|Encounter.extension('http://acme.org/extension').valueCoding
This will result in the following:
"extension": [
{
"url": "http://acme.org/extension",
"valueCoding": {
"system": "http://acme.org/codes",
"code": "ACES",
"display": "Aces!"
}
}
],
Alternatively:
ZXT||CWE|ACES^Aces!^http://acme.org/codes|Encounter.extension('http://acme.org/extension').valueCodeableConcept
ZXT||CWE|DEUCES^Deuces!^http://acme.org/codes|Encounter.extension('http://acme.org/extension').valueCodeableConcept
These will result in the following:
"extension": [
{
"url": "http://acme.org/extension",
"valueCodeableConcept": {
"coding": [
{
"system": "http://acme.org/codes",
"code": "ACES",
"display": "Aces!"
},
{
"system": "http://acme.org/codes",
"code": "DEUCES",
"display": "Deuces!"
}
]
}
}
],
A numeric value is stored as either an integer or decimal. This depends on the path declared in ZXT-4
.
For example: ZXT||NM|3|Patient.multipleBirthInteger
This will result in the following:
"multipleBirthInteger": 3,
Alternatively: ZXT||NM|3|Encounter.extension('http://acme.org/extension').valueInteger
This will result in the following:
"extension": [
{
"url": "http://acme.org/extension",
"valueInteger": 3
}
],
Alternatively: ZXT||NM|3.3|Encounter.extension('http://acme.org/extension').valueDecimal
This will result in the following:
"extension": [
{
"url": "http://acme.org/extension",
"valueDecimal": 3.3
}
],
A textual value is stored as either a string or boolean. This depends on the path declared in ZXT-4
.
For example: ZXT||ST|Aces|Encounter.extension('http://acme.org/extension').valueString
This will result in the following:
"extension": [
{
"url": "http://acme.org/extension",
"valueString": "Aces!"
}
],
Alternatively: ZXT||ST|true|Encounter.extension('http://acme.org/extension').valueBoolean
This will result in the following:
"extension": [
{
"url": "http://acme.org/extension",
"valueBoolean": true
}
],
This also applies where a declared path implies a specific datatype, for example: ZXT||ST|true|Patient.active
For boolean values, ZXT-3
must be either true
or false
.
This field identifies the path for the resulting value. Its value is case-sensitive.
This is most useful for populating extensions but it is not limited to populating extensions. For example, a ZXT segment could be used to populate Patient.name.family
; however, this could overwrite existing values populated while processing the PID segment. This is because ZXT segments are always processed last. As such, the general purpose for ZXT segments is to populate fields and extensions in FHIR that the inbound HL7 v2.x transaction processor doesn't already handle.
Values like Patient.extension('http://acme.org/extension').valueString
and Encounter.extension('http://acme.org/extension').valueString
will result in an extension added to the base of the resource whereas a path such as Encounter.class.extension('http://acme.org/extension').valueString
will result in an extension added to the Encounter's class element.
Nested extensions can be declared as follows: Encounter.extension('http://acme.org/extension').extension('http://acme.org/nestedExtension').valueString
Modifier extensions can also be declared: Encounter.modifierExtension('http://acme.org/extension').valueString
The concept of extra components comes from HAPI. These are non-standard components appended to a field, component, or sub-component in a message, which can be written to and read from using the HAPI HL7 v2.x parser at runtime. Where no suitable component exists, Smile CDR sometimes uses extra components to facilitate translation between HL7 v2.x and FHIR.
A Mapper Bean Type can be implemented to work with extra components within an incoming HL7 v2.x feed prior to converting its messages to FHIR.