This page is part of the Personal Health Device FHIR IG (v2.0.0-ballot: STU 2 Ballot 1) based on FHIR (HL7® FHIR® Standard) v4.3.0. The current version which supersedes this version is 1.0.0. 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 ASN.1 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 ASN.1 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 ASN.1 code is generated by appending a period followed by the MDER Bit position being mapped. Thus a 16-bit ASN.1 BITs measurement may correspond to 16 codes, and a 32-bit ASN.1 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 ASN.1 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 ASN.1 Bits vocabulary one would find it meant 'sensor malfunctioned'.

Reporting Requirements

If the ASN.1 bit represents an event, only the set condition needs to be reported. If the ASN.1 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 version 4 of the IEEE 11073-20601 specification from 2019 the enumeration metric object supports 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 IEEE 11073-20601 versions 3 or earlier that are currently used by PHDs. Thus, the uploader will need to obtain this information from the ASN.1 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 * 2¹⁶ + 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.

• Next: The Observation Identifier
• Previous: Obtaining the Unit code