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 value set 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 an upcoming version 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 the versions of the 11073-20601 specification 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 |