Automated insulin delivery & glucose prediction (closed-loop artificial pancreas)

People with type 1 diabetes must dose insulin around the clock; too much causes dangerous hypoglycaemia, too little causes hyperglycaemia and long-term damage. Automated insulin delivery (AID, "hybrid closed loop") systems connect a CGM to an insulin pump and let a predictive control algorithm adjust insulin every few minutes. The user still announces meals, but the algorithm handles the rest, including overnight. Unlike monitoring products, the software here doses a drug autonomously, so it is regulated as high-risk medical-device software.

Problem & value

• Today: patients decide dozens of dosing questions a day (basal rate, meal bolus, corrections, exercise). Multiple daily injections or open-loop pumps leave many people outside the recommended glucose range, and burden falls on families, school staff and (in pregnancy) very tight targets.
• AI value: the controller predicts glucose 30-120 minutes ahead and suppresses or increases insulin before excursions occur. Randomised trials show higher time-in-range and less hypoglycaemia; in pregnancy the AiDAPT trial reported better overnight and overall time in the pregnancy target range with closed loop (CamAPS FX) than standard care [2].
• Health-system uptake: NICE recommends hybrid closed-loop systems as an option for people with type 1 diabetes meeting defined criteria, including during pregnancy (TA943, Dec 2023) [1]. Reimbursement is a bigger adoption barrier in the EU than technology.

Variants

• Commercial hybrid closed loop (HCL): pump-integrated algorithm with meal announcement.
• Interoperable (iAGC/iCGM/ACE pump) systems: algorithm on a smartphone, free choice of CGM and pump (e.g. CamAPS FX).
• Paediatric and very young children: CamAPS FX is CE-marked from age 1 [3]; parents and school/kindergarten staff use remote follower apps.
• Pregnancy: dedicated lower targets, "boost"/"ease-off" modes; evidence from AiDAPT [2].
• Bolus advisers and meal detection: decision support that proposes carbohydrate-based doses or detects unannounced meals; may exist without full automation (lower risk class, same MDR scope).
• Glucose prediction only: forecast and alert apps without dosing (closer to HLTH-007).
• Type 2 / hospital use: emerging; inpatient closed-loop and type 2 indications are expanding but are not yet routine in the EU.
• Do-it-yourself (DIY) loops: user-assembled open-source systems (Loop, AndroidAPS); not CE-marked and not provided as a service.

How it works

1. CGM (every 1-5 min) ─┐ pump delivery log ───┼
2. state estimation (glucose, insulin-on-board, carbs-on-board) meal / exercise ─────┘
3. glucose prediction (physiological model and/or ML)
4. model predictive control (MPC) or PID-fuzzy controller
5. safety layer (hard limits, max basal/IOB, suspend-on-low)
6. dose command to pump
7. delivery
8. alarms, remote follow, cloud upload
9. clinic review

• Prediction: compartmental insulin/glucose models adapted to the individual; newer systems add learned components (e.g. gradient boosting, LSTM/Transformer forecasters on CGM history).
• Control: MPC dominates (CamAPS FX, Control-IQ); MiniMed 780G uses a PID-with-insulin-feedback design with auto-correction boluses; Omnipod 5 uses SmartAdjust (MPC-style). The algorithm adapts to the user's insulin needs over days.
• Safety layer: deterministic limits and fail-safes independent of any learned component; CGM dropout falls back to preset basal. This layer is the core of the safety case.
• Human-in-the-loop: the user announces meals, confirms alerts and can override/stop; clinicians set initial parameters and review reports (Ambulatory Glucose Profile, time-in-range). Dosing authority always stays within clinician-validated limits.

Data preparation

The data are CGM readings, pump delivery history, meal and exercise entries and personal settings. They live in the device cloud portals of CGM and pump makers (e.g. Dexcom, Abbott, Medtronic, Tandem platforms), in clinic reporting software, and partly in the patient's phone app. For a clinic the work is mostly integration, not training: typical gaps are patients on different vendor portals, missing or unreliable carbohydrate entries, sensor dropouts, data-sharing consent not yet given, and inconsistent clinic accounts.

Preparation steps: set up clinic accounts and patient data-sharing consent per vendor portal, export reports in a uniform format (PREP-005), clean sensor gaps and time zones with simple scripts (PREP-011), and pseudonymise before any research or AI reuse (PREP-022); check purposes and legal basis (PREP-025). Developers building controllers need curated and simulated datasets (e.g. UVA/Padova style simulators, open datasets such as OhioT1DM under licence) and a held-out test set (PREP-018). Effort share for a clinic is low to medium (about 20 to 30 percent); for manufacturers and developers data work is a large part. See GUIDE-003.

Implementation paths

Which path for whom

• Enterprise (clinics, diabetes centres): Path A, because CE-marked AID systems exist and a clinic cannot lawfully run self-built dosing software on patients.
• Developer: Path C, because open-source loop algorithms and simulators allow research and prototyping, though not clinical use as a product without MDR conformity.
• Private: Path A, because certified AID systems prescribed by the care team are the safe route; DIY open-source loops are used at the user's own responsibility and are not a recommendation.

Path A - Buy (recommended)

• Certified AID systems (CE-marked): CamAPS FX (CamDiab, UK; interoperable, runs on Android, pairs with Dexcom/Libre CGM and Ypsomed/Dana pumps), Medtronic MiniMed 780G (Guardian 4 / Simplera sensors), Tandem t:slim X2 with Control-IQ (Dexcom), Insulet Omnipod 5, Ypsomed with CamAPS FX ("mylife Loop", Ypsomed/CamDiab; EU), Diabeloop DBLG1 (France, EU), Sequel twiist (US-led interoperable).
• CGM vendors: Dexcom (G7), Abbott (FreeStyle Libre 3), Medtronic (Simplera).
• Choose A: always, for patient care. Clinics select a system by patient age, pregnancy, device preference and reimbursement; the patient is the buyer/user, the clinic the prescriber.

Path B - Build on cloud APIs

Not applicable to the dosing loop: closed-loop control must run on-device with deterministic latency and cannot depend on a cloud call. Cloud APIs are appropriate for the surrounding layer: data platforms (Glooko, Tidepool, Dexcom Clarity, LibreView, CareLink APIs where available), population dashboards and LLM-generated clinic summaries of AGP reports (see HLTH-018), always with human review. An EU-region data-integration layer using FHIR (HL7) is typical.

Path C - Self-host (open source)

• Open-source loops: Loop / Trio / iAPS (iOS), AndroidAPS and OpenAPS (Android/Linux). They are community projects, not CE-marked; using them is the user's own responsibility, and organisations must not place them on the market as a product or recommend them clinically as a service.
• Research stack: open simulators (UVA/Padova-type in silico testing, open datasets such as OhioT1DM, T1DEXI) and Tidepool's open-source data tools for analysis.
• Hardware: HW1 (phone-class edge; forecasting models are tiny).

Path D - Custom training

Needed by manufacturers and academic groups: training and validating glucose predictors on large CGM datasets, personalised controllers (reinforcement learning, digital twins), and in-silico validation on virtual patient cohorts before clinical trials. Requires long, diverse CGM/pump histories (children, pregnancy, exercise, illness), an FDA-accepted-style simulator and a clinical investigation under MDR (ISO 14155).

State of the art (2026)

• Algorithms: MPC and PID-based hybrid closed loops are mature, with randomised and real-world evidence in adults, children and pregnancy. Fully closed loop (no meal announcement) and faster-acting insulins are the active research front.
• Predictors: deep-learning forecasters (LSTM, Transformer, and time-series foundation models) improve short-horizon glucose prediction, but error grows quickly beyond 60 minutes and after meals or exercise; they supplement rather than replace the safety layer.
• Ecosystem: interoperable controllers decouple algorithm from pump and CGM; more than one AID is now recognised for pregnancy. The CamAPS FX controller also holds FDA authorisation as an interoperable automated glycemic controller (type 1, age 2+) [3].
• Limits and failure modes: CGM sensor errors and compression lows, infusion-set failure, missed or inaccurate meal announcements, exercise and illness, cyber-security (Bluetooth pairing, remote follow apps) and alert fatigue. Users must still know manual dosing and carry backup insulin.

Shared resources & combinations

• time-series + streaming + edge-runtime: shared with HLTH-007 (remote patient monitoring) and HLTH-012 (deterioration early warning); different because AID acts, they alert.
• Downstream: HLTH-020 (population risk stratification from CGM and pump data), PERS-002 (consumer coaching, non-dosing), HLTH-018/HLTH-030 (LLM summaries and patient messages for diabetes teams).
• Data pipelines: CGM/pump data platforms feed diabetes clinics and registries (FHIR/OMOP via HLTH-028).

Effort, cost & KPIs

• Path A (clinic): weeks to onboard patients; costs are devices and sensors, training time of diabetes educators and reimbursement paperwork. Per-patient running costs are dominated by sensors and pump consumables.
• Path D (manufacturer): multi-year; clinical investigation, ISO 13485 QMS, IEC 62304 software life cycle, cybersecurity file, notified body audit.
• KPIs: time in range (70-180 mg/dL, 3.9-10 mmol/L), time below range, time above range, glucose management indicator (GMI), HbA1c, severe hypoglycaemia events, closed-loop usage (% time in auto mode), sensor wear, patient-reported distress.

People & change

Involve the clinic management and the head of the diabetes unit first, then diabetes educators and nurses as daily users, IT security for device and portal access, and the DPO. Patients and caregivers (including parents of children) are key stakeholders from the start: they carry the daily use and must understand the alarms and the manual fallback.

Works council: usually no co-determination, because the systems monitor patients, not employees. Check anyway if clinic staff activity in reporting portals is logged in a way suited to monitor staff (§87(1) no. 6 BetrVG), and inform the works council or Personalrat under §90(1) no. 3 if care processes change materially.

Data protection: health data, so a DPIA is likely (Art. 35 GDPR) and AVV with portal vendors is required (Art. 28 GDPR). AI literacy: support staff with structured training on algorithm limits, hypoglycaemia handling and what to do when the system fails (Art. 4 AI Act; GUIDE-006). Start with a small pilot group of motivated patients, communicate transparently about what the algorithm decides, and keep humans in control: patients can override at any time and the care team reviews time-in-range reports. Typical concerns are trust in automatic dosing and data sharing; address them with training and clear fallback rules. See GUIDE-008, GUIDE-005, GUIDE-009.

Risks, regulation & compliance

• EU MDR (2017/745): software that drives insulin dosing is Class IIb or higher (Rule 11, and active devices administering medicinal products, Rule 12) [4]; needs a notified body, clinical evaluation, post-market surveillance and vigilance reporting.
• EU AI Act: AI components in a device that requires third-party conformity assessment under MDR are high-risk (Art. 6(1), Annex I); high-risk obligations apply from the Act's phased dates for Annex I products (see Digital Omnibus changes) [5]. Controllers without machine learning may fall outside AI Act scope but remain fully under MDR. No Art. 5 prohibited practice is involved.
• GDPR: CGM and insulin data are special-category health data (Art. 9); lawful basis typically explicit consent or healthcare provision, DPA with cloud providers, EU hosting, child consent rules, EHDS for secondary use. DIY remote-follow by parents requires care with third-party access.
• Cybersecurity: MDCG 2019-16 guidance and the Cyber Resilience Act context; secure pairing and signed updates.
• Clinical risks: hypoglycaemia from overdelivery, ketoacidosis from pump failure; mitigated by hard dose limits, suspend-on-low, alarms and structured patient training.

Getting started

1. For clinics: define eligibility criteria with local reimbursement and follow NICE-style criteria as a reference [1].
2. Choose 1-2 CE-marked systems covering your populations (children, pregnancy, adults) and train an educator team.
3. Set up a data platform (Glooko, Tidepool, vendor portals) and standard AGP review visits.
4. Track time-in-range, hypoglycaemia and closed-loop uptake per patient cohort.
5. For developers: study MDR classification, IEC 62304 and in-silico validation before writing code; prototype only on simulators and open datasets.

Sources

1. NICE - Hybrid closed loop systems for managing blood glucose levels in type 1 diabetes (TA943) - https://www.nice.org.uk/guidance/ta943
2. Lee TTM et al., Automated Insulin Delivery in Women with Pregnancy Complicated by Type 1 Diabetes (AiDAPT), NEJM 2023 - https://www.nejm.org/doi/full/10.1056/NEJMoa2303911
3. Drug Delivery Business - FDA approves CamDiab hybrid closed-loop insulin delivery app - https://www.drugdeliverybusiness.com/fda-approves-insulin-delivery-app-camdiab/
4. Regulation (EU) 2017/745 (MDR) - https://eur-lex.europa.eu/eli/reg/2017/745/oj
5. Regulation (EU) 2024/1689 (AI Act) - https://eur-lex.europa.eu/eli/reg/2024/1689/oj
6. DiabetesontheNet - Hybrid closed-loop therapy factsheet - https://diabetesonthenet.com/diabetes-primary-care/factsheet-hybrid-closed-loop-therapy/
7. NHS Hereford & Worcester - CamAPS FX in pregnancy and very young children - https://www.hweclinicalguidance.nhs.uk/clinical-policies/camaps-fx-in-pregnancy-and-very-young-children/
8. OpenAPS / AndroidAPS / Loop open-source projects - https://openaps.org