11073 PHDs report some device or measurement attributes as an integer where each bit in the integer may mean something. There is no HL7 data type that treats this kind of measurement. This code system defines a code for each of the possible bit settings. The bit value can be reported in a CodeableConcept data type.

The bit may either represent an event or a state. When an event, the defined event has occurred when set. If a state, the described item is either set or cleared. In addition the code may derive from an IEEE 11073 attribute or from a measurement. The codes come either from measurements or from a device attribute. This is encoded in a property of the code. More codes maybe added to this list in the future.

The code values for the properties are included here as well, since the valueset extension for properties is not supported for FHIR R4.

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 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 name for the bit 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, a new code is generated by appending a period followed by the bit position being mapped. Thus a 16-bit measurement may correspond to 16 codes.

A 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 is 0001 1000 0000 0000 the bits set are bits 3 and 4. Note that 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.

This code system can be used to report IEEE 11073-10206 Multiple Boolean State observations, where each bit represents a state and for Bluetooth GHS Compound state/event observations that come with a mask to indicate per bit if it is a state or an event and whether it is supported by the device or not.

It can also be used for 11073-20601 Bit-Str metrics. In version 4 of the IEEE 11073-20601 specification 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.

Generated Narrative: CodeSystem ASN1ToHL7

Properties

This code system defines the following properties for its concepts

Concepts

This case-sensitive code system http://hl7.org/fhir/uv/phd/CodeSystem/ASN1ToHL7 defines the following codes: