New FDA guidance on OTS use in MD

tazer

Involved In Discussions
Hi all,
FDA has published a new update of the https://www.fda.gov/media/71794/download guidance.
Compared to the previous one, I am confused about the determination of the level of documentation (LoD) for an OTS.
Previously, the LoD was determined by the level of risk involving the use of OTS. this means that if I use an OTS to display funny images, without any impact on security, safety and performance, in a device for which Enhanced Documentation should be provided, I must also provide Enhanced Documentation for this OTS (Section III.D)
in other words, now the LoD of an OTS seems to be inherited from the LoD of the device.
Any Thought?
 

Tidge

Trusted Information Resource
There is nothing shocking about the guidance, the only difference between basic and enhanced documentation levels for OTS software included in a medical device is that for enhanced level it is required to provide (my emphases):

Information to provide an assurance that the product development methodologies used by the OTS software developer are appropriate and sufficient, and mechanisms exist for assuring the continued performance, maintenance, and support of the OTS software.

This guidance is aligned with previous/recent ones, it is just explicitly recognizing that if OTS software is used, and the enhanced level of documentation is called for, the manufacturer using the OTS has an appropriate level of assurance that the OTS portion will be maintained and supported.

In other words: for certain applications it won't be acceptable to simply find some software library and just hope that it works and hope that there might be a path forward for correcting identified defects by shrugging it of as "don't look at us, it is OTS."

In the previous "Level of Concern" (Minor/Moderate/Major) era it was a straightforward and non-problematic approach to bluntly treat the software components of a device as inheriting their LoC from the finished device... but this was (IMO, influenced by my personal experience) almost entirely due to a reluctance on the part of developers to have a coherent architecture that cleanly allocate (and segregate) functions according to risk (in the old FDA paradigm, LoC)... and once a complicated code base exists, there is often little appetite to explain (in a coherent manner) which elements of the architecture legitimately have a lower LoC.

There was (and probably still is) some daylight between Software "LoC/LoD" and Risks associated with Finished Goods... but there is a sort of "red-faced question" that comes to my mind: Why does this important medical device have these components (e.g. "funny images?") that aren't supporting the Essential Performance of the device? I grok the desire to add on 'nice-to-haves', but such things ought to be cleanly segregated in terms of the architecture... which ought to make it easy to explain the documentation paths.
 

tazer

Involved In Discussions
Thank you Tidge for answering.
All software functions do not necessarily support basic safety or essential performance, some are implemented for ergonomic, commercial or simply aesthetic purposes. If the segregation between items is correctly installed, the 62304 standard allows to classify these functions differently, this also applies to OTS (SOUP).
According to the previous version of the regulations, the decision on documentation required is defined by the LoC of the OTS.
With the current versions, I have the impression that we can no longer isolate the OTS from the rest of the software.
Therefore we can no longer use, for example, an external library which has not already been registered (with of a MAF) or for which we do not have the necessary documentation. The consequence is using OTS non designed for MD is prohibited

That's my understanding of the section III.D-1:
Provide assurance to the FDA that the product development methodologies used by the OTS software developer are appropriate and sufficient for the intended use of the OTS software within the specific medical device. For example, this may include a review of the OTS software developer’s design and development methodologies used in the construction of the OTS software. This review should thoroughly assess the development and qualification documentation generated for the OTS software. If such an assurance is not possible, and if the residual risk evaluation of the hazardous situation after implemented risk control measures is not acceptable as defined in the risk management plan, the use of such OTS software may not be appropriate for the intended medical device application.
 

Tidge

Trusted Information Resource
With the current versions, I have the impression that we can no longer isolate the OTS from the rest of the software.
Therefore we can no longer use, for example, an external library which has not already been registered (with of a MAF) or for which we do not have the necessary documentation. The consequence is using OTS non designed for MD is prohibited

Do you mean that you cannot remove the OTSsoftware and the device will not meet essential performance, or do you mean that the current documentation is where you cannot "isolate" what the OTS software is doing?

If the product meets essential performance and safety without the OTS software (and the OTS software introduces no new risks), I think the path is reasonably clear (and likely to be as easy as you would prefer it to be, in terms of effort).

If the documentation suite has been such that there is no obvious segregation of functions and components... things might be harder to explain in a new submission. If there is no new submission and there is nothing drawing new regulatory attention, I wouldn't worry too much about this, except for internal business reasons (relating to support throughout the product's market life-cycle).

What follows is pure speculation:

If there is a new submission; the agency may have questions specific to this guidance, at which point you will need answers and documentation to support those answers. It is entirely possible that a reviewer asks a question on a new guidance simply to measure how manufacturers are implementing the latest guidance. Software (especially OTS) is likely to be an area of interest because of mandate to take cybersecurity seriously. The directives of the OTS guidance fit nicely with concerns about Software Bills of Material (SBOM).
 

sreelal

Registered
If your device has a safety monitor software/hardware subsystem independent of the primary system, then you can use it to mitigate OTS risk mitigations. You can use that major rationale for the OTS risk mitigations and continue the use of the OTS.
 
Top Bottom