Case study: Neither a SaMD, nor a SiMD; maybe a SaMDA?
A mobile medical app crashing can cause a life-threatening emergency and send you to the hospital. It seems to have fallen through a crack in the regulatory framework for medical software.
Imagine you have Type I diabetes and you rely on your smart insulin pump to manage blood glucose levels in a tight range. It is so smart that you can even control it from a mobile app to deliver an on-demand bolus insulin (i.e. a short acting boost) when you are about to enjoy a special celebratory meal with family and friends!
The mobile app also displays all kind of useful data such as glucose trends, insulin delivery history, insulin on board, carbs, continuous glucose monitoring sensor status, and even important alerts and alarms1.
There is just a small problem.
If you have an older version of this mobile app running on the Apple iOS platform (i.e., iPhone, iPad etc.), the app could crash without warning and be automatically relaunched by the iOS operating system. This cycle may repeat several times, which in turn, can drain the pump battery, resulting in a pump shutdown and interruption in insulin delivery.
According to the Class I recall announcement from the FDA2:
Pump shutdown will cause insulin delivery to suspend, which could lead to an under-delivery of insulin and may result in hyperglycemia or even diabetic ketoacidosis, which can be a life-threatening condition due to high blood sugars and lack of insulin.
There have been 224 reported injuries as of April 15, 2024 and no reports of death.
Clearly, this is a serious issue that has already resulted in many reports of injury to patients.
How could this happen?
The specific functionality of this mobile app which controls the pump to deliver an on-demand bolus insulin certainly meets FDA’s definition of a device software function3 deployed on a mobile platform. However, the regulatory history of this mobile app indicates that it is not regulated as a standalone medical device, rather as an accessory to the insulin pump.
Note that it cannot be treated as a Software in a Medical Device (SiMD) because it is not a part of the insulin pump software, rather a standalone software operating on a mobile platform.
It also does not meet the definition of a Software as a Medical Device (SaMD) because this specific functionality controls another hardware medical device4, that is, the insulin pump.
So, if it is not a SaMD, neither a SiMD, what is it?
Perhaps we should treat it as a SaMDA, or Software as a Medical Device Accessory. But there is no formal definition of SaMDA which can inform an appropriate regulatory approach for these types of device software functions to ensure they are safe and effective.
There is a crack in the regulatory framework for medical software through which this mobile app seems to have fallen through!
In this article, we will explore this question in the context of the regulatory history of the t:connect mobile app, it’s relationship to the t:slim X2 insulin pump, and how it fits within the regulatory framework of a medical device accessory.
Lets us dive in.
The t:connect mobile app: An optional but powerful component of a closed loop diabetes management system
On their website, Tandem Diabetes Care promotes their mobile apps, including the t:connect mobile app, as an enabler of “freedom to more easily manage your diabetes”:
Freedom to deliver: you can deliver bolus from a compatible smartphone when paired with the t:slim X2 insulin pump;
Freedom to see clearly: you can view pump data and other important parameters on your smartphone; and
Freedom to be in the know: you can upload and therapy data to a cloud-based platform to share with your healthcare provider.
Clearly, this mobile app is an important part of the whole system. But it is more than just a convenient way to review data, monitor trends and receive alerts. It also has a therapeutic function which allows a patient to deliver a bolus insulin directly from their smartphone.
Note that the t:connect mobile app is an optional component of the system, and not all software features are universally available to all users. The t:slim X2 pump is perfectly capable of delivering smart insulin therapy without the use of the mobile app. However, the app offers powerful functionality to the user for better, and potentially more effective, management of their condition.
Also note that only the bolus delivery functionality from the Smartphone should be considered as a device software function according to the FDA definition noted above.
As we will see in the regulatory history of the t:connect app below, FDA has not considered this mobile app to be a standalone SaMD. But it is also not a SiMD because it is not embedded in or a part of the t:slim X2 insulin pump. As a result, it appears that FDA has not required extensive testing and documentation generally expected from device software functions5 for this app in marketing submissions.
Regulatory history: A case of regulatory oversight lagging behind technological advancement
A careful review of the relevant FDA approvals and clearances reveals that t:connect started out not as a mobile app on a dynamic platform such as a smartphone, but as a web-based software system used only to review and analyze data downloaded from the insulin pump using a USB cable. As a result, FDA appears to have treated it as an accessory to the insulin pump and related blood glucose meter for regulatory purposes.
However, the t:connect mobile app has rapidly evolved since its early days. Now it operates on a smartphone, not a desktop computer, and connects wirelessly to the insulin pump via Bluetooth. It has a lot more functionality than before, including the ability to deliver an on-demand bolus insulin through the pump directly from the smartphone.
It is not wrong to continue treating it as an accessory to the insulin pump, but it has significantly more advanced technological characteristics and functionality that should require a more rigorous assessment of safety and effectiveness and appropriate regulatory classification.
Here is a brief chronology of relevant FDA approvals and clearances:
2013: K122361 issued for t:connect data management system6, classified as a Class I device, exempt from pre-market notification under 21 CFR 880.5725 with product code OUG. It is considered substantially equivalent to Medtronic MiniMed Diabetes Data Management System (K032164) and the Aidera Diasend System (K101806).
2015: DEN140038 granted to Dexcom for continuous glucose monitor data management software device7, classified as a Class II device exempt from pre-market notification under 21 CFR 862.1350 with product code PJT. Tandem registers the t:connect mobile app under this product code, but there is no record of a 510k associated with this change.
2015: P140015 approved for the t:slim G4 insulin pump with Dexcom G4 platinum CGM8, which also includes the t:connect/CGM Data management program as an accessory.
2019: DEN180058 granted for t:slim X2 insulin pump with interoperable technology9, which creates a new regulatory classification for Alternate Controller Enabled (ACE) infusion pumps, classified as Class II devices under 21 CFR 880.5730. There is no record of the t:connect mobile app as an accessory in the decision summary associated with this reclassification order.
2020: K201214 issued for the t:slim X2 pump with interoperable technology10, using DEN180058 as a predicate device, associated with a software update that prevents a user from inadvertently setting an excessively high basal rate or a temporary basal rate for insulin delivery, as an enhanced safety feature. There is no record of using the t:connect mobile app in this 510k.
2022: K203234 issued for use of the t:connect mobile app with t:slim X2 insulin pump with interoperable technology11. The t:connect mobile app is indicated as an optional method of viewing therapy data and trends, real-time glucose values and trends, and to program and request a bolus insulin from a compatible smartphone. It displays glucose data from Dexcom G6 system but does not allow the user to enable automated insulin delivery or program and deliver extended boluses or basal insulin.
2023: K223213 issued for Tandem Mobi insulin pump with interoperable technology12 where the pump functionality is directly controlled by the t:connect mobile app. Therefore, the t:connect mobile app is no longer an optional accessory; rather a key component of the Mobi insulin pump system.
2024: K240309 issued for Tandem Mobi insulin pump with interoperable technology13 with an expanded indication including children 2 years or older, with a dedicated t:connect mobile app different from the version used for the t:slim X2 pump with interoperable technology per K203234 above.
As noted above, the t:connect mobile app was cleared through K203234, which uses the t:slim X2 insulin pump with interoperable technology as the predicate device (K201214). An important question to ask is whether the t:slim X2 insulin pump cleared through K201214 is the correct predicate, and whether the t:connect mobile app with a safety-critical functionality should be classified separately with its own unique classification.
Clearly, the software used in the t:connect mobile app is significantly different than the software in the t:slim X2 insulin pump. It also operates in a highly dynamic environment on a smartphone. Software updates to the smartphone operating systems are frequent and completely outside the control of the device manufacturer. As a result, the t:connect mobile app should be treated as having a different risk profile than the insulin pump software.
Not just any accessory, t:connect operates on a smartphone with a dynamic operating system
FDA has outlined a regulatory framework and policy for classification of accessories in a guidance document, Medical Device Accessories – Describing Accessories and Classification Pathways, issued in December 201714. In this guidance document, FDA defines an accessory as:
A finished device that is intended to support, supplement, and/or augment the performance of one or more parent devices.
Support means an accessory enables of facilitates a the parent device to perform its intended use. For example, a tunneling tool that helps create a conduit to insert and attach various leads between the target location and a neurostimulation device.
Supplement means an accessory adds a new function or a new way of using the parent device without changing its intended use. For example, a new balloon catheter used to insert an already approved transcatheter valve into smaller diseased arteries by expanding its use to a broader patient population.
Augment means an accessory enables the parent device to perform its intended use more safely and effectively. For example, a software program that adds color or contrast filters to enhance raw images by an imaging device.
In this context, it can be argued that the t:connect mobile app supplements and augments the intended use of the t:slim X2 insulin pump by enabling the user to better manage their diabetes through convenient information sharing, timely alerts and on-demand delivery of bolus insulin directly from a smartphone. Note that the smartphone itself is not an accessory in this case.
FDA has traditionally determined the regulatory classification of an accessory in one of two ways:
Through an existing 510k or PMA, or by explicitly including it in the classification regulation or reclassification order for the parent device; or
By issuing a unique, separate classification regulation for the accessory.
If an accessory does not significantly alter the intended use and technological characteristics, or does not introduce different technological characteristics that do not raise new questions about safety and effectiveness, then it can be rolled into an existing 501k or PMA.
However, if an accessory can be used with multiple parent devices or have unique standalone functions, then FDA may consider issuing a separate classification regulation to reflect a different risk profile requiring a different level of regulatory control.
It is clear that the safety-critical functionality that allows a user to deliver a bolus insulin from the smartphone should be considered as a “standalone” function requiring a closer examination of its risk profile. Even without this function, the incompatibility with the iOS operating system that resulted in draining the pump battery according to the recent recall, presents a new risk that should raise different questions about safety and effectiveness.
The t:connect mobile app was cleared as an accessory through a 510k for the insulin pump under the same classification regulation. It can be argued that the second pathway of issuing a unique, separate classification would have been more appropriate based on differences in the risk profile.
In conclusion
The case of the t:connect mobile app illustrates a potential gap in the regulatory framework for medical software, whether as a standalone device or as an accessory.
It is clear that this mobile app cannot be characterized as a SiMD, because it is not embedded or a part of the t:slim insulin pump.
It also does not meet the definition of a SaMD because one of its function is used to deliver a bolus through the insulin pump. This type of functionality is explicitly excluded from the IMDRF definition of a SaMD.
FDA has discretion to classify and regulate an accessory based on its impact on the parent device and any unique risks independent of the device. One of the unique risks uncovered by this Class I recall is compatibility with and stability on the operating system of the smartphone. It seems that this is where the t:connect mobile app has fallen through the crack in the regulatory framework for medical software.
So, it is not a SaMD, neither a SiMD. Perhaps we need to call it SaMDA, or Software as a Medical Device Accessory! It has been 7 years since the FDA issued its guidance on medical device accessories. It is time for the FDA to expand the medical software terminology and update this guidance.
Tandem Diabetes Care: t:connect Mobile App for t:slim X2 pump features (accessed August 28, 2024).
FDA: Tandem Diabetes Care, Inc. recall announcement (updated May 8, 2024).
FDA: According to the Policy for Device Software Functions and Mobile Medical Applications, a guidance document issued in September 2022, a software function that meets the definition of a medical device under section 201(h) of the FD&C Act is considered to be a “device software function”, which is regulated by the FDA regardless of the platform.
IMDRF: According to the Software as a Medical Device (SaMD): Key Definitions, Software does not meet the definition of SaMD if its intended purpose is to drive a hardware medical device
FDA: In the Content of Premarket Submissions for Device Software Functions, a guidance document issued in June 2023, FDA recommends a risk-based approach to required documentation in the marketing submission. Enhanced documentation level is expected based on the intended use of a device software function when it poses a significant safety risk to the patient. FDA also expects conformance to IEC 62304 to ensure software is developed, tested and managed according to the state of the art to ensure safety and effectiveness.
FDA: See 510k database entry for K122361.
FDA: See De Novo database entry for DEN140038.
FDA: See De Novo database entry for DEN180058.
FDA: See 510k database entry for K201214.
FDA: See 510 database entry for K203234.
FDA: See 510k database entry for K223213.
FDA: See 510 database entry for K240309.
FDA: See guidance document Medical Device Accessories – Describing Accessories and Classification Pathways, issued December 20, 2017.
Brillant article! 😊👏