PhdImplementationGuide 0.3.0 - STU 1 (2nd ballot)
This page is part of the Personal Health Device FHIR IG (v0.3.0: STU 1 Ballot 3) based on FHIR R4. The current version which supercedes this version is 1.0.0. For a full list of available versions, see the Directory of published versions 
The properties and specifications of the PHD are reported in the Device resource. These are the static fields of the attributes reported in the PHD MDS object or Bluetooth Low Energy Device Information Service. Dynamic and observational attributes such as the battery level, remaining battery time, and power status are reported using the Observation resource.
There are six MDS attributes that are reported. The Mds-Time-Info attribute has fields that are dynamic and static, and it is only the static entries which are required should the attribute be present. The following table summarizes these attributes and the Device elements to which they are mapped:
| MDS attribute | Device element |
|---|---|
| System-Id | identifier 1 |
| transport address | identifier 2 |
| Friendly name | deviceName |
| System-Type-Spec-List | specializations |
| Production-Specification | serialNumber version partNumber |
| Reg-Cert-Data-List | version property |
| MdsTimeInfo | property |
The transport address and friendly name are not provided by the MDS but come from the transport protocols. They may not be available and are therefore optional. However, if the PHD does not report a System Id, which may happen if one needs to map non-certified and/or proprietary devices, a transport address should be reported. It is still strongly recommended that the transport address is reported as it is often beneficial to the data consumers. Transport addresses of wireless devices are often printed on the device or the device packaging whereas the system id is not. Most PHD transports provide a means of obtaining a transport address or an equivalent identifier such as a USB VID and PID.
There are several CodeableConcept data types in this mapping where the Coding data type has a ‘display’ element. It is recommended to put the MDC reference identifier as part of the display element if known. The coding system element is always set to “urn.iso.std.iso:11073:10101 when an MDC code”.
The structure definition for the PHD Device Profile is given here
A JSON example is given in PHD Device JSON Example
The uploader shall populate the Device.meta.profile with http://hl7.org/fhir/uv/phd/StructureDefinition/PhdDevice indicating this resource is generated following the PHD Implementation Guide.
All 11073 20601 PHDs are required to have a system identifier. It is an EUI-64 consisting of 8 bytes. The system id is mapped to the Device.identifier.value element as a sequence of 8 2-digit bytes as HEX separated by dashes without the ‘0x’ prefix commonly used in programming languages. An example of such a string is FE-ED-AB-EE-DE-AD-77-C3. Though required for Continua compliance, it is not required in the Bluetooth Low Energy health device specifications. When a PHG encounters such a device it shall enter 00-00-00-00-00-00-00-00 and it is highly recommended to provide a transport address as a means of uniquely identifying the PHD.
In order to discriminate between an identifier that is a system id and that which is a transport address the identifier.type element is used. A Continua-defined CodeSystem Device Identifier Codes has the codes one can use to populate the identifier.type.coding.code element.
The transport addresses are as follows:
| transport | format | example |
|---|---|---|
| Bluetooth | EUI-48 | 00-E5-DE-AD-77-C3 |
| ZigBee | EUI-64 | 36-ED-9A-EE-DE-AD-77-C3 |
| USB | vid.pid | 0043.F90D |
The identifier is encoded as follows:
| Source | Device Encoding |
|---|---|
| System-Id.value | identifier.value=formatted as above identifier.system=”urn:oid:1.2.840.10004.1.1.1.0.0.1.0.0.1.2680” identifier.type.coding.system=”http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDeviceIdentifiers” identifier.type.coding.code=”SYSID” |
| Bluetooth Address | identifier.value=formatted as above identifier.system=”http://hl7.org/fhir/sid/eui-48” identifier.type.coding.system=”http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDeviceIdentifiers” identifier.type.coding.code=”BTMAC” |
| ZigBee Address | identifier.value=formatted as above identifier.system=”http://hl7.org/fhir/sid/eui-64” identifier.type.coding.system=”http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDeviceIdentifiers” identifier.type.coding.code=”ZIGBEE” |
| USB Address | identifier.value=formatted as above identifier.system=”http://hl7.org/fhir/sid/usb” identifier.type.coding.system=”http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDeviceIdentifiers” identifier.type.coding.code=”USB” |
There is actually a problem at the moment as there is no defined system for the transport addresses. Given that the Bluetooth and Ethernet MAC addresses are an EUI-48, the system value ‘http://hl7.org/fhir/sid/eui-48’ represents a placeholder until an actual system value is created. The MAC address placeholder has been floated in the Zulip discussions so it is a reasonable choice at this time. There are no proposals for ZigBee or USB and the placeholders are completely artificial.
The Device type is the same for all PHDs and it indicates that the device is a PHD. The details of what the PHD does is found in the Device.specializations element. The MDC code being used is 65573 (reference id MDC_MOC_VMS_MDS_SIMP). In 11073-10201 this code is described as indicating “a single-purpose medical device”. The code is also used in 11073-20601 to identify the MDS object, but there is no particular description as to its interpretation.
The Device.type shall be encoded as follows:
The display element is optional but highly recommended.
The System-Type-Spec-List attribute contains a list of specializations the PHD complies to. The elements in the list indicate not only what the PHD does, but that it does so in a manner specified in the specialization documents. Each element in the list contains the specialization and its version. The specialization is reported as a 16-bit MDC term code with an assumed partition of INFRA (8) and the version is an integer. In most cases there is just one entry in the list.
For each entry in the System-Type-Spec-List a specializations entry is encoded as follows:
| System-Type-Spec-List entry | Device encoding |
|---|---|
| System-Type-Spec-List.type | specialization.systemType.coding.code=”code” specialization.systemType.coding.system=”urn.iso.std.iso:11073:10101” specialization.systemType.text=”reference-id plus additional text” |
| System-Type-Spec-List.version | specialization.version=”version” |
where “code” is the 32-bit nomenclature code computed from the partition INFRA and the term code from System-Type-Spec-List.type and “version” is the version from System-Type-Spec-List.version.
The display element is optional but it is highly recommended that it be included and the reference id be in the description. The table below gives a list of some of the most common specializations and their codes:
| Specialization | MDC Code partition:term code | Reference Identifier |
|---|---|---|
| Generic 20601 Device | 8::4169 | MDC_DEV_SPEC_PROFILE_GENERIC |
| Pulse Oximeter | 8::4100 | MDC_DEV_SPEC_PROFILE_PULS_OXIM |
| Electro cardiograph | 8::4102 | MDC_DEV_SPEC_PROFILE_MIN_ECG |
| Blood Pressure Cuff | 8::4103 | MDC_DEV_SPEC_PROFILE_BP |
| Thermometer | 8::4104 | MDC_DEV_SPEC_PROFILE_TEMP |
| Respiration rate | 8::4109 | MDC_DEV_SPEC_PROFILE_RESP_RATE |
| Weight Scale | 8::4111 | MDC_DEV_SPEC_PROFILE_SCALE |
| Glucose Monitor | 8::4113 | MDC_DEV_SPEC_PROFILE_GLUCOSE |
| Coagulation meter | 8::4114 | MDC_DEV_SPEC_PROFILE_COAG |
| Insulin Pump | 8::4115 | MDC_DEV_SPEC_PROFILE_INSULIN_PUMP |
| Body Composition Analyzer | 8::4116 | MDC_DEV_SPEC_PROFILE_BCA |
| Peak Flow meter | 8::4117 | MDC_DEV_SPEC_PROFILE_PEAK_FLOW |
| Sleep Apnea Breathing Equipment | 8::4120 | MDC_DEV_SPEC_PROFILE_SABTE |
| Continuous Glucose Monitor | 8::4121 | MDC_DEV_SPEC_PROFILE_CGM |
| Cardiovascular Device | 8::4137 | MDC_DEV_SPEC_PROFILE_HF_CARDIO |
| Strength Equipment | 8::4138 | MDC_DEV_SPEC_PROFILE_HF_STRENGTH |
| Independent Activity/Living Hub | 8::4167 | MDC_DEV_SPEC_PROFILE_AI_ACTIVITY_HUB |
| Medication Monitor | 8::4168 | MDC_DEV_SPEC_PROFILE_AI_MED_MINDER |
The ‘generic’ device on the PHD side indicates that the device follows 20601 but not any specialization. On the PHG side it indicates that the PHG understands anything following the 20601 standard. That would include all specializations since all specializations are a subset of the 20601 standard.
The table below gives the set of 32-bit MDC codes and reference identifiers used in the subsequent mappings.
| 11073 Attribute | description | MDC code | MDC reference identifier |
|---|---|---|---|
| System-Model | Model number | 531969 | MDC_ID_MODEL_NUMBER |
| System-Model | Manufacturer name | 531970 | MDC_ID_MODEL_MANUFACTURER |
| Production-Specification | Unspecified | 531971 | MDC_ID_PROD_SPEC_UNSPECIFIED |
| Production-Specification | Serial number | 531972 | MDC_ID_PROD_SPEC_SERIAL |
| Production-Specification | Part number | 531973 | MDC_ID_PROD_SPEC_PART |
| Production-Specification | Hardware revision | 531974 | MDC_ID_PROD_SPEC_HW |
| Production-Specification | Software revision | 531975 | MDC_ID_PROD_SPEC_SW |
| Production-Specification | Firmware revision | 531976 | MDC_ID_PROD_SPEC_FW |
| Production-Specification | Protocol revision | 531977 | MDC_ID_PROD_SPEC_PROTOCOL |
| Production-Specification | Global Medical Device Nomenclature (GMDN) | 531978 | MDC_ID_PROD_SPEC_GMDN |
| Reg-Cert-Data-List | Continua version | 532352 | MDC_REG_CERT_DATA_CONTINUA_VERSION |
| Reg-Cert-Data-List | Continua Certified Device List | 532353 | MDC_REG_CERT_DATA_CONTINUA_CERT_DEV_LIST |
| Reg-Cert-Data-List | Regulation status | 532354 | MDC_REG_CERT_DATA_CONTINUA_REG_STATUS |
| PHG only | Continua Certified H&FS List | 532355 | MDC_REG_CERT_DATA_CONTINUA_AHD_CERT_LIST |
| Mds-Time-Info | Synchronization method | 68220 | MDC_TIME_SYNC_PROTOCOL |
| Mds-Time-Info | Time capabilities | 68219 | MDC_TIME_CAP_STATE |
| Mds-Time-Info | High resolution relative time resolution | 68224 | MDC_TIME_RES_REL_HI_RES |
| Mds-Time-Info | Relative time resolution | 68223 | MDC_TIME_RES_REL |
| Mds-Time-Info | Absolute Time time resolution | 68222 | MDC_TIME_RES_ABS |
| Mds-Time-Info | Base offset time resolution | 68226 | MDC_TIME_RES_BO |
| Mds-Time-Info | Time synchronization accuracy | 68221 | MDC_TIME_SYNC_ACCURACY |
The System-Model attribute contains two strings, the manufacturer name and the model number. The Device resource has stand-alone primitive elements for these two fields. The mapping is straight forward:
| System-Model | Device encoding |
|---|---|
| System-Model.manufacturer | manufacturer=”System-Model.manufacturer” |
| System-Model.model-number | modelNumber=”System-Model.model-number” |
The Production-Specification attribute values are mapped to three separate elements in the Device, the Device.serialNumber, Device.partNumber, and Device.version. The serialNumber and partNumber elements are string primitives, thus it is not possible to map the PrivateOid of those two values without extensions. The version element, on the other hand, is a Backbone element which will allow such a mapping without the use of extensions.
The mapping is as follows:
| Production-Specification entry | Device encoding |
|---|---|
| Production-Specification.spec-type = 1 (serial number) Production-Specification.value |
serialNumber=”Production-Specification.value” |
| Production-Specification.spec-type = 2 (part number) Production-Specification.value |
partNumber=”Production-Specification.value” |
| Production-Specification.spec-type = 3 (hardware version) Production-Specification.PrivateOid Production-Specification.value |
version.type.coding.code=”531974” version.type.coding.system=”urn.iso.std.iso:11073:10101” version.type.text=”MDC_ID_PROD_SPEC_HW + optional text”** version.value=”Production-Specification.value” version.component.system=”system id formatted as above”* version.component.value=”Production-Specification.PrivateOid”* |
| Production-Specification.spec-type = 4 (software version) Production-Specification.PrivateOid Production-Specification.value |
version.type.coding.code=”531975” version.type.coding.system=”urn.iso.std.iso:11073:10101” version.type.text=”MDC_ID_PROD_SPEC_SW + optional text”** version.value=”Production-Specification.value” version.component.system=”system id formatted as above”* version.component.value=”Production-Specification.PrivateOid”* |
| Production-Specification.spec-type = 5 (firmware version) Production-Specification.PrivateOid Production-Specification.value |
version.type.coding.code=”531976” version.type.coding.system=”urn.iso.std.iso:11073:10101” version.type.text=”MDC_ID_PROD_SPEC_FW + optional text”** version.value=”Production-Specification.value” version.component.system=”system id formatted as above”* version.component.value=”Production-Specification.PrivateOid”* |
| Production-Specification.spec-type = 6 (protocol version) Production-Specification.PrivateOid Production-Specification.value |
version.type.coding.code=”531977” version.type.coding.system=”urn.iso.std.iso:11073:10101” version.type.text=”MDC_ID_PROD_SPEC_PROTOCOL + optional text”** version.value=”Production-Specification.value” version.component.system=”system id formatted as above”* version.component.value=”Production-Specification.PrivateOid”* |
*The PrivateOid is only a 16-bit unsigned number. To give it some meaning, the system-id of the device is placed in the Identifier ‘system’ value to link the PrivateOid to this physical device in the presence of some other possible identifiers.
**The text elements are optional but it is encouraged to include them and populate them with at least the reference identifier.
The Reg-Cert-Data-List contains the Continua version, list of certified PHD interfaces, and the regulation status. The Continua version is mapped to an additional Device.version element and the other two fields are mapped to a Device.property element.
The Continua version has a major and minor component which are 8-bit unsigned integers. The code reported in the Device.versions element is obtained by concatenating the major-version, a dot (.), and the minor version. For example, “6.1” where “6” is the major version and “1” is the minor version.
The Continua version code is mapped to a Device.version element.
The Reg-Cert-Data-List attribute reports the list of Continua certified PHD (Personal Area Network) interfaces as a list of Continua-specified ‘PHD’ codes. Note there is a difference between certified PHD interfaces and supported PHD interfaces. The Continua-specified certification codes obtained from the Reg-Cert-Data-List are a combination of a transport code, Tcode, and a specialization code which is based on the 16-bit term code of the MDC code for the specialization. See generating the PHDCodes
The PHDCodes are mapped to a list of property.valueCode elements. The property.type element, which identifies the property, is given by the MDC 32-bit code 532353. Its reference id is MDC_REG_CERT_DATA_CONTINUA_CERT_DEV_LIST.
The regulation status element is a 16-bit ASN1 BITs ‘state’ value (see ASN1 Coding Description). At the current time only Mder bit 0 is defined. Being a state value, both set and cleared states are reported. In fact, it is the cleared state which represents that the device is regulated.
The regulation status is mapped to an additional Device.property.valueCode element. The Device.property.type element, which identifies the property, is given by 532354.0 following the ASN1 BITs mapping where the code 532354 is the MDC code for the regulation status. Its reference identifier is MDC_REG_CERT_DATA_CONTINUA_REG_STATUS. The ‘0’ appended to the regulation status code indicates Mder bit 0. The Device.property.valueCode will indicate either “Y” (set) or “N” (cleared).
The following table summarizes the mapping of the Reg-Cert-Data-List information to FHIR:
| Reg-Cert-Data-List | Device Mapping |
|---|---|
| Reg-Cert-Data-List: continuaVersion | version.type.coding.code=”532352” version.type.coding.system=”urn.iso.std.iso:11073:10101” version.type.text=”MDC_REG_CERT_DATA_CONTINUA_VERSION + text” version.value=”Continua version code” |
| Reg-Cert-Data-List: certified PHD interfaces | property.type.coding.code=”532353” property.type.coding.system=”urn.iso.std.iso:11073:10101” property.type.text=”MDC_REG_CERT_DATA_CONTINUA_CERT_DEV_LIST + text” property.valueCodeN.coding.code=”PHDCodeN“ property.valueCodeN.coding.system=”http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaPHD” |
| Reg-Cert-Data-List: regulation status | property.type.coding.code=”532354.0” property.type.coding.system=”http://hl7.org/fhir/uv/phd/CodeSystem/ASN1ToHL7” property.type.text=”regulation-status” property.valueCode.coding.code=”Y/N” property.valueCode.coding.system=”http://terminology.hl7.org/CodeSystem/v2-0136 “ property.valueCode.text=”Y=unregulated N=regulated” |
Text elements are recommended but optional.
The Mds-Time-Info attribute is required on PHDs that support a real time clock of some type and report time stamps in their measurements. In Bluetooth Low Energy devices these properties must be inferred from other information like the Current Time Service. If the PHD does NOT report a time stamp in any of its measurements, there is no need to report the static time information EXCEPT that there is no time synchronization.
The Mds-Time-Info attribute has a 16-bit ASN1 BITs field for the time capabilities. They are mapped as follows:
| Mder Bit position | IEEE.ASN1 Code | ASN.1 name | static | Device. |
|---|---|---|---|---|
| 0 | 68219.0 | mds-time-capab-real-time-clock | yes | property.type.coding.code=”68219.0” |
| 1 | 68219.1 | mds-time-capab-set-clock | yes | property.type.coding.code=”68219.1” |
| 2 | 68219.2 | mds-time-capab-relative-time | yes | property.type.coding.code=”68219.2” |
| 3 | 68219.3 | mds-time-capab-high-res-relative-time | yes | property.type.coding.code=”68219.3” |
| 4 | 68219.4 | mds-time-capab-sync-abs-time | yes | property.type.coding.code=”68219.4” |
| 5 | 68219.5 | mds-time-capab-sync-rel-time | yes | property.type.coding.code=”68219.5” |
| 6 | 68219.6 | mds-time-capab-sync-hi-res-relative-time | yes | property.type.coding.code=”68219.6” |
| 7 | 68219.7 | mds-time-capab-bo-time | yes | property.type.coding.code=”68219.7” |
| 8 | 68219.8 | mds-time-state-abs-time-synced | no | |
| 9 | 68219.9 | mds-time-state-rel-time-synced | no | |
| 10 | 68219.10 | mds-time-state-hi-res-relative-time-synced | no | |
| 11 | 68219.11 | mds-time-mgr-set-time | no | |
| 12 | 68219.12 | mds-time-capab-sync-bo-time | yes | property.type.coding.code=”68219.12” |
| 13 | 68219.13 | mds-time-state-bo-time-synced | no | |
| 14 | 68219.14 | mds-time-state-bo-time-UTC-aligned | yes | property.type.coding.code=”68219.14” |
| 15 | 68219.15 | mds-time-dst-rules-enabled | yes | property.type.coding.code=”68219.15” |
The required remaining property elements in each reported case are as follows:
An optional text element containing at least the ASN.1 name from the above table is encouraged:
Only the static fields shall be reported and all the static fields are treated as events thus they only need to be reported if set. Reporting cleared static states is optional.
The Mds-Time-Info.time-sync-protocol indicates the method of time synchronization which has one of the term code values in the following table:
| 32-bit code | Reference identifier | description | partition:term code |
|---|---|---|---|
| 532224 | MDC_TIME_SYNC_NONE | An uncalibrated and unsynchronized local clock source | 8::7936 |
| 532234 | MDC_TIME_SYNC_EBWW | A manually set time, by ‘eyeball and wristwatch’ | 8::7946 |
| 532225 | MDC_TIME_SYNC_NTPV3 | Network Time Protocol Version 3.0 (RFC 1305) | 8::7937 |
| 532226 | MDC_TIME_SYNC_NTPV4 | Network Time Protocol Version 4.0 (under dev) | 8::7938 |
| 532227 | MDC_TIME_SYNC_SNTPV4 | Simple Network Time Protocol v4 (RFC 2030) | 8::7939 |
| 532228 | MDC_TIME_SYNC_SNTPV4330 | Simple Network Time Protocol v4 (RFC 4330) | 8::7940 |
| 532229 | MDC_TIME_SYNC_BTV1 | Bluetooth Medical Device Profile | 8::7941 |
| 532235 | MDC_TIME_SYNC_USB_SOF | Synced to the 1kHz USB “start-of-frame” clock | 8::7947 |
| 532230 | MDC_TIME_SYNC_RADIO | Atomic Clock synchronization through RF | 8::7942 |
| 532231 | MDC_TIME_SYNC_HL7_NCK | Synchronized via Health Level 7 NCK (network clock) | 8::7943 |
| 532232 | MDC_TIME_SYNC_CDMA CDMA | mobile telecommunications synchronization | 8::7944 |
| 532233 | MDC_TIME_SYNC_GSM | GSM - Network Identity and Time Zone (NITZ) | 8::7945 |
| 532236 | MDC_TIME_SYNC_OTHER | A time sync method that is out of scope for IEEE 11073 | 8::7948 |
| 532237 | MDC_TIME_SYNC_OTHER_MOBILE | A time sync method based on other mobile network technology that is not listed above | 8::7949 |
| 532238 | MDC_TIME_SYNC_GPS | A time sync method based on GPS information | 8::7950 |
If the Mds-Time-Info.time-sync-protocol indicates some other value besides 7936 (no time synchronization) the uploader must look at the time capabilities bits 8, 9, 10, or 13 to see if the PHD actually is synchronized. If the time capabilities bits indicate that the PHD is synchronized, then the time synchronization method in Mds-Time-Info.time-sync-protocol is reported in the Device.property element. Otherwise the uploader reports that the PHD is unsynchronized.
The uploader maps the state of synchronization to the Device.property as follows:
To date there are no PHDs that support an external time synchronization. However, many PHDs have the PHG set its time and PHGs are required to support an external time synchronization. The IEEE PHD WG is working on providing some means to indicate synchronization by the PHG. In lieu of that, a consumer can only infer that the PHG probably set the time on the PHG if
The time synchronization accuracy is given by the Mds-Time-Info.time-sync-accuracy field. This value shall not be reported if the PHD reports a value of 0xFFFFFFFF which indicates unknown. Otherwise the value reported is in units of 1/8th millisecond. When reported in the Device.property element it is scaled to microseconds. The mapping is as follows:
#### Time Resolution The Mds-Time-Info attribute has three fields that report the resolution of its time clocks.
The Mds-Time-Info.time-resolution-abs-time represents the resolution of the absolute-time clock when the sensor supports an absolute time clock. If the sensor supports a base-offset time clock it represents the resolution of the base-offset time clock. The sensor is not allowed to support both time clocks simultaneously during an association. Which time clock is supported is indicated by the settings of the Mder 0 and 7 bits of the time capabilities (Mds-Time-Info.mds-time-caps-state).
The sensor may additionally support both relative time clocks or just one or both of the relative time clocks without any ‘wall time’ clock. In practice, support of more than one real time clock at the same time is rare.
If the respective time resolution has a value of 0, it indicates that the resolution is unknown and it shall not be reported. In all other cases, the resolutions are reported.
All time resolution values shall be scaled to units of microseconds. When supporting absolute time, the Mds-Time-Info.time-resolution-abs-time is in units of 1/100th of a second. When supporting base-offset time, the Mds-Time-Info.time-resolution-abs-time is in units of 1/65536th of a second. In the base-offset case, the special value of 0xFFFF means one second. The Mds-Time-Info.time-resolution-rel-time is in units of 1/8th millisecond and the Mds-Time-Info.time-resolution-hi-res-relative-time is in units of microseconds.
Though not a part of the MdsTimeInfo attribute the Tick resolution attribute used for RR-intervals in the ECG specialization is also encoded as a property in this group. However its units are in cycles per second, such that a value as 1024 indicates 1024 cycles per second.
| Device.property element | value |
|---|---|
| Device.property.type.coding.code | “68229” (Tick Resolution) |
| Device.property.type.coding.system | “urn.iso.std.iso:11073:10101” |
| Device.property.type.text (optional) | “MDC_ATTR_TICK_RES” |
| Device.property.valueQuantity.value | Tick-Resolution.value |
| Device.property.valueQuantity.system | “http://unitsofmeasure.org” |
| Device.property.valueQuantity.code | “Hz” (UCUM code for Hertz) |
The encoding for the resolution values is as follows:
| Device.property element | value |
|---|---|
| Device.property.type.coding.code | “68222” (absolute time) “68226” (base-offset time) “68223” (relative time) “68224” (hi-res relative time) |
| Device.property.type.coding.system | “urn.iso.std.iso:11073:10101” |
| Device.property.type.text (optional) | “MDC_TIME_RES_ABS” “MDC_TIME_RES_BO” “MDC_TIME_RES_REL” “MDC_TIME_RES_REL_HI_RES” |
| Device.property.valueQuantity.value | “10000 x Mds-Time-Info.time-resolution-abs-time“ “1000000 x Mds-Time-Info.time-resolution-abs-time/65536” “125 x Mds-Time-Info.time-resolution-rel-time“ “Mds-Time-Info.time-resolution-hi-res-relative-time“ |
| Device.property.valueQuantity.system | “http://unitsofmeasure.org” |
| Device.property.valueQuantity.code | “us” (UCUM code for microseconds) |
An example of a PHD Blood Pressure cuff Device mapping is given here
For the Consumer of this profile the following table gives a quick guide to the main features
| item | Location in Device resource |
|---|---|
| Type of Device | specializations.systemType.coding.code=”MDC 32-bit code for device specialization” |
| Manufacturer name | manufacturer |
| Model number | modelNumber |
| serial number | serialNumber |
| system identifier | identifier.system=”urn:oid:1.2.840.10004.1.1.1.0.0.1.0.0.1.2680” identifier.value=”system id as 8 2-digit HEX values separated by dashes” |
| time synchronization | property.type.coding.code=”68220” property.valueCode.coding.code=”code for time synchronization” |
© HL7.org 2017+ (Devices WG). hl7.fhir.uv.phd#0.3.0 based on FHIR v4.0.0 generated 27/03/2019.
Links: Table of Contents |
QA Report | Search |
Version History |
|
Propose a change