What the FDA's new draft software guidance tells us

    November finally saw the release of the FDA's new draft guidance on premarket software submission content.

    "Content of Premarket Submissions for Device Software Functions" is the first update to the FDA's stance on medical software submission for 16 long years, driven in their own words by the 'rapidly evolving nature of digital health' and the commitments made in the MDUFA IV negotiations.

    The draft guidance was initially scheduled for release in fiscal 2019, with publication presumably pushed back by the challenges of COVID-19.

    Now it's arrived, I've taken a look and shared my thoughts and findings.


    It's part of a trend


    The draft guidance is part of a string of planned software-focused releases from the FDA over the coming months.

    In fact, 25% (4 of 16) of the FDA's 'A-list' of priority planned guidance documents for 2021-22 concern software.

    Other software-centric releases will focus on clinical decision support (CDS) software, medical device cybersecurity, and computer software assurance for production and quality system software. (One for me to keep an eye on.)

    This new focus on software is welcome. Software has been broadly lumped in with hardware under the medical device umbrella for years, despite functioning in markedly and increasingly divergent ways.

    Sharpening the focus on software shows that the FDA is attempting to keep pace with the increasingly digital nature of medical device innovation: wearable, predictive, electronic and AI- and blockchain-driven devices are a rapidly expanding area.


    Sidekick Health app

    Exciting times for SaMD: gamified, behavioral, AI-driven digital health from our customer Sidekick Health


    The nature of the draft, coming as part of this flurry of software guidance, is interesting in itself too: aside from a few sections on revisions and verification, barely any of the current 2005 guidance survives.

    Above all, the draft and its accompanying associates show that regulatory demands are tightening for medical software, as we'll see below.


    Target: medical software manufacturing organizations


    The draft guidance focuses on two targets, and defines them for the first time in an FDA guidance document:


    1) Software as medical device (SaMD)

    Medical software which operates independently without being part of a connected piece of hardware


    2) Software in medical device (SiMD)

    Medical software which forms a constituent part of a hardware system


    Electronic life science quality systems like Qualio, automated manufacturing software, and software which isn't a device do not fall within the guidance scope.

    But any:

    • Standalone software applications
    • Software systems on a general purpose platform
    • Firmware for software-based medical device control
    • Medical devices and medical device accessories supported by software

    will be affected by the guidance when it goes live.


    FDA draft guidance


    It's risk-based


    The existing 2005 guidance categorizing devices by Levels of Concern is being replaced.

    You'll now need to ask yourself 4 key questions (rather than 12) to determine your level of operational risk and whether the guidance's new Basic or Enhanced documentation requirement levels will apply to your company:


    1) Is your device a constituent part of a combination product?

    2) Is it Blood Establishment Computer Software (BECS), or intended to test transfusions or determine donor-patient compatibility?

    3) Is it a Class III device?

    4) Would a flaw or failure in device operation bring a reasonable chance of serious injury or death?


    If you can answer 'no' to all of these questions, the Basic level of documentation will apply and your business should prepare all typical documents connected to a premarket submission like a 510(k), De Novo Classification or PMA.

    That means:

    • Software requirements specification (SPS)
    • Risk management file
    • Design and maintenance information
    • Description of features, analyses, inputs and outputs
    • Validation, testing and revision level histories
    • Unresolved anomaly list
    • An evaluation justifying your document submission level

    If you answered 'yes' to any, your device falls into the Enhanced bracket and an extra layer of content will be required as follows:


    • Software design specification (SDS) outlining how your software meets its terms of intended use, functionality, safety and efficacy
    • An IEC 62304 Declaration of Conformity OR lifecycle development plan summary + complete configuration management and maintenance plan documents
    • Unit and integration level test protocols including expected/observed results, pass/fail determination, unit and integration level test reports


    This all raises some interesting findings.

    Since IEC 62304 launched in 2006, it doesn't appear in the current guidance from 2005 - so its inclusion in the new draft is a welcome addition for organizations already working to its requirements.

    The FDA also intends to update its Off-the-Shelf Software Use in Medical Devices (OTS) guidance to replace Levels of Concern with this Basic and Enhanced format, suggesting this two-tiered risk approach is here to stay.

    But even so, the FDA seems to be raising the bar and treating more and more software as high-risk.

    Take the first Enhanced categorization, for instance: if your device is a 'constituent part of a combination product'.

    FDA 21 CFR 3.2 (e) defines a combination product as having two or more regulated components, i.e.:

    • Drug/device
    • Biologic/device
    • Drug/device/biologic

    SaMD or SiMD with a pharmaceutical component will therefore fall into the Enhanced category by default - a fairly general raising of the regulatory hurdle.

    Not very surprisingly, I'm seeing the most grumbling from quality professionals in these combination product groups. They don't want to apply design controls to the drug component, and they don't think these new strict software controls are needed either. 

    It feels onerous to have to line out every single risk and function of your medical software product once this guidance goes live.
    But only in this way can you document your rationale to NOT have to test every single element of your product and development processes. And it's also a good exercise to prevent bigger issues later: you can't possibly consider your entire risk environment in one attempt, and more than one 'gotcha' once you're in-market can kill your company. 
    Critically, even if you feel you belong in the Basic document category, you can't possibly justify this stance without having documented your entire software infrastructure anyway - from the product itself, through to system and architecture and data flow.
    These elements are so often just skipped or assumed at a very basic level. The FDA is sending a clear signal to start considering and documenting them in a consistent and conscious way.

    As the Quality Director of a quality software provider, one last thing jumped out at me.


    Your QMS is key


    The guidance puts risk analysis and validation front and center.

    That means documented elements of your quality management system dealing with these areas must be bundled into your premarket submission process in a way they wouldn't have to be with a traditional medical hardware 510(k) submission.

    The guidance therefore places new emphasis on a properly controlled and documented quality management system.
    Many QA professionals in the space have been pushing for deeper documentation from their development teams for a while now - but have often experienced pushback because it feels like 'too much documentation' for a software engineer.
    The FDA's fresh requirements bring an end to software as an afterthought and can only be met with ever-closer integration of quality and engineering teams.




    I attended a recent FDA webinar on the draft guidance, where some valuable audience questions were answered by the FDA presentation panel:


    "I'm halfway through my premarket submission - should I start following the new guidance?"

    Until the new guidance goes live, probably at some point in mid-2022, the current 2005 guidance remains in effect - and so you should continue to follow it.


    "If I'm looking at predicate 510(k) submissions for substantial equivalence after this guidance goes live, how do the old Levels of Concern align with the new 2-tier structure? Will 'Minor' and 'Moderate' become 'Basic' under the new guidance?"

    We can reasonably expect most Minor and Moderate LoC submissions to align with the 'Basic' structure of the new guidance, but it's by no means a straight translation.

    Some Moderate submissions may fall under 'Enhanced', for instance. The FDA recommends going back to the original device submission factors and reappraising from the beginning, rather than simply assuming.


    "Why are the third and fourth factors for determining the document level different? A Class III product is one that would cause serious injury or death if it malfunctioned, so they sound the same to me."

    The FDA wants to capture all risk possibilities rather than adopting a blanket approach. A Class II device, such as a ventilator, could still cause injury or death if it failed to work properly. The 4 questions ensure nothing slips through the net in this regard.



    So what happens now?

    The FDA is receiving comments on the new draft until February 2nd, 2022.

    Submit your comments here!