Bolus Calculator Software: FDA Classification, Predicates and Design Requirements

A bolus calculator is software that recommends an insulin dose for a meal or a high glucose reading, using inputs such as carbohydrate intake, current glucose level, insulin on board, and the user’s insulin settings. In the US, the FDA regulates bolus calculators as medical devices, typically Class II devices requiring a 510(k). Which classification applies depends on the inputs and the user: most dose calculators fall under product code NDC (21 CFR 868.1890), calculators that use CGM data fall under QRX (21 CFR 862.1358), and clinician tools that adjust insulin pump settings fall under QCC (also 21 CFR 862.1358).

This guide is for companies building bolus calculator software. It covers how the calculation works, which FDA classification fits your product, which devices have been cleared, why a bolus calculator is not non-device clinical decision support, and what the design has to get right.

How a bolus calculator works

A bolus calculator combines two doses: insulin to cover the carbohydrates in a meal, and insulin to correct glucose that is above target. It then subtracts insulin that is still active from earlier doses. Published guidance on bolus calculator settings, such as Walsh and colleagues in the Journal of Diabetes Science and Technology, describes the settings a calculator needs:

The arithmetic is simple. The risk is in everything around it: a wrong setting, a mistyped value, a missing input, or a dose that ignores insulin already given can all lead to a dangerous recommendation.

How FDA classifies bolus calculators

Two details trip up first-time readers.

• The title of the NDC regulation does not mention insulin. 21 CFR 868.1890 is titled “predictive pulmonary-function value calculator,” yet FDA files product code NDC (“calculator, drug dose”) under it, and most cleared insulin dose calculators use NDC. Search FDA’s product classification database by product code, not by regulation title, when looking for predicates.
• QRX and QCC share one regulation. FDA created 21 CFR 862.1358, the “insulin therapy adjustment device” regulation, when it granted DreaMed’s Advisor Pro De Novo request (DEN170043) on June 12, 2018. QRX was added later under the same regulation. The first QRX clearance was Insulet’s Omnipod 5 SmartBolus Calculator (K203772), decided January 27, 2022.

Calculators built into an insulin pump’s own controller are usually reviewed with the pump. The Omnipod DASH system (K180045, June 1, 2018), for example, was cleared as an insulin pump with a suggested bolus calculator, with NDC listed as a secondary product code. In newer interoperable systems, the calculator can be cleared automatically, as Insulet’s SmartBolus Calculator was.

What 21 CFR 862.1358 requires

For QRX and QCC devices, the regulation sets special controls. Design verification and validation must cover:

• Inputs: all required inputs, including the collection timeframe and number of data points
• Outputs: the recommendations and how the device generates them
• Clinical validity: substantial data showing the recommendations are clinically valid
• Input device requirements: specifications for the glucose monitors and other inputs, including accuracy requirements, with a clinical justification
• Data transmission: secure, reliable transmission with checks for data integrity, accuracy, and reliability
• Understanding: data showing that users understand and correctly interpret the recommendations
• Dosing error risk: a strategy that keeps the residual risk of dosing errors at a “clinically acceptable level”

The regulation also says these devices must not be intended for automated insulin dosing. Software that automatically controls a pump is an interoperable automated glycemic controller, a separate classification covered in our guide to iCGM, ACE pump, and iAGC classifications.

Labeling must list compatible insulin formulations; specifications for compatible glucose monitors and pumps; all required inputs and dosing outputs; and the device’s limitations, including how to prevent disruptions, such as time zone changes during travel.

NDC devices do not have special controls of this kind. 21 CFR 868.1890 is a Class II device type with a 510(k) requirement, so FDA’s expectations are reflected in the 510(k) review, the predicate comparison, and its software and cybersecurity guidance.

Cleared bolus and insulin dose calculators

FDA has cleared dozens of insulin dose calculators. These examples show the range, with decision dates from FDA’s 510(k) records:

The list shows how wide the NDC category is. It covers patient apps for multiple daily injections, connected insulin pens, basal titration tools, and hospital software that recommends intravenous insulin doses. The predicate you choose should match your intended user, inputs, and setting as closely as possible.

Why a bolus calculator is not non-device CDS

Some teams hope a bolus calculator can qualify as non-device clinical decision support (CDS) and skip FDA review. For a patient-facing calculator, FDA’s guidance says no.

FDA’s Clinical Decision Support Software guidance (January 2026) includes this as Device Example 28: software that helps a patient with diabetes “manage their blood sugars by calculating bolus insulin dose” from carbohydrate intake, pre-meal glucose, and planned activity. It fails two of the four non-device criteria:

• Criterion 3: it is intended for the patient, not a healthcare professional.
• Criterion 4: it supports a time-critical decision, which leaves no room for independent review of the recommendation.

A calculator that uses CGM data also fails Criterion 1, because FDA treats continuous glucose readings as a pattern or signal. See our guide to clinical decision support software for how the four criteria work.

The safety case: why FDA regulates these apps

Bolus calculator apps have a documented record of errors. A 2015 systematic assessment in BMC Medicine by Huckvale and colleagues tested 46 insulin dose calculator apps:

• 91% lacked numeric input validation
• 59% allowed a calculation with missing values
• 67% carried a risk of recommending an inappropriate dose
• Only 1 app had no issues

Cleared calculators have had problems too, often in the details of data entry. FDA’s recall database includes:

• Omnipod 5 iOS app (initiated May 2025, Class II). The app did not accept a comma as a decimal separator, which could cause 0.1 unit to be interpreted as 1 unit.
• Omnipod 5 iOS app (initiated September 2025, Class II). Using the iPhone magnifier could duplicate a typed digit in a bolus or carbohydrate ratio entry.
• Accu-Chek Connect app (initiated September 2016, Class II). A Bolus Advisor bug could produce an incorrect bolus recommendation.

Each of these is a software requirement that was missed: locale handling, accessibility features, and calculation logic. They are the kind of failures a design process has to catch before release.

Design requirements for bolus calculator software

Build these into requirements from the start, and trace each one to a test.

1. Validate every input. Enforce numeric ranges, units, and formats, including decimal separators in every supported locale. Block a calculation when a required value is missing or out of date.
2. Account for insulin on board. Track every dose the app knows about, including doses from connected pens or pumps, and show how active insulin changed the recommendation.
3. Protect the settings. Carbohydrate ratios, correction factors, targets, and insulin duration should be set or confirmed with the care team, time-stamped, and difficult to change accidentally.
4. Set limits. Apply maximum dose limits and flag recommendations that are unusual for the user.
5. Show the math. Display the meal dose, correction dose, and insulin-on-board adjustment separately, so the user can see why the dose is what it is.
6. Test platform features. Test accessibility tools, magnification, text size, time zones, and daylight saving changes. Two of the recalls above came from these features, not from the formula.
7. Plan for CGM data quality. If the calculator uses CGM data, define how it handles data gaps, stale readings, and sensor warm-up, and align your input specifications with the accuracy of compatible sensors.
8. Run human factors testing. Test with real users entering real meals under realistic time pressure, in accordance with IEC 62366-1.

Run the software through an IEC 62304 lifecycle with ISO 14971 risk management, and plan cybersecurity for any connected calculator. For the bigger picture of how FDA regulates dosing software, glucose prediction, and AID algorithms, see our guide to AI in diabetes devices. For app development more broadly, see our guide to diabetes management app development.

Frequently asked questions

Is a bolus calculator app regulated by the FDA?

Yes. FDA regulates insulin bolus calculators as medical devices. Most are Class II devices cleared through a 510(k), under product code NDC for drug dose calculators or QRX for calculators that use CGM data. FDA’s clinical decision support guidance gives a patient-facing bolus calculator as an example of a device.

What FDA product code is used for insulin dose calculators?

Most insulin dose calculators are cleared under product code NDC (“calculator, drug dose”), regulation 21 CFR 868.1890. Calculators that use CGM data are cleared under QRX, and clinician software that adjusts insulin pump settings under QCC, both under 21 CFR 862.1358.

What is the difference between QRX and NDC?

QRX covers insulin dose calculators that use continuous glucose monitor data and falls under 21 CFR 862.1358, which has special controls for inputs, clinical validity, data transmission, and dosing error risk. NDC covers drug dose calculators more broadly under 21 CFR 868.1890, and many bolus calculators that use fingerstick or entered values are cleared under it.

How does a bolus calculator calculate a dose?

It adds a meal dose, based on carbohydrates and the insulin-to-carbohydrate ratio, to a correction dose, based on how far glucose is above target and the correction factor. It then subtracts insulin on board, the insulin from earlier doses that is still active.

Can a bolus calculator be non-device clinical decision support?

Not if it is for patients. FDA’s 2026 clinical decision support guidance treats a patient-facing bolus calculator as a device because it is not intended for healthcare professionals and supports time-critical decisions. A calculator that uses CGM data is also a device because it analyzes patterns in sensor readings.

Build bolus calculator software with Sequenex

A bolus calculator is a small piece of software with a large consequence: every recommendation is an insulin dose. Getting it right takes input validation, clear math, platform testing, and design records that show FDA how each risk is controlled.

Sequenex builds diabetes software for device companies, from dose calculators and connected pen apps to CGM-integrated platforms, under a design-first, IEC 62304 process. See our biosensor and CGM software development services, or contact us to talk through your project.