As the regulatory landscape for healthcare apps and Software as a Medical Device (SaMD) begins to firm up, there are three key steps that firms should take as they develop and commercialize smartphone apps and stand-alone software:
1. Review the current best-of-breed regulatory guidance
2. Create a yes/no decision tree to document your decision
3. Clarify the decision and communicate.
Step 1: Review the Current Best-of-Breed Regulatory Guidance
There are four critical guidelines to review that software (and medical device) makers will want to read through:
- The US FDA has dedicated section on its website that summarizes FDA’s current thinking in how FDA regulates Software as a Medical Device. If your software falls under FDA’s SaMD interpretation, you will need to comply with 21 CFR 11 Electronic Records; Electronic Signatures (e.g., Part 11), 21 CFR 820 Quality System Regulation, and 21 CFR 807 Medical Device Reporting (MDR).
- The EU released its guidance document in January 2012, Guidelines on the Qualification and Classification of Stand Alone Software Used in Healthcare within the Regulatory Framework of Medical Devices (PDF). These are the EU "regulations," but see the next two items below before you just rely upon this.
- Sweden’s Medical Products Agency has release a very good analysis of the EU’s medical app guideline (PDF) that is well worth skimming through all six pages. On page 5 is a very nice, short summary of the requirements for the EU to view an app as a medical device.
- The UK’s MHRA released its own guidance and webpage early in 2014, Guidance on Medical Device Stand-Alone Software (including Apps), on how it will assess and regulate Software as a Medical Device, including smartphone apps. The guidance gives numerous, clear examples along with keyword functionality that the MHRA will look for which will cause MHRA to classify your software as a medical device. In addition, this guideline provides several situational clarifications for the EU’s guidance document based on recent cases.
Step 2: Create a Yes/No Decision-Tree to Document Your Decision
Using information from the above guidance documents, draft a decision-tree diagram of a series of yes/no questions. This decision-tree has two immediate audiences: the software engineers developing your software and the firm’s senior management. For both audiences, simplicity and straightforwardness is important as you should expect your initial assessment to be second-guessed.
Ideally the decision-tree will be used to help guide development and commercialization. For instance, firms may want to avoid a quick bit of functionality that will inadvertently tip an app from non-regulated into regulated territory. One yes/no question to ask might be: “Will the app perform a calculation on the raw health data and only present the results of the calculation (rather than the raw data as well)?” In such a situation, the app is likely to be regulated as a medical device. Thus, this decision-tree can be very helpful to developers and project managers looking at different functionalities and the impact to the software; just because a set of coding may be easy might obscure that adding the code will cause the app to suddenly become regulated.
Likewise, senior management (including venture capitalists) must be comfortable with an app’s final functionality target(s) in order to decide its path of commercialization. Is the software unregulated and thus simply released, or will it require regulatory approval and/or costly compliance with 21 CFR 11, 21 CFR 807, and 21 CFR 820 in the US? This type of decision early in commercialization is critical to help executives avoid costly mistakes and potential risky product liability situations.
As an example of what a straightforward yes/no decision-tree might look like, review the EU’s example yes/no diagram on page 10 of the PDF version of its guidance.
Finally, note that by the end of 2015, the International Medical Device Regulators Forum (IMDRF) has stated its intent to release an internationally harmonized regulatory guideline, so keep an eye out for that on the IMDRF website (www.imdrf.org).
Step 3: Clarify the Decision and Communicate
Document the decision-path taken to identify the regulatory status of the software. This record should be retained as part of the software development project documentation (or in the case of a Software as a Medical Device, its Design History File).
In addition, distribute a copy of this highlighted, documented decision path to the developers and any future support engineers. It’s important to communicate the need to stay within the agreed-upon functionality guidelines, not just in initial development but also in post-launch support, bug fixes, and product enhancements.
For new product enhancements and full version revisions (1.xx to 2.xx), consider reviewing and verifying the decision-tree diagram documentation; this will show a traceable path of informed decisions for each software revision.
For more on Software as a Medical Device, see several of my earlier blog posts:
- Poll: Should FDA Regulate Medical Apps
- Majority of Mobile Health Apps Class II Devices for FDA
- Medical Apps, FDA and Patient Data Integrity
And if you need to educate your team on the regulations affecting Software as a Medical Device, how to cost-effectively comply, or help drafting the policies and procedures required, consider contacting me through the Cerulean Associates LLC website.
Comments