October 2026: FDA Calls for Removal of Nova StatStrip Glucose Meter Gen 2.0 — Residual Barcode Can Attribute Glucose Results to Another Patient

Recall overview

On 20 October 2026, the U.S. Food and Drug Administration's Center for Devices and Radiological Health updated its handling of a Class I recall in the Recall and Early Alert section: until a software update becomes available, affected Nova Biomedical StatStrip Glucose Hospital Meter Systems (Gen 2.0) should be removed from locations where they are used and sold.

In the FDA device recall database, the action corresponds to event 99546, comprising 5 records numbered Z-3128-2026 through Z-3132-2026. The FDA publication date is 11 September 2026, the firm-initiated date is 29 July 2026, and the current status is open and classified.

Defect and clinical risk

According to the recall records, the problem lies in software synchronisation and timing between barcode scanning and patient data processing. When a new patient barcode or quality control (QC) liquid barcode is scanned, information from the previous barcode may remain on the screen. If the operator does not notice and simply confirms, the current glucose result is written into the previous patient's medical record and uploaded to the data management system, while the current patient's record receives no result.

The records state that the defect affects all software versions from 0.00.13.10 to 1.5.14.25, but does not affect the analytical accuracy of the glucose measurement itself. FDA determined the cause to be software design.

The consequences run in two directions. The previous patient may receive a glucose value that is not theirs and be treated on that basis, including inappropriate insulin administration. The current patient has no documented glucose status, leaving treatment decisions without a supporting basis. Residual QC barcodes cause a similar problem: QC results may be attached to the wrong identifier, or a test may fail without the user being able to identify why. The records specifically note that critically ill patients, neonates and infants cannot verbalise hypoglycaemia symptoms and are therefore at higher risk.

Affected models and distribution

The affected models are two StatStrip Glucose Hospital Meter Systems (63685 and 66739) and three StatStrip Glucose and β-hydroxybutyrate combined meters (63683, 63910 and 66429). Taking record Z-3128-2026 as an example, 20,616 units are involved, distributed throughout the United States and to 22 countries and regions outside the U.S., including the United Kingdom, Germany, France, Italy, the Netherlands, Ireland, Finland, Switzerland, Israel, Canada, Brazil, Chile, South Korea, Thailand, Turkey and New Zealand.

The product was cleared through the 510(k) pathway under number K232075, product code PZI, and is a prescription glucose meter intended for near-patient testing.

Firm actions

On 29 July 2026, the firm issued an urgent medical device recall notification by email to consignees. It requires users to check that the patient information on screen matches the barcode just scanned, to stop using the device immediately and report to the administrator if a mismatch occurs, to forward the notification to all departments using the device and post it at storage and point-of-use locations, and to return a completed acknowledgement form.

The firm also placed a full shipment hold on all new Gen 2.0 units pending verification of the corrective action.

FDA's 20 October update and interim workarounds

The FDA page published on 20 October 2026 took the action a step further. In addition to recommending removal, it set out interim measures for the period while awaiting the software update:

• Organisations that have electronic health record admission, discharge and transfer (ADT) information enabled should select and apply the Validate Patient ID's setting in NovaNet.
• Set the meter's logout mode to log out automatically after every test.
• Verify patient identifiers such as name and date of birth after each scan, and again once the result is displayed.
• If a result is found to be attributed to the wrong patient, flag or remove it immediately and notify the clinical team.
• Organisations with alternative devices available should stop using the affected devices.

The page also states that the removal recommendation applies only to Gen 2.0 models and not to earlier versions such as Gen 1.86.

Timeline signals

One change in the timeline is worth noting. In the recall records, the firm originally planned to complete validation of the firmware update and announce its availability in September 2026. The FDA page of 20 October 2026 states that the software update is planned for phased release from November 2026. As of 5 October 2026, the firm had reported one serious injury and no deaths.

Read together, these two pieces of information explain why removal was still required on 20 October 2026: the corrective action was not yet in place.

Regulatory significance

From a regulatory pathway perspective, this is a software defect classified at the most serious recall level, and analytical performance was never on the list of issues. The firm did not change reagents or algorithms; it changed a piece of logic that matches barcodes to patients, and the matter was still handled as a recall requiring sites to stop using the device first and then await firmware. For companies making glucose and near-patient testing products, this type of case is harder to address with lessons learned from hardware recalls.

Sources and scope notes

Sources: U.S. Food and Drug Administration, Center for Devices and Radiological Health, Hospital Glucose Meter Removal: Nova Biomedical Removes StatStrip Glucose Hospital Meter Systems, published 20 October 2026, https://www.fda.gov/medical-devices/medical-device-recalls-and-early-alerts/hospital-glucose-meter-removal-nova-biomedical-removes-statstrip-glucose-hospital-meter-systems; U.S. FDA Medical Device Recall Database, event 99546 summary page and record Z-3128-2026, publication date 11 September 2026, https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfRES/res.cfm?start_search=1&event_id=99546; U.S. FDA CDRH New – News and Updates, entry of 20 October 2026, https://www.fda.gov/medical-devices/medical-devices-news-and-events/cdrh-new-news-and-updates.

Verification scope and access date: The pages above were accessed on 23 October 2026 and checked item by item for recall numbers, publication and firm-initiated dates, affected models and software version range, wording of the recall reason, number of units involved, distribution countries and regions, the firm's notification and shipment hold measures, and the removal recommendation and interim measures added by FDA on the 20 October page. The firm's original plan to complete firmware validation in September and the FDA page's statement of phased release from November come respectively from the recall records and the FDA page, and are presented here side by side according to each source.

Scope note: This article is an interpretation of publicly available regulatory information and does not constitute a conclusion or commitment regarding any specific product, company or registration application. The meaning of a Class I recall, the conditions for applying the interim measures and the distribution scope are governed by the official texts. Recall records and page information may change with subsequent official updates, and the latest status in the FDA database should be checked for specific models and software versions.

AIMEILI regulatory interpretation

This case illustrates how a purely software-driven use error can be escalated to the most severe recall class even when measurement performance is unaffected. Under FDA's recall classification framework, Class I applies where there is a reasonable probability of serious adverse health consequences or death; a misattributed glucose value that drives insulin dosing in critically ill or neonatal patients meets that threshold without any change in analytical accuracy.

Three points are worth highlighting for regulatory affairs teams:

• Correction versus removal. FDA distinguishes a correction (repair, modification, relabelling, software update) from a removal (retrieval of a device from its point of use). The 20 October update is effectively a removal instruction issued before the software correction could be deployed, showing that regulators will separate the two and use removal as a risk-control bridge when the corrective action is delayed.
• Human factors and use-error risk management. A residual on-screen barcode combined with an operator confirmation step is a classic use-error scenario addressed by IEC 62366-1. Design controls under 21 CFR 820.30 and ISO 13485, together with software lifecycle controls under IEC 62304, need to demonstrate that race conditions and stale-state displays in the barcode-to-patient matching logic were analysed and mitigated.
• Timeline integrity in communications. The divergence between a firm-stated September validation milestone and FDA's November rollout statement is exactly the type of gap that triggers further regulatory action. Corrective action timelines communicated to regulators and customers should be conservative and tracked against documented verification.

For markets outside the United States, the same event would typically trigger a Field Safety Corrective Action and vigilance reporting under EU MDR Articles 87–88 and the corresponding national frameworks in the UK, Canada, Australia, Brazil and Asian markets. Companies should expect health authorities in the 22 listed countries and regions to request confirmation that the same corrective action and customer notification have been applied locally.

Business impact

• Manufacturers: A firmware-only defect can halt shipments and force field removal. Budget for post-market software change capacity, regression testing covering data-interface states, and a defined risk-based process for deciding when to issue a correction versus a removal.
• Distributors and importers: Confirm that consignee lists for the 22 affected countries and regions are current, that translated customer notifications are distributed, and that acknowledgement records can be produced on request. Distribution records are the first item regulators inspect in a Class I action.
• Hospitals and point-of-care users: Interim measures such as ADT-based patient ID validation, automatic logout after each test and duplicate identity checks add workflow steps that must be reflected in standard operating procedures and staff training until the software update is installed.
• CROs and regulatory teams: For connected IVD and near-patient devices, data integrity between device and LIS/EMR is now a core regulatory surface. Prepare cybersecurity and interoperability documentation, and treat patient-matching logic as a safety-critical function in design history files and risk management files.
• Registration strategy: Expect longer technical review where software performs patient identification, and anticipate questions on use-error validation, software version control and field-update mechanisms across all jurisdictions where the device is registered.