Digital Health Integration and Connectivity Standards (POCT1-A/Bluetooth)

A glucose meter's job seems to end when it shows a number, but that number is often needed somewhere else: a hospital chart, a phone app, a clinician's dashboard. Two quite different sets of standards carry it there. In hospitals, meters follow the POCT1-A connectivity standard and report through a data manager to the lab and medical-record systems [1][2]. At home, meters pair with a phone over Bluetooth [3], may describe their readings in the IEEE 11073 glucose meter format [4], or skip the phone entirely and upload over a cellular network [5].

POCT1-A: how hospital meters reach the lab system

Point-of-care testing (POCT) means a test run at the bedside instead of in the central laboratory. When we read the history, the starting point surprised us: around 2000, hospital glucose meters didn't connect to hospital information systems at all, and only a small fraction of their results were captured electronically [1]. An industry group, the Connectivity Industry Consortium, formed in 2000 to fix that. Its POCT1-A standard was published in 2001 and upgraded to POCT1-A2 in 2005, and the Clinical and Laboratory Standards Institute (CLSI) now maintains it [1].

POCT1-A is a design framework, not a product. FDA's database of recognized standards describes POCT01-A2 as a framework for building devices, workstations and interfaces so that many brands of point-of-care devices can exchange data in both directions with access points, data managers and laboratory information systems from different vendors [2]. As of October 2026, the edition FDA lists is still the second one, POCT01-A2, in an entry dated May 2025 [2].

What the data manager adds

A data manager is the software that gathers results from a hospital's whole fleet of meters and passes them on to the lab and record systems. Much of what people think of as "connected meter" safety lives here and in the meter's own software, not in POCT1-A. A 2011 review of hospital glucose testing describes software that checks each operator's ID against a list of trained staff and blocks patient testing for anyone not on it [6]. Meters can also require control samples, liquids with a known glucose level, at intervals the hospital chooses. If the controls aren't run on time or fall outside their range, the meter locks until someone troubleshoots it and gets a passing result [6].

The same software links each result to the operator, the meter's serial number and the test strip lot, which gives the lab a documentation trail for its federal quality requirements [6]. A 2014 review lists remote quality-control monitoring, and remote lockout of operators who skip their control checks, among the key connectivity goals for hospital meters [1].

Bluetooth: how home meters reach a phone

Most connected home meters talk to a phone app. FDA's decision summary for the Contour Next One, cleared in November 2016, names automatic data transfer to a smart device as the system's key feature: the meter sends results over Bluetooth Low Energy (BLE) to phones and tablets running the Contour Diabetes app [3]. The meter it was compared against, the Contour Next USB, had no wireless link at all [3]. Roche's Accu-Chek Guide, cleared in August 2016, lists BLE for wireless connectivity alongside a USB port for computers [7].

The "low energy" part is the point. In 2010, before BLE reached products, an engineer at Bluetooth chip maker Nordic Semiconductor wrote that classic Bluetooth was already in some glucose meters, but its power draw limited coin-cell battery life to a few tens of hours [8]. BLE was built to fix that, and its first version was planned to include health profiles for measurements such as body temperature, blood pressure and glucose [8]. The Contour Next One runs on a CR2032 coin cell [3].

One gap we couldn't close: the FDA summaries for both meters say "Bluetooth Low Energy" without naming which Bluetooth profile the meter implements [3][7]. A profile is the agreed set of rules for a device type, so this matters for whether a meter can pair with apps other than its maker's, and we didn't find a primary record that answers it.

IEEE 11073: a shared language for the readings

Bluetooth moves the data; a data standard says what the data means. IEEE 11073-10417 is the part of the ISO/IEEE 11073 family that defines how a personal glucose meter communicates with a "compute engine" such as a cell phone, personal computer or set-top box, with the stated goal of plug-and-play interoperability [4]. FDA added the 2023 edition to its recognized list in May 2025 and will accept declarations of conformity to the older 2015 edition until July 4, 2027 [4]. Our article on IEEE 11073 interoperability standards goes further into the standard itself.

A 2015 study from Korea shows what this looks like in practice. The researchers built an Android app containing an IEEE 11073 "manager" that received readings from a glucometer over the classic Bluetooth Health Device Profile, then converted them into an HL7 Continuity of Care Document, a standard clinical summary format, and sent them to a web server [9]. Because both sides spoke the standard, the authors note, the same connector could work with any personal health device that implements ISO/IEEE 11073 [9].

Cellular meters and remote patient monitoring

Some meters don't need a phone. Telcare's meter, cleared in July 2011, had an embedded cellular module that sent results to the company's remote database, called Telserve, and could receive messages back from it; a professional version of Telserve let clinicians review the data [5]. Livongo's BG1000, cleared in June 2020, is described in its FDA summary as a cellular-connected meter whose readings are stored in memory and may be sent over a cellular network to a secure server [10]. Telcare's summary adds a limit worth knowing: the system is not intended to provide automated treatment guidance or decisions [5].

Automatic upload is also what Medicare's remote monitoring rules depend on. CMS's December 2025 booklet for clinicians lists blood sugar among the measurements remote physiologic monitoring can track, and requires that data be collected electronically and uploaded automatically by a device that meets FDA's definition of a medical device [11]. Depending on the billing code, readings must come in on 2 to 15 days, or on 16 or more days, out of each 30 [11]. A meter that uploads every strip result by itself produces exactly that kind of record; a handwritten logbook doesn't. For more on the money side, see the economics of remote patient monitoring and [test strips](/diabetic-test-strips/the-economics-of-remote-patient-monitoring-rpm-and-test-strips/). What a care team does with those uploaded readings is a decision for the patient and that team.