Software in Medical Devices, by MD101 Consulting

Typical examples of multiple function device are platforms with software modules, within which some don't qualify as medical devices or are 510k exempted:
An even simpler case is a mobile app with some MD functions and some non-MD functions:

Impact of 510k exempt or non-MD

Qualifying software as a medical device is not the purpose of this guidance. Other FDA guidance documents are there to answer this absolutely not simple question.
This guidance focuses on the safety and effectiveness of MD functions / modules when they are coupled with non-MD or 510k exempt functions. Practically speaking, the FDA wants to now the impact of these functions on the MD function under review:

• Your MD function is coupled with other software,
• These other software may fail,
• As a side effect your MD function may also fail,
• The consequence of this failure on the safety and effectiveness has to be addressed.

Other function

The guidance defines the term "other function" as functions not regulated by the FDA, or not subject to premarket review (i.e. 510k exempt). The FDA also include General Purpose Computing Platform in this definition.
General Purpose Computing Platform: Rings a bell! It sound like SOUP from IEC 62304 or OTSS from other FDA guidance. This is true, this General Purpose Computing Platform can be a platform developed by 3rd party software editor, it can also be developed by the manufacturer without applying any appropriate state-of-the-art development process (i.e. IEC 62304 or FDA guidance on General Principles on Software Validation), namely the definition of SOUP.

But it can be more than that: this General Purpose Computing Platform can be a class I medical device 510k exempt, developed with appropriate standards according to design controls (820.30) by the manufacturer.
This could be the case in example 1, where the manufacturer could claim that:

• either the software platform is a MDDS or a Medical Image Storage device not regulated by the FDA,
• or it is a class I accessory to the MD module providing low-risk functions like data merging or alerts (not alarms!).

So the "other function" is software not subject to a premarket review.

Negative impact or positive impact of the other function.

The main message of this guidance is: the FDA wants the manufacturer to bring evidence that the other functions don't have a negative impact on the MD function under review. Taking a risk assessment wording, the negative impact is a sequence of events involving the other function that shall not be assessed as an unacceptable risk of software failure.

The second part of this main message is: if there is a positive impact on the MD function (e.g. the platform manages alerts), it shall be documented in the design control records. Finding positive impacts can be far-fetched with frameworks or OS'es. Usually, you chose a general-purpose computing platform because the technology is made like that (e.g. Android or iOS). Full stop. No positive impact there.
So if there is no obvious positive impact, don't waste your time seeking desperately for that one. If you have a positive impact, lucky you!

Note to EU manufacturers: don't mix that positive impact with the benefit of MD found in EU MDR. Please, don't cross the streams. It would be bad.

Is there an impact

The FDA proposes a flowchart as an help to assess the impact of other function. Though simple and not that much helpful, this diagram has the virtue to display the assessment process in a graphical manner.
More interesting are the examples of questions to ask when assessing the impact. They give cues to determine if and how the MD software exchanges data or shares resources with the other function. These questions are very technical and need to document the architecture of the MD software with its interfaces, like IEC 62304 clause 5.3.2.

What is the impact - A taste of SOUP

The guidance continues with recommendations on how to assess the impact when there is one. These recommendations look quite similar to what we do when we assess the impact of SOUP, like IEC 62304 clause 7.1.2.c. The advantage of the guidance is to give a list of questions to clarify the impact assessment. These questions can be advantageously used to identify and evaluate risk arising from SOUP.
Let's do a little exercise to show the analogy between other function and SOUP: replace "other function" by "SOUP":
E.g. #1 in section VI.B.1 bullet 1:

The “SOUP” introduces a new hazardous situation or a new cause of an existing hazardous situation that is not otherwise present in the device function-under-review

E.g. #2 in section VI.B.2 bullet 1:

The performance or clinical functionality of the device function-under-review depends on the “SOUP” for the device function-under-review to perform as specified.

Warning: it doesn't mean that "other functions" shall be treated as SOUP. It means that the process of risk assessment is similar. The big difference between the other function and SOUP is when the other function is a class I device not subject to premarket review. In this case this is not a SOUP, hence subject to design controls. But take note that the last paragraph about general-purpose computing platform before section VII looks very typical of SOUP risk assessment. More, when there is no evidence of design controls, this general-purpose computing platform will be treated as SOUP in IEC 62304 processes.

Cybersecurity

Ah, there it is! The cybersecurity risk assessment shall include the impacts of cyber risks arising from the other function. No surprise there, if a cyber risk can have a consequence on the patient, it shall be addressed in the impact assessment.

Separation of design and implementation

This is the second message of this guidance. Though separation of design is not so much discussed, compared to the negative / positive impact, the former is as important as the latter. Here we retrieve the good old principles of architectural segregation found in IEC 62304.
Our little exercise allows to show once again the analogy: replace medical "device function" by "class B (or class C) software" and "other function" by "class A software".

E.g. #1 in the sentence found in section V.A

The class B function should, to the extent possible, be separated from class A function in its design and implementation (e.g., logical separation, architectural separation, code, and data partitioning).

E.g. #2 in the sentence found in section VII.D

an architecture diagram may demonstrate the independence of the class B function from the class A function, or design documents may demonstrate the use of shared resources

It also works with the impact assessment with the sentence found in section VII.E

The device hazard analysis (...) for the class B software should include the results of a risk-based assessment of any potential adverse impact (...) of the class A software to the safety or effectiveness of the device function-under-review.

Thus, if your software is of major level of concern (or IEC 62304 Class C), be prepared to demonstrate in your premarket submission documentation how your MD software is separated for other functions. Namely by hardware segregation or by fully documented logical segregation with common failure modes analysed in the risk assessment report.
As a consequence, it won't work with web applications with intertwined services or monolithic mobile apps. Fortunately, a not so clear logical segregation may work with MD software in moderate level of concern (or IEC 62304 Class B), provided that other function failure doesn't result in an unacceptable risk.

Documentation requirements

In case of negative or positive impact, you have to add documents on the other function in the premarket submission, to begin with indications for use, device description and specific labelling for the other function. Then, practically speaking, you have to rely on the Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices. It means that you have to assign a level of concern to the other function. Then, the guidance doesn't require to bring all documents according to this level of concern for the other function. Only a subset is required, but their content shall be in line with the guidance on premarket submission for devices with software.

Having all ducks aligned

MD software under review, other function, OTSS, SOUP... Delineating the software components subject to premarket review, the other function, and combining that with OTSS/SOUP of IEC 62304 can be a challenging task! Some cases will be simple:

• A post-processing medical imaging software exchanges images with a PACS server (the other function),
• Software analyzing genetic data exchanges HL7 streams with a LIMS (the other function).

Some other case may be less simple:

• A module raising alerts to check for potential adverse drug events, based on patient data, is included in a larger Computerized physician order entry (CPOE, other function),
• A legacy health information system (HIS, other function) contains some functions qualified as medical devices, intertwined in the system.

Some cases may be a nightmare:
When the other function contains the mitigation action of an unacceptable risk. What should we do? Leave it as other function? Include it in the software under review? This will be a case-by-case answer.

Conclusion

It is quite practical for manufacturers to split their software platform in MD software and other function, allowing to reduce the regulatory burden. This guidance puts an end to the situation where manufacturers legitimately exclude from their submission software not subject to premarket review, leaving blind spots in the submission. And blind spots are the reason for countless questions from the FDA!
By requiring to document in their submission the pedigree of other functions, the FDA ceases to be blind and will be able to assess in a more straightforward way the MD software integrated in its technical environment. There is a drawback for manufacturers: they are forced to document the architecture and the risk assessment of the other function in the premarket submission.




1st EU MDR oriented remark: In the absence of such guidance for the EU MDR, make use of the principles of the FDA guidance when you have a part of your software not qualified as SaMD per MDCG 2019-11. It is a way to answer to general requirements 14.2.d, 14.5, 17.3, and 23.4.ab.

2nd EU MDR totally grumpy and non-constructive remark: don't expect any equivalent guidance from EU MDCG for a long time. FDA is the horizon of other authorities for software, as usual.