How this plays out in a clinic.
MDR / IVDR
MDR: the question is whether your agent is itself a medical device.
Last reviewed: 8 October 2026
Booking an appointment is not a medical purpose. Telling a caller which symptoms warrant an urgent visit may be. The Medical Device Regulation treats software with a medical purpose as a device in its own right, and Rule 11 of Annex VIII is where that line is drawn. Settle which side of it your agent sits on before it takes its first call. The answer decides whether you face a conformity route or a scope-of-practice problem.
What the law requires
- Software intended for diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease is a medical device in its own right, whatever it runs on.
- Regulation (EU) 2017/745, Art. 2(1)
- Software that provides information used to take decisions with diagnostic or therapeutic purposes is class IIa or higher; only software with no such purpose stays in class I.
- Regulation (EU) 2017/745, Annex VIII, Rule 11
- A manufacturer must hold technical documentation, a clinical evaluation and a post-market surveillance system, and must report serious incidents and field safety corrective actions.
- Regulation (EU) 2017/745, Art. 10, Annex II-III, Art. 87
- The IVDR does the same for in-vitro diagnostics; transitional periods for legacy devices run into 2027-2029 depending on class.
- Regulation (EU) 2017/746, Art. 110, as amended by Regulation (EU) 2024/1860
- Member States lay down the penalties, and a non-conforming device can be restricted or withdrawn from the market.
- Regulation (EU) 2017/745, Art. 95 and 113
- Health data is special-category data, so the data protection regime applies at the same time as the device regime. They do not substitute for one another.
- Regulation (EU) 2016/679, Art. 9(1)
What Audact does about it
- Health data is encrypted and held apart from the language model provider; crypto-shredding when the retention window closes is coming soon. Patent-pending.
- In development
- Scope of practice: each sentence segment the model produces is checked before it is sent to speech, and a segment already spoken is not withdrawn. A transfer to a person, triggered by the agent, is in controlled testing.
- In controlled testing
- Automatic hand-off on red-flag signals.
- In development
- Every clinical statement, consent and policy verdict leaves a receipt, so the practice's own file carries a hash of the output the gate released, the decision, and what it declined to say.
- One export of those records shaped for a notified body review or post-market surveillance file.
- In development
The line
Scheduling, triage, and the gap between them.
Most dental and clinic deployments sit comfortably on the administrative side: taking a booking, confirming an appointment, collecting a reason for the visit, chasing a no-show. None of that has a medical purpose, and none of it makes the software a device.
The line is crossed when the agent's output is used to decide something clinical: when it tells a caller that a symptom can wait until Monday, or that it cannot. That is information used for a decision with a diagnostic or therapeutic purpose, and Rule 11 pulls it into class IIa or above. The practical protection is not a legal opinion but a boundary that holds in the conversation: an agent that cannot say the clinical sentence cannot cross the line by accident.
Three regimes at once
The device rules, the data rules and the AI rules all apply to the same call.
A patient-facing agent is regulated three times over. The MDR asks what the software is for. The data protection regime asks on what basis health data is processed, and holds it to the stricter standard for special categories. The AI Act asks whether the patient was told they were speaking to a machine, and whether the deployment falls into its high-risk chapter — a classification question that has to be answered per system rather than assumed.
None of the three excuses the others, and they are enforced by different authorities. What they share is a need for a record of what actually happened on the call, which is the one artefact a practice usually does not have.
Note
Information, not legal advice.
This page sets out the rules as we read them, with the article numbers so you can check us. It is not legal advice, and your own position depends on facts this page cannot know. Take advice from qualified counsel before you rely on it.
Questions
- When does an AI voice agent fall under the MDR?
- When the software has a medical purpose: diagnosing, monitoring, predicting, treating or alleviating disease. Symptom triage, medication reminders, post-operative follow-up and remote monitoring frequently qualify. Appointment scheduling and administrative follow-up do not.
- What are MDR and IVDR?
- Regulation (EU) 2017/745 covers medical devices and Regulation (EU) 2017/746 covers in-vitro diagnostics. Both impose lifecycle duties on manufacturers: technical documentation, clinical or performance evaluation, post-market surveillance, incident reporting and traceability.
- How is health data kept away from the model provider?
- Encryption and separation from the language model provider are in development; crypto-shredding when the retention window closes is coming soon. The approach is patent-pending.
- Can we keep the agent on the administrative side deliberately?
- That is the usual and the sensible design. The scope of practice is set in the policy pack, and a statement outside it is stopped in the conversation rather than caught in a review afterwards, which is what keeps the classification question from being reopened by a single unlucky sentence.
A boundary that holds mid-sentence
Control shows how the scope of practice is set and what happens when an answer would fall outside it, including the handoff to a person.
Related
Healthcare Dental The most common administrative deployment.
GDPR Health data as a special category.
EU AI Act Article 50 Telling the patient what they are speaking to.
All frameworks
