Software in Medical Devices, by MD101 Consulting

The title matters: the FDA regulates SaMD, SiMD, unifying them under the umbrella of Device Software Functions. We already saw that in the Multiple Function Device Products: Policy and Considerations guidance. The title and the content of this draft guidance is consistent with the content of that other guidance. Especially, the appendix B at the end of the draft guidance give quite good examples on how to document health software with device software functions.
This draft guidance is also referencing all the other guidances linked to software in section II Background. It is actually a good starting point to know what the FDA expects from manufacturers about software.

Definition of Serious Injury

Let's do a focus point on the definition of Serious Injury given by the FDA. It is simply the definition found in the 21 CFR 803.3 (w). It is equal to the one in the current guidance, also quoting the 21 CFR 803 (to be specific, an old version of 21 CFR 803). No change there, and there is no discrepancy compared to the definition found in IEC 62304. That's important to underline it, before reading the rest of the document, with the goal in mind to apply this guidance and IEC 62304 seamlessly.

Software validation

A note also on software validation definition. The one in the draft guidance is undoubtedly better than the one found in IEC 82304-1: confirmation, through the provision of objective evidence, that the requirements for a specific INTENDED USE or application have been fulfilled. Advantage: it is short; drawback: it is laconic. The definition found in the draft guidance draws the link with design controls, and gives cues on how to perform that software validation.
Reminder: there's no such definition in IEC 62304, which limits its scope to software verification, not validation.

Documentation level

Here we are in the interesting part of this draft guidance!

The three levels of concern are whipped out, and replaced by a twofold documentation level:

• Basic Documentation Level (BDL) and,
• Enhanced Documentation Level (EDL).

The criteria to evaluate whether a software is in EDL have evolved compared to those present in the determination of the Major Level of Concern of the current guidance. Fortunately, the criterion accessory to a device of major level of concern disappeared; a criterion difficult to apply to SaMD, which raised more questions than it gave answers!
But the other criteria are similar in both versions of the guidance, with an effort to make them more articulate in the draft guidance.

Thus, we have the following strict correspondance between Level of Concern and Documentation Level:

• Major Level of Concern --> Enhanced Documentation Level,
• Moderate or Minor Level of Concern --> Basic Documentation Level.

Likewise, since the definition Serious Injury present in the IEC 62304 is equivalent to the one in the 21 CFR 803.3(w) section, we have a almost strict correspondance between Software Safety Class and Documentation Level:

• Class C --> Enhanced Documentation Level,
• Class B or A --> Basic Documentation Level.

Provided that the software intended use matches factor #4 only. A quite common situation, there aren't so many software in combination products, or blood bank products, or class III devices, compared to all types of software placed on the market.

Risk Control Measures

One ambiguity remains in the factor #4 present in the draft guidance. It's written: These risk(s) should be assessed prior to implementation of risk control measures. It would be better either to rephrase it or to explain in the text under the list of factors that the risks are assessed prior to implementation of risk control measures in software.
Removing this ambiguity would be more in line with the concept of essential performance present in IEC 60601-1. A software doesn't contribute to the essential performance when a hardware risk control measure is present to prevent a hazardous situation coming from a software failure. Likewise, we have the same approach in the chart of IEC 62304 Amd1:2015 clause 4.3, where we evaluate the acceptability of risks, after application on risk control measures external to software.
For the record, the same ambiguity is present in the currently applicable FDA guidance.

Probable risk

The term probable is used in factor #4: A failure or latent flaw of the device software function(s) could present a probable risk of death or serious injury. Then, under the definitions of factors, the guidance adds: The term ‘probable’ in factor #4 above is intended to capture reasonably foreseeable software and hardware risks associated with the device.
That's also somewhat aligned with the chart of IEC 62304 Amd1:2015 clause 4.3, which considers the acceptability of risks. A risk that isn't reasonably foreseeable will leave the software in basic documentation level. Such a risk is usually acceptable (or tolerable) according to a risk management plan, thus leaving the software in class A, according to IEC 62304.

Discussion on the software documentation level

Changing the number of levels, either Level of Concern, or software safety class, isn't a new debate. The options being regularly debated are:

• 4 levels, aligned with the IMDRF Possible Framework for SaMD risk categorization, and the good old GHTF Principles of Medical Devices Classification,
• 3 levels, staying in the current practice. We don't like when things change,
• 2 levels, like in this draft guidance. Exit class A / Low Level of Concern,
• No level, every software is documented like class C / Major Level of Concern!

Some discussions popped out on some social networks, to propose that all software shall be documented like class C software. I don't subscribe to this. This is flawed for two reasons. First objective reason: this is not in line with a risk-based approach, obviously present in the regulatory classes. Second subjective reason: I think this is a bias of people who don’t have enough experience in software development.

Four levels raises the question on the amount of documentation to provide for each level. IMDRF levels I to III could be aligned with IEC 62304 classes A to C. IMDRF level IV would be a kind of IEC 62304 class C+ (or C++ :-)). That fourth level would require a very thoroughly documented design with a clear demonstration of safety and performance, with full horizontal and vertical traceability, like safety assurance cases. This is by the way what the FDA recommends for infusion pumps. Neither IEC 62304, nor current FDA guidances (excepted for infusion pumps) require explicitly such level of scrutiny in the design documentation for highly critical software.

Two levels have the virtue of simplification. Keeping the equivalent of classes B and C, and removing class A isn't a wrong choice (I didn't write this is the right one). The cybersecurity requirements advocate for the removal of class A. Applying UL 2900-x or IEC 81001-5-1 standards require to document the architectural design, and at least the detailed design of interfaces subject to cyber hazards. Likewise, the advent of multiple function devices also advocates for some architectural documentation, which goes beyond pure class A documentation, to understand where the medical device functions reside.

I'd personally be in favor of having 4 levels, aligned with the IMDRF, and aligned with the regulatory classes of the majority of regulations throughout the world. However, this solution is obviously not aligned with the US regulatory classes, and the twofold choice of this draft guidance. By the way, the DO-178C defines 5 levels, but this is another industry.

Differences with IEC 62304

Even if the FDA wants to set their own standards, manufacturers submitting their devices elsewhere than the US, have to rely on the IEC 62304 at the same time. We can try to find the differences between the clause 5 of IEC 62304 and the section V of the draft guidance.

Documentation level evaluation

Even though the criteria differ, the concepts are similar and shall be documented.

Software description

This looks more like what we have in IEC 82304-1 clause 4. However, the FDA expects this both for SaMD and for SiMD. IEC 82304-1 is not applicable to the latter.

System and Software Architecture Diagram

Similar to clause 5.3 of IEC 62304, the wording of the draft guidance is a bit different. It uses the wording module and unit, whereas IEC 62304 uses software item and software unit. These are somewhat similar concepts, with the notable difference that the FDA includes hardware components in these terms. Moreover, modules are generally considered of bigger size than software items. A software item can be a module, but a module-software-item can be decomposed in smaller software items.
However, it is possible to document the architecture the way it is recommended, like in the examples at the end of the draft guidance. Such diagrams can be used both for FDA submissions and IEC 62304 architectural decomposition.

Risk management file

Here, nothing to say, apply ISO 14971 and IEC 62304 clause 7. You will be in line with what is required by this long section of the draft guidance. It should be noted that the draft guidance quotes the IMDRF SaMD risk categorization for identifying and evaluating software risks.

Software requirements specifications

Not surprising, the draft guidance contains recommendations similar to IEC 62304 clause 5.2. However, the FDA goes beyond the standard, by suggesting the use of well elaborated stories, use cases, textual descriptions, screen mockups, and control flows.

Software Design Specification

Software Design specification is required for Enhanced Documentation Level only. We can draw a link with IEC 62304 clause 5.4, where the inner content of software units shall be documented in class C. It is worth noting (funny to note) that the FDA recommends to document SDS prospectively and not retrospectively! Software development teams will appreciate this recommendation.

Software development and maintenance practices

That's... interesting that the FDA relies on the IEC 62304 for this. Whereas the guidance completely overrides the standard, it bounces back to the standard on development and maintenance plans. But why not. A premarket submission is a review of the device design output, not the design history file. The design process is reviewed during FDA inspections.
That’s also why the order of paragraphs in section V is different from the subclauses 5.x of IEC 62304. This guidance is made to let the FDA understand how the software design allows to achieve the claimed safety and performance. The FDA puts the emphasis on readability throughout the text of the draft guidance.

Software testing as part of Verification and Validation

There we retrieve the requirements of clauses 5.5 to 5.7 of IEC 62304 in class B and class C on software testing. However, it is worth noting that the draft guidance has no equivalent of IEC 62304 clause 5.5.4. That was already the case in the current guidance.

Revision level history

The revision level history is present in an indirect manner in IEC 62304, through clauses 8.3 and 5.8. Here the FDA emphasizes that when iterative development methods are used, information on any changed software requirements and how they continue to meet the system requirements or design inputs should be provided. Not a game changer, but not present in IEC 6204.

Unresolved anomalies

There we retrieve the equivalent of IEC 62304 clause 9, to be able to provide such design output. Particularly, FDA suggests ranking anomalies based on risk to patient and/or operator (user), something required by the problem resolution process.

COTS - SOUP

Last thing, SOUP! The FDA just say they're going to update their guidance on COTS: Off-The-Shelf Software Use in Medical Devices. From an IEC 62304 perspective, this guidance requires additional documentation, compared to what is required in the standard. The guidance will remain applicable. So, not a game changer.

Conclusion

This guidance is a draft guidance. Things may be reverted back to three levels of concern, if lots of people post negative comments to the FDA. But this is wishful thinking. The guidance is well thought out. It looks like the FDA spent some energy to create this twofold documentation system. Add multiple function devices plus cybersecurity, and there is very little chance that the FDA fundamentally changes its content.

IEC 62304 committee, forewarned is forearmed.