---
title: API Design for Medical Devices: Regulatory Considerations Under MDR
description: How API design for medical devices under MDR creates a regulated boundary, affects intended purpose, and triggers change control and manufacturer liability.
authors: Tibor Zechmeister, Felix Lenhard
category: Software as a Medical Device
primary_keyword: API design medical devices MDR
canonical_url: https://zechmeister-solutions.com/en/blog/api-design-medical-devices-mdr
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# API Design for Medical Devices: Regulatory Considerations Under MDR

*By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.*

> **An API on a medical device is not a technical convenience. It is a regulated boundary. Under MDR Annex I §14.2(d) and §17.1, every interface that third parties consume becomes part of your intended purpose, your risk file, and your change control scope. Design the API as if an auditor will read the OpenAPI spec, because one will.**

**By Tibor Zechmeister and Felix Lenhard.**

## TL;DR
- An API exposed by a medical device is an interface with other equipment within the meaning of MDR Annex I §14.2(d) and §17.1, and must be specified, verified, and validated.
- Third-party consumers of your API do not automatically become manufacturers. But if they combine your device with other products for a medical purpose, MDR Article 22 and the "system/procedure pack" rules may apply.
- API versioning is change control. A breaking change to an API contract is, at minimum, a software change under EN 62304:2006+A1:2015 clause 6, and can be a significant change under MDR Article 120 depending on impact.
- Authentication, authorisation, and input validation are GSPR items under Annex I §17.2 and §17.4, not optional features.
- The OpenAPI spec, the interface control document, and the risk analysis of foreseeable misuse are the three artefacts an auditor will ask for first.

## Why this matters

Modern SaMD rarely ships alone. A CE-marked triage algorithm receives DICOM studies from a PACS. A blood-glucose prediction model exposes REST endpoints for a third-party patient app. A hospital information system pulls structured risk scores from a regulated backend. In every one of these cases, an API sits at a regulatory boundary. And whoever designed that API either thought about MDR while drawing the contract, or didn't.

Tibor has audited enough SaMD manufacturers to see the pattern: the API is built by the platform team on sprint velocity, the regulatory team finds out at the Stage 1 audit, and suddenly there is no interface specification, no input validation rationale, and no documented assumption about what the consuming system will do with the output. That gap is not cosmetic. It is a GSPR non-conformity waiting to happen.

This post is the regulatory frame you should have before you design the next endpoint.

## What MDR actually says

Three anchors matter.

**MDR Annex I §14.2(d)** requires that devices be designed and manufactured so that "the risks associated with the possible negative interaction between software and the IT environment within which it operates and interacts" are removed or reduced. In plain language: if your software talks to other software, the interaction itself is a hazard source you must analyse.

**MDR Annex I §17.1** requires that devices incorporating electronic programmable systems, including software that is a device in itself, "shall be designed to ensure repeatability, reliability and performance in line with their intended use. In the event of a single fault condition, appropriate means shall be adopted to eliminate or reduce as far as possible consequent risks or impairment of performance." An API is a single fault surface. A malformed request, a missing field, an unexpected unit of measurement. Each is a single-fault scenario.

**MDR Annex I §17.2** requires that software be developed and manufactured in accordance with the state of the art, taking into account the principles of development lifecycle, risk management, verification and validation. The harmonised standard here is EN 62304:2006+A1:2015, and the expectation is that the interface between software items. Including external interfaces. Is specified (clause 5.3), implemented against that specification (clause 5.5), and verified (clause 5.6/5.7).

**MDR Article 2(12)** defines intended purpose as *"the use for which a device is intended according to the data supplied by the manufacturer on the label, in the instructions for use or in promotional or sales materials or statements and as specified by the manufacturer in the clinical evaluation"*. The moment you publish API documentation saying "consume this endpoint to retrieve patient risk scores for display in your clinical workflow," you have supplied data about intended purpose. And you own the consequences.

**MDCG 2019-11 Rev.1** (June 2025 revision) reinforces that software qualification hinges on intended purpose, and that providing an output "to be used as a basis for any decision" relating to diagnosis or therapy qualifies the software as a medical device regardless of whether a human or another system is the immediate consumer.

## A worked example

A Vienna-based startup builds a sepsis prediction model, Class IIa under Rule 11. The model runs as a backend service. The first hospital customer wants to call it from their existing monitoring dashboard over HTTPS. The founder. Call her Lena. Wants to ship fast, so the team publishes a REST endpoint: `POST /v1/predict`, body is a JSON object with vitals, response is a score between 0 and 1.

Here is the regulatory reality of that endpoint.

**The API is part of the intended purpose.** The IFU says the device "outputs a sepsis probability score for use by trained clinicians." The API is the mechanism by which that output reaches the clinician. If the API drops the score's confidence interval, or returns a float with different precision than the clinical evaluation used, the device has silently drifted from its intended purpose.

**Input validation is risk control.** What happens if the consuming system sends heart rate in beats per minute when the model expects beats per 15 seconds? What if a field is null? What if the timestamp is in the future? Every one of these is a foreseeable misuse scenario under EN ISO 14971:2019+A11:2021. The API must reject invalid inputs deterministically, log the rejection, and surface an error the consuming system can act on. "Garbage in, garbage out" is not a regulatory defence.

**Versioning is change control.** Six months later, Lena's team adds a new vitals field. They bump the endpoint to `/v2/predict` and keep `/v1` alive. Under EN 62304 clause 6.1, both versions are now under configuration management. Under MDR, the question is whether the v2 change is a significant change in the sense of Article 120 and MDCG 2020-3. If v2 changes the performance of the algorithm or the intended purpose, it triggers a new conformity assessment. If it is purely additive and v1 behaviour is unchanged, it may be a non-significant change. But the rationale must be documented.

**The consuming hospital is not automatically a manufacturer.** The hospital is using a CE-marked device through its documented interface. Lena is the manufacturer of the SaMD. But if a second startup builds a product that bundles Lena's API with their own dashboard and sells it as an integrated sepsis monitoring solution for a new intended purpose, that second startup may become the manufacturer of a system or procedure pack under MDR Article 22, or of a new device altogether if they change the intended purpose.

This last point is where founders get hurt. Publishing an API without terms of use that define permitted consumers and permitted uses is equivalent to publishing an open invitation to let third parties reshape your regulatory scope.

## The Subtract to Ship playbook

You do not need a 200-page interface specification to design a compliant API. You need five artefacts, each short, each traceable.

**1. Interface Control Document (ICD).** One document per external interface. Purpose of the interface, data elements with units and ranges, error codes, authentication model, rate limits, versioning policy. This is your EN 62304 clause 5.3 software requirements for the interface. If you already maintain an OpenAPI spec, reference it from the ICD. Do not duplicate. An OpenAPI spec under version control is a perfectly acceptable specification artefact, provided it is approved, reviewed, and traceable to design inputs.

**2. Risk analysis of the interface.** Extend your ISO 14971 risk file with an "external interfaces" section. For each endpoint, enumerate foreseeable misuse: wrong units, missing data, replay attacks, consuming system failure, network partitions. Link each hazard to a risk control. Usually input validation, schema enforcement, authentication, or a documented assumption in the IFU. This is your Annex I §14.2(d) and §17.1 evidence.

**3. Terms of use for API consumers.** Legal and regulatory, not marketing. Define: who may consume the API, what constitutes permitted use, what the consumer must display or pass through to the end user, and what changes the consumer may not make. This protects your intended purpose from being silently redefined by a customer. It is also the document a notified body will ask for when they see "third parties integrate with our API" in your technical documentation.

**4. Versioning and change control policy.** Semantic versioning is fine, but the regulatory layer sits on top. Decide, in writing: what counts as a breaking change, how long you support old versions, how you notify consumers, and how each version is assessed against the significant-change criteria of MDCG 2020-3. Every API version is a configuration item under EN 62304 clause 6.

**5. Security controls traceable to EN IEC 81001-5-1:2022.** Authentication, authorisation, transport security, input validation, audit logging. These are not "nice to have". They are state-of-the-art cybersecurity controls that an auditor will expect to see mapped to Annex I §17.2 and §17.4. MDCG 2019-16 Rev.1 is the guidance; EN IEC 81001-5-1:2022 is the standard.

Two things to subtract: do not invent a custom authentication scheme (use OAuth 2.0 or mutual TLS and document the choice), and do not expose internal object models through your API (design a stable public contract and version it independently of your internal data model).

## Reality Check

1. Does your technical documentation include an interface control document for every external API your device exposes?
2. Have you performed a documented risk analysis of foreseeable misuse at each API endpoint, including malformed inputs and wrong units?
3. Is your OpenAPI spec (or equivalent) under version control, approved, and traceable to design inputs?
4. Do you have written terms of use that define permitted API consumers and permitted uses?
5. Can you produce a written policy for what constitutes a breaking change and how it is assessed against MDCG 2020-3?
6. Are authentication, authorisation, and input validation documented as risk controls in your ISO 14971 risk file?
7. If a third party integrated your API into a new product tomorrow, do you know whether they would become the manufacturer of a system under MDR Article 22?
8. Has your PRRC reviewed the API contract before it was published to the first external consumer?

## Frequently Asked Questions

**Is an internal API. One only used by your own frontend. Subject to the same scrutiny?**
The rigour is the same under EN 62304, because clause 5.3 does not distinguish between internal and external interfaces. The MDR Annex I §14.2(d) concern about interaction with the IT environment is weaker for a purely internal API, but you still need specification, verification, and change control.

**Do you need a separate conformity assessment every time you add an endpoint?**
No. Adding an endpoint is a software change that flows through your EN 62304 change control process. Whether it triggers a new conformity assessment depends on whether it is a significant change under MDR Article 120 and MDCG 2020-3. Typically driven by changes to intended purpose, performance, or safety-relevant behaviour.

**What if a hospital customer wants to modify the API response for their workflow?**
They cannot, without becoming a manufacturer of a modified device. This is why terms of use matter. If a customer needs a different response shape, you either add a versioned endpoint under your own change control or decline.

**Is OpenAPI enough, or is a separate "interface specification" document required?**
An approved, version-controlled OpenAPI spec can serve as the interface specification under EN 62304 clause 5.3, provided it is traceable to design inputs and reviewed through your QMS. A one-page ICD that references the OpenAPI spec is often cleaner for auditors.

**Does the EU AI Act change any of this for AI-driven APIs?**
The AI Act adds obligations around transparency, human oversight, and post-market monitoring that apply alongside MDR, but it does not replace the MDR interface requirements. An AI-driven API still needs EN 62304 specification and ISO 14971 risk analysis.

**Who owns the risk when a third-party app misuses your API?**
You own the risk within the scope of your documented intended purpose and interface specification. If a third party uses your API outside its terms of use, that is their regulatory exposure. But only if your terms of use, IFU, and API documentation are clear enough to demonstrate the boundary.

## Related reading
- [What is Software as a Medical Device (SaMD) under MDR](/blog/what-is-software-as-medical-device-samd-mdr) – foundation for everything in this post.
- [MDCG 2019-11 software guidance](/blog/mdcg-2019-11-software-guidance) – how your API affects qualification and classification.
- [Significant change for software under MDR](/blog/significant-change-software-mdr) – the test every API version must pass.
- [Software updates under MDR and new conformity assessment](/blog/software-updates-mdr-new-conformity-assessment) – when an API change triggers re-assessment.
- [Evaluate and document SOUP and OTS components](/blog/evaluate-document-soup-ots-components) – because your API probably depends on third-party libraries too.

## Sources
1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I §14.2(d), §17.1, §17.2, §17.4; Article 2(12); Article 22; Article 120.
2. MDCG 2019-11 Rev.1 (June 2025). Guidance on qualification and classification of software in Regulation (EU) 2017/745.
3. MDCG 2020-3. Guidance on significant changes regarding the transitional provision under Article 120 of the MDR.
4. MDCG 2019-16 Rev.1 (July 2020). Guidance on cybersecurity for medical devices.
5. EN 62304:2006+A1:2015. Medical device software. Software life cycle processes.
6. EN IEC 81001-5-1:2022. Health software and health IT systems safety, effectiveness and security. Part 5-1: Security. Activities in the product life cycle.
7. EN ISO 14971:2019+A11:2021. Medical devices. Application of risk management to medical devices.

---

*This post is part of the [Software as a Medical Device](https://zechmeister-solutions.com/en/blog/category/samd) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*