Common base profile with the elements that are common to the PHD IG Observation profiles.

Observations from a PHD where the measurement is number

Observations from a PHD where the measurement is a set of numbers such as the x, y, and z components of an acceleration.

Observations coming from a PHD where the measurement is a set of numbers such as the x, y, and z components of an acceleration.

Observations coming from a PHD where the measurement value is a code.

Observations from a PHD where the measurement is an ASN1 BITS value.

Observations from a PHD where the measurement is a sample array.

Observations from a PHD where the measurement is a human readable string.

Observations containing a coincident timestamp.

Profile for the Device Resource for a PHD

Profile for the Device Resource for a PHG

The patient information reported from personal health gateways (PHG)

Profile for the DeviceMetric for a PHD

Profile for device alert that capture alert conditions from personal health devices.

The accuracy of a measurable quantity.

The Confidence 95 range of a measurable quantity.

Reference to a coincident timestamp observation that relates the gateway timeline to the PHD timeline.

An example CodeSystem that defines two private codes for an imaginary company in the MDC CodeSystem.

Codes for the IEEE 11073-10206 BITs measurement bit values. For example, 150604.0 is the code for bit 0 in measurement type 150604 which is a pulse oximeter status. The description of that code is 'Indicates the device is not connected with the sensor'.

Codes that identify the device 'identifier', such as whether an EUI is a system id, Bluetooth address, or Ethernet MAC address

Codes used to describe the Continua Health and Fitness interfaces supported by a Personal Health Gateway. More codes maybe added to this list in the future.

Codes used to describe the PHD types and interfaces supported by a Personal Health Gateway. More codes maybe added to this list in the future.

Codes used to categorize device alerts coming from PHD devices.

Codes that are missing from the MDC (Medical Device Communication) standard.

Codes used for tagging observations coming from PHD devices. More codes maybe added to this list in the future.

ValueSet for the ANS1ToHL7 codes that are not derived from enumeration measurements.

ValueSet for the ANS1ToHL7 codes that are not derived from enumeration measurements.

ValueSet for the eventOrState property values in the ASN1ToHL7 CodeSystem

Value set for those Asn1ToHL7 codes whose source is a measurement attribute.

ValueSet for the source property values in the ASN1ToHL7 CodeSystem

ValueSet containing all codes from the ContinuaPHDInterfaceIDs CodeSystem, representing Continua Personal Area Network (PHD) interfaces supported by a Personal Health Gateway.

ValueSet containing all codes from the ContinuaHFS CodeSystem, representing Continua Health and Fitness Server (HFS) interfaces supported by a PHG.

ValueSet for the ISO/IEEE 11073-10101 Nomenclature Codes for Device Specialization types

ValueSet for the ISO/IEEE 11073-10101 Nomenclature Codes for Clock Resolution types

ValueSet for the ISO/IEEE 11073-10101 Nomenclature Codes for Clock Types

ValueSet for the MDC Device Identifier Types

ValueSet for the MDC Device Version Type codes. ToDo: We still need to define a code for the ACOM version.

ValueSet for the ISO/IEEE 11073-10101 Nomenclature excluding Object partition.

ValueSet for the ISO/IEEE 11073-10101 Nomenclature filtered by & Device nomenclature partition.

ValueSet for the MDC codes representing time synchronization methods such as NTP, GPS, and others.

ValueSet for the MDC CodeSystem.

Capability statement. This statement indicates what the server must support and accept to work with this Guide. Though the CapabilityStatement indicates, for example, that the server must support the Device resource, it does not mean the server must save the Device resource. The use case may only be interested in the Observation and Patient resources. What it does mean is that the server cannot generate an error when the PHG uploads a Device resource or references a Device resource that it has uploaded.

This example shows a full first time transaction Bundle containing Patient, Device, and Observation resources.

This example is an upload from a Bluetooth Low Energy Pulse oximeter device streaming data. In this case the gateway has previously uploaded measurements and saved the logical ids of the Patient and Device resources so they are not re-uploaded.

This example PHD Device resource is referenced by other examples and is present for the validator.

This example maps the System Information data from a Blood Pressure PHD. This device did not report Reg-Cert-Data-List information.

This example maps an Glucose monitor PHD. It is referenced by a coded Glucose meal context observation

This example maps an Android Gateway

This example maps an Android Gateway

This example is a PhdDeviceMetric for a Blood Pressure measurement.

This example maps a known patient where an optional patient name is included.

This example maps an unknown patient.

This example is a simple numeric observation of a pulse rate from a pulse oximeter. This particular example also has a component as the original measurement has a Supplemental Information attribute indicating that this is a SPOT measurement (a stable average).

This example is a simple numeric observation from a pulse oximeter with an alert.

This example is a simple numeric observation of a health thermometer.

This example is a simple numeric observation of a (continuous) glucose monitor.

This example contains a NaN (not a number) measurement.

This example is an RTSA observation of a pleth signal from a pulse oximeter. This very short waveform maps to a valueSampledData element.

This example is an RTSA observation of an ECG waveform with scaling.

This example contains measurement that is itself a code. The measurement indicates that the glucose measurement was taken after lunch or dinner, also known as the meal context.

This example is a device and sensor status measurement from a pulse oximeter.

This example reports the status of a BPM measurement.

This example reports a measurement from a Blood Pressure cuff.

This example is from a Blood Pressure cuff with one missing component.

This artificial example combines a glucose measurement and context information.

This example observation reports some arbitrary text from a cardiovascular fitness device.

This example observation reports some arbitrary text from a Glucose meter explaining the failure of the measurement.

This example is a Coincident Timestamp where the PHG is better synchronized to NTP time than the PHD.

This example is a Coincident Timestamp where the PHD has a time fault; it's current timeline is unknown and it reported timestamps in its measurements.

This Coincident Timestamp observation is referenced by the Blood Pressure Observation

This Coincident Timestamp observation is referenced by other Observation examples.

This example defines the structure for blood pressure observations, including systolic (60-279 mmHg) and diastolic (40-200 mmHg) components with absolute ranges, using both IEEE 11073 MDC and LOINC codes.

This example is a PhdDeviceAlert for a Blood Pressure measurement alert condition.

This example is a PhdDeviceAlert generated from a pulse oximeter observation alert condition.