Software in Medical Devices, by MD101 Consulting

Remark: examples in this article are given for Javascript or Typescript (npm). It also works with Python (pip), Ruby (gems), PHP and other languages (I'm sure there are plenty of them).

Third party software inventory

Cloud applications have by definition a back-end, they have a front-end if they have a GUI. Let's make a quick inventory of the libraries, frameworks that we can find throughout the stack.
Please take note that I don't talk about SOUP yet.

Back-end

In the back-end, we find the services developed by the MD software editor. As third party software, we find:

• A framework used to build these services e.g.: Express,
• A database, e.g.: MongoDB, MySQL,
• Generic services like message queuing e.g.: RabbitMQ,
• Also libraries delivering specific functions you chose to implement your software,
• Probably other things present in your dependencies JSON file,
• Some security control of different nature, like CORS or IAM
• The Docker runtime, combined with Kubernetes,
• The operating system,
• And possibly support services, like Google Cloud Logging or Amazon Cloudwatch.

Outside software, we almost forget the hardware running all this stack. It's more and more frequent to have no clue about the hardware, and even the operating system, which our software is running on.

The cloud platform vendors are in permanent competition to offer a myriad of services present off-the-shelf. You don't have to install them and you just instanciate them. For example with AWS RDS (Relational Database) allowing to choose between several database engines and IAM taking care of authentication. Even if you don't install them, they count as third-party libraries.

Front-end

On the front-end, we find the web application framework. E.g.: React JS.
Just don't forget the client host: the browser and the OS. A bit like the back-end, you rely more on the type and version of the web browser, than the underlying OS. Namely, you rely on the behavior of a given browser version running on a given list of OS.
The front-end can also be a mobile app, with the mobile OS, its framework, and possibly other libraries like a third-party cross-platform framework.

Differentiate infrastructure, OTSS and SOUP

Back-end

This inventory is fine, but it mixes apples and oranges. We can separate it in:

• SOUP : third party libraries used at runtime to have your software deliver its medical purpose,
• OTSS : third party libraries or executables not mandatory to run your software, non-functional services, like monitoring, logging,
• Infrastructure : other software or hardware, provided by the cloud service provider, usually invisible from your software.

Below a diagram giving a representation of a typical back-end architecture:


It's not made to be accurate but to give an idea of what to place in SOUP, in OTSS, and in infrastructure.

In this example, we have third party items that are SOUP, others are OTSS, and some others are infrastructure.
SOUPs are those with a direct relationship with your software:

• Either they're incorporated in your MDSW (the SOUPs present in the blue box in the diagram),
• Or they're present off-the-shelf in the cloud services and your MDSW invokes directly their API (the DB container, for example).

Conversely, other third-party software not seen by your MDSW aren't SOUP. They're part of the infrastructure not managed by you. Third-party software used or invoked by SOUPS are sometimes called SOUPs of SOUPs. There is a controversy on whether they should be in the scope of IEC 62034 SOUP definition or not.
A bit of risk assessment is usually enough to place them out of SOUP category. Risks related to this kind of software are usually reduced to an interruption of service, something acceptable for MDSW (unless you develop a close-loop over the internet :-)).
Otherwise we can continue with SOUPs of SOUPs of SOUPs, and so on. It wouldn't take long before we dig oil.

Last, OTSS are independent software which don't contribute to the performance of your MDSW (for example, some monitoring tool used by IT administrators like Zabbix).

It can be hard for some components to place them in the right category. For example, an authentication service: SOUP or Infrastructure or OTSS? This is a service delivered by the cloud provider (infrastructure), it can be directly invoked by your MDSW (SOUP), but it doesn't deliver any clinically relevant function (OTSS). The decision to place it in one or another category depends on the context.

Front-end

On the client side, things are easier, there's no infrastructure, and there's usually no OTSS. For web apps, the OS, the browser are SOUP. For mobile apps, the OS, the framework, the libraries are SOUP.

How to manage them?

Different categories mean different types of activities to perform.

SOUP

SOUP are under the scope of IEC 62304. "Just" manage SOUP according to IEC 62304.
One question is the architectural representation of all SOUPS. You can have something like one hundred lines in your dependencies JSON file. Documenting all these tiny libraries can be burdensome and seen as a loss of time by software development teams.

• Solution 1: Put them all in a SW item called "xxx framework", where xxx is the name of the language, of the technology. In this way we have all the SOUP in bulk. But an IEC 62304 auditor will say you don't teach an old dog new tricks, you can't make a big load of SOUP SW units into a single SW item.
• Solution 2: We refine the architecture, to reveal each SW unit and each SOUP. In this way, we make all the SOUPs appear in a very fine grained representation. But the developer will say he has no time to be jerking around, he does not have time to manage this pile of documentation.
• Solution 3: We refine the architecture for the SOUPs used by a single SW unit, and make a SW item named "xxx framework" containing all the SOUPs, which offer transversal services. In this way, we satisfy the auditor who leaves quite happy with his documented evidence of IEC 62304 clause 5.4.1 and we satisfy the developer who in a half-smile grin will express his satisfaction at being able to continue developing without spending too much of his life documenting things that they find boring.

Such a life.

OTSS

OTSS are under the scope of QMS software requirements, either 4.1.6 of ISO 13485, or 21 CFR 820.70.i automated processes. Thus, outside of IEC 62304 claws. They shall be validated according to guidances like IEC/TR 80002-2 or AAMI TIR 36.
Sad news, quality managers will have to rely on software development teams to validate these OTSS. They develop or assemble OTSS around the MDSW and their knowledge is required to document OTSS validation.

Infrastructure

Infrastructure is all the rest, not seen and not controlled by the MDSW editor. It comprises the hardware and software parts. Not controlled by the MDSW editor doesn't mean not controlled at all. Infrastructure is subject to requirements on ... infrastructure: section 6.3 of ISO 13485 or 21 CFR 820.70.e Environment control. The cloud service provider is subject to purchasing requirements: clause 7.4 of ISO 13485 or 21 CFR 820.50.
There, we are far from IEC 62304. That sounds right, we are far as well from the MDSW source code.

SOUP software safety class

If your software is in class B or C, unless you have good architectural justification, SOUPs will be in the class of your MDSW. In the diagram above, it's hardly feasible to have the blue MDSW in class B, and the SOUPs inside it in another class. A failure in the SOUPs will propagate inside the blue area. Likewise, even if the SOUP DB container is totally separated, a failure in the SOUP DB will lead to a loss of or corruption of data, and possibly wrong information presented to the user leading to a delay in the appropriate medical care.
Thus, you will have hard times to place SOUPs in a lower software safety class when:

• They're intertwined with your source code,
• They deliver a service with an impact on data.

On the contrary, authentication, containerisation, load-balancing SOUPs (if you don't place them in the infrastructure) will only lead to interruption of services, without any impact to the patient (in most cases of course). Thus, it is possible to place them in class A.

SOUP anomalies, changes and obsolescence

With dozens of libraries used by your MDSW, a tool like NPM is your friend to manage SOUP lifecycle according to IEC 62304. Especially clauses 6.1.f and 7.1.2.c.

Risk assessment

Clause 7.1.2 about identification of hazardous situations coming from failure or unexpected results from SOUP is not required in class A. So you have a vested interest to isolate SOUPs in class A.

Anomalies and obsolescence

OK, we have a tool like NPM. But is doesn't tell us how we monitor bugs or obsolescence.
Taking the example of good old technologies like C++, a yearly review of bugs is enough. Libraires like boost or std don't change often. That won't be enough with web SOUPs, which change every other day, or are replaced by new ones. Thus, a monthly review or (less stringent) a quarterly review is better.

Security issues

Dozens of SOUPs also means an increased number of security issues. The SOUP anomalies reviews shall also include the security issues. Contrary to anomalies not related to cyber security, security issues might need be treated in a very short timeframe. Thus, it is more advisable to have a continuous monitoring of security issues, with tools like npm or snyk, to quickly detect and investigate security issues. Please also note that managing security issues is a regulatory requirement. They have to be managed in any software safety class whatsoever.

Freeze at release

Be careful also to freeze the SOUP versions when releasing to production. Every change of SOUP version is a change (tautology). Every change can introduce unexpected side effects, in functionalities, and in risks. Unless you have a fully automated testing strategy (hello Selenium and co.), every change of SOUP shall be thoroughly assessed. Don't let npm change SOUPs version in your back. It means that you'll have to use tricks like adding the version numbers to your dependency files.

Conclusion

Web applications are built over a diverse ecosystem of development tools, libraries, frameworks, and cloud services.
Infrastructure, OTSS, SOUP, it can be hard to choose in which category to place these various third-party software. But it's worth spending time on it to reduce the perimeter of IEC 62304. Even if ISO 13485 or 21 CFR 820 put some overhead on the shoulders of software development teams, it's less than IEC 62304.
When IEC 62304 is applicable, designing the architecture to isolate as many SOUPs as possible in class A is also worth it. IEC 62304 in class A is very light in terms of risk management, compared to other classes.
At last, applying IEC 62304 can be counter-intuitive for software development teams. E.g.: freezing SOUPs versions while you'd like to upgrade to stay in the race. IEC 62304 is seen like red tape by software developers. Having the right tools to automate the 62304 overhead is probably one key to success.