---
title: Telehealth and Remote Monitoring Devices Under MDR
description: When telehealth and remote monitoring systems become medical devices under MDR, how Rules 10 and 11 classify them, and what cybersecurity MDR expects.
authors: Tibor Zechmeister, Felix Lenhard
category: Digital Health, DiGA & Health IT
primary_keyword: telehealth remote monitoring MDR
canonical_url: https://zechmeister-solutions.com/en/blog/telehealth-remote-monitoring-mdr
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# Telehealth and Remote Monitoring Devices Under MDR

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

> **A telehealth or remote monitoring system becomes a medical device under MDR Article 2(1) the moment the manufacturer claims a medical purpose for the data it captures or displays. Vital-signs monitoring falls into Rule 10, decision-support software falls into Rule 11, and both carry MDR Annex I §17 cybersecurity obligations once they are connected.**

**By Tibor Zechmeister and Felix Lenhard.**

## TL;DR
- Telehealth and remote monitoring products are qualified as medical devices when their intended purpose matches MDR Article 2(1), regardless of whether the hardware is worn, implanted, or sits as software on a patient's phone.
- Devices that monitor vital physiological processes fall under MDR Annex VIII Rule 10, with the classification escalating when the monitored parameters can cause immediate danger to the patient.
- Decision-support software that processes the monitored data is classified under MDR Annex VIII Rule 11 and is almost never Class I.
- Once a device transmits or receives patient data, MDR Annex I §17 cybersecurity obligations apply, and MDCG 2019-16 Rev.1 plus EN IEC 81001-5-1:2022 become the working references.
- Startups that treat telehealth as an IT product first and a medical device second almost always rebuild the technical file later at high cost.

## Why telehealth and remote monitoring products trip founders up

Telehealth looks like a software category. The founders building it usually come from consumer health, from digital fitness, or from hospital IT. They talk about onboarding flows, reimbursement, and clinician UX. The regulatory question arrives late, and it arrives hard.

Tibor has seen the same sequence play out across several of the 50+ companies he has guided through MDR certification. A remote monitoring startup builds a product that captures heart rate, SpO2, or ECG. The founders describe it as a "coaching" or "wellness companion" product to investors because that framing is commercially easier. Six months later a clinician asks whether the product can flag arrhythmia. The sales team says yes. The product is now a medical device under MDR Article 2(1), and the architecture has to be requalified against EN 62304:2006+A1:2015, Annex I General Safety and Performance Requirements, and a notified body review.

Felix has coached founders through the commercial pivot this requires. The technical work is solvable. The hard part is that the regulatory framing should have been set on day one.

## When a telehealth system qualifies as a medical device

MDR Article 2(1) defines a medical device as any instrument, apparatus, appliance, software, implant, reagent, material, or other article intended by the manufacturer to be used for one or more of the medical purposes listed in that article, including diagnosis, prevention, monitoring, prediction, prognosis, treatment, or alleviation of disease. Article 2(1) explicitly includes software.

The qualification trigger is the intended purpose, which MDR Article 2(12) defines 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.

Tibor's practical test for a telehealth product: read the marketing website, read the in-app copy, read the first five lines the clinician sees. If any of that text promises monitoring of a disease state, diagnostic information, treatment adjustment, or prognosis, the product is in MDR scope. The hardware is irrelevant to the qualification question. The software claim is what counts.

MDCG 2019-11 Rev.1 is the authoritative guidance on how to apply this qualification logic to software. The four-step decision flow starts with whether the software is software at all in the MDR sense, moves through whether it performs an action on data beyond simple storage or transmission, and ends with whether that action serves a medical purpose under Article 2(1). Most telehealth products fail the "simple storage or transmission" test the moment they calculate a trend, compute a score, or raise an alert.

## Rule 10: monitoring of vital physiological processes

Once a connected device is in MDR scope, classification follows MDR Annex VIII. Rule 10 applies to active devices intended for diagnosis and monitoring. The general class is IIa. Rule 10 escalates the device to Class IIb when it is intended for monitoring of vital physiological processes where variations in those parameters could result in immediate danger to the patient.

Rule 10 in practice:
- A wearable that records heart rate for trend analysis is typically Class IIa under Rule 10 when it is used for clinical monitoring.
- A wearable that monitors cardiac rhythm for arrhythmia detection where a missed event could cause immediate harm is Class IIb under Rule 10.
- A home spirometer used for chronic respiratory monitoring sits at Class IIa under Rule 10 when the output is used for clinical management.
- Continuous glucose monitoring that directly informs insulin dosing sits at Class IIb under Rule 10 because the monitored parameter is vital and the time window to react is short.

The notified body will read the intended purpose and the claims, then apply Rule 10 according to the severity of the worst-case miss. Founders who write vague intended purpose statements hoping for Class IIa often end up in Class IIb during the stage 1 audit, because the reviewer reconstructs the worst-case use from the marketing material.

## Rule 11: decision-support software

A telehealth product almost always has a software component that processes the monitored data. That software is classified under MDR Annex VIII Rule 11, which is the software-specific rule introduced by the MDR.

Rule 11 baseline: software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is Class IIa. The class escalates to Class IIb when such decisions may cause serious deterioration of a person's state of health or a surgical intervention, and to Class III when the decisions may cause death or irreversible deterioration.

Two consequences follow for telehealth platforms:
1. Decision-support modules inside a telehealth system are rarely Class I. The existence of the module triggers at least Class IIa.
2. The hardware class under Rule 10 and the software class under Rule 11 are evaluated independently, and the highest class applies to the combined system when a single CE mark covers both.

MDCG 2019-11 Rev.1 gives worked examples that map closely to telehealth use cases. Tibor uses the guidance during first regulatory strategy workshops as a sanity check on the classification the founders believed they were entitled to.

## MDR Annex I §17 and connected-device cybersecurity

Once a telehealth system transmits data, MDR Annex I §17 applies. Section 17.2 requires that devices incorporating electronic programmable systems are designed to ensure repeatability, reliability, and performance in line with their intended use, and that a single fault condition is managed to minimize risk. Section 17.4 requires manufacturers to set out minimum requirements for hardware, IT network characteristics, and IT security measures, including protection against unauthorized access necessary to run the software as intended.

MDCG 2019-16 Rev.1 is the authoritative guidance on how to meet these cybersecurity obligations. It maps closely to EN IEC 81001-5-1:2022, the harmonized standard for health software security lifecycle. The two documents together define what a reasonable notified body expects to see in a connected-device technical file.

Tibor's cybersecurity maxim from the Notified Body side of the table: a device that is secure at launch can become insecure the day a CVE is published against a library in the software bill of materials. The lifecycle obligation is continuous, not one-time. Startups that treat cybersecurity as a launch checkbox rebuild it after the first surveillance audit.

The practical minimum for a telehealth startup preparing for a first notified body engagement:
- A cybersecurity risk module integrated with the MDR risk management file built against EN ISO 14971:2019+A11:2021.
- A software bill of materials that comes from the EN 62304 configuration item list rather than as a separate document.
- A penetration test result, even a light one, as external evidence of responsible development.
- A documented post-market vulnerability response process tied to the PMS plan under MDR Articles 83-86.

## A worked example: a cardiac remote monitoring platform

A three-founder startup builds a home ECG patch plus a companion app plus a clinician dashboard. The intended purpose is "continuous ECG monitoring for outpatients with suspected atrial fibrillation, providing flagged events for clinician review".

Qualification: yes, medical device under MDR Article 2(1), because the intended purpose explicitly includes monitoring and diagnostic information.

Hardware classification under Rule 10: Class IIb, because cardiac rhythm is a vital physiological process and a missed arrhythmia can cause immediate danger.

Software classification under Rule 11: Class IIb for the clinician dashboard, because the decisions informed by the software can lead to serious deterioration if wrong.

Overall device class: IIb. Conformity assessment under MDR Annex IX requires notified body involvement, a full QMS under EN ISO 13485:2016+A11:2021, and clinical evaluation under MDR Article 61 with supporting clinical data.

Cybersecurity obligation: Annex I §17 applies fully. The team builds the cybersecurity module against MDCG 2019-16 Rev.1 and EN IEC 81001-5-1:2022 from day one rather than retrofitting it at audit time.

Felix worked with a founder facing exactly this scenario. The team had been pitching the product as "consumer heart health" for nine months. The regulatory framing reset cost them six weeks of re-planning. The time to market still beat competitors who tried to stay Class I.

## The Subtract to Ship playbook for telehealth startups

1. Write the intended purpose in a single paragraph before writing any code that touches patient data. Mark every claim that maps to MDR Article 2(1). If the paragraph survives legal review, it becomes the anchor for the entire technical file.
2. Run the MDCG 2019-11 Rev.1 four-step flow on paper. Record the answers. File the result in the QMS as the software qualification rationale.
3. Apply Rule 10 and Rule 11 side by side. Take the higher of the two as the planning class. Do not optimize for the lower class hoping the notified body will agree.
4. Build the cybersecurity module inside the risk management file, not next to it. Tibor's observation from the auditor side: a cybersecurity file that lives outside ISO 14971 risk management is a finding waiting to happen.
5. Treat the SBOM as the EN 62304 configuration item list with extra columns. One list, one update process, one source of truth.
6. Plan penetration testing early enough that the result is in the technical file when the notified body opens it.
7. Write the post-market vulnerability response procedure before launch, not after the first CVE.

## Reality Check

- Does the intended purpose paragraph of the telehealth product contain any medical-purpose claim under MDR Article 2(1)?
- Has the team walked through MDCG 2019-11 Rev.1 step by step and recorded the answers in the QMS?
- Has the team applied Rule 10 and Rule 11 independently and taken the higher class as the plan of record?
- Is the cybersecurity risk module integrated with the EN ISO 14971 risk management file, or does it live as a separate spreadsheet?
- Does the software bill of materials come from the EN 62304 configuration item list, or is it maintained in parallel?
- Is there a documented post-market vulnerability response process tied to the PMS plan under MDR Articles 83-86?
- Has the founding team run a penetration test and filed the result in the technical file?

If more than two of these answers are no, the product is not ready for a stage 1 notified body audit, regardless of how polished the clinician UX feels.

## Frequently Asked Questions

**Is a telehealth platform automatically a medical device under MDR?**
No. Qualification depends on the intended purpose. A telehealth platform that only connects patients and clinicians for video calls and stores unstructured notes is outside MDR. The moment the platform processes clinical data to produce diagnostic information, trends, alerts, or treatment recommendations, MDR Article 2(1) is triggered.

**Can a remote monitoring wearable stay Class I?**
Only in narrow cases. A basic activity tracker marketed as a general wellness product is not in MDR scope at all. Once monitoring is described as clinical, Rule 10 applies and the baseline is Class IIa, with Class IIb whenever the monitored parameter is vital and variation could cause immediate danger.

**What is the minimum cybersecurity documentation a notified body expects?**
A cybersecurity risk analysis integrated with the EN ISO 14971 risk file, a threat model mapped against EN IEC 81001-5-1:2022, evidence of security verification and validation, a software bill of materials derived from EN 62304 configuration items, a penetration test result, and a post-market vulnerability response procedure tied to the MDR PMS plan.

**How does MDCG 2019-16 Rev.1 relate to EN IEC 81001-5-1:2022?**
MDCG 2019-16 Rev.1 is the MDCG guidance on cybersecurity under MDR. EN IEC 81001-5-1:2022 is the harmonized standard for health software security lifecycle. The two documents are complementary. Notified bodies use MDCG 2019-16 Rev.1 as the compliance roadmap and EN IEC 81001-5-1:2022 as the technical reference.

**Does GDPR add anything on top of MDR cybersecurity for telehealth?**
GDPR is separate law and always applies when personal health data is processed. Tibor's repeated observation is that MedTech startups forget GDPR exists until the first data protection review, then find that the cybersecurity risk file does not even list personal data as an asset worth protecting. The fix is awareness on day one, not legal complexity.

## Related reading

- [What is a medical device under MDR](/blog/what-is-medical-device-under-mdr) for the qualification baseline that every telehealth founder should read first.
- [MDR Rule 11 for software, deep dive](/blog/mdr-classification-software-rule-11-deep-dive) for the software-specific classification logic that drives telehealth decision-support modules.
- [MDCG software classification examples for startups](/blog/mdcg-software-classification-examples-startups) for worked examples that map closely to telehealth products.
- [Interoperability under MDR for connected devices](/blog/interoperability-under-mdr-connected-devices) for how data-exchange obligations layer on top of Rule 10 and Rule 11.
- [MDR Rule 11 software classification](/blog/mdr-classification-rule-11-software) for the canonical explainer on Rule 11 class escalation.

## Sources

1. Regulation (EU) 2017/745 on medical devices, consolidated text. Article 2(1), Article 2(12), Annex I §17, Annex VIII Rule 10, Annex VIII Rule 11.
2. MDCG 2019-11 Rev.1, Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 and Regulation (EU) 2017/746, June 2025.
3. MDCG 2019-16 Rev.1, Guidance on Cybersecurity for medical devices, July 2020.
4. EN ISO 14971:2019+A11:2021, Medical devices, Application of risk management to 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.

---

*This post is part of the [Digital Health, DiGA & Health IT](https://zechmeister-solutions.com/en/blog/category/digital-health) 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).*