Glucose Meter Class I Recall: A Use Error Lesson

A Class I recall where the sensor did nothing wrong

On October 20, 2026 the FDA notified the public that Nova Biomedical’s StatStrip Glucose Hospital Meter System Gen 2.0 was under a Class I recall, the agency’s most serious category. The FDA notice is short, and the reason deserves a second read. Nothing was wrong with the glucose measurement. In the notice, Nova Biomedical states that the issue “does not impact the analytical performance of glucose measurements.” What failed was the screen.

When an operator scans a patient ID or a quality control barcode, prior information may remain on the meter’s display. If the operator accepts what’s shown, the glucose result can be filed to the previous patient’s medical record, or to a QC ID. Which also means the record of the patient who was actually tested has no result for that test. The FDA lists the possible harms as delayed treatment, unnecessary treatment including inappropriate insulin, and failure to treat the intended patient. Critically ill patients and infants are at greater risk, because they may not be able to communicate hypoglycemia symptoms.

As of October 5, Nova Biomedical had reported one serious injury and no deaths. Only the Gen 2.0 model is affected, on every firmware version; earlier generations are not. The company has put a shipment hold on new Gen 2.0 systems while it validates a software update, with a phased rollout planned from November 2026. Hospitals that have an alternative meter were told to stop using the affected one until it’s updated. (Figures and dates are from the FDA notice as updated on October 30, 2026.)

Accurate numbers, wrong patient

Everyone who builds a measurement device optimizes the same things: accuracy, repeatability, electrical safety, the certification path. Those are what a spec sheet lists, a test lab measures, and an auditor checks. This recall touched none of them. It landed in the half-second between one test and the next, on a ward, with a nurse holding the meter in one hand.

That half-second is the part of a device that’s hardest to see on a bench. In the lab you scan one barcode, run one strip, read one result, and the sequence is clean. On the floor the sequence gets interrupted a dozen times: a call light, a second patient, a strip that didn’t seat. Through all of that the device has to stay right about its own state. A screen still showing the last patient’s identifier after the next one has been scanned is, technically, a display bug. In risk-management vocabulary it’s a hazard.

Regulators have a name for this category: use error. Not user error, and the difference is the whole point. A use error is an action, or a missing action, by the person using the device that leads to a different result than the manufacturer intended or the user expected. The standard scopes this to normal use, which includes reasonably foreseeable misuse. IEC 62366-1, the usability engineering standard for medical devices, and the FDA’s human factors guidance both start from the same premise: the operator’s workload is one of the device’s operating conditions, and the device doesn’t get to use it as an excuse.

Accuracy is the ticket. Workflow is the bottom line.

Our view, from building home-use medical and health devices for brands since 1996: accuracy gets you into the market. What keeps you there is everything around the measurement. Who the user is, what else they’re doing, what the screen says at the moment they glance at it, and what the device does when they don’t glance at all.

Home-use devices make this harder. The operator is a patient or a family member, untrained, often tired, sometimes the person whose reading is being taken. We covered the sourcing side of that in our home-use medical device guide. The lesson from this recall is that a trained nurse in a hospital was enough to trip the same wire. Designing for the distracted user is the general case. Home use just makes it louder.

The interim measures in the FDA notice are instructive. Facilities were advised to enable “Validate Patient ID’s” in the meter’s data management system (for sites with ADT integration in their EMR), to set operator logoff mode so the operator is logged out after every test, and to verify the patient identifier on the Confirm Patient ID screen and again on the result screen. Two of those are settings that could have shipped switched on; the third is a check the screen could have forced. That’s the design lesson in a single list: the safe behavior was already in the system, and it was optional.

Three questions for the review before tooling

We run a 33-item DFX risk review before any product goes to tooling, with red, yellow and green ratings and a rule that a single red stops the program. Most of the items are about manufacturability, cost, safety and compliance. A recall like this one is a strong argument for making state handling an explicit item on any device with a screen and a memory. Three questions we’d want answered in that review:

What gets cleared, and when? Every event that changes the context (a new user, a new sample, a new session, a timeout) should have a defined effect on what’s displayed and what’s stored. “The previous value stays until it’s overwritten” is a design decision. It should be a deliberate one, written down, and tested with the interruptions the real workflow has.

What does the confirmation screen actually confirm? A confirm screen that shows stale data confirms the wrong thing with complete confidence. The screen should present the value the device is about to act on, read from the same place the device will read it. A cached copy from the last transaction doesn’t count.

Which safe behaviors are defaults? Logging the operator out after each test. Validating the ID against the record system whenever that data is available. If a behavior is safe enough to recommend in a recall notice, it’s safe enough to ship switched on. Let the people who want it off go and turn it off.

None of this is exotic engineering. It’s the kind of item that gets skipped because the firmware works in the demo and the schedule is tight. A gate review exists so that “works in the demo” isn’t the bar. The same thinking already sits behind our rule that a safety-critical function gets two independent protections, hardware and firmware: assume the failure happens, then make it harmless.

What this means if you’re sourcing a device

If you’re a brand sourcing a connected health device, this recall hands you a useful audit question. Ask your manufacturer where use-related risk sits in their design review, and whether it only shows up in the test plan. Ask what their device does when the user changes mid-session. Ask to see a real CAPA case, and check whether the root cause landed at design level or stopped at a replaced part.

On scope: we design and build under ISO 13485:2016 and provide documentation and testing support for your regulatory work. The usability engineering file, the submission and the clearance belong to the device’s legal manufacturer, typically the brand. The state-handling questions above, though, get answered during development, on our side of the table, and we’d much rather answer them before tooling than in a field notice.

If you’re planning a device with a screen and a memory, send an inquiry and ask us to walk through how a DFX review would treat it. You’ll have an initial response within two business days.

FAQ

What does a Class I recall mean?

It’s the FDA’s most serious recall classification: a situation where there is a reasonable probability that use of the product will cause serious adverse health consequences or death. The class describes the potential severity of the hazard, and says nothing about how many incidents have occurred. In this case one serious injury had been reported when the notice was issued.

Was this a hardware fault or a software fault?

According to the FDA notice, the problem is in what the display shows after a barcode scan, it affects Gen 2.0 meters on all firmware versions, and the correction is a software update. According to the notice, analytical performance isn’t affected, so the test chemistry and sensor aren’t implicated.

What’s the difference between use error and user error?

User error puts the blame on the person. Use error, the term used in IEC 62366-1 and in FDA guidance, describes a result the user didn’t intend, under foreseeable conditions of use. The usability engineering process then makes reducing it the manufacturer’s job.

Does a contract manufacturer handle usability engineering?

Partly. The usability engineering file and the regulatory submission belong to the legal manufacturer, usually the brand. A contract manufacturer contributes design-level risk review, state handling and interlock design, and the documentation and test evidence those files need. Agree in writing who owns which part before development starts.