A Class IIb medical device API is the interface to software that carries a CE mark as a Class IIb medical device under the EU Medical Device Regulation (MDR 2017/745). Class IIb means a notified body has assessed the software for monitoring patients whose condition can deteriorate quickly: a person with heart failure gaining two kilos in three days, a COPD patient whose oxygen saturation drops overnight, or someone recovering at home after hospital discharge.

Most health data APIs are not medical devices. They collect and transport data from wearables and apps, such as steps, sleep or heart rate from a smartwatch, but they are not certified to turn that data into clinical alerts. This guide explains where the line sits, what the certification covers when you build on a Class IIb API, and what to ask a vendor before you integrate.

Health data API vs medical device API

What separates the two is the intended purpose declared by the manufacturer. The technology looks the same: both expose endpoints and webhooks. A health data API can tell your app that a user slept six hours. Only a medical device API is certified to tell a nurse that a patient’s blood pressure needs attention today.

Vitalera is on the second side of that line. Our remote patient monitoring software is CE-marked as a Class IIb medical device under the MDR, certified by a notified body and listed in EUDAMED, the European Commission’s public database. We went through that process ourselves, so we know what it demands of the software and of the teams that build on it.

Most health data APIs are not medical devices at all. They move data; they are not allowed to turn it into clinical alerts. This guide explains the difference, what the certification covers when you build on top of one, and what to ask a vendor before you integrate.

If your product only shows steps and sleep, a health data API is enough. If a nurse will act on an alert it generates, you need the right-hand column.

Why remote patient monitoring software is Class IIb

Rule 11 of the MDR classifies software by what happens if it gets something wrong. The rule has two branches that matter for remote monitoring:

• Software that monitors physiological processes is Class IIa. It becomes Class IIb when it monitors vital parameters whose variation could put the patient in immediate danger.
• Software that informs diagnostic or therapeutic decisions starts at Class IIa. It becomes Class IIb when a wrong decision could cause serious deterioration or surgery, and Class III when it could cause death or irreversible harm.

The guidance document MDCG 2019-11, revised in June 2025, adds that each software module is assessed for its own medical purpose. A platform can therefore have certified and non-certified modules side by side, which is why the scope of the certificate matters more than the logo.

What the certification covers when you integrate, and what it does not

A certificate covers the manufacturer's software, used within its declared intended purpose. It does not transfer to the product you build on top. This is the point most vendor pages skip.

1) What you get by building on a certified API

• Monitoring logic, thresholds and alerts that a notified body has assessed.
• A software lifecycle run under IEC 62304, with risk management under ISO 14971.
• Clinical evaluation and post-market surveillance already in place for those functions.
• Controlled releases: you are told when a change affects safety or performance.

2) What stays with you

• If your product adds its own medical logic (your own risk score, your own alert rules), that logic may be a medical device of its own.
• If you market the software under your own name, change its intended purpose or modify it, Article 16 of the MDR gives you the manufacturer's obligations.
• If you use it outside the declared intended purpose (a different patient group, an acute setting), the certificate no longer covers that use.

3) What certification does not change

A consumer smartwatch stays a consumer device. Passing its data through certified software does not make the reading medical-grade. Certified software can ingest that data, but the clinical weight of each signal depends on the device that produced it. A serious vendor tells you which sources are medical devices and which are not.

Building on a Class IIb medical device API

If your product only displays wellness data, a health data API is enough. If a clinician will act on what it shows, you need software certified for that use. Vitalera’s remote patient monitoring platform is CE-marked as a Class IIb medical device under the MDR and listed in EUDAMED. Through the Vitalera API you can connect more than 500 wearables and medical devices, collect PROMs and PREMs, and send monitoring data to the health record in FHIR or HL7. Tell us what you are building and we will check it against our intended purpose before you write a line of code. Talk to the team or read the API documentation.

‍