Point-of-Care Device Implementation Guide
1.0.0 - STU 1

Point-of-Care Device Implementation Guide, published by HL7 International / Devices. This guide is not an authorized publication; it is the continuous build for version 1.0.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/uv-pocd/ and changes regularly. See the Directory of published versions

## Mapping from IEEE 11073-10207 SDC to FHIR

Page standards status: Informative

Within the context of the ISO/IEEE 11073 Point-of-care medical device communication standards, the ISO/IEEE 11073-10207 Domain Information and Service Model defines the network representation of generic medical devices and consists of the device description and dynamic information about the current device state.

### DIM Object Classes

Most object classes in ISO/IEEE 11073 SDC can be mapped to FHIR resources as outlined in the following table.

DIM Object Class | FHIR Resource
--- | ---
MDS | Device (according to the MDS Device profile) and Location or Organization (if needed)
VMD | Device (according to the VMD Device profile)
Channel | Device (according to the Channel Device profile)
Numeric | DeviceMetric (according to the Numeric DeviceMetric profile) and Observation (according to the Numeric Observation profile or Compound Numeric Observation profile)
Enumeration | DeviceMetric (according to the Enumeration DeviceMetric profile) and Observation (according to the Enumeration Observation profile)
ClinicalInfo | Observation (according to the Observation profile)
TimeSampleArray RealTimeSampleArray DistributionSampleArray | DeviceMetric (according to the Sample Array DeviceMetric profile) and Observation (according to the Sample Array Observation profile)
Alert AlertStatus AlertMonitor | to be completed
PatientDemographics | Patient (according to the Patient profile)
OperatorDemographics | Practitioner (according to the Practitioner profile)

### SDC Object Attributes

Please refer to the Mappings tab of each profile page for mapping ISO/IEEE 11073 SDC object attributes to FHIR resource elements.

### Mapping Details

#### Patient

For each of the measurements Height and Weight, an Observation resource is required with mandatory data elements. `Observation.subject` shall be present and refer to a Patient resource or to an MDS Device resource.

Summary of the mandatory requirements for the Height:

- A coding in `Observation.category` for vital-signs with `system`='http://terminology.hl7.org/CodeSystem/observation-category' and `code`=`vital-signs`
- A coding in `Observation.code` for Body Height - Lying with `system`='http://loinc.org' and `code`=`8306-3`
- A coding in `Observation.code` for Body Height with `system`='http://loinc.org' and `code`=`8302-2` in compliance with the FHIR Vital Signs Body Length profile
- Other additional codings are allowed in `Observation.code`- e.g. more specific LOINC Codes, SNOMED CT concepts, system specific codes. All codes should have a system value.
- Either an `Observation.valueQuantity` or, if there is no value, a code in `Observation.dataAbsentReason`
  - The `Observation.valueQuantity` must have:
    - One numeric value in `Observation.valueQuantity.value`
    - a fixed `Observation.valueQuantity.system`="http://unitsofmeasure.org"
    - a UCUM unit code in `Observation.valueQuantity.code` = `cm`, or `[in_i]`

Summary of the mandatory requirements for the Weight:

- A coding in `Observation.category` for vital-signs with `system`='http://terminology.hl7.org/CodeSystem/observation-category' and `code`=`vital-signs`
- A coding in `Observation.code` for Body Weight with `system`='http://loinc.org' and `code`=`29463-7` in compliance with the FHIR Vital Signs Body Weight profile
- Other additional codings are allowed in `Observation.code`- e.g. more specific LOINC Codes, SNOMED CT concepts, system specific codes. All codes should have a system value.
- Either an `Observation.valueQuantity` or, if there is no value, a code in `Observation.dataAbsentReason`
  - The `Observation.valueQuantity` must have:
    - One numeric value in `Observation.valueQuantity.value`
    - a fixed `Observation.valueQuantity.system`="http://unitsofmeasure.org"
    - a UCUM unit code in `Observation.valueQuantity.code` = `kg`, `g`, or `[lb_av]`

#### Neonatal Patient

Information about the mother should be included in the FHIR resource RelatedPerson. `RelatedPerson.patient` should be used to reference the patient this RelatedPerson is related to. The relationship can be modeled by using `RelatedPerson.relationship` with the terminology binding `MTH`, to express that the RelatedPerson is the mother.

For each of the measurements GestationalAge, BirthLength, BirthWeight and HeadCircumference an Observation resource is required with mandatory requirements. `Observation.subject` shall be present and refer to a Patient resource or MDS Device resource.

Summary of the mandatory requirements for the HeadCircumference:

- A coding in `Observation.code` for Head Circumference with `system`='http://loinc.org' and `code`=`9843-4`
- Other additional codings are allowed in `Observation.code`- e.g. more specific LOINC Codes, SNOMED CT concepts, system specific codes. All codes should have a system value.
- Either an `Observation.valueQuantity` or, if there is no value, a code in `Observation.dataAbsentReason`
  - The `Observation.valueQuantity` must have:
    - One numeric value in `Observation.valueQuantity.value`
    - a fixed `Observation.valueQuantity.system`="http://unitsofmeasure.org"
    - a UCUM unit code in `Observation.valueQuantity.code` = `cm`, or `[in_i]`

Summary of the mandatory requirements for the BirthWeight:

- A coding in `Observation.category` for vital-signs with `system`='http://terminology.hl7.org/CodeSystem/observation-category' and `code`=`vital-signs`
- A coding in `Observation.code` for Body Weight with `system`='http://loinc.org' and `code`=`29463-7` in compliance with the FHIR Vital Signs Body Weight profile
- A coding in `Observation.code` for Birth Weight - Infant with `system`='http://loinc.org' and `code`=`8339-4` to indicate that the value applies to an infant
- Other additional codings are allowed in `Observation.code`- e.g. more specific LOINC Codes, SNOMED CT concepts, system specific codes. All codes should have a system value.
- Either an `Observation.valueQuantity` or, if there is no value, a code in `Observation.dataAbsentReason`
  - The `Observation.valueQuantity` must have:
    - One numeric value in `Observation.valueQuantity.value`
    - a fixed `Observation.valueQuantity.system`="http://unitsofmeasure.org"
    - a UCUM unit code in `Observation.valueQuantity.code` = `kg`, `g`, or `[lb_av]`

Summary of the mandatory requirements for the BirthLength:

- A coding in `Observation.category` for vital-signs with `system`='http://terminology.hl7.org/CodeSystem/observation-category' and `code`=`vital-signs`
- A coding in `Observation.code` for Body Height with `system`='http://loinc.org' and `code`=`8302-2`
- A coding in `Observation.code` for Birth Length - Infant with `system`='http://loinc.org' and `code`=`89269-5` to indicate that the value applies to an infant
- A coding in `Observation.code` for Body Height - Lying with `system`='http://loinc.org' and `code`=`8306-3`
- Other additional codings are allowed in `Observation.code`- e.g. more specific LOINC Codes, SNOMED CT concepts, system specific codes. All codes should have a system value.
- Either an `Observation.valueQuantity` or, if there is no value, a code in `Observation.dataAbsentReason`
  - The `Observation.valueQuantity` must have:
    - One numeric value in `Observation.valueQuantity.value`
    - a fixed `Observation.valueQuantity.system`="http://unitsofmeasure.org"
    - a UCUM unit code in `Observation.valueQuantity.code` = `cm`, or `[in_i]`

Summary of the mandatory requirements for the GestationalAge:

- A coding in `Observation.code` for Gestational Age with `system`='http://loinc.org' and `code`=`72147-2`
- Other additional codings are allowed in `Observation.code`- e.g. more specific LOINC Codes, SNOMED CT concepts, system specific codes. All codes should have a system value.
- Either an `Observation.valueQuantity` or, if there is no value, a code in `Observation.dataAbsentReason`
  - The `Observation.valueQuantity` must have:
    - One numeric value in `Observation.valueQuantity.value`
    - a fixed `Observation.valueQuantity.system`="http://unitsofmeasure.org"
    - a UCUM unit code in `Observation.valueQuantity.code` = `d`

#### Location

For every physicalType of a Location an additional Location resource needs to be created. If this Location is physically a part of another Location they can only be connected via a `Location.partOf` reference to the other Location. It is working in the same way with the managing Organization. Both need to reference the lowest Location or Organization in the hierarchy because the references point upwards.

IEEE 11073 SDC | HL7 FHIR Resources | Comment
--- | --- | ---
LocationContextState/Identification/Root | `Location.identifier.system` |
LocationContextState/Identification/Extension | `Location.identifier.value` |
LocationContextState/LocationDetail/Bed | `Location.physicalType` | An additional Location resource with the physicalType `bd` and references (`Location.partOf` and/or `Location.managingOrganization`) to another Location/Organization if the Bed is physically a part of a Location/Organization
LocationContextState/LocationDetail/Room | `Location.physicalType` | An additional Location resource with the physicalType `ro` and references (`Location.partOf` and/or `Location.managingOrganization`) to another Location/Organization if the Room is physically a part of a Location/Organization
LocationContextState/LocationDetail/PoC | `Organization.type` | An additional Organization resource with the Organization type `dept` and a reference (`Organization.partOf`) to another Organization if the PoC is part of an Organization
LocationContextState/LocationDetail/Floor | `Location.physicalType` | An additional Location resource with the physicalType `lvl` and references (`Location.partOf` and/or `Location.managingOrganization`) to another Location/Organization if the Floor is physically a part of a Location/Organization
LocationContextState/LocationDetail/Building | `Location.physicalType` | An additional Location resource with the physicalType `bu` and references (`Location.partOf` and/or `Location.managingOrganization`) to another Location/Organization if the Building is physically a part of a Location/Organization
LocationContextState/LocationDetail/Facility | `Organization.type` | An Organization Resource with the Organization type `prov` and a reference (`Organization.partOf`) to another Organization if the Facility is part of an Organization

#### ImagingStudy

The WorkflowContextState should only be used if the ContextAssociation is `Assoc` (=Associated). The ImagingProcedure/RequestedProcedureId can be mapped to the id of the basedOn reference, which exists when the ImagingProcedure is based on a ServiceRequest.

IEEE 11073 SDC | HL7 FHIR resources |
--- | --- | ---
WorkflowContextState/WorkflowDetail/RequestedOrderDetail/ImagingProcedure/AccessionIdentifier/Root WorkflowContextState/WorkflowDetail/RequestedOrderDetail/ImagingProcedure/StudyInstanceUid/Root | `ImagingStudy.identifier.system` |
WorkflowContextState/WorkflowDetail/RequestedOrderDetail/ImagingProcedure/AccessionIdentifier/Extension WorkflowContextState/WorkflowDetail/RequestedOrderDetail/ImagingProcedure/StudyInstanceUid/Extension | `ImagingStudy.identifier.value` |
WorkflowContextState/WorkflowDetail/RequestedOrderDetail/ImagingProcedure/Modality/Code | `ImagingStudy.modality.code` |
WorkflowContextState/WorkflowDetail/RequestedOrderDetail/ImagingProcedure/Modality/CodingSystem | `ImagingStudy.modality.system` |
WorkflowContextState/WorkflowDetail/RequestedOrderDetail/ImagingProcedure/Modality/CodingSystemVersion | `ImagingStudy.modality.version` |
WorkflowContextState/WorkflowDetail/RequestedOrderDetail/ImagingProcedure/ProtocolCode/Code | `ImagingStudy.procedureCode.coding.code` |
WorkflowContextState/WorkflowDetail/RequestedOrderDetail/ImagingProcedure/ProtocolCode/CodingSystem | `ImagingStudy.procedureCode.coding.system` |
WorkflowContextState/WorkflowDetail/RequestedOrderDetail/ImagingProcedure/ProtocolCode/CodingSystemVersion | `ImagingStudy.procedureCode.coding.version` |

#### ServiceRequest

The WorkflowContextState should only be used if the ContextAssociation is `Assoc` (=Associated). The resource ServiceRequest may be used to share relevant information required to support a referral or a transfer of care request from one practitioner or organization to another.

IEEE 11073 SDC Status | HL7 FHIR | Comment
--- | --- | ---
WorkflowContextState/WorkflowDetail/AssignedLocation | `ServiceRequest.locationReference` |
WorkflowContextState/WorkflowDetail/RelevantClinicalInfo | `ServiceRequest.supportingInfo` |
WorkflowContextState/WorkflowDetail/RequestedOrderDetail/Performer | `ServiceRequest.performer` |
WorkflowContextState/WorkflowDetail/RequestedOrderDetail/ReferringPhysician WorkflowContextState/WorkflowDetail/RequestedOrderDetail/RequestingPhysician | `ServiceRequest.requester` | The resource ServiceRequest may be used to share relevant information required to support a referral or a transfer of care request from one practitioner or organization to another. Therefore, both the RequestingPhysician and the ReferringPhysician are mapped to the `ServiceRequest.requester`. If both exist, there should be a reference (`ServiceRequest.basedOn`) from the RequestingPhysician to the ReferringPhysician.
WorkflowContextState/WorkflowDetail/PerformedOrderDetail/ResultingClinicalInfo | `DiagnosticReport.result` |

#### Valuesets

##### Valuesets for AbstractDeviceComponentState/ActivationState:

IEEE 11073 SDC Status | HL7 FHIR `Device.statusReason` | Comment
--- | --- | ---
`On` | `online` |
`NotRdy` | `not-ready` |
`StndBy` | `standby` |
`Off` | `off` |
`Shtdn` | `not-ready` |
`Fail` | `not-ready` |

##### Valuesets for AbstractMetricState/ActivationState:

IEEE 11073 SDC Status | HL7 FHIR `DeviceMetric.operationalStatus` | Comment
--- | --- | ---
`On` | `on` |
`NotRdy` | `off` |
`StndBy` | `standby` |
`Off` | `off` |
`Shtdn` | `off` |
`Fail` | `off` |

##### Valuesets for MetricCategory:

IEEE 11073 SDC MetricCategory | HL7 FHIR `DeviceMetric.category` | Comment
--- | --- | ---
`Unspec` | `unspecified` |
`Msrmt` | `measurement` |
`Clc` | `calculation` |
`Set` | `setting` |
`Preset` | `unspecified` |
`Rcmm` | `unspecified` |

##### Valuesets for calibration state:

IEEE 11073 SDC ComponentCalibrationState | HL7 FHIR `DeviceMetric.calibration.state` | Comment
--- | --- | ---
`No` | `not-calibrated` |
`Req` | `calibration-required` |
`Run` | `not-calibrated` |
`Cal` | `calibrated` |
`Oth` | `unspecified` |

##### Valuesets for calibration type:

IEEE 11073 SDC ComponentCalibrationType | HL7 FHIR `DeviceMetric.calibration.type` | Comment
--- | --- | ---
`Offset` | `offset` |
`Gain` | `gain` |
`TP` | `two-point` |
`Unspec` | `unspecified` |

##### Measurement Validity

Observed values in ISO/IEEE 11073 SDC include a field that indicates measurement validity. FHIR Observations do not have a single element for this purpose. Instead there is security metadata, `dataAbsentReason` for missing values, and `interpretation` to report significance of a result.
Measurement validity information is mapped to `Observation.meta.security`, `Observation.dataAbsentReason` or `Observation.component.dataAbsentReason`, and `Observation.interpretation` or `Observation.component.interpretation` elements. The `interpretation` value set binding is extended to add relevant codes from the Measurement status codes defined in this implementation guide.

MeasurementValidity | `meta.security` | `dataAbsentReason` | `interpretation`
--- | --- | --- | ---
`Vld` | `RELIABLE` |  |
`Vldated` | `HRELIABLE` |  | `validated-data`
`Ong` |  | `temp-unknown` | `msmt-ongoing`
`Qst` | `UNCERTREL` |  | `questionable`
`Calib` | `UNCERTREL` |  | `calibration-ongoing`
`Inv` | `UNRELIABLE` | `error` |
`Oflw` |  |  | `>`
`Uflw` |  |  | `<`
`NA` |  | `not-performed` |

Note that `dataAbsentReason` and `interpretation` are mutually exclusive: `dataAbsentReason` shall only be present if there is no observation value, whereas `interpretation` adds relevant information about an existing observation value.

#### CalibrationInfo at MDS and VMD Level

In ISO/IEEE 11073-10207 SDC, `CalibrationInfo` is part of `AbstractDeviceComponentState` and can therefore appear at the MDS, VMD, or Channel state level. For example, an anesthesia device may be required to perform a daily self-test, where `ComponentCalibrationState` transitions from `Req` (required) after system boot to `Cal` (calibrated) following a successful self-test. VMDs may also have specific calibration requirements.

The current PoCD profiles define `DeviceMetric.calibration` mappings at the Channel level (see the calibration state and calibration type value set tables above), but do not address CalibrationInfo when it is associated with MDS or VMD state.

Representing MDS/VMD-level calibration information in FHIR requires further analysis. Possible approaches include:

- An extension on the Device resource (for MDS or VMD Device profiles) to carry calibration state and type at those levels.
- Using DeviceMetric resources with `DeviceMetric.parent` referencing the VMD or MDS Device, combined with Observation resources for calibration result values.

Additionally, when calibration involves human interaction, multiple Observations may be needed to capture different aspects such as error codes and interaction identifiers.

This is tracked as an open issue in FHIR-51356.