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.1.0 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 Time Stamp.

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 only 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 Time Stamp Observation.

The next sections examine each of 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 just arbitrary human-readable strings. These kinds of measurements are rare as they cannot be processed by machine.
• discrete state or event measurements (alpha-numeric codes) which report a set of conditions that may occur simultaneously. An example would be a room status measurement in an independent living facility such as patient in room, door closed, window closed, climate control off, and video monitoring off.
• 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 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 st the Rosetta Terminology Mapping Management Service (RTMMS). It provides descriptions and, if applicable, the units associated with the measurement in both MDC and UCUM. Equaivalent 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 (R4) 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 the LOINC "magic value". 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.coding.code element with value "vital-signs" when the measurement is a vital sign.

The Time Stamp: 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. The period has both a start and end. Results of a workout session are a common type of measurement with a period. The 'instant' data type is not used 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 resolution.

All time stamps 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 time stamp 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 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 Element Fields

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

The Profile: Observation.meta.profile

A PHD profile element may identifiy what type of measurement value the Observation has. For example, if Observation.meta.profile entry contains "http://hl7.org/fhir/uv/phd/StructureDefinition/PhdNumericObservation" the measurement is a scalar.

The Coincident Time Stamp extension

The consumer can obtain further information about the time stamp from a referenced coincident time stamp Observation identified by the profile value "http://hl7.org/fhir/uv/phd/StructureDefinition/PhdCoincidentTimeStampObservation". This reference may be present in the CoincidentTimeStampReference extension. If the reference is NOT present, it means that the PHD did not provide a time stamp, and the PHG used the time of reception as the time stamp. PHDs that send stored data shall include time stamps in their measurements.

The Coincident Time Stamp 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 time stamp, and if it did, by how much. An example of the Coincident Time Stamp extension is shown below:

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

Additional information about the Coincident Time Stamp can be found here.

References to Other Observations

There are situations where a given Observation is an important part of another Observation such as a glucose meal context measurement giving additional information about a glucose concentration measurement. In that case the context measurement will have an Observation.derivedFrom.reference element that points to the Observation resource containing the glucose 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 points to the master session Observation with a Observation.memberOf.reference which has the activity type and duration (period).

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 element. The type of additional information is given by the Observation.component.code element. The value of such additional information is given by an Observation.component or an Observation.extension 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.coding.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 forn 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. Should IEEE 11073-10206/20601 Supplemental Information be modeled as a FHIR Observation.component or as an extension in FHIR? Input is welcome.

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 measurement 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 values, "Not a Number", "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.

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. Other systems may add further identifiers.

Measurement Values that are Single-Number 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. If the PHD reports a special value; Not a number, Positive infinity, Negative infinity, and two other possible values unknown to FHIR, an Observation.dataAbsentReason element replaces the valueQuantity and there is no value[x] element.

An Observation resource following the Phd Numeric Observation Profile will have an Observation.meta.profile entry containing "http://hl7.org/fhir/uv/phd/StructureDefinition/PhdNumericObservation".

When there is no special value 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 a special value is reported an Observation.dataAbsentReason 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.dataAbsentReason.coding.system in the above cases is always

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

IEEE 11073-20601 defines two other special values that are not translated to FHIR which are encoded as "error". To date, there has been no market PHD which reports the other two special values.

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

"valueQuantity": {
    "value": 35.6,
    "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 "http://hl7.org/fhir/uv/phd/StructureDefinition/PhdCompoundObservation" 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. 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.

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

An example of a Blood Pressure measurement would be as follows:

The Observation.code and Observation.category (since the measurement is a vital sign) entries describing the 'entire' measurement:

{
  "resourceType" : "Observation",
  ...
  "category" : [
    {
      "coding" : [
        {
          "system" : "http://terminology.hl7.org/CodeSystem/observation-category",
          "code" : "vital-signs"
        }
      ]
    },
    {
      "coding" : [
        {
          "system" : "http://hl7.org/fhir/uv/phd/CodeSystem/PhdObservationCategories",
          "code" : "phd-observation"
        }
      ]
    }
  ],
  "code" : {
    "coding" : [
      {
        "system" : "urn:iso:std:iso:11073:10101",
        "code" : "150020",
        "display" : "MDC_PRESS_BLD_NONINV"
      },
      {
        "system" : "http://loinc.org",
        "code" : "85354-9",
        "display" : "Blood pressure panel with all children optional"
      }
    ]
  },
  ...
}

and the individual Observation.component entries describing each compound entry where the MEAN entry was unable to be determined and reported a NaN (Not a Number):

{
  "resourceType" : "Observation",
  ...
  "component" : [
    {
      "code" : {
        "coding" : [
          {
            "system" : "urn:iso:std:iso:11073:10101",
            "code" : "150021",
            "display" : "MDC_PRESS_BLD_NONINV_SYS"
          },
          {
            "system" : "http://loinc.org",
            "code" : "8480-6",
            "display" : "Systolic blood pressure"
          }
        ]
      },
      "valueQuantity" : {
        "value" : 116,
        "unit" : "mm[Hg]",
        "system" : "http://unitsofmeasure.org",
        "code" : "mm[Hg]"
      }
    },
    {
      "code" : {
        "coding" : [
          {
            "system" : "urn:iso:std:iso:11073:10101",
            "code" : "150022",
            "display" : "MDC_PRESS_BLD_NONINV_DIA"
          },
          {
            "system" : "http://loinc.org",
            "code" : "8462-4",
            "display" : "Diastolic blood pressure"
          }
        ]
      },
      "valueQuantity" : {
        "value" : 71,
        "unit" : "mm[Hg]",
        "system" : "http://unitsofmeasure.org",
        "code" : "mm[Hg]"
      }
    },
    {
      "code" : {
        "coding" : [
          {
            "system" : "urn:iso:std:iso:11073:10101",
            "code" : "150023",
            "display" : "MDC_PRESS_BLD_NONINV_MEAN"
          }
        ]
      },
      "dataAbsentReason" : {
        "coding" : [
          {
            "system" : "http://terminology.hl7.org/CodeSystem/data-absent-reason",
            "code" : "not-a-number",
            "display" : "Not a Number (NaN)"
          }
        ]
      }
    }
  ]
}

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 entry (not ASN1ToHL7) and the MDC entry will never have a partition value (the upper 16 bits) equal to 1.

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. Observations following that profile may have an Observation.meta.profile entry containing "http://hl7.org/fhir/uv/phd/StructureDefinition/PhdCodedEnumerationObservation".

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 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. The V2 binary "Y"/"N" code system is used to express the corresponding values.

Measurement values that fall into this category are mapped to an Observation following the Phd Bits Enumeration Observation profile. An Observation following this profile is indicated by an Observation.meta.profile entry containing "http://hl7.org/fhir/uv/phd/StructureDefinition/PhdBitsEnumerationObservation".

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 in an Observation.component.valueCodeableConcept entry using the V2 binary code system. 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 "Y" 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 "Y". The ASN1ToHL7 code system will have the assignment and readers will need to examine it.

In future PHD versions the PHD will be able to 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.dataAbentReason element with reason "unsupported". Currently there are no market PHDs that support this feature.

Event and/or state measurements 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 of event entries either. It is possible for each state or event entry to be unsupported and that will be reported with a Observation.component.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 the states and/or events measurements are similar to compound or vector measurements. It is also possible that state and/or event measurements have 'additional descriptions' as discussed in the Additional Descriptive Data section. To distinguish the measurement component entries from the additional description component entries one only needs to examine the Observation.component.code.coding.system. If it is ASN1ToHL7, it is part of the measurement.

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 "Y" indicting 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. In addition, the MDC code of the overall measurement will never have a partition (the upper 16 bits) value of 1.

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. An Observation following this profile is indicated by an Observation.meta.profile entry containing "http://hl7.org/fhir/uv/phd/StructureDefinition/PhdRtsaObservation". 'Rtsa' means real time sample array.

Periodic measurements are reported in Observation.valueSampledData and Observation.referenceRange 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 Observation.referenceRange element is for convenience and is not necessary for decoding the data. It was designed for plotting as it gives the upper and lower bounds of the trace at any time (it does not mean that either value is obtained in the transmitted sequence). One can create a graph with such 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 magic value rules apply as they do for scalar and vector measurements.

String measurements

PHDs can send a measurement value that is just an arbitrary human readable string. An example of such a measurement might be the name of an exercise program on a piece of gym equipment.

String measurement values are mapped to an Observation following the Phd String Enumeration Observation profile. An Observation following this profile is indicated by an Observation.meta.profile entry containing "http://hl7.org/fhir/uv/phd/StructureDefinition/PhdStringEnumerationObservation".

The measurement is reported in an Observation.valueString element which has the value of the human readable string.

An example of this measurement is as follows:

"valueString": "Test Strip Buckled"

String measurements are rare in PHDs.

The PHD Coincident Time Stamp Observation Resource

The coincident time stamp is a comparison of the PHD's and PHG's time lines. PHDs have limited resources and are often battery driven and therefore depend upon the user or the PHG to set its time. Though it is possible for PHDs to support an external time synchronization there are currently no market PHDs that do such. The time lines 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 asks the PHD for its 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 time lines, the two states of synchronization, and the two states of synchronization accuracy. If the PHG is better synchronized, the PHG will correct the PHD reported times by the difference between the two time lines. The PHG will also set the PHD's time if the PHD supports it, automatically bringing the two time lines into synchrony.

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

The coincident time stamp also indicates whether there is a time fault. In the case of relative times, the coincident time stamp provides the 'anchor' that allows the PHG to create wall clock times from the PHD's 'tick' values.

The following core information is available from the coincident time stamp observation:

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

The coincident time stamp follows the Phd Coincident Time Stamp Observation Profile. An Observation following this profile is indicated by an Observation.meta.profile entry containing "http://hl7.org/fhir/uv/phd/StructureDefinition/PhdCoincidentTimeStampObservation".

All readers should check whether or not there is a time fault. Otherwise the information provided by this Observation is mostly for auditing.

The PHD Device Resource

The PHD Device resource follows the Phd Device Profile. It is identified by the Device.meta.profile element containing the entry "http://hl7.org/fhir/uv/phd/StructureDefinition/PhdDevice". Its structure definition is found here.

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
  • USB Pid and Vid values if the PHD uses USB transports
• Device.manufacturer
  • Manufacturer name
• Device.modelNumber
  • Model number
• Device.serialNumber
  • serial number
• Device.partNumber
  • part number
• Device.type
  • PHD (Simple MDS)
• 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.

UDI

At the moment there are no PHDs which electronically support a UDI. The latest version of the IEEE 11073-20601 protocol will support this field. When the updated standard is released and PHD support seems imminent UDI support will be added to this IG.

Device identifier

The identifier contains elements that are (supposed) to uniquely identify the PHD. To distinguish one identifier from another, especially in the case where two identifiers are the same 'bitness' a code from the ContinuaDeviceIdentifiers code system is used in the Device.identifier.type. There are five possible codes defined:

The system Id is an EUI-64 which contains an IEEE assigned manufacturer identifier (the 24 most significant bits) with the remaining 40 bits up to the manufacturer. An example of a system Id identifier entry is shown below:

"identifier" : [
  {
    "type" : {
      "coding" : [
        {
          "system" : "http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDeviceIdentifiers",
           "code" : "SYSID"
       }
      ]
    },
    "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"
  }
]

The public Bluetooth address is an EUI-48 which contains an IEEE assigned manufacturer identifier (the 24 most significant bits) with the remaining 32 bits up to the manufacturer. An example of a Bluetooth identifier entry is shown below:

"identifier" : [
  {
    "type" : {
      "coding" : [
        {
          "system" : "http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDeviceIdentifiers",
          "code" : "BTMAC"
        }
      ]
    },
    "system" : "http://hl7.org/fhir/sid/eui-48/bluetooth",
    "value" : "00-1C-05-FF-E8-74"
  }
]

For USB a transport address is far less important as most end users will not know what the VID and PID are or have easy access to them. An example of an USB identifier entry is shown below:

"identifier" : [
  {
    "type" : {
      "coding" : [
        {
          "system" : "http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDeviceIdentifiers",
          "code" : "USB"
        }
      ]
    },
    "system" : "http://hl7.org/fhir/sid/usb",
    "value" : "0042.F90D"        // pid.vid
  }
]

The examples are shown individually but in practice one would see the system id entry and perhaps a transport entry.

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",
  ...
  "identifier" : [
    {
      "type" : {
        "coding" : [
          {
            "system" : "http://hl7.org/fhir/uv/phd/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://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDeviceIdentifiers",
            "code" : "BTMAC",
            "display" : "Bluetooth MAC address"
          }
        ]
      },
      "system" : "http://hl7.org/fhir/sid/eui-48/bluetooth",
      "value" : "00-1C-05-FF-E8-74"
    }
  ],
  ...
}

"type" : {
    "coding" : [
      {
        "system" : "urn:iso:std:iso:11073:10101",
        "code" : "65573",
        "display" : "MDC_MOC_VMS_MDS_SIMP"
      }
    ]
}

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, and even the Continua version their communication software supports. Not all devices will expose all this information but most PHDs expose their firmware and software versions and those PHDs that are Continua compliant will expose their Continua version.

The MDC code system has a code to identify each one of these version types. The version itself it just a simple alpha-numeric string. The MDC codes for the various version types are as follows:

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

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

The versions can be helpful identifying different PHD behaviors.

Specializations

The Device.specialization entry is probably the entry most consumers will want to expose. 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-20601 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 market PHD following the Glucose specialization:

"specialization" : [
    {
      "systemType" : {
        "coding" : [
          {
            "system" : "urn:iso:std:iso:11073:10101",
            "code" : "528405"
          }
        ],
        "text": "MDC_DEV_SPEC_PROFILE_GLUCOSE: Glucose Monitor"
      },
      "version" : "1"
    }
]

Property

The property element contains time clock information and certification information. There will be at least one property entry for every PHD and that is the time synchronization information. The entry will be present even if the PHD supports no time clock, and that 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 specification, a property cannot contain both a quantity and coded element.

The Device.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 always TIME_SYNC_NONE (532224) if the PHD is not synchronized or has no time clock at all. To date ALL PHDs have no external time synchronization capabilities and this entry is always TIME_SYNC_NONE.

An example of time synchronization property entry is shown below:

{
  "type" : {
    "coding" : [
      {
        "system" : "urn:iso:std:iso:11073:10101",
        "code" : "68220"
      }
    ],
    "text": "MDC_TIME_SYNC_PROTOCOL: Time synchronization protocol"
  },
  "valueCode" : [
    {
      "coding" : [
        {
          "system" : "urn:iso:std:iso:11073:10101",
          "code" : "532224"
        }
      ],
      "text": "MDC_TIME_SYNC_NONE: No time synchronization"
    }
  ]
}

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 Device.property.type.coding.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".

The example below gives the time capabilities of a market pulse oximeter:

{
    "type": {
        "coding": [
            {
                "system": "http://hl7.org/fhir/uv/phd/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://hl7.org/fhir/uv/phd/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://hl7.org/fhir/uv/phd/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"
        }
    ]
}

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 Device.property.type.coding.code having one of four MDC codes "68222, 68223, 68224, and 68226". The value is a valueQuantity.

An example of a time resolution property for an absolute time clock with a time resolution of of one second is shown below:

{
    "type": {
        "coding": [
            {
                "system": "urn:iso:std:iso:11073:10101",
                "code": "68222"
            }
        ],
        "text": "MDC_TIME_RES_ABS: absolute time clock resolution"
    },
    "valueQuantity": [
        {
            "value": 1000000,
            "system": "http://unitsofmeasure.org",
            "code": "us"
        }
    ]
}

Time Tick Resolution for R-R Intervals

The Time Tick resolution is not used for measurement time stamps but for measuring R-R intervals (time between electrocardiogram R-wave peaks) in ECG and Heart Rate specializations. 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.

The time tick is given as a property and its units are Hertz. However, the R-R interval is given in the number of these ticks and many PHGs will not make the conversion as there is no UCUM code for the MDC dimension code of Ticks and therefore the units reported will be the MDC unit of ticks. Thus the reader will have to obtain the R-R interval using the R-R reported tick value and the tick frequency given in the Device property element.

The property is indicated by the Device.property.type.coding.code having the MDC code "68229". The value is a valueQuantity.

An example of the Tick resolution property entry is given below.

{
    "type": {
        "coding": [
            {
                "system": "urn:iso:std:iso:11073:10101",
                "code": "68229"
            }
        ],
        "text": "MDC_ATTR_TICK_RES: Frequency of ticks"
    },
    "valueQuantity": [
        {
            "value": 1024,
            "system": "http://unitsofmeasure.org",
            "code": "s-1"    // 1/seconds or Hz
        }
    ]
}

Time Synchronization Accuracy

The time synchronization accuracy is the accumulated difference between the PHD's internal clock and external reference source since last synchronization. It is reported in units of microseconds. To date no PHD is externally time synchronized so no PHD reports this attribute value.

The property is indicated by the Device.property.type.coding.code having the MDC code "68221". The value is a valueQuantity.

An example of the time synchronization accuracy property entry is given below.

{
    "type": {
        "coding": [
            {
                "system": "urn:iso:std:iso:11073:10101",
                "code": "68221"
            }
        ],
        "text": "MDC_TIME_SYNC_ACCURACY: Time synchronization accuracy"
    },
    "valueQuantity": [
        {
            "value": 1005,
            "system": "http://unitsofmeasure.org",
            "code": "us"
        }
    ]
}

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 Device.property.type.coding.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.

An example of an entry for an FDA regulated device is shown below:

"type": {
    "coding": [
        {
            "system": "http://hl7.org/fhir/uv/phd/CodeSystem/ASN1ToHL7",
            "code": "532354.0",
            "display": "regulation-status"
        }
    ]
},
"valueCode": [
    {
        "coding": [
            {
                "system": "http://terminology.hl7.org/CodeSystem/v2-0136",
                "code": "N"
            }
        ],
        "text": "Device is regulated"
    }
]

Continua Certified PHD Interfaces

This property is a list of codes that indicate which specializations and transports 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 organisation certified PHDs for compliance to its guidelines that referenced this IG.

The property is indicated by the Device.property.type.coding.code having the MDC code "532353". The value is a list of valueCodes where the codes come from the ContinuaPHD code system. How these codes are generated is given here.

An example of a property entry where a PHD is certified for the pulse oximeter specialization over both Bluetooth Low Energy, USB, and Continua version 1.0 where there was no transport indicated, is given below:

{
  "resourceType" : "Device",
  ...
  "identifier" : [
    {
      "type" : {
        "coding" : [
          {
            "system" : "http://hl7.org/fhir/uv/phd/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://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDeviceIdentifiers",
            "code" : "BTMAC",
            "display" : "Bluetooth MAC address"
          }
        ]
      },
      "system" : "http://hl7.org/fhir/sid/eui-48/bluetooth",
      "value" : "00-1C-05-FF-E8-74"
    }
  ],
  ...
}

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 time stamps, 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. There is no code in the list of device types provided by FHIR here that indicates a personal health gateway. Instead we use the MDC code MDC_MOC_VMS_MDS_AHD that indicates a gateway.

Certified Health and Fitness Interfaces

This property is a list of codes that indicate which Health and Fitness interfaces the PHG has been certified for. There is no certification body active for this IG, so this entry can be populated with interfaces the PHG supports.

The property is indicated by the Device.property.type.coding.code having the MDC code "532355". The value is a list of valueCodes where the codes come from the ContinuaHFS code system. The code system is simple and limited to only eight values at the current time.

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 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 XDSb institutional identifier and the identifier.value the patient record number (also known as the patient identifier).

The above information exposes no personal health information as only the organization responsible for the patient has the dictionary that can relate these codes to a given person.

An example of a Patient.identifier following the XDSb notation is given below:

{
  "resourceType" : "Patient",
  ...
  "identifier" : [
    {
      "type" : {
        "coding" : [
          {
            "system" : "http://terminology.hl7.org/CodeSystem/v2-0203",
            "code" : "MR"
          }
        ]
      },
      "system" : "urn:oid:1.2.3.4.5.6.7.8.10",
      "value" : "sisansarahId"
    }
  ],
  ...
}

An example of an unknown patient using the Version 2 Table 0004 patient class code system is given here