Personal Health Device Implementation Guide
1.0.0 - STU 1

Publication Build: This will be filled in by the publication tooling

## 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.

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