This page is part of the Personal Health Device FHIR IG (v1.0.0: STU 1) based on FHIR R4. This is the current published version in its permanent home (it will always be available at this URL). For a full list of available versions, 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. Manual entry of data is not considered by this IG as it is subject to human error.

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 is only one extension used in the PHD related profiles and that is 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. Most of this IG is dedicated to the PHD to FHIR mapping that a PHG must follow. Those sections do require IEEE 11073 domain knowledge.

PHGs following this IG use only three FHIR resources, Patient, Device, 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 the Coincident Time Stamp. Most users of these profiles will not need to understand the Coincident Time Stamp and will only need it to check if the reported times are valid. The reader need not understand the concept at this time. It will be further discussed in the PHD Coincident Time Stamp Observation Resource section here for those who are interested.

The next sections examine each of the resources generated by PHGs following this IG. Note that all ‘text’ entries are optional.

The Measurement Observation Resources

PHDs measurements are encoded into Observation resources. There are six 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 six measurement value types are:

• single number such as a temperature, weight, glucose concentration, pulse rate, blood oxygen saturation, or miles run. Single number or ‘scalar’ measurements are the most common type of measurement and usually have a unit. All measurements in this category follow the Phd Numeric Observation Profile and can be identified when the Observation.meta.profile=”http://hl7.org/fhir/uv/phd/StructureDefinition/PhdNumericObservation”.
• multiple-number where multiple numbers at a single point in time need to be taken together to represent the value, also known as compound or vector, such as the systolic, diastolic, and mean components of the blood pressure or x-, y-, and z- components of an acceleration. Compound measurements usually have units. All measurements in this category follow the Phd Compound Numeric Observation Profile and can be identified when the Observation.meta.profile=”http://hl7.org/fhir/uv/phd/StructureDefinition/PhdCompoundNumericObservation”.
• alpha-numeric code 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. In the case of the meal context some of the options are pre-meal, post-meal, bedtime, fasting, etc. All measurements in this category follow the Phd Coded Enumeration Observation Profile and can be identified when the Observation.meta.profile=”http://hl7.org/fhir/uv/phd/StructureDefinition/PhdCodedEnumerationObservation”.
• 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. All measurements in this category follow the Phd Bits Enumeration Observation Profile and can be identified when the Observation.meta.profile=”http://hl7.org/fhir/uv/phd/StructureDefinition/PhdBitsEnumerationObservation”. It should be noted that there is no ‘room status’ measurement defined for PHDs; it is used here because if it did exist it would be an illustrative example of a state measurement value.
• periodic samples (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. These measurements are a periodic sequence of scalars and usually have units. All measurements in this category follow the Phd Rtsa Observation Profile and can be identified when the Observation.meta.profile=”http://hl7.org/fhir/uv/phd/StructureDefinition/PhdRtsaObservation”.
• string measurements which are just arbitrary human-readable strings. These kinds of measurements are rare as they cannot be processed by machine. All measurements in this category follow the Phd String Enumeration Observation Profile and can be identified when the Observation.meta.profile=”http://hl7.org/fhir/uv/phd/StructureDefinition/PhdStringEnumerationObservation”.

Common Observation Element Fields

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

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

Description of the Fields

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

The Profile: Observation.meta.profile

For the consumer the PHD profile element tells one what type of measurement value the Observation has. For example, if Observation.meta.profile entry contains “http://hl7.org/fhir/uv/phd/StructureDefinition/PhdNumericObservation” one knows that this measurement is a scalar. As discussed in the Phd Numeric Observation Profile section, scalars are mapped to a valueQuantity element, thus one knows the value[x] element is of type valueQuantity, which may make parsing the value[x] element a little simpler.

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. The MDC code system consists of 32-bit integers. Examples of some common MDC codes are

A comprehensive list of MDC codes is available using the NIST RTMSS Rosetta. It provides descriptions and, if applicable, the units associated with the measurement in both MDC and UCUM. The Rosetta is still a work in progress. One can find more information about the MDC code system here.

For those consumer applications that would like to have the codes as LOINC and the uploader did not provide them, there is a mapping from MDC to LOINC available here with a direct link to the download here. The FHIR MDC to LOINC concept map is available here. One may freely download and use this material as needed in an implementation license free, but it does require that one create a (free) login account. At the time of this writing there is no comprehensive mapping of MDC to other code systems such as SNOMED CT. A mapping from MDC to SNOMED CT for some of the more common codes is available in the 2017 Continua Design Guidelines H.813 HIS Interface document. The guidelines are freely available for download, however it is not known what the licensing requirements are for use of the SNOMED CT code system.

Vital Signs

FHIR requires that a LOINC ‘magic’ value be 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 same LOINC magic value (8867-4). A PHG is not required to use the magic values but may map the MDC codes more specifically to LOINC.

In addition to the LOINC magic value, FHIR requires an Observation.category.coding.code element with value “vital-signs” when the measurement is a vital sign. When the measurement is not a vital sign, the PHD measurement profiles do not require an Observation.category element.

Below is a snippet showing a code element for a measurement type that is a vital sign (body temperature) along with the FHIR-required ‘vital signs’ category element:

"category": [
    {
        "coding": [
            {
                "system": "http://terminology.hl7.org/CodeSystem/observation-category",
                "code": "vital-signs",
                "display": "Vital Signs"
            }
        ]
    }
],
"code": {
    "coding": [
        {
            "system": "urn:iso:std:iso:11073:10101",
            "code": "150364"
        },
        {
            "system": "http://loinc.org",
            "code": "8310-5"
        }
    ],
    "text": "MDC_TEMP_BODY: Body temp"
}

Caveats

The PHG may express the code in additional coding systems but the consumer cannot rely on it. The PHD profiles in this IG require only the MDC code as it is provided by the PHD and the LOINC magic value if the measurement is a vital sign. It is also possible that a vital sign is not mapped to LOINC by the PHG. By design, the PHG is written to map the data from the PHD without any knowledge to what the data is. The exception is for the LOINC magic values which require the PHG to pre-code a map. If a new PHD specialization is created after the PHG is already implemented, the new PHD may possess a new MDC code and the new code may be a vital sign (perhaps the new code represents a pulse rate obtained via a new technique). The PHG can still populate the Observation.code.coding.code with the MDC code as that is provided in the PHD protocol, but the new MDC code will not be in its pre-coded local map of MDC codes to LOINC magic values.

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:

"effectiveDateTime": "2019-05-10T16:47:31-04:00"

The Coincident Time Stamp

The consumer can obtain further information about the time stamp from the coincident time stamp Observation identified by the profile value “http://hl7.org/fhir/uv/phd/StructureDefinition/PhdCoincidentTimeStampObservation”. A reference to the coincident time stamp Observation may be present in the Observation.derivedFrom element. 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. Only PHDs that send live data are allowed to send measurements without time stamps.

If the PHD sent the measurement with a time stamp, there will be an Observation.derivedFrom element referencing the coincident time stamp Observation resource. The Observation can be used to determine if the PHD had a time fault. A time fault means the PHD had measurements with time stamps but lost its sense of current time for those measurements. Such an error could occur on a battery change or from a bug in the PHD code. If the PHD loses its sense of current time there is no way for the PHG to validate the time stamps or correct them. Time faults need to be reported to assure that the end user of the data is aware that the time stamps are untrustworthy. This Coincident Time Stamp can also be used to see if the PHG needed to correct the time stamp, and if it did, by how much. In that manner one can get the originally reported time stamps by the PHD and its original time line.

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

The PHG reference: Observation.extension.valueReference:

The reference to the Device resource containing the PHG properties is the only extension used in this implementation guide. An example of the element is shown below:

"extension": [
    {
        "url": "http://hl7.org/fhir/StructureDefinition/observation-gatewayDevice",
        "valueReference": {
            "reference": "Device/12"
        }
    }
]

The extension is one of the registered extensions for Observations.

The PHD reference: Observation.device:

The reference to the Device resource containing the properties of the PHD that took the measurement is placed in the Observation.device element.

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.

References to Other Observations: Observation.derivedFrom.reference:

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 which has the activity type and duration (period).

The most common use of this element will be for referencing the Coincident Time Stamp Observation. Every measurement where the PHD provides a time stamp will reference a Coincident Time Stamp Observation.

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

"derivedFrom": [
    {
        "reference": "Observation/1294"
    }
]

There is no way to ascertain from the reference whether the Observation is a Coincident Time Stamp Observation or another measurement Observation. One must examine the Observation.meta.profile element of the referenced Observation to ascertain that information.

Additional Descriptions: Observation.component:

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. 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 the additional information is given by the Observation.component.value[x] element. PHDs support the following types of additional information:

At the time of this writing, only the supplemental types and the high resolution relative time stamp ‘additional descriptions’ are used by current PHDs on the market. Some of the text string descriptions are unlikely to be used given that the IEEE 11073 20601 specification only allows ASCII 127 and consumers of the data are likely to provide their own descriptions customized to their locale.

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:

"component": [
    {
        "code": {
            "coding": [
                {
                    "system": "urn:iso:std:iso:11073:10101",
                    "code": "68193"
                }
            ],
            "text": "MDC_ATTR_SUPPLEMENTAL_TYPES: Supplemental information"
        },
        "valueCodeableConcept": {
            "coding": [
                {
                    "system": "urn:iso:std:iso:11073:10101",
                    "code": "150588"
                }
            ],
            "text": "MDC_MODALITY_SPOT: Modality Spot"
        }
    }
]

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

Relative Times

A PHD may use a relative time clock. A relative time clock is nothing but a series of ticks with a fixed interval between ticks. The IEEE 11073 20601 standard allows for two types of relative time clocks where the standard specifies what the fixed interval between ticks is. Clearly such a clock is much simpler for a PHD to implement. As long as the PHD provides its current tick value, the PHG can convert these relative times to a user-friendly wall clock time. The time stamp reported in the Observation.effective[x] element is always the user-friendly wall clock time.

However, there may be use cases where the relative time stamp is desired. Relative time stamps have, by spec, a resolution of either 125 microseconds or microseconds depending upon which relative time clock is used. FHIR only reports time stamps to the millisecond. If one’s use case requires knowing the time stamp to the microsecond, one will need to obtain the reported ticks in this component element. The coincident time stamp Observation will, in this case have information about the current relative time ticks, if, for some reason that is needed.

Note that just because a PHD uses a relative time clock it does not mean that the PHD reports the time stamp at that resolution. One must look at the corresponding PHD Device resource to see what the actual resolution of the relative time clock is.

At the time of this writing there are no PHDs on the market that use relative time stamps because they need very precise time stamps for their measurements. Relative time stamp use has been for simplicity and reduced power consumption. Devices that need very precise time stamps are much more likely to be Point of Care Devices (PoCDs) used in hospital environments.

There are two types relative time stamps defined by IEEE 11073 20601. A ‘relative time’ with a maximum resolution of 125 microseconds and a ‘high resolution relative time’ with a maximum resolution of microseconds. Which relative time stamp is used is given by the MDC code in the Observation.component.code.coding.code element:

The value of the relative time is reported as a valueQuantity in units of microseconds for BOTH types of relative time stamps. An example of a component containing high resolution relative time stamp information is as follows:

"component": [
    {
        "code": {
            "coding": [
                {
                    "system": "urn:iso:std:iso:11073:10101",
                    "code": "68073"
                }
            ],
            "text": "MDC_ATTR_TIME_STAMP_REL_HI_RES: High resolution relative time stamp"
        },
        "valueQuantity": {
            "value": 1234534,
            "system": "http://unitsofmeasure.org",
            "code": "us"
        }
    }
]

Accuracy

Accuracy information is indicated by the Observation.component.code.coding.code element having the value 67914. The accuracy applies only to measurement values that are quantities. It gives the maximum deviation as an absolute value of the reported measurement value from the actual measurement over the entire range of the measurement. It is reported in the units of the measurement itself. Though the IEEE 11073 specializations encourage providing this value it is not mandatory and few market PHDs implement it. An example of an accuracy entry for a thermometer is shown below:

"component": [
    {
        "code": {
            "coding": [
                {
                    "system": "urn:iso:std:iso:11073:10101",
                    "code": "67914"
                }
            ],
            "text": "MDC_ATTR_NU_ACCUR_MSMT: Measurement accuracy"
        },
        "valueQuantity": {
            "value": 0.1,
            "system": "http://unitsofmeasure.org",
            "code": "Cel"
        }
    }
]

Current Limits

The Current Limits component is currently only used in the Pulse Oximeter specialization. It gives the low and high threshold limit values of the primary measurement being monitored. The Current Limits applies only to measurement values that are quantities. When either threshold limit is met an alarm event is triggered if the alarm for the given threshold limit is enabled. If this component is present, an Alert Operational State component shall also be present which indicates the disabled/enabled state of the alarms.

The entry is indicated by the Observation.component.code.coding.code element having the value 67892. The value is encoded in an Observation.component.valueRange element. The units have the same units as the primary measurement. An example of a Current Limits entry is shown below:

"component": [
    {
        "code": {
            "coding": [
                {
                    "system": "urn:iso:std:iso:11073:10101",
                    "code": "67892"
                }
            ],
            "text": "MDC_ATTR_LIMIT_CURR: Current lower and upper alarm threshold values"
        },
        "valueRange": {
            "low": {
                "value": 88,
                "system": "http://unitsofmeasure.org",
                "code": "%"
            },
            "high": {
                "value": 100,
                "system": "http://unitsofmeasure.org",
                "code": "%"
            }
        }
    }
]

Alert Operational State

The Alert Operational State is identified by an Observation.component.coding.code containing one of three possible ASN1ToHL7 codes 67846.n where n is 0, 1, or 2. When reported, there will be a component entry for all three states. The Alert Operational state is used in the Pulse Oximeter specialization. The Alert Operational State applies only to measurement values that are quantities.

The Alert Operational State is a state and not en event. It indicates that the PHD supports an alert mechanism for the primary measurement. It does not indicate that the alert has been triggered. What these alert thresholds might be are indicated in the Current Limits component. A PHD that reports this state shall also report the Current Limits values.

The value of the component entry is a CodeableConcept using the V2 binary code system of “Y” or “N”. When the value is “Y”, the condition is disabled which maybe contrary to expectation. The three entries are as follows:

An example of an entry where the low alert alarm is enabled is as follows:

"component": [
    {
        "code": {
            "coding": [
                {
                    "system": "http://hl7.org/fhir/uv/phd/CodeSystem/ASN1ToHL7",
                    "code": "67846.0"
                }
            ],
            "text": "lim-alert-off: Alerts limits state"
        },
        "valueCodeableConcept": {
            "coding": [
                {
                    "system": "http://terminology.hl7.org/CodeSystem/v2-0203",
                    "code": "N"
                }
            ],
            "text": "At least one alert limit is enabled"
        }
    },
    {
        "code": {
            "coding": [
                {
                    "system": "http://hl7.org/fhir/uv/phd/CodeSystem/ASN1ToHL7",
                    "code": "67846.1"
                }
            ],
            "text": "lim-low-off: Alerts lower limit state"
        },
        "valueCodeableConcept": {
            "coding": [
                {
                    "system": "http://terminology.hl7.org/CodeSystem/v2-0203",
                    "code": "N"
                }
            ],
            "text": "The lower alert limit is enabled"
        }
    },
    {
        "code": {
            "coding": [
                {
                    "system": "http://hl7.org/fhir/uv/phd/CodeSystem/ASN1ToHL7",
                    "code": "67846.2"
                }
            ],
            "text": "lim-high-off: Alert high limit state"
        },
        "valueCodeableConcept": {
            "coding": [
                {
                    "system": "http://terminology.hl7.org/CodeSystem/v2-0203",
                    "code": "Y"
                }
            ],
            "text": "The high alert limit is disabled"
        }
    }
]

It may be convenient for implementers to take advantage of the fact that every ASN1ToHL7 code, though an alpha-numeric string and not a decimal number, contains an MDC code. The digits on the left hand side of the period, when converted to an integer, are an MDC code. The MDC code 67846 in the example above is the Alert Operational State Attribute identifier.

Alert Operational Text String

The Alert Operational Text String provides a human readable string describing the lower and upper threshold limits expressed in the Current Limits component. It is currently used only in the Pulse Oximeter specialization. The Alert Operational Text String applies only to measurement values that are quantities.

The entry is indicated by the Observation.component.code.coding.code element having the value 68104. The text string is limited to US ASCII. The value is encoded in the Observation.component.valueString element. Both the ‘low’ and ‘high’ strings are encoded into a single valureString entry in an application-dependent manner. The strings are not machine processable.

An example of a component entry is as follows:

"component": [
    {
        "code": {
            "coding": [
                {
                    "system": "urn:iso:std:iso:11073:10101",
                    "code": "678104"
                }
            ],
            "text": "MDC_ATTR_AL_OP_TEXT_STRING: PHD provided threshold descriptions"
        },
        "valueString": "Low limit for SpO2 - High limit for SpO2"
    }
]

Measurement Confidence 95

The Measurement-Confidence-95 component is currently used only in the Continuous Glucose specialization. The compoent gives a lower and upper bound between which the manufacturer is 95% confident that the actual reported measurement is within that bounds. The Measurement Confidence 95 applies only to measurement values that are quantities.

The entry is indicated by the Observation.component.code.coding.code element having the value 68236. The value is encoded in an Observation.component.valueRange element. The ranges have the same units as the primary measurement. An example of a Measurement Confidence 95 entry is shown below:

"component": [
    {
        "code": {
            "coding": [
                {
                    "system": "urn:iso:std:iso:11073:10101",
                    "code": "68236"
                }
            ],
            "text": "MDC_ATTR_MSMT_CONFIDENCE_95: Current lower and upper alarm threshold values"
        },
        "valueRange": {
            "low": {
                "value": 98,
                "system": "http://unitsofmeasure.org",
                "code": "mg/dL"
            },
            "high": {
                "value": 100,
                "system": "http://unitsofmeasure.org",
                "code": "mg/dL"
            }
        }
    }
]

The above states that the Continuous Glucose Monitor PHG is 95% sure that the reported measurement of (say 99 mg/dL) lies between 98 and 100 mg/dL.

Threshold Notification String

This component contains a human readable string regarding the various threshold settings a PHD might have. Currently, only the Continuous Glucose Monitor specialization defines the use of this string with respect to its threhold settings. The Threshold Notification String applies only to measurement values that are quantities.

The entry is indicated by the Observation.component.code.coding.code element having the value 68232. The text string is limited to US ASCII. The value is encoded in the Observation.component.valueString element.

An example of a component entry is as follows:

"component": [
    {
        "code": {
            "coding": [
                {
                    "system": "urn:iso:std:iso:11073:10101",
                    "code": "68232"
                }
            ],
            "text": " MDC_ATTR_THRES_NOTIF_TEXT_STRING: PHD provided information about the threshold"
        },
        "valueString": "Glucose concentration has gone under the minimum"
    }
]

Measurement Status

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 will report any measurement it receives from the PHD including error states and let the end user decide what to do with 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 table below lists the special conditions reported and in what elements they are found. The code system from which the code is drawn is also shown.

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

The Observation.identifier entry created by this IG is not for consumption. It is for preventing data duplication during uploads. It is used in conditional create transactions. Consumers are expected to ignore the element.

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 Multi-Number or Compounds

Multi-number or compound or vector quantities are reported in Observation.component elements. There is one component for each compound entry or vector projection. A vector or compound measurement follows the Phd Compound Numeric Observation Profile. An Observation follows the compound profile if the Observation.meta.profile contains a “http://hl7.org/fhir/uv/phd/StructureDefinition/PhdCompoundNumericObservation” entry.

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

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:

"category": [
    {
        "coding": [
            {
                "system": "http://terminology.hl7.org/CodeSystem/observation-category",
                "code": "vital-signs"
            }
        ],
        "text": "Vital Signs"
    }
]
"code": {
    "coding": [
        {
            "system": "urn:iso:std:iso:11073:10101",
            "code": "150020"
        },
        {
            "system": "http://loinc.org",
            "code": "55284-4"
        }
    ],
    "text": "MDC_PRESS_BLD_NONINV: Blood pressure"
},

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

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

The Phd Compound Numeric Entry Profile can contain additional compound entries as noted in the Additional Descriptions 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

There will always be a discussion about whether compounds should be reported together in a single Observation or as a separate Observations. Both approaches are totally reasonable. This IG does not make that decision. That decision is made by the designers of the PHD specialization standard. If the PHD reports the measurement as a compound, it is mapped as a compound.

Measurement Values that are Codes

Sometimes the PHD measurement value is a code. Like every other code in FHIR, one will need a dictionary to look up what the code means. Measurements that are codes follow the Phd Coded Enumeration Observation profile. Observations following that profile will 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:

"valueCodeableConcept": {
    "coding": [
        {
            "system": "urn:iso:std:iso:11073:10101",
            "code": "8417872"
        }
    ],
    "text": "MDC_CTXT_GLU_MEAL_POSTPRANDIAL: 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 Descriptions 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. The ASN1ToHL7 additional description entry alert operation state is not possible in a state or event 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 is shown below:

The overall measurement type is given in the Observation.code element:

"code": {
        "coding": [
            {
                "system": "urn:iso:std:iso:11073:10101",
                "code": "150604"
            }
        ],
        "text": "MDC_PULS_OXIM_DEV_STATUS: Measuring process issues"
    }

and the components containing the events:

"component": [
    {
        "code": {
            "coding": [
                {
                    "system": "http://hl7.org/fhir/uv/phd/CodeSystem/ASN1ToHL7",
                    "code": "150604.2"
                }
            ],
            "text": "sensor-displaced"
        },
        "valueCodeableConcept": {
            "coding": [
                {
                    "system": "http://terminology.hl7.org/CodeSystem/v2-0136",
                    "code": "Y"
                }
            ],
            "text": "Sensor is incorrectly placed on user"
        }
    },
    {
        "code": {
            "coding": [
                {
                    "system": "http://hl7.org/fhir/uv/phd/CodeSystem/ASN1ToHL7",
                    "code": "150604.7"
                }
            ],
            "text": "signal-pulse-questionable"
        },
        "valueCodeableConcept": {
            "coding": [
                {
                    "system": "http://terminology.hl7.org/CodeSystem/v2-0136",
                    "code": "Y"
                }
            ],
            "text": "Questionable pulse detected"
        }
    },
    {
        "code": {
            "coding": [
                {
                    "system": "http://hl7.org/fhir/uv/phd/CodeSystem/ASN1ToHL7",
                    "code": "150604.10"
                }
            ],
            "text": "signal-low-perfusion"
        },
        "valueCodeableConcept": {
            "coding": [
                {
                    "system": "http://terminology.hl7.org/CodeSystem/v2-0136",
                    "code": "Y"
                }
            ],
            "text": "Signal experiencing low perfusion"
        }
    },
    {
        "code": {
            "coding": [
                {
                    "system": "http://hl7.org/fhir/uv/phd/CodeSystem/ASN1ToHL7",
                    "code": "150604.11"
                }
            ],
            "text": "signal-poor"
        },
        "valueCodeableConcept": {
            "coding": [
                {
                    "system": "http://terminology.hl7.org/CodeSystem/v2-0136",
                    "code": "Y"
                }
            ],
            "text": "Signal is poor"
        }
    },
    {
        "code": {
            "coding": [
                {
                    "system": "http://hl7.org/fhir/uv/phd/CodeSystem/ASN1ToHL7",
                    "code": "150604.12"
                }
            ],
            "text": "signal-inadequate"
        },
        "valueCodeableConcept": {
            "coding": [
                {
                    "system": "http://terminology.hl7.org/CodeSystem/v2-0136",
                    "code": "Y"
                }
            ],
            "text": "Signal is inadequate"
        }
    }
]

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:

"type" : {
    "coding" : [
      {
        "system" : "urn:iso:std:iso:11073:10101",
        "code" : "65573"
      }
    ],
    "text" : "MDC_MOC_VMS_MDS_SIMP: Continua 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, 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:"
    }
  ]
}

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

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:

"type": {
    "coding": [
        {
            "system": "urn:iso:std:iso:11073:10101",
            "code": "532353"
        }
    ],
    "text": "MDC_REG_CERT_DATA_CONTINUA_CERT_DEV_LIST: Continua certified device list"
},
"valueCode": [
    {
        "coding": [
            {
                "system": "http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaPHD,
                "code": "32772"
            }
        ]
    },
    {
        "coding": [
            {
                "system": "http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaPHD",
                "code": "8196"
            }
        ]
    },
    {
        "coding": [
            {
                "system": "http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaPHD",
                "code": "4"
            }
        ]
    }
]

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 Continua certified Health and Fitness interfaces. 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 Continua compliance, PHGs must also report their Continua version, the list of certified PHD interfaces, the list of certified Health & Fitness interfaces, and the regulation status.

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 that indicates a gateway. This entry will be identical for all PHGs following this IG. It appears as follows:

"type" : {
    "coding" : [
      {
        "system" : "urn:iso:std:iso:11073:10101",
        "code" : "531981"
      }
    ],
    "text" : "MDC_MOC_VMS_MDS_AHD: Continua Gateway"
}

Continua 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 entry for which Health and Fitness interfaces the PHG supports, so this field is often erroneously populated to indicate support.

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 property entry where a PHG is certified for web-services PCD-01 uploads, FHIR uploads, capability exchange, and Authenticated Persistent Sessions is given below:

"type": {
    "coding": [
        {
            "system": "urn:iso:std:iso:11073:10101",
            "code": "532355"
        }
    ],
    "text": "MDC_REG_CERT_DATA_CONTINUA_AHD_CERT_LIST: Continua certified Health&Fitness interfaces list"
},
"valueCode": [
    {
        "coding": [
            {
                "system": "http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaHFS",
                "code": "0"  // web services PCD-01 uploads
            }
        ]
    },
    {
        "coding": [
            {
                "system": "http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaHFS",
                "code": "7"  // FHIR uploads
            }
        ]
    },
    {
        "coding": [
            {
                "system": "http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaHFS",
                "code": "2"  // Capability exchange
            }
        ]
    },
    {
        "coding": [
            {
                "system": "http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaHFS",
                "code": "6"  // Authenticated Persistent Sessions
            }
        ]
    }
]

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 following the Phd Patient Profile is identified by the Patient.meta.profile element having a “http://hl7.org/fhir/uv/phd/StructureDefinition/PhdPatient” entry.

There is only one additional required entry in the Phd Patient Profile; the Patient.identifier. Any other information is optional and it will not be discussed here.

The required Patient.identifier entry contains an identifier.type using the version 2 Table 0203 code system “http://terminology.hl7.org/CodeSystem/v2-0203” found here. 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:

"identifier": [
    {
        "type": {
            "coding": [
                {
                    "system": "http://terminology.hl7.org/CodeSystem/v2-0203",
                    "code": "MR"
                }
            ],
            "text": "Medical record number"
        },
        "system": "urn:oid:1.2.3.4.5.6.7.8.11",
        "value": "sisansarahId"
    }
]

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

"identifier": [
    {
        "type": {
            "coding": [
                {
                    "system": "http://terminology.hl7.org/CodeSystem/v2-0203",
                    "code": "U"
                }
            ],
            "text": "Unspecified"
        },
        "system": "http://terminology.hl7.org/CodeSystem/v2-0004",
        "value": "U"
    }
]

Links to the Profile Structure Definitions

• Base Observation Profile
• Numeric Observation Profile
• Compound Numeric Observation Profile
• Coded Enumeration Observation Profile
• BITs Enumeration Observation Profile
• Rtsa Observation Profile
• String Enumeration Observation Profile
• Coincident Time Stamp Observation Profile
• Phd Device Profile
• Phg Device Profile
• Patient Profile