Personal Health Device Implementation Guide
1.0.0 - STU 1

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

ASN1 BITs Code System

11073 PHDs report some measurements as a 16- or 32-bit integer where each bit in the integer may mean something. There is no HL7 data type that treats this kind of measurement. Continua has created a code system where each of the possible bit settings in a given measurement is mapped to a code. The code can be reported in a CodeableConcept data type.

The uploader can generate the code from the data received from the PHD. No external information is necessary unless the uploader wants to populate the ‘display’ element of the CodeableConcept data type. It is recommended that the uploader populate the display element with at least the 11073 specialization ASN1 name for the bit setting. It is not required because it is desired to have an uploader that can still work with future specializations and in that case, it is not possible for the uploader to know what the 11073 specialization ASN1 name is as it is not sent over the wire; it is only available from the specialization documents.

To generate the code, the uploader obtains the code for the type of measurement which is used to populate the Observation.code.coding.code element. Then for each bit to be reported, the new ASN1 code is generated by appending a period followed by the Mder Bit position being mapped. Thus a 16-bit ASN1 BITs measurement may correspond to 16 codes, and a 32-bit ASN1 BITs measurement may correspond to 32 codes.

Each code is reported in an Observation.component.code.coding.code element which means there may be up to 16 or 32 component elements in the measurement. An ASN1 bit can only have two values, set or cleared. Thus the value is reported in the Observation.component.valueCodeableConcept.coding.code element using the HL7 Version 2 binary coding system; “Y” for set and “N” for cleared.

  • As an example, the continuous glucose monitor specialization has a Device status measurement whose type is given by the code 8418060. If the value reported in the BITs field is 0001 1000 0000 0000 the Mder bits set are bits 3 and 4. Note that Mder bit 0 is the HIGH order bit. Bit 3 means ‘sensor malfunction’ and bit 4 means ‘device specific alert’. This measurement would require two component elements and one would be 8418060.3 and the other would be 8418060.4. Note these are alpha-numeric strings and not decimal numbers. If one took the code 8418060.3 and looked it up in the ASN1 Bits vocabulary one would find it meant ‘sensor malfunctioned’.

Reporting Requirements

If the ASN1 bit represents an event, only the set condition needs to be reported. If the ASN1 bit represents a state, both the set and cleared conditions need to be reported. If the device does not support the bit, it is not required to report the value. If the uploader would, nevertheless, desire to report the unsupported situation it is done in an Observation.component.dataAbsentReason.coding.code element with code “unsupported”. The Observation.component.value[x] element is absent. Undefined bits are never reported.

In the upcoming version 4 of the 11073 20601 specification the enumeration metric object will support both a Capability-Mask-Simple/Basic and State-flag-Simple/Basic attribute that must be present when an enumeration BITs measurement is reported. The Capability-Mask attribute will have a bit set when the corresponding bit in the actual measurement is supported by the device. The State-Flag attribute will have a bit set if the corresponding bit is a state. If cleared, the corresponding bit is an event.

However, these attributes are not present in 11073-20601 versions 3 or earlier that are currently used by PHDs. Thus, the uploader will need to obtain this information from the ASN1 mapping tables.

Mder Bit Position

To generate this code, the uploader needs to understand that Mder Bit position 0 is the most significant bit of the 16- or 32-bit integer and the Mder Bit position 15 or 31 is the least significant bit of the 16- or 32-bit integer, respectively. The following table shows the Mder bit position and the corresponding integer value representing it when that bit is set.

Mder Bit Position 16-bit integer value 32-bit integer value
0 0x8000 0x80000000
1 0x4000 0x40000000
2 0x2000 0x20000000
3 0x1000 0x10000000
4 0x800 0x8000000
5 0x400 0x4000000
6 0x200 0x2000000
7 0x100 0x1000000
8 0x80 0x800000
9 0x40 0x400000
10 0x20 0x200000
11 0x10 0x100000
12 0x8 0x80000
13 0x4 0x40000
14 0x2 0x20000
15 0x1 0x10000
16   0x8000
17   0x4000
18   0x2000
19   0x1000
20   0x800
21   0x400
22   0x200
23   0x100
24   0x80
25   0x40
26   0x20
27   0x10
28   0x8
29   0x4
30   0x2
31   0x1

Example mapping

A pulse Oximeter sends a ‘Device and sensor annunciation status’ measurement. The Type attribute value for this measurement is MDC_PULS_OXIM_DEV_STATUS which has a term code 19532 in the partition SCADA (2). The 32-bit code value is then 2 * 216 + 19532 or 150604. The defined ASN.1 bits for this measurement in the pulse oximeter specialization are:

bit position ASN.1 Item Description
0 sensor-disconnected Agent reports that the sensor is disconnected from the instrument.
1 sensor-malfunction Agent reports that the sensor is malfunctioning or faulting.
2 sensor-displaced Agent reports that the sensor is not properly attached or has been dislodged, an accurate measurement is, therefore, prevented.
3 sensor-unsupported An unsupported sensor is connected to the agent.
4 sensor-off Agent reports that sensor is not connected to the user.
5 sensor-interference Agent reports that there is interference due to ambient light or electrical phenomena.
6 signal-searching Signal analysis is currently in progress prior to measurement availability.
7 signal-pulse-questionable Agent determines that a questionable pulse is detected.
8 signal-non-pulsatile Agent detects a nonpulsatile signal.
9 signal-erratic Agent reports that the signal is erratic or is not plausible.
10 signal-low-perfusion Agent reports a consistently low perfusion condition exists.
11 signal-poor Agent reports a poor signal exists, possibly affecting accuracy.
12 signal-inadequate Agent reports that the incoming signal cannot be analyzed or is inadequate for producing a meaningful result.
13 signal-processing-irregularity Agent has determined that some irregularity has been detected while processing the signal.
14 device-equipment-malfunction A general device fault has occurred in the agent.
15 device-extended-update An extended display update is currently active.

The mapped codes reported in the FHIR Observation.component.coding.code elements are given by

HL7 Code ASN.1 name bit type
150604.0 sensor-disconnected event
150604.1 sensor-malfunction event
150604.2 sensor-displaced event
150604.3 sensor-unsupported event
150604.4 sensor-off event
150604.5 sensor-interference event
150604.6 signal-searching event
150604.7 signal-pulse-questionable event
150604.8 signal-non-pulsatile event
150604.9 signal-erratic event
150604.10 signal-low-perfusion event
150604.11 signal-poor event
150604.12 signal-inadequate event
150604.13 signal-processing-irregularity event
150604.14 device-equipment-malfunction event
150604.15 device-extended-update event

See currently defined ASN1 Codes.