How Do We Certify API-Only Software As a Medical Device?

Question

Our software only provides an API. We think it’s a medical device. How do we get it certified?

Short Answer

If your API will be integrated into another medical device, there might be a chance that you don’t need to certify it at all.

However, there are API Medical Devices out there. The qualification as a medical device highly depends on how it will be used. There are two possibilities:

Your API can be used independently (standalone) –> The API is a medical device.
Your API will only be integrated into another medical device –> You’re a supplier.

Long Answer

Assuming that the API is intended to fulfil a medical purpose, the main differences between an API and a normal medical device software are:

APIs don’t have a Graphical User Interface (GUI)
APIs are helpers providing functionalities to another software

Depending on how the API will be used, it is possible that the API is a medical device in itself or that it is a part of a larger medical device. It is also possible to integrate a medical device into a non-medical device – but not as an API.

API as a medical device in itself

Let’s take the example of an API that transforms images: In theory, you could go to your command line, send an image to this API and you’ll get back a modified version of the image, maybe highlighting potential cancer lesions. That’s a modification with a medical purpose, so it’s a medical device. You’re making it available to users, so you’re actually bringing it to the market. That means you need to certify it.

The easier way would be to make your API only available to medical device softwares integrating your APIs functionalities.

Challenges in Certifying APIs as Medical Devices

Usability:

As there is no Graphical User Interface in APIs, it makes little sense to follow IEC 62366 and to conduct a usability evaluation with your API. However, you can still improve the usability by making requests easy, outputs unambiguous and the API documentation easy to understand.

Label:

Ok, this is probably a regulator’s worst nightmare: There is no space for a label! The “label” is the section where regulatory symbols like the CE mark and identifiers like the UDI can be found. As a API, you can return this information on a data level. If your API is integrated into another software, however, the label will likely not be displayed to the end user. This is a legal grayzone. The smartest solution would be to ask the integrating software to give your label some space in their software’s Help/About section.

Feedback Management:

As APIs are providing embedded functionalities, the API manufacturers are hardly ever directly in contact with their end users. Therefore, feedback management is a special challenge for them. My recommendation is to set up a contract with the integrating software manufactuer that demands they forward any feedback that could be related to API.

Functionalities vs. Risks:

APIs can serve numerous use cases, from telemedicine platforms to remote patient monitoring systems. In the end, the risk assessment of an API boils down to how the API is being used. For the certification, it is important to define a use case for the API and an intended purpose.

Lack of Clear Regulatory Guidelines: The regulatory framework for certifying APIs as standalone medical devices is still evolving (read: not existent). Software is already a bit of a niche in the medical device field and APIs even more so. However, the reason for this could also be that in practice it actually rarely makes sense to certify an API as a standalone medical device. Other than that, it is not much different from a regular software medical device certification.

Liability: As an API manufcaturer you’re responsible to define the accepted input, the nature of your computations and the output. As a manufacturer of a software medical device integrating this API, you’re responsible to provide the correct input to the API, but also to display its output. The question of liability in case of an incorrect output to the patient needs to be discussed and contractually settled.

Integrating the API into a medical device

That’s a favorable scenario for the API manufacturer. The API is being integrated into a medical device. The API manufacturer acts as a supplier to the medical device manufacturer and commits to creating the necessary documentation (mostly IEC 62304) and to hand it over to the MD manufacturer.

API Risk Class

Let’s take the example of an API that segments and measures the dimensions of the liver on CT scans. This API is implemented into a software for surgery planning and in one for diagnosis of liver zirrhosis. The same API used in different contexts would lead different risk classes => IIb or III for the surgery and IIa for the diagnosis of liver zirrhosis.

The point is: The API is a tool for calculations. How the results are used determines the risk class of the whole endeavour. Someone has to define how the API will be used in order to determine the risk class. This could be the integrating software defining its use of the API and certify their own software accordingly. Likewise, if the API manufacturer certifies its API, they should clearly define the possible applications. Integrating softwares would then be bound to those application. To allow a wide range of API applications, it makes more sense if the integrating software defines the applications and obtains the certification.

Is it SOUP?

An argument could be made for an API being a SOUP within the context of a medical device software. However, the IEC 62304 defines SOUP as “off-the-shelf software” and notes that a SOUP should be generally available and not manufactured for the purpose of being integrated into the medical device. Also, medical device software systems in itself are expecially excluded from the definition. A cynical question at this point: If the API manufacturer certifies its device as a medical device in itself, would this make it impossible for an integrating software to declare it as a SOUP component as the API is officially a medical device system in itself? - We don’t know.

If the API manufacturer offers its service to different companies, it is indeed a generally available software and not (specifically) made to be integrated into your medical device and therefore: SOUP. What would be the alternative to declaring it SOUP?

API as externally developed component

If the manufacturer of the API tailors it to your needs, it would be an externally manufactured software component. That would mean, you need to set up all the supplier documentation for the API manufacturer and get the Technical Documentation on the API from them. They should also follow the requirements from ISO 13485, 14971 and IEC 62304 and 62366 (and whatever applicable). You might also need to audit them depending on how critical their component is to your device.

Representation of the Output

When receiving the output from the API, this needs to be displayed to the users. This representation can alter the perception of the outcomes and in some cases, the outputs might even be enhanced by the displaying software in some ways. That’s why you usually have Usability Testing. The API manufacturer cannot influence how the output is ultimately displayed to the end users. Likewise, the integrating software would have to take on the responsibility of displaying the outputs correctly, maybe displaying the medical device label of the API along with the results. The overall situation is not ideal. It feels like cutting a medical device in half and distributing the core responsibilities between two parties. Only if both of their efforts are aligned, the medical device will be compliant (and complete). That’s why I would always favor that the integrating software is a medical device. This way, the output to the end user is properly controlled. Everything that’s happening under the hood with the API can either be dealt with as a SOUP or an externally developed component (see previous point).

A medical device within a non-medical device

It is possible to divide a software into different components. Further, it is possible that some of those components are medical devices and some are not. While this is a topic that would make another article, I want to briefly highlight the case if one of those components in an external API.

If you’re offering services with a medical device purpose, either the overarching software needs to be certified as a medical device or the component (in this case, the API). Integrating a medical device component into a non-medical device comes with the requirements of clearly indicating that users are now dealing with a medical device when opening the software part with the MD functionality. Especially, users need to see the device label with all it’s safety instructions and warnings. It is critical to isolate this component from the rest of the software. You will want to avoid that the other components somehow drive the medical device component as that would immediately convert them into medical devices themselves. However, a API does not have a GUI and therefore, I would argue that it is impossible to integrate an API (without GUI) into a non-medical device as there will never be enough separation between the two and users wouldn’t be able to tell the difference.

TL;DR Possible Scenarios

1. True standalone API

If your API can be called without an interface and you give people the opportunity to do so, you need to define the Intended Use of your device because that defines if your API is a medical device or not. If the API fulfils a medical purpose, it should be certified.

2. Certify API, integrating software is not an MD

In this case, the API is a medical device. It serves a specific Intended Purpose and is integrated by a software that is not a medical device. You could for example have a Fitness Tracker App that displays your heart rate and then there’s a part inside that app that analyzes possible heart defects. The Fitness App would send its data to the Heart Analysis API and output the API’s results.

Regulatory-wise this is not a clean approach. The display of the label and the display of the API outputs are in this case out of control of the medical device manufacturer. Therefore, the usability aspect is probably only partially covered. It is questionable whether this would be accepted in the long run. Instead of certifying “just an API”, it would be wise to certify it with a simple user interface (like a “component as a device”).

3. Certify integrating software, API is not an MD

This is the most elegant approach. The only question is how to integrate the API into the Technical Documentation. It can be either SOUP or an externally developed component (see “Is it SOUP?”)

4. API is not an MD, integrating software is not an MD

This is only possible if none of the two is intended to fulfil a medical purpose. Then why are you on this website at all?

Secondary Matters

Data Security and Privacy Concerns

APIs often handle sensitive patient data. Ensuring robust data security and privacy measures is paramount, and the EU’s General Data Protection Regulation (GDPR) adds an extra layer of complexity to API certification in healthcare.

Interoperability (Cybersecurity) Challenges

APIs are designed to facilitate interoperability between various systems and devices. However, this very interoperability can introduce potential vulnerabilities that need to be carefully addressed during certification.