On this page:

22.5Segment Definitions

 

This page contains definitions for the Smile CDR HL7 v2.x segments.

22.5.1Segment: MSH (Message Header)

 
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

Field MSH-3 (Sending Application)

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.

Field MSH-4 (Sending System)

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.

Field MSH-5 (Receiving Application)

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.

Field MSH-6 (Receiving System)

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.

Field MSH-10 (Control ID)

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

22.5.2Segment: EVN (Event)

 
Seq / Field Opt Card DT Len Table Description Sample
EVN-2 R 1..1 TS Recorded Date/Time

Field EVN-2 (Recorded Date/Time)

This field is populated for outbound (sending) HL7 v2.x messages, but ignored for inbound (receiving) HL7 v2.x transactions.

22.5.3Segment: PID (Patient)

 
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

Field PID-3 (Patient Business Identifier)

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 either MR or MB – depending on which is configured for a given HL7 v2.x Listening Endpoint module. This will be used as the primary business identifier upon which other processing decisions will be made.

Whichever of the two values is used in PID-3[0]-5, it must be used consistently to ensure Patients are updated correctly. The accepted value can be configured using the Patient Primary Identifier Type property.

Note that this setting should not be changed for a repository that already contains data. Changing it may result in multiple Patient resources for the same real-world patient.

Patients may have an unlimited number of other identifiers as well.

Identifiers in this field must be globally unique, and must never be reused.

Field PID-5 (Patient Name List)

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.

Field PID-6 (Mother's Maiden Name)

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.

Field PID-10 (Race)

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:

  • CE.1: Code
  • CE.2: Display Name
  • CE.3: Code System
  • CE.4: (Unused)
  • CE.5: (Unused)
  • CE.6: (Unused)
  • CE.7: Extension URL
  • CE.8: Nested Extension URL

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.

Field PID-13 (Phone/Telecom List - Home)

PID-13.2 (Telecom Use) will be assumed to be PRN (Home) if not present.

Field PID-14 (Phone/Telecom List - Work)

PID-14.2 (Telecom Use) will be assumed to be PRN (Work) if not present.

Field PID-17 (Religion)

Note that this field is not currently populated for outbound interfaces.

Field PID-18 (Patient Account Number)

Field PID-13 (Race)

A standalone Account resource will be added when use_standalone_pid18_patient_account is toggled on and identifiers are provided.

Otherwise, it is mapped to a contained Account resource on the Encounter.

Field PID-22 (Ethnicity)

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:

  • CE.1: Code
  • CE.2: Display Name
  • CE.3: Code System
  • CE.4: (Unused)
  • CE.5: (Unused)
  • CE.6: (Unused)
  • CE.7: Extension URL
  • CE.8: Nested Extension URL

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.

Field PID-27 (Veterans Military Status)

Note that this field is not currently populated for outbound interfaces.

Field PID-28 (Nationality)

Note that this field is not currently populated for outbound interfaces.

Converting CE Fields to FHIR Extensions

The following CE fields (Coded Elements) are converted into FHIR-equivalent extensions with optional nested extensions:

  • PID-10 (Race)
  • PID-17 (Religion)
  • PID-22 (Ethnic Group)
  • PID-27 (Veterans Military Status)
  • PID-28 (Nationality)

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; and
  • Extension URL in first extra component CE.7.

Optionally, the following may be included:

  • Text in second component CE.2; and/or
  • Nested 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.

22.5.4Segment: PD1 (Patient Demographics Extended)

 
Seq / Field Opt Card DT Len Table Description Sample
PD1-19 O 0..1 IS Military Branch
PD1-20 O 0..1 IS Military Rank
PD1-21 O 0..1 IS Military Status

22.5.5Segment: PV1 (Visit/Encounter)

 
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-4 O 0..1 IS 0007 Admission Type E
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-7 O 0..* XCN Attending Provider
PV1-7.1 C ST Identifier Value
PV1-7.2.1 C ST Family Name
PV1-7.3 C ST Given Name
PV1-7.4 O ST Middle Name
PV1-7.5 O ST Suffix
PV1-7.6 O ST Prefix
PV1-7.7 O ST Degree
PV1-7.9.1 C IS Identifier System
PV1-8 O 0..* XCN Referring Provider
PV1-8.1 C ST Identifier Value
PV1-8.2.1 C ST Family Name
PV1-8.3 C ST Given Name
PV1-8.4 O ST Middle Name
PV1-8.5 O ST Suffix
PV1-8.6 O ST Prefix
PV1-8.7 O ST Degree
PV1-8.9.1 C IS Identifier System
PV1-9 O 0..* XCN Consulting Provider
PV1-9.1 C ST Identifier Value
PV1-9.2.1 C ST Family Name
PV1-9.3 C ST Given Name
PV1-9.4 O ST Middle Name
PV1-9.5 O ST Suffix
PV1-9.6 O ST Prefix
PV1-9.7 O ST Degree
PV1-9.9.1 C IS Identifier System
PV1-10 O 0..1 IS 0069 Service Code 1^Adoption/Permanent Care Info/Support^http://terminology.hl7.org/CodeSystem/service-type
PV1-10.1 O IS Service Code
PV1-10.2 O ST Service Code Display Name
PV1-10.3 O IS Service Code System
PV1-14 O 0..1 IS Admit Source
PV1-15 O 0..1 IS 0009 Ambulatory Status A1^Ambulates with assistive device^http://terminology.hl7.org/CodeSystem/v2-0009
PV1-15.1 O IS Ambulatory Status
PV1-15.2 O ST Ambulatory Status Display Name
PV1-15.3 O IS Ambulatory Status System
PV1-17 O 0..* XCN Admitting Provider
PV1-17.1 C ST Identifier Value
PV1-17.2.1 C ST Family Name
PV1-17.3 C ST Given Name
PV1-17.4 O ST Middle Name
PV1-17.5 O ST Suffix
PV1-17.6 O ST Prefix
PV1-17.7 O ST Degree
PV1-17.9.1 C IS Identifier System
PV1-18 O 0..1 IS 0018 Patient Type
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-20 O 0..1 FC Financial Class
PV1-20.1 O IS Financial Class Code
PV1-20.2 O DTM Effective Date
PV1-24 O 0..1 IS Contract Code
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

Location Processing for Fields PV1-3 (Assigned Patient Location) and PV1-6 (Prior Patient Location)

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.

No Identifiers

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.1Location.nameWard Name
PL.2Location.nameRoom Name
PL.3Location.nameBed 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||||

Comprehensive Identifiers in PL.10

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.1Location.nameWard Name
PL.2Location.nameRoom Name
PL.3Location.nameBed Name
PL.4.1Location.managingOrganizationFacility Identifier Value
PL.9Location.descriptionLocation/Ward Description
PL.10.1Location.identifier.valueLocation/Ward Identifier Value
PL.10.2Location.identifier.systemLocation/Ward Identifier System
PL.11.1Location.identifier.systemAssigning Authority for Location
PL.12Location.managingOrganizationFacility Identifier System
PL.13Location.descriptionRoom Description
PL.14Location.identifier.systemRoom Identifier Value
PL.15Location.identifier.valueRoom Identifier System
PL.16Location.descriptionBed Description
PL.17Location.identifier.systemBed Identifier Value
PL.18Location.identifier.valueBed 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||||

Identifier System in PL.11.1

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:

  • The identifier system is drawn from PL.11.1
  • The identifier value is drawn from 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.1Location.name
Location.identifier.value
Ward Name
Ward Identifier Value
PL.2Location.name
Location.identifier.value
Room Name
Room Identifier Value
PL.3Location.name
Location.identifier.value
Bed Name
Bed Identifier Value
PL.11.1Location.identifier.systemWard 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||||

Field PV1-3 (Assigned Patient 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.

Component PV1-3.1 (Ward)

If PV1-3.1 is populated, the following will occur:

  • A Location resource will be created/updated for this ward.
  • The value of PL.1 will be stored in Location.name.
  • Location.type will indicate a hospital unit.
  • Location.physicalType will indicate a ward.
  • The value of PL.9 will be stored in Location.description.
  • If both 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.

Component PV1-3.2 (Room)

If PV1-3.2 is populated, the following will occur:

  • A Location resource will be created/updated for this room.
  • The value of PL.2 will be stored in Location.name.
  • Location.physicalType will indicate a room.
  • The value of PL.13 will be stored in Location.description.
  • If both 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).

Component PV1-3.3 (Bed)

If PV1-3.3 is populated, the following will occur:

  • A Location resource will be created/updated for this bed.
  • The value of PL.3 will be stored in Location.name.
  • Location.physicalType will indicate a bed.
  • The value of PL.16 will be stored in Location.description.
  • If both 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).

Component PV1-3.4 (Facility)

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.

Field PV1-4 (Admit Type)

For inbound messages, Smile CDR will accept any value supplied in this field and will map to Encounter.type, creating a coding with Coding.system = "http://terminology.hl7.org/CodeSystem/v2-0007".

For outbound messages, Smile CDR will map any Coding in Encounter.type with a system = "http://terminology.hl7.org/CodeSystem/v2-0007" to this field.

Field PV1-6 (Prior Patient Location)

PV1-6 is processed similarly to PV1-3 with one addition:

  • Encounter.location.status will indicate a status of completed.

Alternate Processing of Fields PV1-3 (Assigned Patient Location) and PV1-6 (Prior Patient Location)

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.

Field PV1-3 (Assigned Patient Location)

PV1-3 will result in a single atomic Location resource.

Component PV1-3.3 (Bed)

If PV1-3.3 is populated, the following will occur:

  • A Location resource will be created/updated for this bed.
  • The value of PL.3 will be stored in Location.name.
  • Location.physicalType will indicate a bed.
  • The value of PL.9 will be stored in Location.description.
  • If both 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.

Component PV1-3.2 (Room)

Otherwise if PV1-3.2 is populated, the following will occur:

  • A Location resource will be created/updated for this room.
  • The value of PL.2 will be stored in Location.name.
  • Location.physicalType will indicate a room.
  • The value of PL.9 will be stored in Location.description.
  • If both 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.

Component PV1-3.1 (Ward)

Otherwise if PV1-3.1 is populated, the following will occur:

  • A Location resource will be created/updated for this ward.
  • The value of PL.1 will be stored in Location.name.
  • Location.type will indicate a hospital unit.
  • Location.physicalType will indicate a ward.
  • The value of PL.9 will be stored in Location.description.
  • If both 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.

Component PV1-3.4 (Facility)

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.

Field PV1-6 (Prior Patient Location)

PV1-6 is processed similarly to PV1-3 with one addition:

  • Encounter.location.status will indicate a status of completed.

Field PV1-7 (Attending Provider)

This field is not used by default, as it is preferable to use the ROL segment for Encounter-Practitioner mappings.

For inbound messages, this field will only be processed if Parse Encounter Providers is enabled in the HL7 v2.x Listening Endpoint module configuration.

For outbound messages, this field will only be populated if Populate Encounter Participants in PV1 is enabled.

Field PV1-8 (Referring Provider)

This field is not used by default, as it is preferable to use the ROL segment for Encounter-Practitioner mappings.

For inbound messages, this field will only be processed if Parse Encounter Providers is enabled in the HL7 v2.x Listening Endpoint module configuration.

For outbound messages, this field will only be populated if Populate Encounter Participants in PV1 is enabled.

Field PV1-9 (Consulting Provider)

This field is not used by default, as it is preferable to use the ROL segment for Encounter-Practitioner mappings.

For inbound messages, this field will only be processed if Parse Encounter Providers is enabled in the HL7 v2.x Listening Endpoint module configuration.

For outbound messages, this field will only be populated if Populate Encounter Participants in PV1 is enabled.

Field PV1-10 (Service Type)

This field is of type IS in HL7 v2.x, meaning it does not provide a space for a code system and assumes the code to be in HL7 Table 0069.

An optional extra component in PV1-10.2 may be used to specify a display value for the code used in PV1-10.1.

An optional extra component in PV1-10.3 may be used to specify a code system URL for the code used in PV1-10.1.

This field is mapped to FHIR Encounter.serviceType which is of type CodeableConcept.

Field PV1-14 (Admit Source)

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:

  • PV1-14.1: Code
  • PV1-14.2: Display Name
  • PV1-14.3: Code System

Field PV1-15 (Ambulatory Status)

This field is of type IS in HL7 v2.x, meaning it does not provide a space for a code system and assumes the code to be in HL7 Table 0069.

An optional extra component in PV1-15.2 may be used to specify a display value for the code used in PV1-15.1.

An optional extra component in PV1-15.3 may be used to specify a code system URL for the code used in PV1-15.1.

This field is mapped to an extension on the FHIR Encounter which is of type CodeableConcept and has the following URL: https://smilecdr.com/fhir/ns/StructureDefinition/encounter-ambulatory-status

Field PV1-17 (Admitting Provider)

This field is not used by default, as it is preferable to use the ROL segment for Encounter-Practitioner mappings.

For inbound messages, this field will only be processed if Parse Encounter Providers is enabled in the HL7 v2.x Listening Endpoint module configuration.

For outbound messages, this field will only be populated if Populate Encounter Participants in PV1 is enabled.

Field PV1-18 (Patient Type)

For inbound messages, Smile CDR will accept any value supplied in this field and will map to Encounter.type, creating a coding with Coding.system = "http://terminology.hl7.org/CodeSystem/v2-0018".

For outbound messages, Smile CDR will map any Coding in Encounter.type with a system = "http://terminology.hl7.org/CodeSystem/v2-0018" to this field.

Field PV1-20 (Financial Class)

This field is mapped to an extension on the FHIR Encounter with the following URL: https://smilecdr.com/fhir/ns/StructureDefinition/encounter-financial-class

The value of PV1-20.1 is placed in a child extension with a url of code with a datatype of Coding.

The value of PV1-20.2 is placed in a child extension with a url of effectiveDate with a datatype of DateTime.

Field PV1-24 (Contract Code)

This field is mapped to an extension on the FHIR Encounter which is of type CodeableConcept and has the following URL: https://smilecdr.com/fhir/ns/StructureDefinition/encounter-contract-code

Field PV1-36 (Discharge Disposition)

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:

  • PV1-36.1: Code
  • PV1-36.2: Display Name
  • PV1-36.3: Code System

Field PV1-19 (Visit Number)

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.

Field PV1-39 (Servicing Facility)

An Encounter.serviceProvider can be generated if both PV1-39.1 and PV1-39.2 are populated, and there exists an organization in the fhir database with Organization.identifier.value and Organization.identifier.system matching the values in PV1-39.1 and PV1-39.2 respectively. The organization with the provided identifier will be to be referenced in Encounter.serviceProvider.

22.5.6Segment: PV2 (Visit/Encounter Additional)

 
Seq / Field Opt Card DT Len Table Description Sample
PV2-2 O 0..1 CE 0129 Accommodation Code wheel^Wheelchair^http://terminology.hl7.org/CodeSystem/encounter-special-arrangements
PV2-3 O 0..1 CE Admit Reason 183005^Autoimmune pancytopenia^http://snomed.info/sct
PV2-4 O 0..1 CE Transfer Reason
PV2-8 O 0..1 TS Expected Admit DateTime
PV2-9 O 0..1 TS Expected Discharge DateTime
PV2-26 O 0..1 DT Previous Treatment Date
PV2-27 O 0..1 IS 0112 Expected Discharge Disposition
PV2-27.1 O IS Expected Discharge Disposition Code
PV2-27.2 O ST Expected Discharge Disposition Display Name
PV2-27.3 O IS Expected Discharge Disposition System

Field: PV2-2 (Accommodation Code)

This field is mapped to FHIR Encounter.hospitalization.specialArrangement. The use of FHIR Special Arrangements codes is recommended.

Field: PV2-3 (Admit Reason)

This field is mapped to FHIR Encounter.reasonCode. The use of FHIR Encounter Reason codes is recommended.

Field: PV2-4 (Transfer Reason)

This field is mapped to an extension on the FHIR Encounter resource with a value type of Coding and a URL of: https://smilecdr.com/fhir/ns/StructureDefinition/encounter-transfer-reason

Field: PV2-8 (Expected Admit DateTime)

This field is mapped to an extension on the FHIR Encounter resource with a value type of dateTime and a URL of: https://smilecdr.com/fhir/ns/StructureDefinition/encounter-expected-admit-datetime

Field: PV2-9 (Expected Discharge DateTime)

This field is mapped to an extension on the FHIR Encounter resource with a value type of dateTime and a URL of: https://smilecdr.com/fhir/ns/StructureDefinition/encounter-expected-discharge-datetime

Field: PV2-26 (Previous Treatment Date)

This field is mapped to an extension on the FHIR Encounter resource with a value type of date and a URL of: https://smilecdr.com/fhir/ns/StructureDefinition/encounter-expected-previous-treatment-date

Field: PV2-27 (Expected Discharge Disposition)

This field is mapped to an extension on the FHIR Encounter resource with a value type of Coding and a URL of: https://smilecdr.com/fhir/ns/StructureDefinition/encounter-expected-discharge-disposition

This field is an HL7 IS datatype in HL7 v2.x. The format for this overloaded field is as follows:

  • PV2-27.1: Code
  • PV2-27.2: Display Name
  • PV2-27.3: Code System

22.5.7Segment: ROL (Role)

 
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

Field ROL-3 (Role Code)

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.

Field ROL-4 (Role Person)

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.

Field ROL-12 (Phone/Telecom List)

ROL-12.2 (Telecom Use) will be assumed to be WPN (Work) if not present.

22.5.8Segment: DG1 (Diagnosis)

 
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

Field DG1-3 (Diagnosis Code)

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.

Field DG1-4 (Diagnosis Description)

This field is only mapped if DG1-3-2 (Diagnosis Code Text) is not present.

Field DG1-5 (Diagnosis Date/Time)

The value of DG1-5 will be mapped to Condition.assertedDate.

Field DG1-6 (Diagnosis Type)

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.

Field DG1-15 (Diagnosis Priority)

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.

Field DG1-16 (Diagnosing Clinician)

If this field is populated, its value will be mapped to a Practitioner resource that is referenced by Condition.asserter.

Field DG1-20 (Diagnosis Identifier)

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.

Converting CE Fields to FHIR Extensions

The following CE fields (Coded Elements) are converted into FHIR-equivalent extensions with optional nested extensions:

  • DG1-3 (Diagnosis Code)

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; and
  • Extension URL in first extra component CE.7.

Optionally, the following may be included:

  • Text in second component CE.2; and/or
  • Nested 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.

22.5.9Segment: PR1 (Procedure)

 
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

Field PR1-1 (Set ID - PR1)

If PR1-1 is populated, the value will be stored within a procedure-sequence extension at the root of the resulting Procedure resource.

Field PR1-3 (Procedure Code)

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.

Field PR1-5 (Procedure Date/Time)

The field PR1-5 is a DTM datatype. If DTM.1 is populated, its value will be mapped to Procedure.performedDateTime.

Field PR1-19 (Procedure Identifier)

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

22.5.10Segment: MRG (Merge Patient Information)

 
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)

22.5.11Segment: GT1 (Guarantor)

 
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)

Field GT1-2 (Guarantor Number)

When use_standalone_gt1_related_person is toggled on, and this field is populate, a standalone Related Rerson resource will be created and referenced.

Otherwise, a contained resource will be created.

Field GT1-6 (Phone/Telecom List - Home)

GT1-6.2 (Telecom Use) will be assumed to be PRN (Home) if not present.

Field GT1-7 (Phone/Telecom List - Work)

GT1-7.2 (Telecom Use) will be assumed to be WPN (Work) if not present.

22.5.12Segment: IN1 (Insurance)

 
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)

Field IN1-2 (Health Plan ID)

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.

Field IN1-7 (Insurance Co Phone/Telecom List)

IN1-7.2 (Telecom Use) will be assumed to be WPN (Work) if not present.

22.5.13Segment: IN2 (Insurance Additional Information)

 
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

Field IN2-14 (Military Service)

Military Service is mapped to an extension in Patient.

Field IN2-15 (Military Rank / Grade)

Military Rank / Grade is mapped to an extension in Patient.

Field IN2-16 (Military Status)

Military Status is mapped to an extension in Patient.

Converting IS Fields to FHIR Extensions

The following IS fields (Coded Value for User-Defined Tables) are converted into FHIR-equivalent extensions with optional nested extensions:

  • IN2-14 (Military Service)
  • IN2-15 (Military Rank / Grade)
  • IN2-16 (Military Status)

Please note: A given IS field will only be converted if all three of the following are populated:

Optionally, the following may be included:

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.

Field IN2-63 (Insured's Phone/Telecom List)

IN2-63.2 (Telecom Use) will be assumed to be PRN (Home) if not present.

Field IN2-64 (Insured's Employed Phone/Telecom List)

IN2-64.2 (Telecom Use) will be assumed to be WPN (Work) if not present.

22.5.14Segment: ORC (Order Control)

 
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-9 O 0..1 TS Date/Time of Transaction
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

Field ORC-1 (Order Control)

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.

Field ORC-2 (Placer Order Number)

This field is conditionally required.

When mapping an ORM_O01 message, this field must 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).

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.

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 VXU_V04 message, this field must contain a value that will be treated as the primary identifier for the resulting resource (i.e. Immunization).

Identifiers in this field must be globally unique, and must never be reused.

Field ORC-7.4 (Start Date/Time)

For FHIR R3, this field is mapped to ProcedureRequest.occurrenceDateTime.

For FHIR R4+, this field is mapped to ServiceRequest.occurrenceDateTime.

Field ORC-9 (Date/Time of Transaction)

This field is not used when processing Immunization messages.

22.5.15Segment: OBR (Observation Request)

 
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 0123 Result Status
OBR-27 O 0..1 TQ Quantity/Timing
OBR-27.6 R ST 6 Priority

Field OBR-2 (Placer Order Number)

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.

Field OBR-3 (Filler Order Number)

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.

Field OBR-4 (Universal Service 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.

Field OBR-7 (Observation Date/Time)

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.

Field OBR-22 (Status Change Time)

This field is treated as the DiagnosticReport.issued value when mapping to FHIR.

Field OBR-24 (Diagnostic Service Section ID)

This field is treated as the DiagnosticReport.category value when mapping to FHIR.

Field OBR-27 (Quantity / Timing)

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.

22.5.16Segment: OBX (Observation)

 
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

Field OBX-5 (Value)

OBX segments may have any of the following value types:

OBX-5 Textual Observations (ST, TX, FT)

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.

OBX-5 Numeric Observations (NM)

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:

  • Whole numbers, e.g. 15
  • Non-whole numbers with arbitrary precision, e.g. 15.300
  • Negative numbers, e.g. -22.3
  • Numbers with greater-than, greater-or-equal, less-than, or less-or-equal comparator, e.g. >15.3, <15.3, >=15.3, <=15.3
  • Comparator but no number, e.g. >

All of the above values will be converted into FHIR Quantity when processing inbound HL7 v2.x messages.

OBX-5 Structured Numeric (SN)

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|

### OBX-5 Encapsulated / Binary Observations (ED)

The ED datatype can be used in OBX-5 to communicate a binary attachment. In this case, Smile CDR converters will assume that this data represents the presented form of the report.

When converting this type, the OBX segment will be handled differently from other datatypes. The binary data will be added to DiagnosticReport.presentedForm and no Observation resource will be generated for the OBX segment with the ED data.

Note that because no Observation resource is created, other fields in the OBX segment containing the ED data will be ignored. Any NTE segments associated with the individual OBS segment will also be ignored.

When converting an ED data value, OBX-5 must contain the following components:

The following example shows an OBX segment containing an ED value: OBX||ED|||^^GIF^Base64^SHD7e743ydG [..base64 content trimmed..]

OBX-5 Boolean Observations

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.

Field OBX-7 (Reference Range)

Values for this field may take one of the following forms:

  • Numeric range (e.g. 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.
  • String (anything else) – any other value that is present is treated as a freetext string range, and is not machine processable.

Field OBX-11 (Observation Status)

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.

Field OBX-14 (Effective Time)

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.

Field OBX-15 (Producer's ID)

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.

Field OBX-19 (Date/Time of Analysis)

This field is mapped to Observation.issued. This mapping is not completely semantically identical, but it is still considered a useful mapping.

ADT OBX Segments

Some ADT messaging includes OBX segments. Observation resources derived from ADT OBX segments are handled slightly differently because in practice such observations rarely include a unique business identifier. For this reason, ADT OBX segments only result in an Observation resource when all of the following are present:

  • OBX-3.1 (Observation Identifier Code), which maps to Observation.code.coding[0].code
  • OBX-3.3 (Observation Identifier System), which maps to Observation.code.coding[0].system
  • OBX-14 (Observation DateTime), which maps to Observation.effectiveDateTime

The HL7 v2.x inbound processor will use these values and a reference to the Patient to perform a conditional update operation. For example:

"request": {
  "method": "PUT",
  "url": "Observation?subject=Patient/123&code=http://loinc.org|8302-2&date=2021-07-03"
}

In practice, most ADT messages only provide precision to the day in OBX-14 (e.g. 20210703). This means an observation for a given code can be captured only once per patient per day. If multiple measurements are taken in a day, only the most recent will persist as the same Observation resource gets versioned.

Where a given message results in an Encounter resource derived from PV1, this means an observation for a given code can be captured only once per patient per day per visit. This accounts for multiple measurements taken in a day so long as they are treated as discrete encounters. In such a case, the HL7 v2.x inbound processor will use the above values, a reference to the Patient, and a reference to the Encounter to perform a conditional update operation. For example:

"request": {
  "method": "PUT",
  "url": "Observation?subject=Patient/123&code=http://loinc.org|8302-2&date=2021-07-03&encounter=Encounter/456"
}

Naturally, the greater the precision of OBX-14, the better. For example, two measurements for the same code and patient taken 12 hours apart at 20210703093042 (or 2021-07-03T09:30:42-04:00) and 20210703213042 (or 2021-07-03T21:30:42-04:00) will result in two discrete Observation resources regardless of the day or Encounter.

22.5.17Segment: NK1 (Next of Kin / Patient Contact)

 
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://terminology.hl7.org/CodeSystem/v2-0131
NK1-8 O 0..1 DT Start Date 2021-05-04
NK1-9 O 0..1 DT End Date 2026
NK1-10 O 0..1 ST Job Title
NK1-14 O 0..1 CE Marital Status
NK1-13 O 0..1 XON Organization Name
NK1-15 O 0..1 IS Administrative Sex
NK1-16 O 0..1 TS Birth Date/Time
NK1-29 O 0..1 CE Contact Reason
NK1-30 O 0..1 XPN Contact Person's Name
NK1-33 O 0..1 CX Next of Kin/Associated Party's Identifiers 0123456789^^^http://acme.org/organization

Fields NK1-3 (Relationship) and NK1-7 (Contact Role)

These fields are mapped to Patient.contact.relationship.

Field NK1-5 (Phone/Telecom List - Home)

NK1-5.1 (Telecom Use) will be assumed to be PRN (Home) if not present.

Field NK1-6 (Phone/Telecom List - Work)

NK1-6.2 (Telecom Use) will be assumed to be WPN (Work) if not present.

Field NK1-10 (Job Title)

This field does not have an obvious mapping in the Patient contact resource model, so it is mapped to an extension at the path Patient.contact with a value type of string and a URL of: https://smilecdr.com/fhir/ns/StructureDefinition/patient-contact-job-title

Fields NK1-13 (Organization Name) and NK1-33 (Next of Kin/Associated Party's Identifiers)

A standalone Organization resource will be added when use_standalone_nk113_associated_party is toggled on and identifiers are provided.

Otherwise, a contained resource will be added to the Patient.

Field NK1-14 (Marital Status)

This field does not have an obvious mapping in the Patient contact resource model, so it is mapped to an extension at the path Patient.contact with a value type of Coding and a URL of: https://smilecdr.com/fhir/ns/StructureDefinition/patient-contact-marital-status

Field NK1-16 (Birth Date/Time)

This field does not have an obvious mapping in the Patient contact resource model, so it is mapped to an extension at the path Patient.contact with a value type of DateTime and a URL of: https://smilecdr.com/fhir/ns/StructureDefinition/patient-contact-birth-datetime

Field NK1-29 (Contact Reason)

This field does not have an obvious mapping in the Patient contact resource model, so it is mapped to an extension at the path Patient.contact with a value type of Coding and a URL of: https://smilecdr.com/fhir/ns/StructureDefinition/patient-contact-reason

22.5.18Segment: NTE (Note)

 
Seq / Field Opt Card DT Len Table Description Sample
NTE-3 R 1..* FT Note Text

22.5.19Segment: FT1 (Financial Transaction)

 
Seq / Field Opt Card DT Len Table Description Sample
FT1-1 O 0..1 SI Set ID - FT1 1
FT1-2 R 1..1 ST Transaction ID 12345^http://example.com/transaction-ids
FT1-2.1 R ST Transaction ID Value
FT1-2.2 R ID Transaction ID System
FT1-4 O 0..1 DR Transaction Date
FT1-4.1 O TS Range Start 20150325000000-0000
FT1-4.2 O TS Range End 20150325000000-0000
FT1-6 O 0..1 IS 0017 Transaction Type
FT1-8 O 0..1 ST Transaction Description
FT1-10 O 0..1 NM Quantity
FT1-16 O 0..1 PL Location
FT1-20 O 0..1 XCN Performed By
FT1-21 O 0..1 XCN Ordered By

Field FT1-2: Transaction ID

The HL7 v2.x specification specifies that the transaction ID field is of type ST (string), and does not allow for a naming system to be specified. This field is used to generate the ChargeItem.identifier field when mapping from HL7 v2.x to FHIR, so a system is needed.

As a result, Smile CDR expects an additional component in this field. A valid value might be:

FT1|12345^http://example.com/charge_items

Field FT1-6: Transaction Type

This field does not have an obvious mapping in the ChargeItem resource model, so it is mapped to an extension in the ChargeItem resource with a value type of CodeableConcept and a URL of: https://smilecdr.com/fhir/ns/StructureDefinition/chargeitem-type

Field FT1-16: Location

This field does not have an obvious mapping in the ChargeItem resource model, so it is mapped to an extension in the ChargeItem resource with a value type of Reference and a URL of: https://smilecdr.com/fhir/ns/StructureDefinition/chargeitem-location

Field FT1-20: Performed By

This field does not have an obvious mapping in the ChargeItem resource model, so it is mapped to an extension in the ChargeItem resource with a value type of Reference and a URL of: https://smilecdr.com/fhir/ns/StructureDefinition/chargeitem-performed-by

Field FT1-21: Ordered By

This field does not have an obvious mapping in the ChargeItem resource model, so it is mapped to an extension in the ChargeItem resource with a value type of Reference and a URL of: https://smilecdr.com/fhir/ns/StructureDefinition/chargeitem-ordered-by

22.5.20Segment: RXA (Pharmacy Administration)

 
Seq / Field Opt Card DT Len Table Description Sample
RXA-2 C 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-15 O 0..1 ST 20 Substance Lot Number
RXA-16 O 0..1 TS Substance Expiration Date
RXA-17 O 1..1 CE Substance Manufacturer Name
RXA-17.1 C 0..1 ST 20 Identifier Value
RXA-17.2 R 1..1 ST 199 Identifier Test
RXA-17.3 C 0..1 ID 12 Name of Identifier Coding System
RXA-20 O 0..1 ID 0322 Completion Status

Field RXA-2: Administration Sub-ID Counter

RXA-2 for Medication Domain

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.

RXA-2 for Immunization Domain

This field is not used when processing immunization messages.

Field RXA-4: Date/Time End of Administration

This field is not used when processing immunization messages.

Field RXA-8: Dosage Form

This field is not used when processing Immunization messages.

Field RXA-12: Administered Time (Per Unit)

RXA-12 for Medication Domain

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

RXA-12 for Immunization Domain

This field is not used when processing immunization messages.

Field RXA-17

When populated, this field is mapped to an organization corresponding to the manufacturer of the immunization. When only a name (RXA-17.2) is supplied, the organization is created as a contained resource on the existing immunization. When RXA-17.1 is populated, it is used as the manufacturer Organization.identifier.value. It MUST be accompanied by RXA-17.3, which is used as Organization.identifier.system. If an organization with this identifier is found to already exist, it will be updated.

22.5.21Segment: RXC (Pharmacy Component)

 
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

Field RXC-3 (Component Amount) and Field RXC-4 (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.

22.5.22Segment: ZXC (Pharmacy Component)

 

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.

22.5.23Segment: RXE (Pharmacy Encoded Order)

 
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

Field RXE-1 (Quantity Timing)

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

Field RXE-1.4 (Start Date/Time) and Field RXE-1.5 (End Date/Time)

If populated, these will be treated as the start and end dates that the patient should be taking this medication.

Field RXE-2 (Give Code)

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.

Field RXE-7 (Administration Instructions)

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.

Field RXE-23 (Give Rate Amount) and Field RXE-24 (Give Rate Units)

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.

22.5.24Segment: RXR (Pharmacy Route)

 
Seq / Field Opt Card DT Len Table Description Sample
RXR-1 O 0..1 CE Route
RXR-2 O 0..1 CE Administration Site

22.5.25Segment: AL1 (Allergy Information)

 
Note that this segment is not processed by default, and must be enabled via module configuration.
Seq / Field Opt Card DT Len Table Description Sample
AL1-2 O 0..1 CE 0127 Allergen Type Code FA^Food allergy^http://terminology.hl7.org/CodeSystem/v2-0127
AL1-2.1 R 1..1 ST Allergen Type Code
AL1-2.3 R 1..1 ID Allergen Type Code System
AL1-3 R 1..1 CE Allergen Code 256259004^Pollen (Substance)^http://snomed.info/sct
AL1-3.1 R 1..1 ST Allergen Code
AL1-3.2 O 0..1 ST Allergen Code Display
AL1-3.3 R 1..1 ID Allergen Code System
AL1-4 O 0..1 CE 0128 Severity Code SV^Severe^http://terminology.hl7.org/CodeSystem/v2-0128
AL1-4.1 R 1..1 ST Severity Code
AL1-4.2 O 0..1 ST Severity Code Display
AL1-4.3 R 1..1 ID Severity Code System
AL1-5 O 0..* ST Reaction Wheezing

22.5.26Segment: IAM (Patient Adverse Reaction)

 
Seq / Field Opt Card DT Len Table Description Sample
IAM-2 O 0..1 CE 0127 Allergen Type Code FA^Food allergy^http://terminology.hl7.org/CodeSystem/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^Severe^http://terminology.hl7.org/CodeSystem/v2-0128
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

Field IAM-17 (Clinical Status)

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
# Segment: MRG (Merge)
Seq / Field Opt Card DT Len Table Description Sample

22.5.27Segment: SPM (Specimen)

 
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

Field SPM-2 (Specimen ID)

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.

22.5.28Segment: SCH (Scheduling)

 
Seq / Field Opt Card DT Len Table Description Sample
SCH-1 R 0..1 EI Placer Appointment ID 1234^http://acme.org/placer
SCH-1.1 R 1..1 ST Placer Appointment ID - ID
SCH-1.2 R 1..1 IS Placer Appointment ID - System
SCH-2 O 0..1 EI Placer Appointment ID 1235^http://acme.org/filler
SCH-2.1 R 1..1 ST Filler Appointment ID - ID
SCH-2.2 R 1..1 IS Filler Appointment ID - System
SCH-6 R 0..1 CWE Event Reason 22^Hypnotherapy
SCH-7 O 0..1 CWE 0276 Appointment Reason ROUTINE
SCH-9 O 0..1 NM Appointment Duration 30
SCH-10 O 0..1 CNE Appointment Duration Units minutes
SCH-11 O 0..1 TQ Appointment Timing Quantity ^^^201701021200-0500^201701021230-0500
SCH-11.4.1 O 0..1 DTM Start Date/Time 201701021200-0500
SCH-11.5.1 O 0..1 DTM End Date/Time 201701021230-0500
SCH-16 R 1..* XCN Filler Contact Person 2345^Smith^Jane^^^^^^http://acme.org
SCH-16.1 R 1..1 ST Person Identifier 2345
SCH-16.2 R 1..1 FN Family Name Smith
SCH-16.3 R 1..1 ST Given Name Jane
SCH-16.9 R 1..1 HD Assigning Authority http://acme.org
SCH-20 R 1..* XCN Entered By Person 2345^Smith^Jane^^^^^^http://acme.org
SCH-20.1 R 1..1 ST Person Identifier 2345
SCH-20.2 R 1..1 FN Family Name Smith
SCH-20.3 R 1..1 ST Given Name Jane
SCH-20.9 R 1..1 HD Assigning Authority http://acme.org
SCH-25 O 0..1 CWE 0278 Filler Status Code Booked

Fields SCH-1 and SCH-2 (Placer Appointment ID and Filler Appointment ID)

SCH segments are mapped to FHIR Appointment resources, with SCH-1 being used as an appointment's primary identifier. If populated, SCH-2 is added as a secondary appointment identifier.

Field SCH-6 (Event Reason)

This field is required by the V2 spec and mapped to Appointment.serviceType. As such, it should draw from the corresponding CodeSystem. In the case of a code from this CodeSystem, only SCH-6.1 need be populated. In the absence of such a code, however, Smile will map SCH-6.1 to an instance of Appoinment.serviceType.coding.code, and SCH-6.2 to the corresponding Appoinment.serviceType.coding.display.

Field SCH-7 (Appointment Reason)

If populated, this field is mapped to Appointment.reasonCode. The V2 spec mandates that the value of this field should come from Table 0276. While this table is user-defined, Smile expects the suggested values given there, and maps them to appropriate SNOMED codes, which are preferred bindings for Appointment.reasonCode in FHIR. In the case that such a code is not used but SCH-7.1 and SCH-7.2 are both present, Smile sets Appointment.reasonCode.code using the former and Appointment.reasonCode.display using the latter. In the absence of one or the other (or both), a code of "UNKNOWN" with a display of "Unknown" is set.

Fields SCH-9 and SCH-10 (Appointment Duration and Appointment Duration Units)

The first of these fields is mapped to Appointment.minutesDuration, and as such, is treated as having a value of minutes regardless of the value of SCH-10. If you wish to use other units of time besides this, others can be accounted for using a conversion script, or one could rely only on start and end to give a temporal description of the resulting appointment.

Field SCH-11 (Appointment Timing Quantity)

If populated, SCH-11.4.1 is mapped to Appointment.start, and SCH-11.5.1 to Appointment.end.

Fields SCH-16 and SCH-20 (Filler Contact Person and Enterer Contact Person)

These fields are required for the purposes of ensuring an auditable trail of people in the creation and fulfillment of appointments. Both are added to the Appointment as participants with type PART. Additionally, both are mapped to Practitioner resources.

22.5.29Segment: RGS (Resource Group Segment)

 
Seq / Field Opt Card DT Len Table Description Sample
RGS-1 O 0..1 SI Set ID - RGS 1

Note that the RGS segment is not presently mapped to FHIR; however, it is required for messages using the SIU_S12 structure.

22.5.30Segment: AIL (Location Resource)

 
Seq / Field Opt Card DT Len Table Description Sample
AIL-1 R 1..1 SI Set ID - AIL 1234
AIL-3 R 1..* PL Location Resource ID
AIL-4.1 R 0..1 CWE 0305 Location Type - AIL C (clinic)

Field AIL-3 (Location Resource ID)

This field, which is required, is mapped in the same way that PV1-3 is, and is tied to the same configuration option - to either leave it as a single location, or map it to up to three distinct locations.

Field AIL-4 (Location Type - AIL)

If populated, this field sets Location.type for each of the Location resources created in the mapping of an AIL segment. As mentioned above, the mapping expects values from V2 table 0305, and maps to the closest match in FHIR. If not populated and AIL-4.1 and AIL-4.2 are both mapped, the resultant Location.type is set using these two values. If either is not set, a value of "U" with display "Unknown" is set.

Field AIL-12 (Filler Status Code)

One might expect AIL-12 to map to Location.status, however, it is not in the scope of Location resources to track their bookings. Instead Location.status is set to active.

22.5.31Segment: AIP (Personnel Resource)

 
Seq / Field Opt Card DT Len Table Description Sample
AIP-1 R 1..1 SI Set ID - AIP 1234
AIP-3 R 1..* XCN Personnel Resource ID 5432^Smith^Jane^^^^^^http://acme.org
AIP-4 C 0..1 CWE Resource Type ADM (admitter)

Field AIP-3 (Personnel Resource ID)

This field is required, and is mapped to a Practitioner resource, as well as being added as an Appointment.participant on the appointment resulting from an SCH segment transformation as part of SIU message handling. The participant entry is marked as required and accepted.

Field AIP-4 (Resource Type)

This field technically maps to Table 0182, but as it is user-defined, and there are no suggested values, Smile expects appropriate Encounter Partiticpant Types to set Appointment.participant.type. If no Encounter Partiticpant Type is provided, this defaults to PART. Mapping from your own codes to these can be done using a pre-convert script.

AIP-12 (Filler Status Code)

The Practitioner resource has no status field, so this is not mapped to anything. Note again that there are FHIR workflow resources for tracking a practitioner's schedule.

22.5.32Segment: ZXT (Non-Standard)

 

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

Field ZXT-2 (Value Type)

This field identifies the value type in ZXT-3.

Field ZXT-3 (Value)

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!

ZXT-3 Coded Elements (CE)

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.

ZXT-3 Coded with Exceptions (CWE)

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!"
				}
			]
		}
	}
],

ZXT-3 Numeric Values (NM)

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
  }
],

ZXT-3 Textual Values (ST)

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.

Field ZXT-4 (Path)

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

22.5.33A Note about Extra Components

 

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.