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

Consuming the PHD Profile FHIR Resources

This chapter is for those whose use cases require measurement data from Personal Health Devices (PHD) and need that data in FHIR format. In most cases PHDs are used when the measurements are taken by individuals who are not medical professionals and outside of the health care provider's institution. The individuals could be patients recovering at home from a serious operation, diabetics managing their condition while trying to live as normal a life as possible, or athletes wearing fitness devices keeping track of their training. Point of Care Devices (PoCD) used in acute care are not covered by this IG. There is a separate implementation guide here for such devices.

It is important to understand that this Implementation Guide (IG) assumes that the source of the data is from communicating PHDs. This IG does NOT cover measurement data entered manually, such as a pulse rate taken by putting one's fingers on the wrist, or reading data from a non-communicating medical device.

PHGs following this IG use the following FHIR resources: Patient, Device, DeviceMetric and Observation. A Device resource is used for the PHG properties and a second Device resource is used for the PHD properties. Observation resources are used for each measurement and for the Coincident Timestamp Observation.

Understanding the content of the FHIR resources specified in this IG should be straight forward. Familiarity with the MDC coding system is the only IEEE 11073 domain-specific knowledge required. In addition, there are a few extensions used in the PHD-related profiles. One supports a reference to the Personal Health Gateway (PHG) Device resource in the PHD Observation profiles. A PHG is the unit that is typically responsible for communicating with the PHD and encoding that data into FHIR. It may be a mobile phone, a PC, or a dedicated set-top box. Another supports linking the timelines of the PHG and the PHD via a Coincident Timestamp Observation.

The next sections discuss the resources generated by PHGs following this IG.

The Measurement Observation Resources

PHDs measurements are encoded into Observation resources. There are different types of measurement values that can be reported by PHDs. Each measurement value type has its own profile but the profiles differ only in the way the value of the measurement is reported in the Observation resource. The supported measurement value types are:

• numeric such as a temperature, weight, glucose concentration, pulse rate, blood oxygen saturation, or miles run.
• coded such as the meal context and health status in a glucose monitor. A coded measurement is used when there is a limited set of options and each option is specified by a code.
• sample array (often waveforms) such as an ECG trace, a forced exhalation flow rate from a spirometer, a pleth wave of a pulse oximeter, or a sequence of heart rates.
• string measurements which are normally human-readable strings.
• discrete state or event measurements report multiple related boolean conditions that can occur at the same time. They are typically used for reporting device status conditions such as for an ECG "Loss of 1st lead signal" and "Loss of 3rd lead wire or electrode connection". Each of the reported conditions is represented as a separate component with a boolean value (in the Observation.component.value[x] element).
• compound where multiple measurements at a single point in time need to be taken together to represent the value, such as the systolic, diastolic, and mean components of the blood pressure or x-, y-, and z- components of an acceleration.

Common Observation Element Fields

Every PHD generated measurement Observation resource contains the following information regardless of the measurement value type:

In this section each of the fields summarized above is discussed.

The Measurement Type: Observation.code.coding.code

The measurement type tells what the measurement is. In HL7 such information is typically done through codes and it is no different here. However, one must understand the coding system in order to interpret what the code means. Consumers of the PHD profiles must understand the MDC code system to interpret the measurement. One can find more information about the MDC code system here.

MDC codes are available from the Rosetta Terminology Mapping Management Service (RTMMS). It provides descriptions and, if applicable, the units associated with the measurement in both MDC and UCUM. Equivalent LOINC codes are also provided. The Rosetta system is updated on a regular basis with new codes and corrections.

For those consumer applications that would like to have the codes as LOINC and the uploader did not provide them, a mapping table between MDC and LOINC is also included in LOINC since v2.54 available here. The FHIR MDC to LOINC concept map is available here. One may freely download and use this material as needed in an implementation, but it does require a (free) login account. A mapping from MDC to SNOMED CT for some of the more common codes is available in the somewhat outdated Continua Design Guidelines H.813 HIS Interface document. The guidelines are freely available for download, however licensing requirements for the use of the SNOMED CT code system apply.

FHIR requires that a LOINC code is present if the measurement is one of the vital signs given here. In that case, the Observation.code shall have at least a second coding element containing a LOINC code. The consumer must be aware that the MDC-to-LOINC mapping may be many to one. For example, both the pulse rate obtained from a Blood Pressure Cuff (149546) and the pulse rate obtained from a Pulse Oximeter (149530) may be mapped to the LOINC code (8867-4). A PHG may map these MDC codes also to more specific LOINC codes.

In addition to the LOINC code, FHIR requires an Observation.category element with value "vital-signs" when the measurement is a vital sign.

Measurement Status

In normal situations PHD reported Observation resources have a Observation.status element set to "final". However, every real device is going to experience challenges at some time. These challenges can interfere with the measurement and therefore need to be reported. One could argue that measurements with errors should not be delivered, but in a scenario where the PHG might be headless and one is happy that the patient can even take the measurement, it may be important to know that the measurement attempt was made. Therefore this IG supports a PHG to report any measurement it receives from a PHD including error states and let downstream consumers address it.

There are other non-error special conditions that may also be reported, such as the measurement is test or demo data.

Depending upon what the special condition is, it is reported in either the dataAbsentReason, interpretation, or meta.security element. All of these entries are CodeableConcepts. When the condition is reported in the dataAbsentReason, there will be no measurement value entry in accord with the FHIR specification, even if the PHD reports a measurement value. Note that there may be multiple interpretation entries but only one dataAbsentReason element.

The exact mapping of IEEE 11073-10206 Observation status conditions to FHIR is covered in the PhdBaseObservation profile.

In addition to the conditions listed above, when the measurement value is a quantity, PHDs may also report one of a set of special FLOAT values, "Not a Number", "Not at this resolution", "Positive infinity", or "Negative infinity". These errors can results from a failure of the floating point software or hardware, or the inability of the sensor to completely acquire a value. These errors are reported in the dataAbsentReason element and will be discussed in the sections discussing the measurement values. "Not a Number" is the most common special condition reported by PHDs currently on the market. Reporting of the other special situations listed above are, in practice, rare.

The Timestamp: Observation.effective[x]

All measurements contain a time stamp which is either an instant in time (a dateTime data type), or a period of time (a Period data type). A period reported by a PHD has both a start and an end. Results of a workout session are a common type of measurement with a period. The dateTime data type is chosen as it is permissible for PHDs to report time at resolutions greater than a day in which case there is no time zone. An activity monitor reporting only daily summaries could be an example of a PHD using such a time resolution.

All timestamps with resolutions finer than a day contain the offset to UTC. If the offset is -00:00, it means that the offset to local time is not known, and what is being reported is UTC time, even though the measurement is taken in Japan. If the offset is +00:00, it means the offset IS known; the measurement just happens to be in a time zone that is UTC.

Below is an example of the effective[x] when the timestamp is an instant in time:

{
  "resourceType" : "Observation",
  ...
  "effectiveDateTime" : "2025-01-08T19:07:48-05:00",
  ...
}

The PHG reference extension

The reference to the Device resource containing the PHG properties is encoded in an extension element. An example of the PHG extension is shown below:

{
  "resourceType" : "Observation",
  ...
  "extension" : [
    {
      "url" : "http://hl7.org/fhir/StructureDefinition/observation-gatewayDevice",
      "valueReference" : {
        🔗 "reference" : "Device/phg-ecde3d4e58532d31.000000000000"
      }
    },
    ...
  ]
}

The Patient reference: Observation.subject:

The reference to the Patient resource containing information about the patient upon whom the measurement was taken is placed in the Observation.subject element. In many cases the patient is also the person that is taking the measurement. In other cases a general physician may be using a PHD in his clinic. When known to the gateway a reference to the performer may be present in an Observation.performer element.

The PHD reference

The reference to the PHD device is placed in the Observation.device element. There is a dedicated profile for the PHD device that is used to capture the system information, clock and power information that the PHG receives from the PHD.

Other Observation Elements

In addition to the elements that are always present, the following set of elements may be present.

The Profile: Observation.meta.profile

An Observation may contain a meta.profile element that can help to identify the type of the Observation. For example, if Observation.profile entry contains "http://hl7.org/fhir/uv/phd/StructureDefinition/PhdNumericObservation" the measurement is a scalar. Note that there is no requirement that the profile element be present. If it is not present, the consumer can determine the type of measurement value by looking at the Observation.value[x] element.

The Coincident Timestamp extension

When present, the consumer can obtain further information about the timestamp from a referenced coincident timestamp Observation that adheres to the PhdCoincidentTimeStampObservation profile. This reference may be present in the CoincidentTimeStampReference extension. If the reference is NOT present, it means that the PHD did not provide a timestamp and the PHG used the time of reception as the timestamp or that the PHG determined that the PHD timestamp is reliable and can be used as is. PHDs that send stored data shall include timestamps in their measurements.

The Coincident Timestamp Observation can be used to determine the PHD's timeline and clock status. It can also be used to see if the PHG needed to correct the timestamp, and if it did, by how much. An example of the Coincident Timestamp extension is shown below:

{
  "resourceType" : "Observation",
  ...
  "extension" : [
    ...
    {
      "url" : "http://hl7.org/fhir/uv/phd/StructureDefinition/CoincidentTimeStampReference",
      "valueReference" : {
        🔗 "reference" : "Observation/coin-20181119174911"
      }
    },
    ...
  ]
}

Related Observations

There are situations where a given Observation is derived from or part of another Observation such as a BMI observation being derived from a height and weight measurement. In that case the Observation will have Observation.derivedFrom elements that point to the Observation resources containing the height and weight measurement. Another common case where an Observation references another Observation is in an activity monitor. Results of an exercise session such as miles run, calories burned, average and maximum heart rates, etc. are reported as Observations where each Observation is referenced from the master session Observation in an Observation.hasMember element.

An example of a reference to another Observation is shown below:

{
  "resourceType" : "Observation",
  ...
  "derivedFrom" : [
    {
      🔗 "reference" : "Observation/compound-numeric-blood-pressure"
    }
  ],
  ...
}

Additional Descriptive Data

In this section we further define Observation details that a PHD may provide but are uncommon. The reader may wish to skip to to the description of the measurement values sections here and return to this section when relevant.

PHDs can send measurements that have additional descriptive information. An example would be a pulse oximeter indicating the modality used when taking the measurement. Some of the additional information reported can only occur if the measurement value is a of a specific value type such as a quantity. This additional information is reported in an Observation.component or an Observation.extension element. The type of additional information is given by the Observation.component.code or Observation.extension.url element. The value of such additional information is given by an Observation.component.value[x] or an Observation.extension.value[x] element. PHDs support the following types of additional information:

More details on the extensions that can be used with quantities can be found in the PhdNumericObservation profile.

Supplemental Types

Supplemental type information is indicated by the Observation.component.code element having the value 68193. The value type of a supplemental type entry is always a CodeableConcept and is therefore given by Observation.component.valueCodeableConcept.coding.code. There may be more than one Observation.component entry containing supplemental type information. An example of a supplemental types component entry is as follows:

{
  "resourceType" : "Observation",
  ...
  "component" : [
    {
      "code" : {
        "coding" : [
          {
            "system" : "urn:iso:std:iso:11073:10101",
            "code" : "68193",
            "display" : "MDC_ATTR_SUPPLEMENTAL_TYPES"
          }
        ]
      },
      "valueCodeableConcept" : {
        "coding" : [
          {
            "system" : "urn:iso:std:iso:11073:10101",
            "code" : "150588",
            "display" : "MDC_MODALITY_SPOT"
          }
        ]
      }
    }
  ]
}

A 'spot modality' means that the pulse oximeter sensed over a period long enough to obtain a stable average.

Should we move Supplemental Type information to an extension? In the PHD IG v1.0 an attempt was made to avoid extensions as much as possible. In this version we are using extensions for less-often used elements of the IEEE 11073 PHD ACOM model and in places were the PHD model and the FHIR model for observation are too different to have a 1-1 mapping between data elements of these models. The question is if this applies to Supplemental Type information as well. - Is it appropriate to map IEEE supplemental information to `observation.component` as a generic and pragmatic solution? - Moving forward, should IEEE 11073-10206/20601 Supplemental Information be modeled as a FHIR `Observation.component` or as an extension in FHIR? Input is welcome!

Identifier

To prevent data duplication during uploads, and enable use of conditional create transactions, identifiers are provided for the Observations described in this IG. No additional meaning is associated with those identifiers. Details can be found in the Identifier section. Other systems may add further identifiers.

Measurement Values that are numeric or scalar

Scalar numeric measurements are the most common type of measurement reported by PHDs. Temperature, weight, height, miles run, pulse rate, etc. are examples. Scalar numeric measurements are reported in Observation resources following the Phd Numeric Observation Profile. The scalar values are reported in the Observation.valueQuantity element.

Normally the Observation.valueQuantity is populated with the scalar value, the units, and the system. The units and system are UCUM unless the PHG does not know the UCUM translation for the MDC unit code. The latter can happen if a new specialization, written after the PHG was implemented, introduces a new MDC unit code not previously used in PHDs. The scalar value is reported with the precision indicated by the PHD. Thus 2 and 2.00 represent the same value but measured to a different precision.

If the PHD reports a special FLOAT value an Observation.dataAbsentReason element replaces the valueQuantity and there is no value[x] element.

If a special FLOAT value is reported an Observation.dataAbsentReason then this replaces the valueQuantity. The dataAbsentReason is a CodeableConcept and will have the following possible codes from the data absent reason coding system "http://terminology.hl7.org/CodeSystem/data-absent-reason":

• Observation.dataAbsentReason.coding.code="not-a-number"
• Observation.dataAbsentReason.coding.code="positive-infinity"
• Observation.dataAbsentReason.coding.code="negative-infinity"
• Observation.dataAbsentReason.coding.code="error"

The Observation.system in the above cases is always

• Observation.dataAbsentReason.coding.system="http://terminology.hl7.org/CodeSystem/data-absent-reason"

An example of the valueQuantity in the Phd Numeric Observation Profile for a thermometer reporting a value in °C is as follows:

{
  "resourceType" : "Observation",
  ...
  "valueQuantity" : {
    "value" : 36.5,
    "unit" : "C",
    "system" : "http://unitsofmeasure.org",
    "code" : "Cel"
  },
  ...
}

Measurement Values that are Compounds

IEEE 11073-10206 (ACOM) supports compound observations where the components can have a numeric, a string, a code or a sample array value. This type of observation is mapped to the Phd Compound Observation profile.

There is no primary Observation.value[x] entry and there is no Observation.dataAbsentReason unless the entire measurement had an error, in which case there will be no compound entries either. It is possible for each compound entry to have its own error and that will be reported in an Observation.component.dataAbsentReason element. All Observation.component entries could have dataAbsentReason entry but that does NOT mean the entire measurement has an Observation.dataAbsentReason entry. It is also possible that a component will have its own interpretation element of the same type as shown in the Measurement Status section. Currently there are no market PHDs that generate an Observation.component.interpretation element.

Compound Observations will have a code indicating what the 'entire' measurement is, for example, non-invasive blood pressure or acceleration. Each Observation.component element will have its own code describing each individual compound or vector entry, for example, the systolic, diastolic, and mean pressures for the blood pressure or x-, y-, and z-projections of an acceleration.

Each Observation.component will have the following:

Measurement Values that are Numeric Compounds

IEEE 11073-20601 does only support compound measurements with numeric components. These observations adhere to the Phd Compound Numeric Observation Profile ("http://hl7.org/fhir/uv/phd/StructureDefinition/PhdCompoundNumericObservation"). For the numeric components the following applies:

Note that the Observation.component.code element is subject to the same FHIR LOINC code requirement as the Observation.code element if the component is one of the vital signs here. The Systolic and Diastolic pressures are in that list, but the MEAN component is not.

See the blood pressure observation example for details on Observation.code, Observation.category, and Observation.component entries.

The Phd Compound Numeric Profile can contain additional entries as noted in the Additional Descriptive Data section above. However, the codes of all Observation.component entries that are part of a compound measurement will always have an MDC code and not a code from the ASN1ToHL7 code system.

Remark on compound observations

The decision to report a compound observation versus independent observations is made by the designers of the IEEE PHD device specialization standards. The IEEE PHD and FHIR policies to choose between these options are similar. This IG maps an ACOM compound observation to a FHIR Observation resource with multiple components.

Measurement Values that are Codes

Sometimes the PHD measurement value is a code. The code comes from the MDC code system. Measurements that are codes follow the Phd Coded Enumeration Observation profile.

The measurement value is reported in an Observation.valueCodeableConcept element. Coded measurements are usually 'context' measurements that provide extra information about another measurement. They will often have an Observation.derivedFrom reference pointing to the Observation resource they support. There are no coded enumeration measurements that are vital signs.

An example of a coded measurement is a meal context in a glucose monitor:

{
  "resourceType" : "Observation",
  ...
  "valueCodeableConcept" : {
    "coding" : [
      {
        "system" : "urn:iso:std:iso:11073:10101",
        "code" : "8417872",
        "display" : "MDC_CTXT_GLU_MEAL_POSTPRANDIAL"
      }
    ],
    "text" : "After lunch/dinner"
  },
  ...
}

This measurement indicates that the glucose concentration measurement was taken after a meal.

Measurement Values that are sets of Events or States

PHDs support a measurement value type that indicate a set of states or events, for example, an independent living monitor may be surveilling an elderly patient's room and report its current state 'door closed', 'window closed', 'climate control on', 'patient in room', and 'lights off'. The report may have been triggered by an event like 'patient entered room'. (There is no such measurement type as a current room state but it illustrates the concept.) PHDs have an efficient way to package such reports into a single integer. This type of reporting is done when more than one state and/or event can occur simultaneously. In order to understand such a report one has to know what the state or event is, and its value. States and events are binary. A state is either on or off and an event either happens or it doesn't. There is no corresponding HL7 data type for this kind of measurement thus the ASN1ToHL7 code system has been developed to express these states and events as codes. A Boolean is used to express the corresponding values.

Measurement values of this type are mapped to an Observation following the Phd Bits Enumeration Observation profile.

Each event or state is reported in a component element. The Observation.component.code will be the ASN1ToHL7 code indicating what the state or event is. The value of the state or event will be a Boolean value. It should be noted that 'state' values must be reported for either state. It is as important to know whether the door is opened or closed. Events are only required to be reported when they happen.

Implementers should not make any assumption about the state assignment. For example, to assume that 'something opened' is signified by a true can lead to misinterpretation. The monitor specification may have been designed with the idea that everything closed was the desired state and signified it with true. The ASN1ToHL7 code system will have the assignment and readers will need to examine it.

PHD can indicate that is does not support certain state or event flags in a given measurement report. This situation is expressed by replacing the Observation.component.valueCodeableConcept element with an Observation.component.dataAbsentReason element with reason "unsupported". Currently there are no market PHDs that support this feature.

Observations following the Phd Bits Enumeration Observation profile have no primary Observation.value[x] entry and there is no Observation.dataAbsentReason unless the entire measurement has an error, in which case there will be no state or event entries either. It is possible for each state or event entry to be unsupported and that will be reported with a Observation.dataAbsentReason element. Even if every Observation.component entry reports 'unsupported' that does not have the same meaning as the entire measurement being in error.

In structure these Observations are similar to compound Observations. It is also possible that 'additional descriptions' as discussed in the Additional Descriptive Data section are present.

Each Observation.component entry will have the following:

The 'independent living' example mentioned above does not currently exist in any specialization but it is illustrative of the concept. However, a pulse oximeter device sensor status measurement containing several different events does exist. An example of such a measurement can be found here

All of the entries are events in this example so the values are always true indicating the event occurred. One might note that the ANS1ToHL7 code 150604.x in all cases contains the MDC code of the measurement 150604. That relationship will always be true for all event and state measurement value types.

Periodic measurements

Periodic measurements are typically waveforms like ECG traces and are a sequence of scalars. Measurement values that fall into this category are mapped to an Observation following the Phd Rtsa Observation profile. 'Rtsa' means real time sample array.

Periodic measurements are reported in Observation.valueSampledData data elements as follows:

To obtain the original values of the measured sequence one uses the following equation:

original_value[i] = valueSampledData.scaleFactor * valueSampledData.data[i] + valueSampledData.origin.value

or the familiar equation of a line

 y(i) = mx(i) + b

The upperLimit and lowerLimit elements are for convenience and are not necessary for decoding the data. They can be used when plotting the data as they give the upper and lower bounds of the trace at any time. One can create a graph with these limits without examining the sequence.

It is possible that the periodic measurement is a vital sign, for example, a heart rate. If it is a vital sign, the same FHIR-required LOINC code requirements apply as they do for scalar and vector measurements.

String measurements

PHDs can send a measurement value that is a human readable string. An example of such a measurement might be the name of a customized exercise program on a piece of gym equipment. String measurement values are mapped to an Observation following the PhdStringObservation profile. The string is reported in an Observation.valueString element.

An example of this measurement is as follows:

{
  "resourceType" : "Observation",
  ...
  "valueString" : "Test Strip Buckled",
  ...
}

The PHD Coincident Timestamp Observation Resource

The coincident timestamp is a comparison of the PHD's and PHG's timelines. PHDs have limited resources and are often battery driven and may depend upon the user or the PHG to set its time, though it is possible for PHDs to support an external time synchronization method. The timelines of PHDs can therefore be dubious. PHGs are required to support external time synchronization and if possible, to obtain the local offset to UTC.

In the PHD-PHG exchange, the PHG retrieves the PHD's current time, time synchronization state, and accuracy. At the time of the query the PHG also records its current time. The PHG compares the two timelines, the two states of synchronization, and the two states of synchronization accuracy as far as available. If the PHG is better synchronized, the PHG will correct the PHD reported times by the difference between the two timelines. The PHG may also set the PHD's time if the PHD supports it and when needed, bringing the two timelines into synchrony.

If the PHD is better synchronized than the PHG, the PHG reports the PHD's times unaltered.

The coincident timestamp also indicates whether there is a time fault. In the case of relative times, the coincident timestamp provides the 'anchor' that allows the PHG to create wall clock times from the PHD's 'tick' values. PHDs use tick counters or relative time as they are much simpler to implement than a civil-time or UTC clock that needs to track day, month and year boundaries and possibly needs to handle DST adjustments.

The following core information is available from the coincident timestamp observation:

If the Observation containing the measurement has no reference to a coincident timestamp, it means the PHD provided no measurement timestamp and the PHG used the time of reception as the current timestamp.

The coincident timestamp follows the Phd Coincident Timestamp Observation Profile.

The information provided by this Observation is mostly for auditing, but readers could check whether or not there is a time fault.

The PHD Device Resource

The PHD Device resource follows the Phd Device Profile.

The PHD Device resource contains the following information about the PHD in the following elements:

• Device.identifier
  • IEEE EUI-64 System identifier
  • IEEE EUI-48 Bluetooth Address if the PHD uses Bluetooth transports
  • EUI-64 ZigBee address if the PHD uses ZigBee transports
• Device.udiCarrier
  • UDI (Unique Device Identifier) string
  • UDI issuer
  • UDI regulatory authority
• Device.manufacturer
  • Manufacturer name
• Device.modelNumber
  • Model number
• Device.serialNumber
  • serial number
• Device.partNumber
  • part number
• Device.type
  • PHD (Simple MDS) (fixed value)
• Device.version
  • firmware version
  • hardware version
  • software version
  • protocol version
  • Continua version
• Device.specialization
  • Specialization (Blood pressure, thermometer, etc.)
  • Specialization version
• Device.property
  • Time clock capabilities
  • Time clock synchronization method
  • Time synchronization accuracy
  • Time clock resolution
  • Regulation status
  • Certified transports and specializations

The bold items are required to be reported by all PHDs and the italicized items are exposed by most PHDs. The transport addresses are only exposed in the transport protocol and are, of course, only applicable to PHDs using that transport. It is encouraged by the PHG implementer to add the wireless transport address identifiers since these numbers are often available on the device whereas the system id is not. However, obtaining these addresses may not always be possible on certain platforms.

Device identifier

The identifier contains elements that (are intended to) uniquely identify the PHD. To distinguish one identifier type from another a code from the ContinuaDeviceIdentifiers code system is used in the Device.identifier.type. Supported codes include the IEEE EUI-64 System Identifier and transport-based identifiers. See the CodeSystem-ContinuaDeviceIdentifiers for the complete list of codes. These identifiers are formatted as hexadecimal strings with each pair of characters separated by dashes and using capitals.

An example is shown below:

{
  "resourceType" : "Device",
  ...
  "identifier" : [
    {
      "type" : {
        "coding" : [
          {
            "system" : "http://terminology.hl7.org/CodeSystem/ContinuaDeviceIdentifiers",
            "code" : "SYSID",
            "display" : "IEEE 11073 System Identifier"
          }
        ]
      },
      "system" : "urn:oid:1.2.840.10004.1.1.1.0.0.1.0.0.1.2680",
      "value" : "74-E8-FF-FE-FF-05-1C-00"
    },
    {
      "type" : {
        "coding" : [
          {
            "system" : "http://terminology.hl7.org/CodeSystem/ContinuaDeviceIdentifiers",
            "code" : "BTMAC",
            "display" : "Bluetooth MAC address"
          }
        ]
      },
      "system" : "http://hl7.org/fhir/sid/eui-48/bluetooth",
      "value" : "00-1C-05-FF-E8-74"
    }
  ],
  ...
}

UDI

The UDI (Unique Device Identifier) is supported by the PHD Device profile as an optional element. It is supported by the IEEE 11073-10206 standard and the Bluetooth GHS specifications. When provided by the PHD the actual UDI string will be in human readable form and comes with metadata identifying the issuer and the regulatory authority

Simple String Entries

There are several Device elements that are just basic strings. Their meanings are straight forward. In the Phd Device profile they are the following:

• Device.manufacturer
• Device.modelNumber
• Device.serialNumber
• Device.partNumber

Device Type

This field states that the device is a PHD. There is no code in the list of device types provided by FHIR here that indicates a personal health device. Instead we use the MDC code that indicates a simple MDS (Medical Device System) object. This entry will be identical for all PHDs following this IG. It appears as follows:

{
  "resourceType" : "Device",
  ...
  "type" : {
    "coding" : [
      {
        "system" : "urn:iso:std:iso:11073:10101",
        "code" : "65573",
        "display" : "MDC_MOC_VMS_MDS_SIMP"
      }
    ],
    "text" : "Simple PHD"
  },
  ...
}

Versions

The Device.versions entry is an array of CodeableConcepts. A single version is unable to represent a PHD as they have a version for the sensor hardware, the internal protocol they may be using, the communication software, sensor firmware, etc. the PHD supports. Not all devices will expose all this information but most PHDs expose their firmware and software versions.

The MDC Device Version Type codes ValueSet has a code to identify each one of these version types. The version itself it just a simple alpha-numeric string. The versions can be helpful identifying different PHD behaviors.

Below is an example of the different versions exposed by a PHD:

{
  "resourceType" : "Device",
  ...
  "version" : [
    {
      "type" : {
        "coding" : [
          {
            "system" : "urn:iso:std:iso:11073:10101",
            "code" : "531976",
            "display" : "MDC_ID_PROD_SPEC_FW"
          }
        ],
        "text" : "Firmware revision"
      },
      "value" : "r2.1"
    },
    {
      "type" : {
        "coding" : [
          {
            "system" : "urn:iso:std:iso:11073:10101",
            "code" : "531975",
            "display" : "MDC_ID_PROD_SPEC_SW"
          }
        ],
        "text" : "Software revision"
      },
      "value" : "r1.5 9.7"
    },
    {
      "type" : {
        "coding" : [
          {
            "system" : "urn:iso:std:iso:11073:10101",
            "code" : "531974",
            "display" : "MDC_ID_PROD_SPEC_HW"
          }
        ],
        "text" : "Hardware revision"
      },
      "value" : "r1.0"
    },
    {
      "type" : {
        "coding" : [
          {
            "system" : "urn:iso:std:iso:11073:10101",
            "code" : "532352",
            "display" : "MDC_REG_CERT_DATA_CONTINUA_VERSION"
          }
        ],
        "text" : "Continua version"
      },
      "value" : "6.0"
    }
  ],
  ...
}

Specializations

The Device.specialization entry is probably the entry most consumers will want to inspect. This entry states what kind of measurements the PHD takes. It is this entry that tells the consumer if the PHD is a blood pressure cuff, heart rate monitor, pulse oximeter. PHDs can support multiple specializations. This element shall always be populated.

In IEEE 11073-10206 ACOM specializations are, in addition to a general description of what the PHD is, standards. The specialization standards are a refinement of the generic standard, and have versions.

A table of some of the most common specializations can be found in the specialization section here.

The example below shows an example of a PHD following the Glucose specialization:

{
  "resourceType" : "Device",
  ...
  "specialization" : [
    {
      "systemType" : {
        "coding" : [
          {
            "system" : "urn:iso:std:iso:11073:10101",
            "code" : "528401",
            "display" : "MDC_DEV_SPEC_PROFILE_GLUCOSE"
          }
        ],
        "text" : "Glucose Monitor"
      },
      "version" : "1"
    }
  ],
  ...
}

Property

property elements contain time clock information and certification information. There will be at least one property entry for every PHD and that reports the time synchronization information. The entry will be present even if the PHD supports no time clock, and in that case the value will be 'no time synchronization'.

There are two types of properties, one that is described by a list of codes, and one that is described by a list of quantities. The list often contains only one entry. Though not obvious from the FHIR 4.0.1 specification, a property cannot contain both a quantity and coded element.

The property.type is a CodeableConcept which tells what the property is. There are MDC or ASN1ToHL7 codes for each property type a PHD can expose. They are as follows:

Time Synchronization

There will always be a time synchronization entry. It is identified by a property.type.coding.code="68220". It indicates the method the PHD uses to externally synchronize to a time reference. The value is a single valueCode entry. MDC codes express the possible synchronization methods. A table of the possible codes can be found in the time synchronization section here. This value is TIME_SYNC_NONE (532224) if the PHD does not support a synchronization protocol or has no time clock at all.

Time Capabilities

The time capabilities defines the types of real time clocks supported, whether the time can be set, whether external time synchronization is possible, etc. Each capability is treated as an event, so most PHGs will only report the capability if the PHD indicates it has the capability. The value is a single valueCode which will be either "Y" if the PHD has the capability or "N" if not. Most PHGs will not report the "N" case as that would significantly increase the size of the resource on the wire. There may be several such time capability property entries.

The time capabilities property is indicated by the property.type.code having one of the ASN1ToHL7 codes of "68219.x" which is NOT a decimal number! The value is a valueCode with codes "Y" or "N".

Time Clock Resolutions

The time clock resolutions is given by one of four MDC codes for each of the possible types of time clocks. Note that a PHD can only simultaneously support an absolute time (wall clock time with no offset) or base offset time (wall clock time with offset). A PHD may support both relative time clocks thus there could be up to three separate time resolution property entries though in most cases there is only one clock.

The resolution value is a valueQuantity and it gives the time interval between clock 'pulses', regardless of the type of time clock, in units of microseconds.

The property is indicated by the property.type.code having one of four MDC codes "68222, 68223, 68224, and 68226". The value is a valueQuantity.

Time Tick Resolution for R-R Intervals

This section is only relevant for PHDs that support the Heart Rate or ECG specializations based on IEEE 11073-20601. It is not used for measurement timestamps but for measuring R-R intervals (time between electrocardiogram R-wave peaks) in ECG and Heart Rate specializations. The time tick resolution is a high frequency clock that is used to measure the time between R-wave peaks in an ECG trace. The number of ticks is reported in the valueQuantity.value element in Observations, not the effective[x] which is the time the measurement is taken. These special clocks typically have a resolution of 1024 Hz or better. When R-R intervals are reported, they are reported in units of these ticks, so one must know what the frequency of the clock is. The reason for this special clock is that R-R intervals have been traditionally timed using dedicated crystal oscillators.

ACOM-based ECGs do not use the time tick resolution to report R-R intervals.

Regulation Status

The Regulation status is a set of states where only one state is defined. Regulation Status is used to indicate which regulation body the PHD is regulated by. At the moment, the single defined state is assumed to be FDA. All market devices that currently report a regulated state are FDA regulated.

The property is indicated by the property.type.code having the ASN1ToHL7 code "532354.x" where the only currently defined entry is x=0. The value is a valueCode which can have a value "Y" or "N". The twist here is that the state has been defined in the negative. Thus a code value of "N" means regulated. Note that since this is a state, the PHG is required to report both the "Y" and "N" values if the PHD reports a regulation status.

Continua Certified PHD Interfaces

This property contains a code that indicates a specialization and transport the PHD has been (self-)certified for. Note there is a difference between 'support' and 'certified' support. The Device specialization entries indicate what the PHD supports. Certified means the PHD has been (independently) placed through a set of extensive tests for the specialization and the transport over which the specialization operates. In the past, the Continua organization certified PHDs for compliance to its guidelines that referenced this IG.

The property is indicated by the property.type.code having the MDC code "532353". The value is a code from the ValueSet for PHD Interfaces code system.

Example of a PHD Device Resource properties

The fragment below shows the set of properties of an example PHD. Note that the time synchronization protocol is "none" and the time resolution is "relative" with a resolution of 1 second. The PHD is regulated and has certified interfaces.

{
  "resourceType" : "Device",
  ...
  "property" : [
    {
      "type" : {
        "coding" : [
          {
            "system" : "urn:iso:std:iso:11073:10101",
            "code" : "532353",
            "display" : "MDC_REG_CERT_DATA_CONTINUA_CERT_DEV_LIST"
          }
        ],
        "text" : "Each element of the certified interfaces list as a separate property"
      },
      "valueCode" : [
        {
          "coding" : [
            {
              "system" : "http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaPHDInterfaceIDs",
              "code" : "32772",
              "display" : "Bluetooth LE Pulse Oximeter certified"
            }
          ]
        }
      ]
    },
    {
      "type" : {
        "coding" : [
          {
            "system" : "urn:iso:std:iso:11073:10101",
            "code" : "532353",
            "display" : "MDC_REG_CERT_DATA_CONTINUA_CERT_DEV_LIST"
          }
        ],
        "text" : "Each element of the certified interfaces list as a separate property"
      },
      "valueCode" : [
        {
          "coding" : [
            {
              "system" : "http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaPHDInterfaceIDs",
              "code" : "8196",
              "display" : "PHDC USB Pulse Oximeter certified"
            }
          ]
        }
      ]
    },
    {
      "type" : {
        "coding" : [
          {
            "system" : "urn:iso:std:iso:11073:10101",
            "code" : "532353",
            "display" : "MDC_REG_CERT_DATA_CONTINUA_CERT_DEV_LIST"
          }
        ],
        "text" : "Each element of the certified interfaces list as a separate property"
      },
      "valueCode" : [
        {
          "coding" : [
            {
              "system" : "http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaPHDInterfaceIDs",
              "code" : "4",
              "display" : "Pulse Oximeter certified"
            }
          ]
        }
      ]
    },
    {
      "type" : {
        "coding" : [
          {
            "system" : "http://terminology.hl7.org/CodeSystem/ASN1ToHL7",
            "code" : "532354.0",
            "display" : "negated-regulation-status"
          }
        ]
      },
      "valueCode" : [
        {
          "coding" : [
            {
              "system" : "http://terminology.hl7.org/CodeSystem/v2-0136",
              "code" : "N"
            }
          ]
        }
      ]
    },
    {
      "type" : {
        "coding" : [
          {
            "system" : "urn:iso:std:iso:11073:10101",
            "code" : "68220",
            "display" : "MDC_TIME_SYNC_PROTOCOL"
          }
        ],
        "text" : "Time synchronization protocol"
      },
      "valueCode" : [
        {
          "coding" : [
            {
              "system" : "urn:iso:std:iso:11073:10101",
              "code" : "532224",
              "display" : "MDC_TIME_SYNC_NONE"
            }
          ]
        }
      ]
    },
    {
      "type" : {
        "coding" : [
          {
            "system" : "http://terminology.hl7.org/CodeSystem/ASN1ToHL7",
            "code" : "68219.0",
            "display" : "mds-time-capab-real-time-clock"
          }
        ]
      },
      "valueCode" : [
        {
          "coding" : [
            {
              "system" : "http://terminology.hl7.org/CodeSystem/v2-0136",
              "code" : "Y"
            }
          ],
          "text" : "real time clock supported"
        }
      ]
    },
    {
      "type" : {
        "coding" : [
          {
            "system" : "http://terminology.hl7.org/CodeSystem/ASN1ToHL7",
            "code" : "68219.1",
            "display" : "mds-time-capab-set-clock"
          }
        ]
      },
      "valueCode" : [
        {
          "coding" : [
            {
              "system" : "http://terminology.hl7.org/CodeSystem/v2-0136",
              "code" : "Y"
            }
          ],
          "text" : "setting the time supported"
        }
      ]
    },
    {
      "type" : {
        "coding" : [
          {
            "system" : "http://terminology.hl7.org/CodeSystem/ASN1ToHL7",
            "code" : "68219.2",
            "display" : "mds-time-capab-relative-time"
          }
        ]
      },
      "valueCode" : [
        {
          "coding" : [
            {
              "system" : "http://terminology.hl7.org/CodeSystem/v2-0136",
              "code" : "Y"
            }
          ],
          "text" : "relative time supported"
        }
      ]
    },
    {
      "type" : {
        "coding" : [
          {
            "system" : "urn:iso:std:iso:11073:10101",
            "code" : "68223"
          }
        ],
        "text" : "MDC_TIME_RES_REL: relative time clock resolution"
      },
      "valueQuantity" : [
        {
          "value" : 1000,
          "system" : "http://unitsofmeasure.org",
          "code" : "us"
        }
      ]
    }
  ]
}

The PHG Device Resource

The PHG Device Resource, can, in theory have all the same entries as in the PHD Device Resource plus one additional property that gives the list of certified Health and Fitness interfaces (to downstream servers). A PHG can be certified for both proper operation with PHD specializations as well as proper operation with downstream servers. One of those 'Health and Fitness' interfaces is the upload to RESTFul FHIR servers. Some PHGs also support uploads of the data as PCD-01 and some support questionnaires.

However, the only required PHG entries are the time synchronization protocol and the system id identifier. For compliance with this IG, PHGs must also report the list of certified PHD interfaces and the list of certified Health & Fitness interfaces.

The time synchronization protocol is important as the PHG plays an important role in the measurement timestamps, and may change them from what the PHD reports if warranted.

Only the entries that are different from the PHD are discussed in the following sections.

Device Type

This field states that the device is a PHG. This IG uses the MDC code MDC_MOC_VMS_MDS_AHD that indicates a gateway. "AHD" stands for Application Hosting Device and is an older name for what is commonly known as a PHG.

Continua Certified Health and Fitness Interfaces

In addition to the certified PHD interfaces the PHG can report its certified Health and Fitness interfaces as a list of properties. Each of these properties reports a code that indicates a Health and Fitness interface the PHG has been (self-)certified for.

The property is indicated by the property.type.code having the MDC code "532355". The valueCode comes from the ContinuaHFS code system.

An example of a PHG resource is given here.

Patient Resource

It is assumed here that the reader has access to the Patient resource uploaded by the PHG and that the PHG uploaded a Patient resource. There is a special case where the PHG will not upload a Patient resource.

The uploaded Patient resource is following the Phd Patient Profile as defined here.

There is only one additional required entry in the Phd Patient Profile; the Patient.identifier.

The required Patient.identifier entry contains an identifier.type using the Table 0203 identifierType code system from HL7 v2. The code entry is generally "MR" for medical record number, but other likely entries are "LR" for local registry or "U" for unspecified identifier. The "U" is also used when handling a "John or Jane Doe" unknown patient.

The identifier.value and identifier.system entries are used to quantify the entries of the given identifier.type. For example, the identifier.system might be the institution's XDS.b assigning authority and the identifier.value the patient record number (also known as the patient identifier). See IHE Cross-Enterprise Document Sharing.

Note that a medical record number is considered PHI in some jurisdictions and use cases. Even when the medical record number is not in itself PHI, the fact that the PHG's communication will convey both the MRN and health data could put the whole communication into the realm of PHI.

An example of a Patient.identifier following the XDS.b notation is given here. An example of an unknown patient using the identifier.type "U" is given here.