New FDA Software Guidance - Here We Go Again

Our guest medical device experts this week are the British hair band Whitesnake. Thinking about the new FDA software guidance relative to the current one, they sum it up in the first line of the song. "I don't where I'm going but I do know where I've been." and then the chorus "Here I go again." (My hair does not look like that.)

In 2005, Houston lost the World Series and the FDA released the wordy title "Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices". (deep link)

In 2021, Houston lost the World Series (Go Braves!) and the FDA released the less wordy title "Content of Premarket Submissions for Device Software Functions" (Draft) which when it is fully released will replace the 2005 version. (deep link)

There is a seminar with FDA on the new draft guidance in December. (deep link)

I was in the Medical Device software business in 2005 so I have been living with the old one so long I can recite most of the key tables and decision questions without pulling it up. How will I adjust?

Scope

In the introduction the new draft guidance mentions Software in a Medical Device (SiMD) and Software as a Medical (SaMD) so I started to think this guidance was maybe going to move us more into the Internet of Things (IoT) for Medical Devices. However, when you get into the scope we are still in 2005. The scope for both documents is exactly the same.

• firmware and other means for software-based control of medical devices

• stand-alone software applications

• software intended for installation in general-purpose computers

• dedicated hardware/software medical devices.

• accessories to medical devices when those accessories contain or are composed of software.

Actually, no, not exactly the same, in 2005 the last word of bullet 3 was 'computers' and in 2021 it is 'computing platforms'. That does seem slightly more modern but not too much of a jump.

No Longer Concerned

The Level of Concern analysis; Major, Moderate and Minor? Gone! We are left with Basic and Enhanced Documentation Levels. In a nutshell, Minor was eliminated and we are left with Moderate = Basic and Major = Enhanced. Here are the criteria to get to Enhanced in the 2021 draft guidance.

• The device is a constituent part of a combination product

• The device (a) is intended to test blood donations for transfusion-transmitted infections; or (b) is used to determine donor and recipient compatibility; or (c) is a Blood Establishment Computer Software.

• The device is classified as class III.

• 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.

Recall that the threshold to get to Major level of concern was also direct or indirect risk of 'death or serious injury' and the threshold to get to Moderate was 'minor injury'. My reading is that formerly Moderate software would be Basic unless you fall into the first 3 bullets.

As a side note, it is probably rare that one would work on Class III device software that was a Moderate Level of Concern under the 2005 guidance. However I did work on an implantable diagnostic device where there was no software in the implant. That software will likely move from Moderate to Major now since the entire system is Class III. That does not seem right since a failure of the software could not reasonably result in serious injury or death.

Comment #1 - Basic vs. Enhanced should be driven by the risk posed by the software not the overall system classification. (I plan on submitting these comments to FDA.)

Recommended Documents

Once you know if you are basic or enhanced, the 2021 draft guidance details the required documents. I will only focus on the changes since 2005. Below is a comparison of Table 1 in the 2021 draft guidance with Table 3 of the 2005 guidance.

Minor to Basic

If you were minor level of concern, you will need to add several more things under basic documentation level.

• System software architecture design chart

• Full software requirements up from only a summary of requirements

• Summary of the life cycle development plan

• Summary of configuration management

• Summary of maintenance activities

• *OR* Interestingly the previous 3 bullets could be replaced by a declaration of conformity to IEC 62304 (But don't be fooled that there really is a tradeoff, Class A 62304 software needs all 3 of these 3 things. This is Comment #2, that there really is no *OR* here.)

• Summary of unit and integration testing

• Unresolved anomaly list

Honestly, though, these things are all a part of good software discipline so it should just be a matter of submitting them now.

Moderate to Basic

If you were moderate level of concern, then there is not much change.

• Subtract software design specification

• Could optionally add a declaration of conformity to IEC 62304

Major to Enhanced

The names of the documents are basically the same but there is one big change in document content.

• Software Design Specification (SDS) is now expected to contain "how the software design completely and correctly implements all the requirements of the SRS" which is much more involved than the previous "the SDS describes how the requirements in the SRS are implemented". Pause for a freak out here. My experience is that it should be extremely flexible for the software development team to document the architecture and design up front and also as implemented. Doing it up front means using flexible drawing tools like Visio and flexible document tools like Word. Documenting the as implemented design means using code based tools like Doxygen. On the flip side, doing full traceability from requirements to design means using a tool like Doors or Jama. In my experience, these tools are not flexible and do not play easily with drawings. Appendix B has software requirements in the software architecture charts. I could see how that would help a reviewer get oriented but it cannot be exhaustive for a project with hundreds of software requirements. Adding some key requirements in the architecture is fine though. Comment #3 - Do not burden flexible design with full SRS to design traceability. This introduces a major new burden on the teams. End freak out.

Risk Management

The 2005 guidance used the terminology "device hazards analysis". That terminology is replaced by "risk assessment" which is more in line with ISO 14971. Also note that the columns in the risk assessment now add risk evaluation for risk acceptability (only yes/no) pre and post control measures. There is also a discussion risk benefit for any residual risks. Strictly speaking the 2005 guidance did not even ask you to evaluate the risk.

Note To The World! The 2005 guidance and the 2021 draft guidance do not ask you to estimate occurrence for software. Period. That is correct! Just because the company DFMEA template or the DFMEA software tool have occurrence for other types of hazardous situations does not mean you need to do it for software. Please do not make us set occurrence to 100% and then require some justification why low severity software hazards are now evaluated at high or critical risk. Arrrggghhh!

Document Element Descriptions

The descriptions of what goes into each of the documentation elements is much more detailed in the new draft guidance. The 2005 guidance describes all of the documentation elements in a little over 4 pages. The 2021 draft guidance takes 13 pages. In general, I am a fan of more detail. There are examples in the Appendices too which is helpful.

In the additional detail there is nothing that seems overly burdensome besides the full software requirements to software design trace I mentioned above.

Small quibble. I don't think that the programming language and compiler version goes in the software requirements document. Software requirements are about design input, that is to say, what is the software supposed to do. The software design is about how the software is going to do it (they even say that on line 616 of the 2021 draft guidance). Compiler version seems particularly silly since you will release the requirements fairly early in the design process and the compiler version is likely to change several times after that. I would even vote to put it in the software release document with the final binary. As I said a small quibble, I doubt FDA would reject a submission if the compiler version was documented somewhere other than the software requirements.

Comment #4: Programming language and compiler version do not belong in the SRS.

Back to my freak out above about the software design specification. What does this mean regarding the SDS? "how the software design traces to the SRS in terms of intended use, functionality, safety, and effectiveness". Functionality I understand but should we justify the use of a certain class inheritance pattern with respect to intended use, safety and effectiveness? Clearly, I am struggling with this. Hopefully, they make it more clear as the comment period goes on.

Very small quibble. For the revision level history it says "The last entry in the list should be the final version to be incorporated in the released device." I prefer to put the revision history in descending order so you don't have to search for the recent stuff.

What about IEC 62304?

Section C seems to try to justify why FDA still bothers with their own software guidance. Most medical device companies that I know use IEC 62304 as the basis for their internal procedures and work instructions. It would have been nice if the FDA had made the self-certification to IEC 62304 sufficient to meet FDA requirements. In general, though, I think IEC 62304 does. I have not done a line by line comparison yet but with the exception of the full trace from software requirements to software design which is not present in IEC 62304 this new draft guidance is a subset of IEC 62304.

Starting at line 863 of the 2021 draft guidance, they say that self certification to IEC 62304 reduces the amount of documentation. I discussed that above. It doesn't since IEC 62304 has the same things.

Summary

As Whitesnake says, "Here we go again." The 2021 draft guidance is not a major departure from the 2005 guidance with a few exceptions: minor level of concern was eliminated, it brings the guidance up to modern ISO 14971 standards with respect to risk assessment and then the burdensome full trace from SRS to design. Here we go again!