New FDA Guidance: What You Need to Know in 2 Observations

Executive Summary

The FDA is currently collecting feedback on the draft guidance “Content of Premarket Submissions for Device Software Functions“, a highly anticipated draft to help update the guidance on software design file requirements based on risk.

Orthogonal is pleased to publish this guest blog by Brian Binkowski, who recently joined digital therapeutics (DTx) pioneer Happify (Congrats Brian!) after working at several MedTech companies, including Boston Scientific and Medtronic. Brian is an accomplished and impressive “friend of Orthogonal.” He shares our belief that the MedTech industry can rapidly improve patient outcomes by adopting fast feedback loop techniques to the development and enhancement of Software as a Medical Device (SaMD), DTx and connected medical device systems.

If you’re a technical person working at the intersection of regulatory, quality and software engineering in MedTech organizations and interested in the gritty details, then this article is a must-read. Have something to add? Feel free to reach out on our Contact Us page, or message Brian or Randy at their LinkedIn Pages.

Background on the FDA’s Goals

To start this blog, I’ll share text from the FDA’s announcement of the document and highlight the most important information. Then, I’ll discuss what impact this document may have on those of us working with the development and manufacturing of SaMD.

The FDA’s Call for Comments on this draft guidance provides a concise overview of the contents of the actual document. Below, I pulled quotes from that announcement and added bold text for emphasis:

• This guidance document is intended to provide information regarding the recommended documentation sponsors should include in premarket submissions for the FDA’s evaluation of the safety and effectiveness of device software functions, which are functions that meet the definition of a device under section 201(h) of the Federal Food, Drug, and Cosmetic Act (FD&C Act).[1]
• The recommendations in this guidance document pertain to device software functions, including Software in a Medical Device (SiMD) and Software as a Medical Device (SaMD).^[2]
• When final, this document will replace the FDA’s Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices issued on May 11, 2005, and it will update the FDA’s thinking related to the documentation the FDA recommends sponsors include for the review of device software functions in premarket submissions.
• This guidance identifies the software information generally necessary for evaluating the safety and effectiveness of a device in a premarket submission.
• The recommendations in this guidance also may help facilitate the FDA’s premarket review. 
• The least burdensome approach was applied to identify the minimum amount of information that, based on the FDA’s experience, would generally be needed to support a premarket submission for a device that uses software. 
• During premarket review, FDA may request additional information that is needed to evaluate the submission.

My Observations on this Draft Guidance

Observation #1: Documentation Package Levels

One of the key takeaways – and a major update from the previous guidance from 2005 – is the breakdown of the following Documentation Package Levels:

• Basic: Should be provided for any premarket submission that includes device software functions where Enhanced Documentation does not apply.
• Enhanced: Should be provided for any premarket submission that includes device software functions, where any of the following factors apply:
  1. The device is a constituent part of a combination product.
  2. The device
     • is intended to test blood donations for transfusion-transmitted infections; or
     • is used to determine donor and recipient compatibility; or
     • is a Blood Establishment Computer Software.
  3. The device is classified as Class III.
  4. A failure or latent flaw of the device software function(s) could present a probable risk of death or serious injury, either to a patient, user of the device, or others in the environment of use. These risk(s) should be assessed prior to implementation of risk control measures. You should consider the risk(s) in the context of the device’s intended use; the direct and indirect impacts to safety, treatment, and/or diagnosis; and other relevant considerations.

As with its predecessor, this updated guidance also provides the details of what should be included within each documentation level. However, I believe that one very useful and necessary thing that is missing from this new draft guidance is a cross-walk table that provides a correlation between the software safety classification and the directly related Documentation Levels.

To give an example of how the absence of this kind of cross-walk could lead to potential confusion, review the information in the “Software Testing as Part of Verification and Validation” row. (See Table 1.) In the new draft guidance, the Basic Documentation Level lists out unit and integration level testing descriptions to be included in the submission, but this is not consistent with the requirements in IEC 62304.[3] This could lead to situations where organizations – or multiple groups within one organization – follow the same guidance but end up with different sets of documentation for the same device, without a clear understanding of which set is appropriate.

(The good news in this particular example is that the bold “OR” statements in the “Software Development and Maintenance Practices” row allows conformance to IEC 62304. In other words, if you are already compliant with 62304, you don’t have to worry about a Basic vs. Enhanced level of documentation.)

Observation #2: Linkage to ANSI/AAMI SW91:2018, Classification Of Defects In Health Software

Another area that caught my interest was the surprising callout to ANSI/AAMI SW91:2018, Classification Of Defects In Health Software.[4] To date, SW91 has not received much traction in the industry, and it is unclear how defect classifications are expected to be utilized as part of the submission process or post-market trending. It also came as a surprise that the reference to SW91 is within this guidance, but not referenced as part of the FDA Pre-Cert Pilot, which could be a significant step forward in helping to establish defect categories for the monitoring of industry-wide trends under Real World Performance Monitoring (RWPM).

By establishing clear defects that the industry can collectively trend, it sets the expectation that health software applications take defect trending seriously. For RWPM, the standardization of such defects could assist with clinical evaluations, change assessment and submission updates and future product submissions; existing data in the field can be utilized to demonstrate viable performance of the application.

Conclusion

Overall, I am excited to see how this document develops through the commenting period, and how it improves and gains more traction to help companies in this space.

Author’s Note: The opinions expressed in this blog are solely my own and do not express the views or opinions of Happify Health or any prior employers.

About Brian Binkowski

Brian Binkowski is a Director of Quality for Happify, a pioneering MedTech firm working in the Prescription Digital Therapeutic (PDT) space.  Brian has deep experience working in the Digital Health space, and is passionate about Quality System Compliance in the new Digital era. He has previously worked at leading MedTech firms including Boston Scientific and Medtronic.

Happify’s Intelligent Healing Platform™ enables them to design personalized, science-based care solutions to improve health and well-being across the continuum of care—from digital therapeutics and coaching to community and wellness.

References:

1. This footnote is carried over from the FDA’s webpage: The term "device" is defined in 201(h) of the Federal Food, Drug, and Cosmetic (FD&C) Act to include an "instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including any component, part, or accessory, which is ...intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, in man ... or intended to affect the structure or any function of the body of man..." and "does not include software functions excluded pursuant to section 520(o) of the FD&C Act."

2. This footnote is carried over from the FDA’s webpage: See FDA website on "Software as a Medical Device (SaMD)."

3. IEC 62304:2006. ISO. https://www.iso.org/standard/38421.html. Published 2006. Accessed February 4, 2022.

4. ANSI/AAMI SW91:2018 - Classification of defects in health software. Webstore.ansi.org. https://webstore.ansi.org/standards/aami/ansiaamisw912018. Published 2018. Accessed February 4, 2022.