Definition of a Metric Measurement

The 11073 20601 protocol is not only extensible but self-describing. The PHG does not need to know, in advance, anything about the type of measurements the PHD supports. All this information is provided in the protocol exchanges. That exchange may involve the sending of data that is not a measurement, for example the user may change the units on a weight scale from pounds to kilograms. The scale will inform the PHG of this change. If that change is sent without an accompanying weight, the incidence of the change alone makes no sense to send downstream. Consequently, a measurement is only reported if the PHD sends one of twelve attributes in the metric event (called an Observation Scan in 11073-20601 language). These attributes are:

A metric measurement always contains one and only one of the above attributes. If a metric event is sent by the PHD that does NOT contain one of the 12 measurement attributes, the metric event is providing information so the PHG can decode any subsequently sent measurements.

Again, these details are only of concern to the encoder of the FHIR resources, the consumer of the FHIR resources is not concerned with the types of attributes delivered by the PHD.

Metric Protocol-Only Attributes

Protocol-Only attributes are not mapped to FHIR.

In the 11073 20601 specification, measurements are mapped to Metric Objects. The Metric Object contains several attributes that are used to describe the measurement such as the Type, Unit-Code, and Simple-Nu-Observed-Value. However, it also contains attributes that are only of interest to the PHG for the purposes of decoding the measurement. For the purposes of optimization on the wire, the PHD only sends attributes that have changed when it sends a measurement. The PHG is expected to retain static and dynamic information. There are also techniques used to efficiently encode the data and tell the PHG how big and in what sense this data may come. To accomplish this encoding the PHD sends keys describing the encoding and the PHG uses these keys to decode the data. These keys are not meant for security purposes but just to minimize data transmission size.

Attributes are also used for these keys. Once the measurement has been reconstructed using these keys and the retained static and dynamic data, the attributes providing these keys are no longer of interest. This guide will refer to these attributes as 'Protocol-Only' attributes.

The last four attributes are essential for the decoder to properly map ASN1 BITS measurements to FHIR using the ASN1 coding system but the attributes themselves are not of interest once mapped. For example, the Capability-Mask-* attribute tells which bits are supported by the PHD. The encoder needs to know which bits these are but once known, the attribute value itself is no longer of interest. The State-Flag-* indicates to the decoder whether the bit is an event or a state. If an event, only the set case (event occurred) needs to be recorded, for example, 'sensor malfunctioned' in the sensor status measurement of several specializations. If a 'state' both the set or cleared case needs to be reported, for example 'patient in room' or 'patient not in room' in the independent living case.

Mder FLOATs and SFLOATs

Mder FLOATs and SFLOATs are the 11073 20601 means of encoding floating point numbers. The primary reason for this encoding is to indicate the precision of the measurement. The SFLOAT is 16-bits and the FLOAT is 32-bits. In the SFLOAT, the most significant 4 bits is the exponent and the remaining 12 bits the mantissa. In the FLOAT, the most significant byte is the exponent and the remaining 24 bits the mantissa. Both the exponent and mantissa are signed.

The exponent gives the precision. It indicates where the decimal point goes in the mantissa. A negative exponent of -N moves the decimal point to the left N places and a positive exponent of +N moves the decimal point to the right N places.

Thus, it is possible in this encoding to distinguish between the value 2, 2.0, 2.00, etc. Numerically, they all have the same value, but 2.00 indicates that the value is two but taken with a sensor that has a precision to the hundredths.

The table below gives some examples of SFLOAT values and how they shall be encoded into the FHIR valueQuantity.value:

In the FLOAT case the above values would be encoded as follows:

Special Values

The Mder encoding also has a set of 5 reserved special values which represent some type of error condition. They are as follows:

Nomenclature codes

11073 20601 uses nomenclature codes to represent and entity that needs to be machine readable. Nomenclature codes are 32-bit unsigned integers. The most significant 16 bits give the partition and the least significant 16 bits give the term code. Partitions group the term codes into sets with a common meaning. For example, in PHD there is a health and fitness partition which groups terms assoicated with health and fitness, such as term codes for activities like run, bike, swim, altitude gained, distance, etc.

In FHIR, the 32-bit value of the code is always used. In the PHD to PHG exchange, the 16-bit code is used when the partition can be inferred from the attribute to decrease bandwidth.

CodeableConcepts

In this guide there will be several instances where the 11073 10101 nomenclature (MDC) codes are mapped to FHIR. In almost all cases this mapping involves an element that is a CodeableConcepts data type. The mapping is as follows:

• CodeableConcept.coding.code = partition * 2¹⁶ + term code
• CodeableConcept.coding.system = urn:iso:std:iso:11073:10101
• CodeableConcept.coding.display = reference identifier (optional)

The display element is optional since the uploader may not know what the code means; for example, if the uploader works with a PHD specialization developed after the uploader had been released. However, this guide strongly encourages that the display element contains at least the normative reference identifier for the MDC code if it is known.

Obtaining the Observation.code

Every 11073 20601 metric instance is required to have a Type attribute. In most cases, the Type attribute value maps directly to the Observation.code element. However, the metric object may contain other attributes which modify or change this value. The following algorithm indicates the procedure an encoder can take to obtain the Observation.code entry:

• set partition = Type.partition
• set termCode = Type.code
• if there is a Metric-Id attribute:
  • set termCode = Metric-Id
  • if there is a Metric-Id-Partition attribute:
    • set partition = Metric-Id-Partition
• if there is a Nu-Observed-Value or Enum-Observed-Value
  • set termCode = *-Observed-Value.metric
• final 32-bit MDC code: value = partition * 2¹⁶ + termCode

Once this MDC code value is obtained, the Observation.code element is populated as follows:

• if the application wishes to transcode this MDC code into other coding systems the application is free to do so but
  • the MDC code shall be present in a coding element
  • if the code matches one of the FHIR LOINC magic codes, the LOINC magic code shall be present in a coding element
  • any other coding translations desired may be placed in an additional coding element.
• for the MDC code the mapping is as follows:
  • Observation.code.coding.code = value
  • Observation.code.coding.system = "urn:iso:std:iso:11073:10101"
  • Observation.code.display should contain the reference identifier as part of the text.

The requirement for the MDC reference identifier is not mandatory and is not used as the Observation.code.coding.code value because the reference identifier is not provided by the sensor device in the exchange protocol. Requiring the reference identifier would require that the PHG have an internal map. However, the main reason for not requiring the reference identifier is that doing so would defeat future interoperability. An older PHG would not know the reference identifier of a new specialization but it would be able to propagate the new code since that is provided by the device.

The consumer of FHIR resources containing the PHD data does not need to concern itself with this complexity. All it needs to do is obtain the Observation.code.coding.code element supporting the 11073-10101 system value to get the measurement type.

Obtaining the Unit Code

Measurements that are quantities (numerics and real-time-sample-arrays) may have units. Though the 11073 20601 specification allows units for enumeration measurements, the use of units for such measurements does not make sense and this profile assumes that enumeration measurements will never have units. In the newer versions of the 20601 specification, units are not allowed in Enumeration objects.

Obtaining the units in most cases is a simple as decoding the Unit-Code attribute. However, the Nu-Observed-Value and Compound-Nu-Observed-Value attributes have their own unit code, and this value overrides the value in the Unit-Code attribute. When these attributes are received applications will need to obtain the unit code from the unit-code subtructure.

11073-20601 unit codes are 11073-10101 MDC values in partition DIM which has a value of 4. The partition value is assumed in the 20601 exchanges and only the term code value of the units is sent. The FHIR encoder will need to create the 32-bit code from the term code and the assumed partition value of 4.

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.

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:

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

The Observation Identifier

Some PHDs will resend old data repeatedly. To prevent excessive resource duplication on the RESTful FHIR server this IG specifies an Observation.identifier whose sole purpose is to perform a conditional create transaction. The identifier is not to be interpreted by a consumer of the resource.

The idea is that the identifier uniquely describes the measurement such that if the same measurement were resent at a later time, the identifier would be the same. At the same time it needs to be selective enough such that no other newly taken measurement will produce the same identifier.

In practice it is preferred that the uploader filter the data in some application dependent manner such that duplicates are not sent. Duplicates, even if armed with a conditional create transaction, waste bandwidth and conditional create operations are more demanding on the server than simple create transactions.

The identifier is generated from a combination of the basic measurement components, such as the type, value, timestamp, units, and contributions from extra descriptors should they be present. The specifics on how to create this identifier are specified in this guide.

Generating the PHD Reported Time Stamp Identifier

This algorithm shows how one generates the time stamp as reported by the PHD for use in the Observation.identifier element. The Observation.identifier element is used in the PHD profiles to perform conditional creates and thus eliminate data duplication.

• If the sensor reports absolute time this string will be encoded as an HL7 DTM YYYYMMDDTHHMMSS.ss.
  • Example 1: The sensor reports absolute time as an 8-byte Binary Coded Decimal (BCD) Mder OCTET STRING: 0x20 0x07 0x02 0x01 0x12 0x05 0x20 0x86 which is the date and then the time. reported_sensor_timestamp = 20070201120520.86
  • Example 2: The BTLE sensor reports absolute time as a 7-byte string with no hundredths and it is not BCD or Mder. The year is the first two bytes in little endian thus 0x7E0 = 2016: 0xE0, 0x07, 0x05, 0x17, 0x11, 0x34, 0x11 reported_sensor_timestamp = 20160523T175217.00
• If the sensor reports base-offset time this string will be encoded as seconds.fractional_seconds.offset. The sensor reports base offset time as an 8-byte string. The first four bytes are the seconds since 1900/01/01 00:00:00 (not the Unix Epoch!), the next two bytes the fractional seconds in units of 1/65536th of a second and the last two bytes are the offset in minutes. Only the offset is signed.
  • Example: 8-byte Mder OCTET STRING: 0xD4 0x67 0x40 0x38 0x13 0x14 0xFE 0xD4. The seconds are 0xD4674038 = 3563536440, fractional seconds 0x1314 = 4884, and offset -300.
    • The reported_sensor_timestamp = 3563536440.4884.-300.
    • If offset is positive: reported_sensor_timestamp = 3563536440.4884.+300
• If the sensor reports relative time the string will be the reported value in units of 1/8th seconds as a decimal unsigned integer with no leading zeros. On the wire this value is an Mder sequence of 4 bytes with the MSB to the left.
• If the sensor reports high resolution relative time, the string will be the number of microseconds as an unsigned integer with no leading zeros. On the wire this value is an Mder sequence of 8 bytes with the MSB to the left.