Your App is a Medical Device

How Can an App Be a Medical Device?

Due to the emergence of thousands of mobile apps intended for health purposes, the FDA has published guidance that will help you, as an application publisher, determine if your app should actually be considered a medical device. The FDA considers any app that meets their definition of a medical device to be subject to the same regulations as a physical medical device. 

What Is a Medical Device (As It Pertains to Software)?

Software as a Medical Device (SaMD) is any piece of software that is intended to diagnose or treat diseases or other health conditions. This includes applications that are intended to be used as accessories to pharmaceutical treatments. 

How Do I Know if My App Qualifies as a Medical Device?

The key to knowing whether your app is actually a medical device is the determination of its intended use as well as the indications for use of the product. With this intended use, one can then search the FDA Product Classification Database or search for devices that may have similar intended uses or design. You should also consider the risk that an application may pose to patients who use it – can you adversely affect a patient’s health if something goes wrong in your application? If the answer is YES, then you likely have a medical device on your hands. 

SaMD Examples

Listed below are some applications that are clearly medical devices, with links to their FDA 510(k) responses confirming their device classifications. These are a decent example of types of applications that need to be classified as medical devices due to the risks they could pose to patients’ health had they not been built to account for risk and did not adhere to a quality software development process. 

My Dose Coach – Sanofi

This application is intended to help type 2 diabetics manage their insulin dosage with a prescribed dose plan from their physician. In this case the app itself is adjusting the recommended dosage of a patient’s insulin intake, landing it as a Class 2 medical device. Learn more about our work with Sanofi.

reset-O – Pear Therapeutics

This application is intended to help patients dealing with Opioid addiction and is a prescriptible digital therapy used alongside other outpatient treatment options including transmucosal buprenorphine. As a behavioral intervention for a life-threatening condition, this application is considered a Class 2 medical device. 

MyPKFit – Baxalta/Takeda

This application is used by both patients and HCPs to monitor a hemophilia patient’s dosages and bleeds based on their FVIII deficiency. The platform guides dosage recommendations of Advate, an Antihemophilic replacement for factor VIII and is a Class 2 device since it may impact the dosage of Advate that a patient injects. 

EndeavorRX – Akili Interactive Labs

This is a digital therapeutic indicated to improve attention function in children with ADHD. As a Class 2 medical device EndeavorRX is a prescriptible application that would accompany clinician-directed therapies including medication and education programs.

My App is a Medical Device. Now What?

Understanding that your app is a medical device and that its operation has an impact on the health and safety of a patient should lead you to adjust your development approach to focus on risk. The FDA and other regulatory bodies take a risk-based approach when assessing your application to determine its potential impact on a patient and its device classification, and this approach should be taken when you evaluate all aspects of your software development process. Regulatory bodies will be looking for evidence that you took a risk-based approach and have documented your procedures around risk analysis and have taken steps to document and mitigate any of these hazards and risks to the patient. 

Knowing ahead of time how you’re going to analyze risk, and then work to mitigate these risks and provide full traceability of your risk mitigations through requirements and test verifications, is key to a software development process that will satisfy regulatory bodies. Several standards exist providing guidelines on how to accomplish this. In the US, this is known as CFR 21 Part 820, which governs the Quality Management System that you should have in place when building a medical device. Globally, this standard is aligned with ISO 13485 (Quality Management Systems for Medical Devices). Building your software under a QMS that is certified to these standards is one step in assuring that you’re building safe and effective software for patients that minimizes risks to their health.

Additional standards are also helpful to guide your development process so that all the deliverables a regulatory body might look for are available. IEC 62304 is an international standard for Software Development Processes, that can align well with your Quality Management System. This standard is not prescriptive – it defines the required inputs and outputs of your process, but how you get there is up to you. Ideally you can adapt your organizations existing workflow, be it Agile, Kanban, Waterfall or anything in-between to align with this standard.  

In Conclusion

Don’t avoid medical software development because the regulations and standards seem daunting. The FDA encourages the development of applications that improve health care and provide consumers and health care professionals with valuable information. Standards and processes exist to ensure patient safety, and with a little additional work you can ensure that your medical application / SaMD is built in a proven safe manner and will stand up to regulatory scrutiny.