Personal Health Device Implementation Guide
1.1.0 - STU 1.1
Personal Health Device Implementation Guide
1.1.0 - STU 1.1
This page is part of the Personal Health Device FHIR IG (v1.1.0: STU 1) based on FHIR (HL7® FHIR® Standard) 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
The PHD Base Observation profile contains the elements that are common to all PHD Observation profiles describing measurements. These element are:
The structure definition is given here
HL7 has predefined an extension for the Observation resource to reference a gateway device. This extension is used in this profile to reference the Device resource representing the Personal Health Gateway (PHG) device.
The PHD Observation Identifier is used to prevent data duplication. It serves as the selection criteria in the conditional create. All measurements that have a timestamp earlier than the current time of connection are required to use the conditional create upload when converted to FHIR. If the uploader knows that the received measurement is a new measurement or the measurement is received with no time stamp, then the identifier is not needed.
Ideally the uploader will implement a duplication detection mechanism and filter out any measurements that have already been uploaded. One possible mechanism is to record the latest time stamp of any measurement received during a connection. Then for a given device and patient and upload destination, on a subsequent connection filter out any measurements with a time stamp earlier than the recorded latest time stamp of the previous connection. The latest time stamp is then updated given the information received during the current connection. The filter not only saves the server from handling the conditional update transaction but saves bandwidth and upload costs.
The identifier is a combined string of elements that contain sufficient information to uniquely identify the measurement for a given patient and device. The identifier is thus a combination of the device identifier, patient identifier, PHD timestamp of the measurement, measurement type code, measurement value, and the list of Supplemental-Types codes if any. Each entry is separated by a dash (-). It is important to use the time stamp of the PHD and not the potentially modified time stamp placed in the Observation.effective[x] element. Two PHGs may have slightly different times which would allow a duplicate measurement to appear different.
All Continua compliant PHGs must implement this identifier in the same manner. Compliance assures that even if the patient uploads the same measurement to the same server from a different PHG, a duplicate of the measurement will not be generated on the server. Some Bluetooth Low Energy PHDs do not provide a means of deleting stored data and will upload all the old data with each new addition up to the point of the device storage.
The consumer of this Observation resource should ignore the identifier element used for the PHD Profiles.
Generation of the PHD Observation Identifier is PHD Profile specific and is outlined in the respective profiles.
One obtains the IEEE 11073-20601 measurement type for the code element in the same manner for all metric measurements. See the section Obtaining the Observation.code for the details of this mapping.
The subject element points to the PhdPatient resource using the logical id of the Patient resource, for example 'Patient/123546'
In situations where the gateway knows that the patinet is the person performing the measurement, a Observation.performer[] element can also point to the PhdPatient resource. However, in most situations this is unknown and the performer is not filled in.
PHDs report time stamps in one of four methods and may not report time stamps at all. The PHG will include a time stamp in every observation that is uploaded using a conversion as needed based on the time stamp data received from the PHD. The time stamp types and corresponding PHG conversions are summarized below:
| Time Stamp Type | Description | PHD requirement | PHG conversion |
|---|---|---|---|
| Absolute Time | Local Wall clock time without time zone information | PHD must provide its current absolute time | PHG maps UTC plus offset and may correct it as described in the section Coincident Time Stamp |
| Base-Offset Time | Time as UTC plus time added in minutes to get the local time | PHD must provide its current base-offset time | PHG maps UTC plus offset and may correct it as described in the section Coincident Time Stamp |
| Relative time | The number of ticks in units of 1/8th millisecond | PHD must provide its current relative time | PHD obtains the current relative time at its current time and maps all measurement times to UTC plus offset based upon the difference given by the current relative time |
| Hi-Resolution Relative time | The number of ticks in units of microseconds | PHD must provide its current hi-res time | PHD obtains the current hi-res relative time at its current time and maps all measurement times to UTC plus offset based upon the difference given by the current relative time |
| No time stamp | PHG uses time of reception as UTC plus offset |
The PHG maps the 'converted' time stamp to either an Observation.effectiveDateTime element or an Observation.effectivePeriod element. The second situation occurs when the metric measurement includes a Measurement-Active-Period (duration) attribute. Then the time stamp attribute gives the start of the period and the end of the period is obtained by adding the Measurement-Active-Period value to it. If no time stamp is provided, the PHG, using the time of reception of the measurement as its time stamp must then do the reverse; the time of reception is the end time and the start time is given by subtracting the Measurement-Active-Period value from it.
The Observation.device element is a reference to the Device resource representing the PHD that took the measurement.
This element references Observation resources that are in some manner related to this Observation resource. In the PHD use case, this situation occurs whenever the metric measurement reported by the PHD has a time stamp and/or the measurement contains a source handle reference attribute.
When the metric measurement contains a time stamp, there will be a Coincident Time Stamp Observation defining the details of how the Observation.effective[x] element is generated.
A Source-Handle-Reference attribute points to a previously reported measurement that is important to this measurement. By previously it is meant that the measurement is reported prior to the current measurement but in the same connection. If multiple such measurements have been received, the correct one is that which is most recently received. As an example, the cardiovascular specialization defines a session measurement defining some type of exercise period, such as a run. All measurements taken during that run have a source handle reference attribute pointing to the session measurement. Since Source-Handle-Reference attributes use IEEE 11073 Object handle values and not Logical resource ids to point to measurements, the PHG will need to keep track of the Observation resources created during a connection to identify the correct Observation resource, and thus logical id, the Source-Handle-Reference attribute points to. The latest version of the IEEE 11073-20601 standard also supports a Source-Handle-Reference-List containing a list of handles so there can be more than one entry generated due to these attributes. The references are placed in a derivedFrom element.
Component elements are used whenever the metric measurement contains additional information attributes that further describe the measurement. There are four such attributes that can be reported by all three types of metric measurements; the Supplemental-Types, Relative-Time, Hi-Res-Relative-Time, and Measurement-Status.
The Supplemental Types attribute contains a list of one or more partition-term code pairs. These define MDC codes that describe some property of the measurement. There will be one component element for each entry pair in the list. For example, the code MDC_MODALITY_SPOT used in the pulse oximeter specialization indicates that the measurement reported is a stable average. In contrast there is MDC_MODALITY_FAST and MDC_MODALITY_SLOW. The component elements are as populated as follows:
| Observation.component element | entry | Additional Information |
|---|---|---|
| code.coding.code | 68193 | This is the MDC code for the Supplemental Types attribute |
| code.coding.system | urn:iso:std:iso:11073:10101 | Indicates the MDC coding system |
| code.text | optional but | Should contain the reference id MDC_ATTR_SUPPLEMENTAL_TYPES along with any other additional text |
| valueCodeableConcept.coding.system | urn:iso:std:iso:11073:10101 | Indicates the MDC coding system |
| valueCodeableConcept.coding.code | the 32-bit MDC code | (partition) * 216 + term code |
| valueCodeableConcept.text | optional but | Should contain the reference id for the reported code along with any other additional text |
The Relative-Time-Stamp attribute contains the time stamp of the measurement in units of ticks where each tick is 1/8th of a millisecond. When mapped to FHIR, it is converted to microseconds (multiplied by 125). This attribute is reported to audit the derivation of the Observation.effective[x] time stamp value. The component element is mapped as follows:
| Observation.component element | entry | Additional Information |
|---|---|---|
| code.coding.code | 67985 | This is the MDC code for the Relative-Time-Stamp attribute |
| code.coding.system | urn:iso:std:iso:11073:10101 | Indicates the MDC coding system |
| code.text | optional but | Should contain the reference id MDC_ATTR_TIME_STAMP_REL along with any other additional text |
| valueQuantity.value | the value | This is relative time value scaled to microseconds |
| valueQuantity.unit | optional | |
| valueQuantity.system | http://unitsofmeasure.org | Indicates the UCUM coding system |
| valueQuantity.code | shall be the code 'us' for microseconds |
The Hi-Res-Relative-Time-Stamp attribute contains the time stamp of the measurement in units of ticks where each tick is a microsecond. This attribute is reported as a means to audit the derivation of the Observation.effective[x] time stamp value. The component element is mapped as follows:
| Observation.component element | entry | Additional Information |
|---|---|---|
| code.coding.code | 68073 | This is the MDC code for the Relative-Time-Stamp attribute |
| code.coding.system | urn:iso:std:iso:11073:10101 | Indicates the MDC coding system |
| code.text | optional but | Should contain the reference id MDC_ATTR_TIME_STAMP_REL_HI_RES along with any other additional text |
| valueQuantity.value | the value | This is relative time value scaled to microseconds |
| valueQuantity.unit | optional | |
| valueQuantity.system | http://unitsofmeasure.org | Indicates the UCUM coding system |
| valueQuantity.code | shall be the code 'us' for microseconds |
The category attribute contains an element identifying the observation as being generated by a PHD. This can be used in searches and distinguishes such observations from observations collected using clinical equipment or collected in a clinical context. Uploaders shall include a category element with a fixed coding as specified by the profile.
Note that for vital signs observations there also should be a category element.
The Measurement Status attribute is an ASN.1 16-BITs measurement used to report errors or other special conditions. It defines 11 events. Being events, only set bits are reported. The attribute reports one or more of the following conditions in the indicated Mder bit position:
Though it is possible to have multiple bits simultaneously set, some combinations of set bits do not make sense and should not occur.
To report these cases in FHIR requires the use of three different elements. The interpretation codes are taken from the measurement status value set defined in the Point of Care implementation guide. The mapping is shown in the following table:
| status Mder bit | ASN1 name | Observation element |
|---|---|---|
| 0 | invalid | dataAbsentReason.coding.code="error" http://terminology.hl7.org/CodeSystem/data-absent-reason |
| 1 | questionable | interpretation.coding.system="http://hl7.org/fhir/uv/pocd/CodeSystem/measurement-status" interpretation.coding.code="questionable" |
| 2 | not-available | dataAbsentReason.coding.code="not-performed" dataAbsentReason.coding.system="http://terminology.hl7.org/CodeSystem/data-absent-reason |
| 3 | calibration-ongoing | interpretation.coding.system="http://hl7.org/fhir/uv/pocd/CodeSystem/measurement-status" interpretation.coding.code="calibration-ongoing" |
| 4 | test-data | meta.security.coding.code="HTEST" meta.security.coding.system="http://terminology.hl7.org/CodeSystem/v3-ActReason" |
| 5 | demo-data | meta.security.coding.code="HTEST" meta.security.coding.system="http://terminology.hl7.org/CodeSystem/v3-ActReason" |
| 8 | validated-data | interpretation.coding.system="http://hl7.org/fhir/uv/pocd/CodeSystem/measurement-status" interpretation.coding.code="validated-data" |
| 9 | early-indication | interpretation.coding.system="http://hl7.org/fhir/uv/pocd/CodeSystem/measurement-status" interpretation.coding.code="early-indication" |
| 10 | msmt-ongoing | dataAbsentReason.coding.code="temp-unknown" dataAbsentReason.coding.system="http://terminology.hl7.org/CodeSystem/data-absent-reason" |
| 14 | msmt-value-exceed-boundaries | interpretation.coding.system="http://hl7.org/fhir/uv/pocd/CodeSystem/measurement-status" interpretation.coding.code="in-alarm" |
| 15 | msmt-state-ann-inhibited | interpretation.coding.system="http://hl7.org/fhir/uv/pocd/CodeSystem/measurement-status" interpretation.coding.code="alarm-inhibited" |
Note that a status field is reported in the Nu-Observed-Value and Enum-Observed-Value attributes. When these attributes are sent, the status field in the attribute replaces the Measurement-Status attribute should the PHD have sent both (which would seem unlikely).
The status field is also reported in the Compound-Nu-Observed-Value. In this case the status field applies only to the Observation.component. An overall Measurement-Status attribute may also be present. The Observation.component has its own dataAbsentReason and interpretation element. However it does not have a meta element. On the other hand it does not make sense to have one sub-value of a compound report test data while another does not. A compound measurement in 20601 is a single measurement taken as a whole. However it is possible that a sub-value fails in the measurement process thus an error can occur on one sub-value while the others succeed.
IG © 2016+ HL7 International / Health Care Devices. Package hl7.fhir.uv.phd#1.1.0 based on FHIR 4.0.1. Generated 2024-10-18
Links: Table of Contents |
QA Report
| Version History |
|
Propose a change