27.10.1Segment Definitions

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

27.10.2Segment: MSH (Message Header)

27.10.2.1Field MSH-3 (Sending Application)

For an inbound message being consumed by Smile CDR, this field will be placed in MessageHeader.source.endpoint (MSH-3.1) and MessageHeader.source.name (MSH-3.2) when the Create Message Header for Each Message property or the Store Original HL7v2 message property is used.

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.

Note that this field has a DSTU3 mode mapping.

27.10.2.2Field MSH-4 (Sending System)

For an inbound message being consumed by Smile CDR, this field will be placed in MessageHeader.sender.identifier when the Create Message Header for Each Message property is enabled. Note this mapping requires both MSH-4.1 and MSH-4.2 to be populated with an identifier system and value respectively.

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.

27.10.2.3Field MSH-5 (Receiving Application)

For an inbound message being consumed by Smile CDR, this field will be placed in MessageHeader.destination.endpoint (MSH-5.1) and MessageHeader.destination.name (MSH-5.2) when the Create Message Header for Each Message property is used.

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.

Note that this field has a DSTU3 mode mapping.

27.10.2.4Field MSH-6 (Receiving System)

For an inbound message being consumed by Smile CDR, this field will be placed in MessageHeader.destination.receiver.identifier when the Create Message Header for Each Message property is enabled. Note this mapping requires both MSH-4.1 and MSH-4.2 to be populated with an identifier system and value respectively.

For an outbound message being generated by Smile CDR, this field can be sourced from MessageHeader.destination.receiver.identifier. See Using Persisted MessageHeader Resources for more information.

27.10.2.5Field MSH-9 (Message Type)

For an inbound message being consumed by Smile CDR, Event Type (MSH-9.2) will be used as the EventType for MessageHeader.event. If an unknown Event Type is provided, a Coding with no system, no code, and a display of "Unknown" is used.

In addition, this field will be used to infer Encounter.status. If an unknown Trigger Event is provided, a default EncounterStatus of Unknown is used.

Note that this field has a DSTU3 mode mapping.

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

27.10.3Segment: EVN (Event)

27.10.3.1Field 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.

27.10.4Segment: PID (Patient)

27.10.4.1Field 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.

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

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

27.10.4.2Field 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.

27.10.4.3Field PID-6 (Mother's Maiden Name)

Repetitions of this field are mapped to mothersMaidenName extensions on the Patient.

Note that this field has a DSTU3 mode mapping.

27.10.4.4Field 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.

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

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

Note that this field is an XTN Data Type.

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

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

Note that this field is an XTN Data Type.

27.10.4.7Field PID-17 (Religion)

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

27.10.4.8Field PID-18 (Patient Account Number)

27.10.4.9Field 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.

27.10.4.10Field 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.

27.10.4.11Field PID-27 (Veterans Military Status)

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

27.10.4.12Field PID-28 (Nationality)

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

27.10.4.13Converting 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.

27.10.5Segment: PD1 (Patient Demographics Extended)

27.10.6Segment: PV1 (Visit/Encounter)

27.10.6.1Location 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.

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.

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

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

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

27.10.6.2Field PV1-2 (Patient Class)

The PV1-2 (Patient Class) is used to infer Encounter.class. If an unknown Patient Class is provided, Encounter.class will use an IMP (Inpatient) ActEncounterCode.

Note that this field has a DSTU3 mode mapping.

27.10.6.3Field 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.

27.10.6.4Field 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.

27.10.6.5Field 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.

27.10.6.6Alternate 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.

27.10.6.7Field PV1-3 (Assigned Patient Location)

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

27.10.6.8Field 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.

27.10.6.9Field 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.

27.10.6.10Field 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.

27.10.6.11Field 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.

27.10.6.12Field 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.

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

27.10.6.14Field 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 0009.

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

27.10.6.15Field 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.

27.10.6.16Field 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.

27.10.6.17Field 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.

27.10.6.18Field 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.

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

27.10.6.20Field PV1-36 (Discharge Disposition)

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

This field is mapped to Encounter.hospitalization.dischargeDisposition which is of type CodeableConcept.

An optional extra component in PV1-36.2 may be used to specify a display name for the code used in PV1-36.1.

An optional extra component in PV1-36.3 may be used to specify a coding system for the code used in PV1-36.1.

27.10.6.21Field 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.

27.10.6.22Field PV1-41 (Account Status)

This field is mapped to Account.status. Where PV1-41 is not populated, the resulting Account.status will be populated with unknown.

Although Table 0117 - Account Status is a user-defined table for which no suggested values are defined, Account.status is a required field in FHIR with a required terminology binding. As such, the FHIR values are expected or must be mapped to.

27.10.7Segment: PV2 (Visit/Encounter Additional)

27.10.7.1Field: PV2-2 (Accommodation Code)

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

27.10.7.2Field: PV2-3 (Admit Reason)

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

27.10.7.3Field: 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

27.10.7.4Field: 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

27.10.7.5Field: 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

27.10.7.6Field: 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

27.10.7.7Field: 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

27.10.8Segment: ROL (Role)

27.10.8.1Field 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.

27.10.8.2Field 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.

27.10.8.3Field ROL-12 (Phone/Telecom List)

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

Note that this field is an XTN Data Type.

27.10.9Segment: DG1 (Diagnosis)

27.10.9.1Field DG1-1 (Set ID)

If running with Use DG1 segment id for condition.identifier.value setting enabled, the DG1-1 field must be populated, and failure to do so will result in an error.

27.10.9.2Field 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.

27.10.9.3Field DG1-4 (Diagnosis Description)

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

27.10.9.4Field DG1-5 (Diagnosis Date/Time)

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

27.10.9.5Field DG1-6 (Diagnosis Type)

If this field is not populated, the diagnosis will be mapped to Encounter.reason instead of a Condition resource. 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.

27.10.9.6Field 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.

27.10.9.7Field DG1-16 (Diagnosing Clinician)

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

27.10.9.8Field 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. Note that DG-1-6 needs to be populated in order for the Condition resource to be created.

27.10.9.9Converting 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.

27.10.10Segment: PR1 (Procedure)

27.10.10.1Field 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.

27.10.10.2Field 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.

27.10.10.3Field 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.

27.10.10.4Field 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. The identifier will be formed by the concatenation of PR1-19.1 (unique identifier) and PR1-3.1 (Code) with a hyphen in between them (e.g. 12345-6789-2W53XYZ). However, there will be no resulting Procedure if these fields are not populated.

If PR1-5 is populated, the unique identifier in PR1-19.1 will be concatenated with the value of both PR1-3.1 and PR1-5 to be the final identifier (e.g. 12345-6789-2W53XYZ-200101010700-0400).

27.10.11Segment: MRG (Merge Patient Information)

27.10.12Segment: GT1 (Guarantor)

27.10.12.1Field 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.

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

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

Note that this field is an XTN Data Type.

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

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

Note that this field is an XTN Data Type.

27.10.13Segment: IN1 (Insurance)

27.10.13.1Field 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.

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

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

Note that this field is an XTN Data Type.

27.10.14Segment: IN2 (Insurance Additional Information)

27.10.14.1Field IN2-14 (Military Service)

Military Service is mapped to an extension in Patient.

27.10.14.2Field IN2-15 (Military Rank / Grade)

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

27.10.14.3Field IN2-16 (Military Status)

Military Status is mapped to an extension in Patient.

• Identifier in first component IS.1;
• Name of Coding System in second extra component IS.3; and
• Extension URL in third extra component IS.4.

Optionally, the following may be included:

• Text in first extra component IS.2; and/or
• Nested 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.

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

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

Note that this field is an XTN Data Type.

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

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

Note that this field is an XTN Data Type.

27.10.15Segment: ORC (Order Control)

27.10.15.1ORC Segments and ServiceRequest Resources

Many of the ORC segment fields map to fields in the ServiceRequest resource, however there is no meaningful mapping for ServiceRequest.intent. Because ServiceRequest.intent is a required field, a default RequestIntent of proposal is used.

Note that this field has a DSTU3 mode mapping.

27.10.15.2Field 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.

27.10.15.3Field 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.

27.10.15.4Field ORC-5 (Order Status)

The ORC-5 (Order Status) field is used to infer ServiceRequest.status. If an unknown value is provided, a default RequestStatus of Unknown will be used.

Note that this field has a DSTU3 mode mapping.

27.10.15.5Field 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.

27.10.15.6Field ORC-9 (Date/Time of Transaction)

This field is not used when processing Immunization messages.

27.10.16Segment: OBR (Observation Request)