TECHNOLOGY EXPLAINER
Smartphone Connectivity and Digital Twins
— the paths that carry the signal, the regulatory standing of apps, and where "twins" really stand
Between a biosensor and a smartphone there is a fork: a sensor with its own battery and radio (Bluetooth) or a battery-free sensor using near-field communication (NFC). An app is not outside regulation simply because it runs on a smartphone; it is judged by what it does. And "digital twin" is a phrase that mixes parts used in regulatory settings with parts that are still research.
- What smartphone connectivity and digital twins are (the short version)
- The paths that carry the signal — Bluetooth and NFC
- A materials engineer's view (1): what becomes the materials job when you drop the battery
- Data formats and interoperability — units, time, records
- The regulatory standing of apps — Japan, the US and Europe
- A materials engineer's view (2): when the smartphone becomes "instrument variation"
- Cybersecurity
- Digital twins — research or practice?
- Cautions about overstated claims
- What is still open, and what we could not confirm
- Glossary / References / Claim-to-source audit
This article explains communication, data formats, software regulation, security and modelling concepts. It does not evaluate or recommend any product or company, and it is not medical advice on how to read a measured value or on diagnosis, treatment or medication. Some of the numbers in the figures are our own calculations to illustrate a mechanism and are not the performance of any real product. Please consult a health professional about decisions concerning your health or your readings.
Sourced = stated in published material (link given)
Our calculation = a figure this article derived from stated assumptions
Not yet confirmed = a plan or draft that is not final
Our arrangement of the material and our readings of the materials side are marked separately as Commentary. Regulatory categories are given as the regulators' own documents state them; note that a clearance or authorization concerns a specific intended use and does not mean "safe and accurate however it is used".
1. What smartphone connectivity and digital twins are (the short version)
- The path: there are three broad ways to carry sensor data to a smartphone: a sensor with its own battery and radio (Bluetooth LE), a battery-free sensor powered by the smartphone's field (NFC), and a disposable sensor coupled to a reusable transmitter (our summary). The choice changes the sensor's weight, encapsulation, lifetime and contact design.
- The standing of the app: the FDA looks at an app not by the fact that it runs on a phone but by its function and risk. Software that only transfers, stores or displays glucose-meter data is not a device, but software that analyzes glucose readings and issues alerts is subject to device oversightSourced.
- Digital twins: a committee of the US National Academies defines a digital twin as a virtual construct that is dynamically updated with data from its physical twin, has predictive capability, and informs decisions, with bidirectional interaction at its centreSourced. A 2026 scoping review in diabetes reports that validation was mostly retrospective or simulation-based, with few clinical trialsSourced.
"Connected", "measuring" and "how it is regulated" are three different questions. A Bluetooth connection does not guarantee sensor accuracy. Whether an app is a medical device is decided not by how its screen looks but by its intended use and function. And a product labelled "digital twin" has to be checked, source by source, for which parts are in practice and which are research.
2. The paths that carry the signal — Bluetooth and NFC
For a continuous glucose monitor (CGM), Facchinetti (2016) lists three parts: a needle-type sensor, a transmitter that sends the signal, and a portable device that displays the value, and says calibration can take place either in the transmitter or in the receiverSourced. Here we sort the "paths" from sensor to smartphone by the schemes that appear in published material.
(1) Bluetooth Low Energy: a battery and a radio on board
The Bluetooth SIG's Continuous Glucose Monitoring Profile (CGMP) and Service (CGMS) are both v1.0.2 (18 January 2022, prepared by the Medical Devices Working Group). The CGMP defines two roles, the CGM Sensor (the measuring side) and the Collector (the receiving side), and the Collector acts as a GATT client. The specifications state the followingSourced.
- One to one: a CGM Sensor is to be connected to only one Collector at a given time ("shall be connected to only one Collector").
- Mandatory characteristics: the CGMS has seven mandatory characteristics: measurement, feature, status, session start time, session run time, record access control point and a specific-ops control point.
- Units: glucose concentrations of measurements and calibration values are sent in mg/dL only, as a 16-bit SFLOAT.
- Calibration: support for calibration is optional; when supported, the sensor keeps calibration records (glucose concentration, time, status).
- Authentication: reading and writing the characteristics and descriptors "requires authentication".
- Error detection: a device that supports E2E-CRC must protect the measurement with a CRC.
ISO/IEEE 11073-10425:2024 (third edition, September 2024) is an international standard that defines communication between CGM devices (agents) and managers such as mobile phones and personal computers so that they achieve plug-and-play interoperability. It describes CGM as measurement "on a regular (typically 5 minute) basis"Sourced. The Bluetooth profile says characteristics of the Device Information Service may be transcoded by the Collector for use in an ISO/IEEE 11073 ecosystemSourced.
(2) NFC: no battery, powered by the smartphone
One family of proximity communication standards is ISO/IEC 15693. Part 2 (ISO/IEC 15693-2:2019) is titled "Cards and security devices for personal identification — Contactless vicinity objects — Part 2: Air interface and initialization" and specifies the characteristics of the fields for power and bidirectional communication between vicinity coupling devices and vicinity cardsSourced. As a research example, Bandodkar et al. (2019) report a battery-free wireless skin-interfaced sensor, using a chip with an ISO 15693-compatible radio front endSourced. The main points, with conditions:
- Construction: two parts: a disposable soft microfluidic network (the sweat channels) and a reusable thin NFC electronic module. The module's NFC interface (about 0.1 g) handles both wireless power and data transmission, to any NFC-enabled device such as a smartphone, tablet or watch.
- Weight and size: the whole platform is about 1 g and is estimated to be nearly 20 times lighter and 4 times smaller in lateral dimension than approaches that rely on battery-powered Bluetooth radios (the paper's estimate).
- Reading distance: in a bench test with a constant reference signal (equivalent to 100 mV from a constant-current source), the reader recorded stable signals out to about 38 mm. For orientation, at about 1 cm it recorded uninterrupted signals up to 70°, with a voltage error of 2 mV. This is a test of the reading characteristics of the device, not a result on a body.
- Human testing: in two-day human trials comparing glucose and lactate in sweat and blood, the paper says the results suggest "a potential basis for noninvasive, semi-quantitative tracking" of physiological status. It is a research-stage demonstration and not a product or a clinical performance claim.
| Scheme | Power | When data move | Materials and implementation concerns (commentary) |
|---|---|---|---|
| A Bluetooth LE (on-board) | Battery in the sensor | At each measurement, or in a batch when connected | A battery and radio add volume, mass, encapsulation and disposal burdens. One-to-one connection (specification) |
| B NFC (battery-free) | From the smartphone's field | When the smartphone is brought close | No battery and light (about 20 times by estimate). A circuit that works as coupling strength varies, and a stable antenna, are the key points |
| C Separate transmitter | Battery in the transmitter | From the transmitter, as in A | The contact between the disposable and reusable parts is a reliability hot spot |
Power and operation follow Bluetooth SIG [Refs. 10, 11], Bandodkar et al. (2019) [Ref. 14] and Facchinetti (2016) [Ref. 17]. The right-hand column is our commentary.
3. A materials engineer's view (1): what becomes the materials job when you drop the battery
The platform of Bandodkar et al. (2019) describes its materials in detail, which makes it a good teaching caseSourced.
- Substrates: the electronic module is a two-layer flexible circuit board of copper on polyimide (18 mm in diameter, about 0.5 mm thick). The disposable microfluidic part is a silicone elastomer with a low modulus of about 1 MPa, attached with a layer of skin-compatible adhesive.
- Connection: the module and the disposable part are joined, repeatedly detachable, by small neodymium magnets (1 mm in diameter, 0.5 mm high) and conductive adhesive. The holding force is about 1.5 N, which the paper describes as sufficient for low to medium intensity physical activity. It also measured current-voltage behaviour over repeated attachment and detachment, and the impedance of the contacts when bent.
- Circuit design: so that it keeps working when NFC coupling is weak, the signal conditioning is made independent of fluctuations in supply voltage. The antenna characteristics are shown to remain stable under bending.
What we read from this (commentary): dropping the battery removes the problems of battery encapsulation, safety and disposal, but three other things become the work of materials and implementation.
- A circuit and substrate that absorb variation in coupling: power and communication both rely on electromagnetic coupling, so distance, angle and bending of the board change it. The circuit has to tolerate supply fluctuations.
- The contact joining the disposable and reusable parts: resistance must not change with repeated attachment, because it bears directly on signal stability. The paper tests repeated attachment for this reason.
- The material that touches the skin: softness (low modulus) has to be combined with adhesion, which affects comfort and detachment. See our explainer on patch-type sensors and skin adhesion.
Limits: concentrations in sweat are not the same as concentrations in blood; the paper shows a correlation with blood only as a "potential basis". Numbers such as the 38 mm reading distance are values under bench-test conditions.
4. Data formats and interoperability — units, time, records
A number from a sensor becomes a "record" only once the smartphone gives it a unit, a time and a way of handling gaps. Agreements that align this meaning exist, layer by layer.
- Bluetooth (CGMS): glucose concentration is sent in mg/dL only. There is a field that expresses time as elapsed minutes (a 16-bit unsigned integer) from the session start timeSourced.
- ISO/IEEE 11073-10425:2024: defines a common core of CGM communication, specifying term codes, formats and behaviours and restricting optionality in favour of interoperabilitySourced.
- HL7 FHIR R5 Observation: a resource for measurements and simple assertions about a patient, device or other subject, whose scope includes vital signs, laboratory data (for example blood glucose) and device measurements. Values can be of types such as Quantity, with a reference to the device that made the measurementSourced.
- How to summarize: the ATTD (Advanced Technologies & Treatments for Diabetes) published an international consensus in 2019 on using and reporting CGM data (Battelino et al., Diabetes Care)Sourced. It is an effort to align the definitions of the metrics; this article does not discuss target values.
- Unit conversion: the molar mass of glucose (C6H12O6) is 180.16 g/mol, so 1 mmol/L = 180.16 mg/L = about 18.02 mg/dL. 5.0 mmol/L is 90.1 mg/dL, 7.0 mmol/L is 126.1 mg/dL and 10.0 mmol/L is 180.2 mg/dL (rounded to one decimal)Our calculation. Because the specification sends only mg/dL, in countries that use mmol/L the app does the conversion. If the conversion factor or rounding differs, the displayed value differs slightly between device and app.
- The limit of the time offset: the largest value a 16-bit unsigned integer can hold is 65,535 minutes, which is about 45.5 days (65,535 / 1,440)Our calculation. How longer sessions are handled depends on other mechanisms in the specification (we did not check them).
- Number of points: measuring every 5 minutes without gaps for 14 days gives 288 per day x 14 days = 4,032 pointsOur calculation.
Premises and limits: the conversion is simple arithmetic with a chemical constant. We did not check where real products round or which conversion factor they use.
The point for a materials engineer is that the meaning of a measured value is decided outside the sensor's materials and structure. However long one spends polishing sensitivity, if the handling of units, time and gaps is not aligned, another app will not read it as the same value. For continuous monitoring there is one more point: because the specification says "a sensor is connected to only one Collector at a time", reading the same sensor in several apps at once is not the standard form in the specification (commentary).
5. The regulatory standing of apps — Japan, the US and Europe
(1) United States: judged by function
The FDA's "Policy for Device Software Functions and Mobile Medical Applications" (version of 28 September 2022; first issued 2013) defines a mobile medical app as an app that meets the device definition and is intended to be used as an accessory to a regulated medical device or to transform a mobile platform into a regulated medical deviceSourced. The software functions the FDA oversees include the followingSourced.
- Functions that connect to a device in order to control it or analyze its data. The connection may be wired or wireless; an example is an app that sends control signals to an insulin pump.
- Functions that turn a smartphone into a medical device using attachments or sensors. An example is an app that attaches a blood glucose strip reader to the phone so that it works as a glucose meter; NBW (21 CFR 862.1345) is given as an example product code.
- A software function that analyzes readings from a blood glucose monitor and alerts the user when they are outside a predetermined range is also listed as an example of regulated software.
On the other hand, Appendix A of the policy gives, as an example of what is not a device, software intended solely to transfer, store, convert formats of and display medical device data without controlling or altering the functions or parameters of any connected device (Non-Device MDDS). It does not include functions that generate alarms or alerts, because these involve analysis or interpretation and are device software functionsSourced.
(2) United States: clinical decision support software (January 2026)
The current version of the FDA's "Clinical Decision Support Software" guidance is dated 29 January 2026 (superseding the version of 6 January 2026). It explains the conditions (four criteria) under which the 21st Century Cures Act excludes certain clinical decision support software from the device definitionSourced. The first criterion is that the software is not intended to acquire, process or analyze a medical image, a signal from an in vitro diagnostic device, or a pattern or signal from a signal acquisition system. The guidance says that, for a CGM, a photometric or electrochemical signal generated by an assay and instrument is processed to generate repeated glucose measurements over time, which is considered a pattern, and it distinguishes a single, discrete test result (medical information) from continuous sampling such as CGM readings (a pattern or signal)Sourced. Software that analyzes CGM readings therefore fails this criterion and remains a device. The guidance also says the FDA's existing digital health policies continue to apply to software functions intended for patients or caregiversSourced.
(3) United States: examples of how diabetes-related software is classified
Diabetes-related software is classified by function under separate regulations. The further a function moves from "showing data" to "deciding a dose", the heavier the regulatory treatmentSourced (the arrangement based on the CFR text is ours).
| 21 CFR | Name (as in the regulation) | Main content of the regulation |
|---|---|---|
| 862.2120 | Continuous glucose monitor data management system (Class I) | An electronic device that acquires, processes and correlates retrospective data from a CGM; used by patients or healthcare providers when determining therapeutic strategies. It is not a drug dose calculator and does not provide treatment recommendations. Exempt from 510(k) notification (with limitations) |
| 862.1350 | Continuous glucose monitor secondary alarm system (Class II) | A secondary alarm for a CGM. Special controls: measures to protect against unauthorized access to and modification of data, a warning that dosing decisions should not be made based on the device, and a statement that it does not replace self-monitoring |
| 862.1358 | Insulin therapy adjustment device (Class II) | A device that uses CGM data and other inputs to recommend insulin therapy adjustments. Special controls: a full description of required inputs, an assessment of the accuracy requirements of the devices providing the inputs, a strategy for secure and reliable data transmission, and mitigation of dosing recommendation errors. Not intended for automated insulin dosing |
| 862.1356 | Interoperable automated glycemic controller (Class II) | A device that automatically calculates drug doses from inputs such as glucose and commands a connected infusion pump to deliver them. Special controls: clinical performance data, a human factors study, a data transmission strategy, specifications for connected devices, and verification of design measures that keep therapy safe when communication is interrupted |
All Sourced (eCFR, text as of 1 September 2026 checked) [Refs. 3 to 6]. The right-hand column is a summary of the regulations, not their full text.
21 CFR 880.6310, the "medical device data system (MDDS)", is now defined as a hardware device and is Class I. It transfers, stores, converts the format of or displays medical device data without controlling or altering the functions of connected devices, and excludes devices used for active patient monitoringSourced [Ref. 8]. The software counterpart was removed from the device definition under the 21st Century Cures Act (Appendix A of the FDA policy).
(4) Japan: judged by intended use and risk
The Ministry of Health, Labour and Welfare's "Guideline on whether a program is a medical device" (31 March 2021, partly revised 31 March 2023; in Japanese) says a program is judged on its intended use, as shown in labelling, explanatory material and advertising, and on the degree of riskSourced. The main points are these.
- Programs with the same function can be judged differently if their intended use differs.
- For a program with several functions, if at least one function meets the definition of a medical device program, the whole is subject to the distribution rules for medical devices.
- A program that works as a medical device in combination with general-purpose sensors such as a computer's web camera is judged as an integrated product including the sensor.
- A typical example of what is not a medical device is a program that lets users view their own medical or health information, for instance recording data obtained from medical devices (blood glucose, blood pressure, heart rate, weight) and sharing or registering it with medical staff or family (including showing it over time or as statistically processed numbers).
(5) Europe: MDCG 2019-11 Rev.1 (June 2025)
The Medical Device Coordination Group (MDCG) "Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR" was first issued in October 2019 and has revision 1 of June 2025Sourced. It says the criteria for medical device software (MDSW) apply to "apps" as well, wherever they run (mobile phone, cloud and so on). Software that does no more than storage, archival, communication or simple search is not MDSW, and wellness and fitness apps do not qualifySourced. Rule 11 of the MDR (Regulation (EU) 2017/745) classifies software that provides information used for diagnostic or therapeutic decisions as Class IIa in principle; Class III if such decisions could cause death or irreversible deterioration, and Class IIb if they could cause serious deterioration or a surgical intervention. Software that monitors physiological processes is Class IIa, or Class IIb if it monitors vital parameters whose variations could result in immediate dangerSourced. The overall EU categories are covered in our explainer on medical device approval categories and home use.
6. A materials engineer's view (2): when the smartphone becomes "instrument variation"
The FDA decision summary for 510(k) K222921 (judged substantially equivalent on 8 September 2023) concerns a home-use urine analysis system made up of a smartphone application, a dedicated colour board and an ACR (albumin-creatinine ratio) reagent stripSourced. The intended use is the semi-quantitative measurement of albumin and creatinine in urine and the presentation of their ratio; it is an in vitro diagnostic system for prescription use only (Rx). The principle is reflectance photometry, and the measuring range is stated as 10 to 150 mg/L albumin and 10 to 300 mg/dL creatinine.
Three points matter from the materials and measurement-system side (as stated in the decision summary).
- Camera settings were what changed: this submission modified an existing device by increasing control over two camera features, exposure and white balance. What was reviewed was not only the strip chemistry but the imaging conditions.
- Evaluation by phone model: testing used 3 lots of the device with 8 representative smartphones (iOS and Android, several manufacturers), on samples near the cut-offs. So lot-to-lot differences (the point of Section 3) and phone-to-phone differences were both treated as variation in the measurement system. Phones and operating system versions that are not compatible are blocked from downloading the app.
- The role of the colour reference: calibration is stated as not needed ("calibration is not needed"). It can be read as the colour board compensating for differences in lighting and cameras (commentary; the decision summary does not explain the role).
Commentary: when a smartphone is used as the detector, the camera sensor, the image processing, operating system updates and the lighting all become part of the measurement system. On the materials side, reproducible colour development of the strip and the printing and fading of the colour reference cannot be separated from the optical variation. Whether a re-evaluation is needed when the operating system or camera software is updated is a decision for each product (we did not check how this is handled).
7. Cybersecurity
The current version of the FDA's cybersecurity guidance ("Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions") is dated 3 February 2026 and supersedes the version of 27 June 2025Sourced. Its introduction says that the increasing integration of wireless, Internet- and network-connected capabilities has made cybersecurity a matter of safety and effectiveness.
(1) What a cyber device is: section 524B
The Food and Drug Omnibus Reform Act of 2022 (FDORA), enacted on 29 December 2022, added section 524B to the FD&C Act. For premarket submissions from 29 March 2023, the sponsor of a cyber device (a device that includes software, has the ability to connect to the internet and has technological characteristics that could be vulnerable to cybersecurity threats) must submit information showing that it meets the cybersecurity requirementsSourced. The submission includes a plan and procedures to monitor, identify and address postmarket vulnerabilities (524B(b)(1)), reasonable assurance that the device and related systems are cybersecure ((b)(2)) and a software bill of materials (SBOM) ((b)(3)). Section 524B(b)(2)(B) requires that for critical vulnerabilities, updates and patches be made available as soon as possible, outside the regular update cycleSourced.
(2) Development frameworks: the SPDF and standards
The guidance recommends a Secure Product Development Framework (SPDF) as one way to satisfy the Quality Management System Regulation (QMSR). An SPDF is a set of processes that reduce the number and severity of vulnerabilities in products. A related standard is IEC 81001-5-1:2021 ("Health software and health IT systems safety, effectiveness and security — Part 5-1: Security — Activities in the product life cycle", published 16 December 2021), which sets life cycle requirements for health software to support conformance with IEC 62443-4-1Sourced.
(3) The radio link and dated material
On the Bluetooth side, the CGMS specification requires authentication for all characteristics (above). But what a specification says is separate from whether a real product implements it properly and keeps it up to date (commentary). The US National Institute of Standards and Technology's "Guide to Bluetooth Security" (SP 800-121 Rev. 2, May 2017, updated 19 January 2022) covers both BR/EDR and LE, but only Bluetooth 1.1 to 4.2Sourced. Features of later versions are outside it, so it should be used with care when assessing newer products (commentary).
(4) Japan
A briefing document from the MHLW and PMDA, "Cybersecurity of medical devices" (in Japanese), organizes the related notifications. The basic requirements standard was amended on 9 March 2023, and the list includes "Application of Article 12, paragraph 3 of the basic requirements standard" (Yakusei Kishin-hatsu 0331 No. 8, 31 March 2023) and "Revision of the guide to introducing cybersecurity for medical devices" (Yakusei Kishin-hatsu 0331 No. 11 and another, 31 March 2023)Sourced. We have not checked the content of these notifications in detail.
The SBOM asks for a list of the software components in a product, an idea close to the composition sheets and the control of substances such as under REACH/RoHS in the materials world (commentary). Just as a materials supplier notifies customers of a change in the composition of a delivered material, when a vulnerability is found in a software component the device side takes on an obligation to keep responding with updates and patches after marketing. The "make it once and you are done" instinct for materials does not carry over to connected devices. Even if a sensor lasts only a few days, the app and the cloud are expected to be updated for years (commentary).
8. Digital twins — research or practice?
"Digital twin" means different things to different people. The committee behind the National Academies of Sciences, Engineering, and Medicine (NASEM) report of 2024 defines it as followsSourced.
A digital twin is a set of virtual information constructs that mimics the structure, context and behavior of a natural, engineered or social system, is dynamically updated with data from its physical twin, has a predictive capability, and informs decisions that realize value. The bidirectional interaction between the virtual and the physical is said to be central to the digital twin.
The same report lists, among gaps that are particularly critical to biomedical sciences and medical systems, bioethics, the handling of measurement errors and temporal variations in clinical measurements, capture of adequate metadata to enable data harmonization, the complexities of clinical decision-making with digital twin interactions, the safety of closed-loop systems and privacySourced. On this definition, "a model built from past data" or "a predictive AI" is not by itself a digital twin. It is a twin only when there is a loop in which it keeps being updated by data, predicts, and is used in decisions (commentary).
(1) The part used in regulatory settings: simulators of virtual patient populations
A review by the developers of the UVA/Padova type 1 diabetes simulator (Cobelli and Kovatchev, 2023) says that in 2007 they introduced a simulator with a population of 300 virtual subjects, and that "in January 2008, in an unprecedented decision, the Food and Drug Administration (FDA) accepted this simulator as a substitute to animal trials for the pre-clinical testing of insulin treatment strategies"Sourced (the developers' own account). A 2009 paper (Kovatchev et al.) likewise describes a system of 300 virtual subjects (100 adults, 100 adolescents, 100 children) combined with simulators of CGM sensor error and of an insulin pump as accepted by the FDA as a substitute for animal trialsSourced. Facchinetti (2016) says a two-week trial in 40,000 virtual adult and pediatric patients was run with this simulator, and that material including the results was presented to an FDA advisory panel on 21 July 2016Sourced.
40,000 people x 14 days x 288 per day (every 5 minutes) = about 161.28 million CGM valuesOur calculation. Premise: each virtual patient is assumed to be measured every 5 minutes without gaps; this is only an order-of-magnitude calculation. The paper does not say how many points were actually handled.
How to read it: the strength of a virtual population is that it can try combinations at a scale a real clinical trial cannot collect. Its reliability depends on how well the model reproduces real variability. Facchinetti (2016) himself writes that reliable results need a large-scale simulation model that describes both physiological variability in the population and the variability of the technology.
(2) The research-stage part: personalized models
ReplayBG (Cappon et al., 2023) uses the "digital twin" idea to identify a personalized model of glucose-insulin dynamics from insulin, carbohydrate and CGM data and then "replays" the same scenario under a different therapy to simulate the glucose concentrationSourced. It was assessed on 100 virtual subjects from the UVA/Padova simulator, comparing the glucose traces it produced with the simulator's for five treatment-modification scenarios, and two case studies with real data are presented. The authors conclude it is a reliable tool for exploring the effect of new treatments retrospectively and for preliminary evaluation before clinical trialsSourced.
(3) Use in clinical decisions: limited evidence
A scoping review of digital twins in diabetes (Sarani Rad et al., JMIR Diabetes 2026) selected 28 studies from the literature up to April 2025 and reported the followingSourced.
- Most used data-driven, hybrid or simulation-based approaches, for glucose prediction, therapeutic control and decision support.
- Validation was mainly retrospective or simulation-based, with few clinical trials. Reported outcomes included improved HbA1c and time-in-range and reduced hypoglycemia.
- The implementation barriers named were validation gaps, data quality and workflow integration.
- The conclusion is that the evidence is heterogeneous, inconsistently reported and limited in prospective clinical validation; standardized definitions, real-world evaluation, fairness and governance, and integration into clinical workflows are the gaps.
So a claim that "an individual digital twin optimizes care" was, as of 2026, not an established fact but a direction of research (our summary).
(4) Model credibility: the FDA's framework
The FDA guidance "Assessing the Credibility of Computational Modeling and Simulation in Medical Device Submissions" (17 November 2023) sets out a risk-informed framework for assessing the credibility of computational models used in submissionsSourced. Credibility is defined as trust in a model's predictive capability. The core of the framework is to define the context of use, assess the model risk (the combination of how much the model influences the decision and how serious the consequence of a wrong decision would be), and set credibility goals that match it. It applies to first-principles (physics-based or mechanistic) models, including mechanistic models of physiological processes, but not to standalone statistical or data-driven models such as regression, machine learning or AI models. For hybrid models only the first-principles part is coveredSourced. For evidence on data-driven models, it recommends seeking the FDA's feedback through the Q-Submission process.
This is the practical point about digital twins: a twin that mixes mechanistic and data-driven parts is not set up so that one framework evaluates the whole (commentary). We could not confirm whether the FDA has a device category named "digital twin".
9. Cautions about overstated claims
The table below sorts out what to check when reading public material. It does not judge any product and is not advice to any individual reader.
| Typical wording | What to check (how to read the material) | Public documents and literature that help |
|---|---|---|
| "Just connect it to your phone and it measures" | Where is the sensor's own performance (reference, subjects, conditions) stated? Are the connection method and the measurement accuracy being mixed up? | A communication specification does not guarantee accuracy (the Bluetooth SIG specifications fix communication rules)Sourced |
| "Medical-grade app" | Which regulatory category (not a device, Class I, Class II, certification and so on)? What is the intended use? | The FDA judges by function and risk; Japan by intended use and riskSourced |
| "Wellness app" | Does it avoid claims about diagnosis, treatment or managing disease? In Japan, if even one of several functions has a medical purpose, the whole can be a medical device | MHLW guideline; MDCG 2019-11 Rev.1Sourced |
| "Securely encrypted" | What is protected (device, radio, app, cloud)? Are there plans for updates and for responding to vulnerabilities? Is the SBOM maintained? | FDA guidance (section 524B), IEC 81001-5-1Sourced |
| "AI builds your personal twin" | Is the model kept updated with data? Is there a loop between prediction and decision? Has it been validated prospectively in clinical use? | The NASEM definition; the 2026 review in diabetesSourced |
| "Virtual patients accepted by the FDA" | What exactly was accepted (use in preclinical testing, or use in care)? Whose account is it (developers' or the regulator's)? | The acceptance of UVA/Padova is the developers' accountSourced |
- The path from sensor to smartphone can be sorted into three: Bluetooth LE (battery and radio), NFC (no battery) and a configuration through a transmitter. In the Bluetooth specification a sensor connects to only one Collector at a time, and values are sent in mg/dL onlySourced
- A research example of a battery-free patch sensor weighs about 1 g, estimated to be about 20 times lighter than battery-powered Bluetooth approaches. Its human testing was a two-day research demonstrationSourced
- 5.0 mmol/L is 90.1 mg/dL, and a 16-bit time offset covers about 45.5 days. The meaning of units and time is fixed outside the sensorOur calculation
- Apps are judged by function. Only transferring, storing and displaying is not a device; analyzing and alerting, proposing doses and commanding delivery automatically are progressively heavier categoriesSourced
- When a smartphone camera reads a test strip, the phone model and camera settings are part of the measurement system. The FDA decision summary records evaluation with 8 phone models and 3 lotsSourced
- Cybersecurity is something to maintain through the life of the product; section 524B asks for update and patch plans and an SBOM. The FDA guidance of 3 February 2026 is currentSourced
- Among digital twins, simulators of virtual patient populations are used in regulatory settings (developers' account); personal twins are at the research stage. Prospective clinical validation of their use in care is limitedSourced
10. What is still open, and what we could not confirm
(1) How Japan and the EU treat digital twins
We could not confirm whether Japan or the EU has a regulatory position specific to digital twins. We have also not confirmed whether "digital twin" is used as a device category name at the FDA.
(2) How Bluetooth security is implemented
We confirmed that the CGMS specification has an authentication requirement, but we could not confirm the details of the pairing method (for example LE Secure Connections) or how individual products implement it. The NIST guide covers Bluetooth only up to 4.2.
(3) The regulatory status of individual apps
This article organizes the regulatory framework; it did not investigate under which category any individual app is authorized or certified.
(4) The NFC standards as a whole
We did not check the NFC Forum specifications or the other parts of ISO/IEC 14443 and 15693 (only the title and scope of ISO/IEC 15693-2). Numbers such as reading distance are values from the bench tests in the paper.
(5) The content of Japan's cybersecurity notifications
We confirmed the titles and numbers of the notifications listed in the MHLW/PMDA briefing document, but did not check the details of the notifications themselves.
11. Glossary
- BLE (Bluetooth Low Energy)
- Low-power short-range radio used to connect sensors to mobile devices.
- GATT
- The way a Bluetooth LE device exposes data as "services" and "characteristics".
- NFC
- Near-field communication. Some forms let the reader's field power a battery-free device while communicating.
- SFLOAT
- A 16-bit floating-point format (4-bit exponent, 12-bit mantissa), used for glucose values in the Bluetooth CGMS.
- MDDS
- Medical device data system: only transfers, stores, converts the format of or displays device data.
- MDSW
- Medical device software in the EU: software within scope of the MDR and IVDR.
- SaMD
- Software as a medical device: software with a medical purpose that is not part of a hardware medical device.
- Clinical decision support (CDS)
- Software that supports a clinician's decision. The FDA uses four criteria to decide whether it is a device.
- Section 524B
- The section of the FD&C Act on cyber devices. It asks for plans, assurance and an SBOM.
- SBOM
- Software bill of materials: a list of the software components in a product.
- SPDF
- Secure Product Development Framework.
- Digital twin
- A virtual construct linked to a physical counterpart by bidirectional data, dynamically updated and predictive (summary of the NASEM definition).
- In silico trial
- A trial run on virtual subjects in a computer.
- VVUQ
- Verification, validation and uncertainty quantification.
- Context of use
- A statement of the question a computational model addresses and the role it plays.
12. References
- FDA "Policy for Device Software Functions and Mobile Medical Applications", version of 28 September 2022 (first issued 25 September 2013), guidance page — fda.gov
- FDA "Clinical Decision Support Software", version of 29 January 2026 (PDF text checked), guidance page — fda.gov
- eCFR "21 CFR 862.2120 Continuous glucose monitor data management system" — ecfr.gov
- eCFR "21 CFR 862.1350 Continuous glucose monitor secondary alarm system" — ecfr.gov
- eCFR "21 CFR 862.1358 Insulin therapy adjustment device" — ecfr.gov
- eCFR "21 CFR 862.1356 Interoperable automated glycemic controller" — ecfr.gov
- eCFR "21 CFR 862.1355 Integrated continuous glucose monitoring system" — ecfr.gov
- eCFR "21 CFR 880.6310 Medical device data system" — ecfr.gov
- FDA "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions", version of 3 February 2026 (PDF text checked), guidance page — fda.gov
- Bluetooth SIG "Continuous Glucose Monitoring Service" v1.0.2 (18 January 2022) — bluetooth.com
- Bluetooth SIG "Continuous Glucose Monitoring Profile" v1.0.2 (18 January 2022) — bluetooth.com
- ISO/IEEE "ISO/IEEE 11073-10425:2024 Health informatics — Device interoperability — Part 10425: Personal health device communication — Device specialization — Continuous Glucose Monitor (CGM)" (third edition, September 2024) — iso.org
- ISO/IEC "ISO/IEC 15693-2:2019 Cards and security devices for personal identification — Contactless vicinity objects — Part 2: Air interface and initialization" — iso.org
- Bandodkar AJ et al. "Battery-free, skin-interfaced microfluidic/electronic systems for simultaneous electrochemical, colorimetric, and volumetric analysis of sweat", Sci Adv 2019;5:eaav3294 (open access) — pmc.ncbi.nlm.nih.gov
- HL7 "FHIR R5 Observation" — hl7.org
- Battelino T et al. "Clinical Targets for Continuous Glucose Monitoring Data Interpretation: Recommendations From the International Consensus on Time in Range", Diabetes Care 2019;42:1593-1603 — doi.org
- Facchinetti A. "Continuous Glucose Monitoring Sensors: Past, Present and Future Algorithmic Challenges", Sensors 2016;16(12):2093 (open access) — pmc.ncbi.nlm.nih.gov
- FDA "510(k) Substantial Equivalence Determination Decision Summary, K222921" (Minuteful - kidney test) — accessdata.fda.gov
- Ministry of Health, Labour and Welfare "Guideline on whether a program is a medical device" (in Japanese), 31 March 2021, partly revised 31 March 2023 (PDF hosted by PMDA) — pmda.go.jp
- MDCG "MDCG 2019-11 Rev.1 Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR", June 2025 (PDF) — health.ec.europa.eu
- NIST "SP 800-121 Rev. 2 Guide to Bluetooth Security", May 2017 (updated 19 January 2022) — csrc.nist.gov
- IEC "IEC 81001-5-1:2021 Health software and health IT systems safety, effectiveness and security — Part 5-1: Security — Activities in the product life cycle" — webstore.iec.ch
- MHLW and PMDA "Cybersecurity of medical devices" (briefing document, in Japanese) — pmda.go.jp
- National Academies of Sciences, Engineering, and Medicine "Foundational Research Gaps and Future Directions for Digital Twins" (2024) — nationalacademies.org
- Cobelli C, Kovatchev B. "Developing the UVA/Padova Type 1 Diabetes Simulator: Modeling, Validation, Refinements, and Utility", J Diabetes Sci Technol 2023;17:1493-1505 — doi.org
- Kovatchev BP et al. "In silico preclinical trials: a proof of concept in closed-loop control of type 1 diabetes", J Diabetes Sci Technol 2009;3:44-55 — doi.org
- Cappon G et al. "ReplayBG: A Digital Twin-Based Methodology to Identify a Personalized Model From Type 1 Diabetes Data and Simulate Glucose Concentrations to Assess Alternative Therapies", IEEE Trans Biomed Eng 2023;70:3227-3238 — doi.org
- Sarani Rad F et al. "Digital Twin Applications in Diabetes Management: Scoping Review", JMIR Diabetes 2026;11:e83059 — doi.org
- FDA "Assessing the Credibility of Computational Modeling and Simulation in Medical Device Submissions", 17 November 2023 (PDF text checked) — fda.gov
- PubChem "Glucose (CID 5793)" — pubchem.ncbi.nlm.nih.gov
- openFDA record of 510(k) K222921 (decision date and so on) — api.fda.gov
13. Claim-to-source audit
| Claim in the text | Basis | Label |
|---|---|---|
| The definition of a mobile medical app (accessory to a device, or transforming the platform into a device). The regulated software functions (control or data analysis of a device, a phone with a strip reader as a glucose meter, notification of readings outside a range). That Non-Device MDDS (transfer, store, convert, display only; no alarms) is an example of a non-device. Version of 28 September 2022; first issued 25 September 2013. NBW (21 CFR 862.1345) as an example | FDA mobile medical app policy (PDF text and page checked)[Reference 1] https://www.fda.gov/regulatory-information/search-fda-guidance-documents/policy-device-software-functions-and-mobile-medical-applications | Sourced |
| That the CDS guidance version of 29 January 2026 supersedes that of 6 January 2026; the four criteria; that the processed output of a CGM is a "pattern", distinguished from a single test result; that software analyzing CGM readings fails criterion 1; that existing policy applies to patient- or caregiver-directed device software functions | FDA CDS guidance (PDF text checked)[Reference 2] https://www.fda.gov/regulatory-information/search-fda-guidance-documents/clinical-decision-support-software | Sourced |
| 862.2120 (Class I, retrospective data, not a dose calculator) | 21 CFR 862.2120[Reference 3] https://www.ecfr.gov/current/title-21/chapter-I/subchapter-H/part-862/subpart-C/section-862.2120 | Sourced |
| 862.1350 (Class II, measures against unauthorized access and modification, warnings) | 21 CFR 862.1350[Reference 4] https://www.ecfr.gov/current/title-21/chapter-I/subchapter-H/part-862/subpart-B/section-862.1350 | Sourced |
| 862.1358 (Class II, assessment of input accuracy requirements, data transmission strategy, mitigation of wrong recommendations, not for automated dosing) | 21 CFR 862.1358[Reference 5] https://www.ecfr.gov/current/title-21/chapter-I/subchapter-H/part-862/subpart-B/section-862.1358 | Sourced |
| 862.1356 (Class II, automatic calculation and commanding of delivery, safe therapy when communication is lost) | 21 CFR 862.1356[Reference 6] https://www.ecfr.gov/current/title-21/chapter-I/subchapter-H/part-862/subpart-B/section-862.1356 | Sourced |
| The requirement for a strategy for secure and reliable data transmission for iCGM | 21 CFR 862.1355(b)(2)[Reference 7] https://www.ecfr.gov/current/title-21/chapter-I/subchapter-H/part-862/subpart-B/section-862.1355 | Sourced |
| That the MDDS in 880.6310 is a hardware device and Class I | 21 CFR 880.6310[Reference 8] https://www.ecfr.gov/current/title-21/chapter-I/subchapter-H/part-880/subpart-G/section-880.6310 | Sourced |
| That the cybersecurity guidance version of 3 February 2026 supersedes that of 27 June 2025; the mention of wireless and network connection; section 524B (FDORA, 29 December 2022, from 29 March 2023), the definition of a cyber device, the plan, assurance and SBOM submissions, out-of-cycle patches for critical vulnerabilities; the SPDF | FDA cybersecurity guidance (PDF text and page checked)[Reference 9] https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-medical-devices-quality-management-system-considerations-and-content-premarket | Sourced |
| The seven mandatory characteristics of the CGMS, mg/dL only, SFLOAT, optional calibration, authentication required, E2E-CRC, a 16-bit time offset in minutes | Bluetooth SIG CGMS v1.0.2[Reference 10] https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/CGMS_v1.0.2/out/en/index-en.html | Sourced |
| The two roles of the CGMP, that the Collector is a GATT client, connection to only one Collector, transcoding of Device Information Service characteristics. v1.0.2, 18 January 2022; first approved 18 November 2014 | Bluetooth SIG CGMP v1.0.2[Reference 11] https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/CGMP_v1.0.2/out/en/index-en.html | Sourced |
| The content of ISO/IEEE 11073-10425:2024 (third edition, September 2024) and its description of measurement "typically every 5 minutes" | ISO page[Reference 12] https://www.iso.org/standard/88164.html | Sourced |
| The title and scope of ISO/IEC 15693-2:2019 | ISO page (title checked)[Reference 13] https://www.iso.org/standard/73601.html | Sourced |
| The NFC sensor's construction (reusable module about 0.1 g, whole about 1 g, about 20 times lighter and 4 times smaller by estimate), the ISO 15693-compatible front end, reading distance about 38 mm and angle 70 degrees (bench test with a constant reference signal), two-day human trials, materials (copper-on-polyimide board, silicone of about 1 MPa, magnets, holding force about 1.5 N) | Bandodkar et al. (2019)[Reference 14] https://pmc.ncbi.nlm.nih.gov/articles/PMC6357758/ | Sourced |
| The scope and value types of the FHIR R5 Observation | HL7 FHIR R5[Reference 15] https://hl7.org/fhir/R5/observation.html | Sourced |
| That the ATTD international consensus on reporting CGM metrics was published in 2019 | Abstract of Battelino et al. (2019)[Reference 16] https://doi.org/10.2337/dci19-0028 | Sourced |
| The three parts of a CGM, that calibration can be done in the transmitter or the receiver, the two-week trial in 40,000 virtual patients, the FDA advisory panel of 21 July 2016, the need for a large-scale model | Facchinetti (2016)[Reference 17] https://pmc.ncbi.nlm.nih.gov/articles/PMC5191073/ | Sourced |
| K222921: intended use (smartphone application, colour board, reagent strip, prescription only), measuring range, reflectance photometry, camera-feature modification, evaluation with 8 phones and 3 lots, download blocking for incompatible phones, no calibration needed, classification (JFY, JIR, KQO) | FDA 510(k) decision summary[Reference 18] https://www.accessdata.fda.gov/cdrh_docs/reviews/K222921.pdf | Sourced |
| The decision date of K222921 (8 September 2023) and the decision code (substantially equivalent) | openFDA 510(k) record[Reference 31] https://api.fda.gov/device/510k.json?search=k_number:K222921 | Sourced |
| The content of the MHLW guideline (intended use and risk; a whole program is regulated if one function qualifies; integration with general-purpose sensors; examples of viewing programs). 31 March 2021; partly revised 31 March 2023 | MHLW guideline (PDF text checked)[Reference 19] https://www.pmda.go.jp/files/000240233.pdf | Sourced |
| MDCG 2019-11 Rev.1 (October 2019; revision 1 June 2025). Applies to apps; wellness and fitness apps do not qualify; the content of Rule 11 | MDCG 2019-11 Rev.1 (PDF text checked)[Reference 20] https://health.ec.europa.eu/document/download/b45335c5-1679-4c71-a91c-fc7a4d37f12b_en?filename=md_mdcg_2019_11_guidance_qualification_classification_software_en.pdf | Sourced |
| The NIST Bluetooth guide (May 2017, updated 19 January 2022, covering Bluetooth 1.1 to 4.2) | NIST page[Reference 21] https://csrc.nist.gov/pubs/sp/800/121/r2/upd1/final | Sourced |
| The title and publication date (16 December 2021) of IEC 81001-5-1:2021 and its relation to IEC 62443-4-1 | IEC Webstore[Reference 22] https://webstore.iec.ch/en/publication/63293 | Sourced |
| Titles, numbers and dates of Japanese cybersecurity notifications (the basic requirements standard amended on 9 March 2023, Yakusei Kishin-hatsu 0331 No. 8 and No. 11, and others) | MHLW/PMDA briefing document[Reference 23] https://www.pmda.go.jp/files/000267352.pdf | Sourced |
| The NASEM committee's definition of a digital twin and bidirectional interaction; examples of research gaps needed in biomedicine | Summary chapter of the NASEM report[Reference 24] https://www.nationalacademies.org/read/26894/chapter/2 | Sourced |
| The UVA/Padova simulator: introduced in 2007, 300 virtual subjects, the developers' account that the FDA accepted it as a substitute for animal trials in January 2008 | Abstract of Cobelli and Kovatchev (2023)[Reference 25] https://doi.org/10.1177/19322968231195081 | Sourced |
| 300 virtual subjects (100 adults, 100 adolescents, 100 children), simulators of sensor error and pump, the statement of FDA acceptance | Abstract of Kovatchev et al. (2009)[Reference 26] https://doi.org/10.1177/193229680900300106 | Sourced |
| The ReplayBG method, validation on 100 virtual subjects, two real-data case studies, the conclusion | Abstract of Cappon et al. (2023)[Reference 27] https://doi.org/10.1109/tbme.2023.3286856 | Sourced |
| The scoping review of digital twins in diabetes: 28 studies, validation mainly retrospective or simulation-based, few clinical trials, the conclusion | Abstract of Sarani Rad et al. (2026)[Reference 28] https://doi.org/10.2196/83059 | Sourced |
| The FDA CM&S guidance (17 November 2023; draft 23 December 2021): the definition of credibility, context of use, model risk, mechanistic models covered while standalone data-driven models are not, hybrid models covered only in the first-principles part, the Q-Submission recommendation | FDA guidance (PDF text checked)[Reference 29] https://www.fda.gov/media/154985/download | Sourced |
| That the molar mass of glucose is 180.16 g/mol | PubChem[Reference 30] https://pubchem.ncbi.nlm.nih.gov/compound/5793 | Sourced |
| 1 mmol/L = about 18.02 mg/dL and the converted values, the limit of the time offset (65,535 minutes = about 45.5 days), the number of points in 14 days (4,032), 40,000 x 14 days x 288 = about 161.28 million | Our calculation. Premises: molar mass of 180.16 g/mol, a 16-bit unsigned integer, measurement every 5 minutes with no gaps. Not the displayed values of any real product nor the actual data volume in a paper | Our calculation |
| The arrangement of three connection schemes. The reading of what becomes the materials job when the battery is dropped. The arrangement of layers of agreement. The ordering of functions by weight. The reading that the smartphone becomes part of the measurement system. The analogy between an SBOM and a materials composition sheet. The classification of digital twins into three types. The table for checking overstated claims | Commentary and organization by this article, based on the published material. Not views stated by the companies or agencies | Commentary |
| Regulatory positions specific to digital twins in Japan and the EU, details of the Bluetooth implementation, the regulatory status of individual apps, the NFC standards as a whole, and the text of Japanese cybersecurity notifications | Not confirmed within the scope of this investigation, so not stated | Commentary |
| That Figs. 1, 2, 4, 5, 6 and 7 are explanatory drawings, and that the hero image and Fig. 3 are AI-generated concepts | Note by this article | Commentary |
Last updated October 2026. Sources are limited to primary material (publications of the FDA, MHLW, PMDA, MDCG and NIST, 21 CFR, standards-body pages, and peer-reviewed papers). Because the article includes arrangements of the material and readings of the materials side, those are marked as commentary and kept separate from sourced fact. Regulatory positions specific to digital twins in Japan and the EU, the details of Bluetooth security implementation, the regulatory status of individual apps, the NFC standards as a whole and the text of Japan's cybersecurity notifications could not be confirmed and are therefore not stated. Some figure values, such as the conversions in Fig. 2, are our calculations and do not show the performance of any real product. The NFC sensor values are conditioned values from bench tests in a research paper.