Interoperability Standards (IEEE 11073)

Interoperability Standards: Unlocking Connected Health

ISO/IEEE 11073 is a family of standards for how personal health devices, blood glucose meters (BGMs) among them, describe their readings and send them to another device. It doesn't make a meter wireless. What it gives a meter that already connects is a shared vocabulary, so software from a different company can read a result without guessing what each number means [1][2].

The glucose meter part is IEEE 11073-10417. FDA's database of recognized standards describes it as a definition of communication between glucose meters and "compute engines," such as phones and personal computers, using specific term codes and behaviors so the devices work together plug-and-play [1]. In the standard's terms, the meter is the agent and the receiving system is the manager. The two first associate, the agent then reports its readings, and the connection is released when they're done [2].

As of October 2026, FDA recognizes the 2023 edition of IEEE 11073-10417 and will accept declarations of conformity to the older 2015 edition until July 4, 2027 [1]. ISO adopted the 2015 edition word for word as ISO/IEEE 11073-10417, third edition, in April 2017 [3]. FDA staff wrote in 2015 that most diabetes devices were not broadly interoperable, with proprietary communication protocols leaving few ways to analyze meter data alongside pump and CGM data [4].

Key Achievements

• Semantic Interoperability: "Semantic" means the receiving system understands what a value is, not only that it arrived. The 11073 family does this with Medical Device Communication (MDC) codes from ISO/IEEE 11073-10101 [5]. For a glucose meter, those codes are meant to tell the receiving system which sample type a reading came from, so a control-solution test isn't filed as a blood reading.
• Bluetooth Harmonization: Bluetooth's versions of the 11073 device standards are its health profiles, and for meters that is the Bluetooth Low Energy (BLE) Glucose Profile [5]. FDA's 2016 review of the Contour Next One describes automatic transfer of readings over Bluetooth to the company's own Contour Diabetes App [6]. Here's what surprised us: using BLE isn't the same as using the profile. Every Bluetooth device has to comply with the Bluetooth Core Specification, which only covers getting bytes across. Sending proprietary data over BLE is common. In a review published in January 2025, only a few diabetes products were certified as reaching the semantic level [5]. Our article on Bluetooth and BLE connectivity standards covers the radio side.
• Safety Protocols: Control solution is a liquid with a known glucose range, used to check that a meter and its strips are working. Its results belong in a separate bucket from blood readings. FDA's review of the Contour Next GEN says results run in the meter's "QC" mode are marked as control tests and kept out of the average of the person's results [7]. How a meter knows it's a control test varies. FDA's review of the OneTouch Ultra Plus Flex lists manual tagging of blood versus control solution, while its predicate, an earlier OneTouch Verio system, detected the sample type automatically [8]. A data standard can carry that label to another system, but it can't add a label the meter never recorded.

Enabling Connected Health

From the phone, readings travel on to health apps and records. Apple's HealthKit has had a blood glucose data type since iOS 8 [9]. Glooko's early history shows the problem these standards were meant to solve. Its 2013 FDA clearance describes a MeterSync cable that plugged into the phone's headphone jack, with an adapter for some meters and an infrared adapter for others, to download readings from a named list of compatible meters [10].

One route into a hospital's electronic health record (EHR) is translation into HL7 FHIR (Fast Healthcare Interoperability Resources), a web-based format. A 2018 comparison found that 11073 messages are compact but can't carry patient information, while FHIR resources are larger and can link each observation to a patient and a device [2]. Security is a separate job. A 2025 overview noted that security issues are frequent with both Bluetooth LE and FHIR interfaces, and that at the time of writing only two diabetes management services had publicly declared a FHIR interface [5].