# Is your clinic software a medical device? Settle this before you build > It depends on what the software is meant to do, and what you say it does. Software that only stores, sends or schedules is usually not a medical device. Software that works on one patient’s data to inform a diagnosis or a treatment usually is. Decide it module by module, in writing, before design starts. By Dion Zeneli · 26 August 2026 · 9 min read Source: https://www.theweb0.com/blog/is-your-clinic-software-a-medical-device Filed under: Health, Checklist, Process --- If you run a clinic or a healthtech company and want software built, this question comes before the first screen is drawn. The answer changes the budget, the timeline and the words you are allowed to put on your website. > **Not legal advice.** > > This is how the rules work as I read them when I scope a build for a clinic. I am a designer and developer, not a lawyer or a regulatory specialist. Before you rely on any of it, have one of them read your plans. ## What decides whether software is a medical device? Its intended purpose. Not how clever the code is, and not how risky it feels. The EU's guidance on medical device software, MDCG 2019-11, put it in one line in its June 2025 revision: "Software must have a medical purpose on its own to be qualified as a MDSW".[^mdcg] MDSW is medical device software. The same guidance says the risk of harm "is not a criterion on whether the software qualifies as a medical device." Intended purpose is defined in the Medical Device Regulation, Article 2(12). It covers what the manufacturer says on the label and in the instructions, and also what it says "in promotional or sales materials or statements".[^mdcg] That last part is the one founders miss. Your landing page, your app store listing and your pitch deck are part of the intended purpose. Two products with identical code can land on different sides of the line because one website says "keeps your records in order" and the other says "spots problems early". ## How does the Commission's guidance walk through it? MDCG 2019-11 gives five decision steps, drawn as a flowchart in its Figure 1.[^mdcg] Here they are in plain words. 1. **Is it software?** In the guidance's sense: a set of instructions that turns input data into output data. If yes, carry on. 2. **Is it an accessory to a medical device, an MDR Annex XVI product, or software that drives or influences a medical device?** If yes, it is regulated together with that device, or on its own as an accessory. If no, carry on. 3. **Does it do something with the data beyond "storage, archival, communication, simple search, lossless compression"?** If it only does those, it is not medical device software. If it does more, carry on. 4. **Is that action for the benefit of individual patients?** Software that only aggregates population data, or gives generic pathways, literature or templates, is not. 5. **Does it meet the definition of medical device software?** That means a medical purpose from MDR Article 2(1): diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease, among others. If yes, it is medical device software, and the next question is its class. *Figure: The five decision steps of MDCG 2019-11 rev.1, Figure 1, in my words. The guidance's own text decides, not this drawing. See it at https://www.theweb0.com/blog/is-your-clinic-software-a-medical-device* ## What does that mean for typical clinic software? The guidance has examples, and most of what a clinic asks me for falls on the outside. Here is how the usual pieces line up against it. | What the software does | Usually, and why | | --- | --- | | Booking, scheduling, staff rotas | **Not a medical device.** The guidance lists "staff planning" among non-medical purposes, and says hospital information systems "are not in themselves qualified as medical devices" | | Invoicing and reimbursement | **Not a medical device.** "Invoicing" is on the same list | | Reminders and messages to patients | **Not a medical device.** So are "e-mailing, web or voice messaging" | | A patient record that replaces paper files | **Not a medical device.** Record systems "when used solely to replace traditional paper-based patient files" do not meet the definition | | Analysing one patient's data to suggest a dose or flag a drug interaction | **Medical device software.** The guidance gives it as an example of a module that qualifies | | Viewing scans with measurement overlays or automatic anomaly detection | **Medical device software.** Also given as a module that qualifies | | Recommending exercises to one patient, based on their own data, to relieve pain | **Medical device software.** Also given as an example: "recommending personalised rehabilitation exercises" | All from MDCG 2019-11 rev.1, sections 3.1 and 7 and Annex I.[^mdcg] "Usually" is doing work in that table. The words you use about each feature can move it. ## Can one product be partly a medical device? Yes, and this is the most useful idea in the guidance for anyone building a platform. Section 7 says it plainly: "Some of these modules serve a medical purpose, while others do not." Its own list puts administrative patient data, medical history, invoicing and prescription links outside, and "expert assistance for clinical decision-making" inside.[^mdcg] It also puts a duty on the manufacturer "to clearly delineate the boundaries and interfaces of the various modules". In practice that is a design decision as much as a legal one. If one feature would be medical device software, I would rather build it as its own module, with its own name, its own screens and its own sentence of intended purpose, so the records, the booking and the billing stay outside. Then you can launch the plain parts first and take the regulated one through its own process when it is ready. ## If it is a medical device, what class? The class decides how much evidence and paperwork the manufacturer needs. For software, the MDR's Rule 11 (Annex VIII) does most of the work. Software "intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as class IIa", or higher if those decisions could cause serious harm. Software that monitors physiological processes is class IIa, or IIb for vital parameters. Then: "All other software is classified as class I."[^mdcg] What this means for a build: a module that informs decisions about one patient is a regulatory project with its own budget and timeline. Find that out at the scoping stage, not after launch. ## What applies even if it is not a medical device? Data protection, and for health data it is strict. None of this goes away because the software is "only" a record system. - **Health data is a special category.** GDPR Article 9(1) prohibits processing it unless one of the exceptions in Article 9(2) applies, such as health care under 9(2)(h). Article 9(4) lets member states add "further conditions, including limitations".[^gdpr9] - **Belgium adds its own.** The Act of 30 July 2018, Article 9, requires the controller, and where relevant the processor, to name the categories of people who have access to health data, keep that list available for the data protection authority, and bind those people to confidentiality.[^be] Your software should be able to produce that list from its roles. - **Whoever builds or runs it may be a processor.** If a developer can see real patient data, GDPR Article 28 requires a contract, and the processor acts "only on documented instructions from the controller".[^gdpr28] The clinic stays the controller. - **A large-scale system needs an impact assessment.** GDPR Article 35(3)(b) requires one for "processing on a large scale of special categories of data".[^gdpr35] The assessment is the clinic's. The builder should supply the data map it is built on. ## What is coming next? Two European laws will matter more over the next few years. | Law | What applies when | | --- | --- | | European Health Data Space | In force since 26 March 2025. Key parts apply from March 2029. It sets "strict security and interoperability criteria for EHR systems", with manufacturers required to certify compliance.[^ehds] | | AI Act | Prohibited practices and AI literacy duties since 2 February 2025. Transparency rules since August 2026. High-risk rules for Annex III uses from 2 December 2027. AI inside products regulated under Annex I has a transition period until 2 August 2028.[^aiact] | Two parts of the AI Act are worth knowing now. Article 50(1) says a system that talks to people must be designed so they "are informed that they are interacting with an AI system".[^art50] And Annex III lists "emergency healthcare patient triage systems" as high-risk.[^annex3] So an AI feature that sorts incoming patient requests by urgency needs a careful look before it is designed, not after. For the overlap between the two regimes, the medical device group published MDCG 2025-6, a FAQ on the MDR and the AI Act, in June 2025.[^list] ## Have I built clinic software myself? Yes. I have designed and built one multi-clinic platform, with patient records, 3D insole design in the browser and a line to a 3D printer. It is shown, with recreated screens, on the [health page](https://www.theweb0.com/health). ## What should be settled before anyone builds? This is the list I would want answered before design starts. Most of it is the clinic's to own. All of it is cheaper to settle on paper than in code. - One sentence of intended purpose for each module, written down and kept. - Your website, app store listing and sales deck read against those sentences, word by word. - A named regulatory contact who reads the intended purpose before the first screen is designed. - A data map: what is stored, where it lives, who can see it and how long it is kept. - A hosting region, chosen and written down, with the providers that sit behind it. - Roles that match the list of people with access, so the software can print it. - An access log: who opened which record, and when. - A data processing agreement with anyone who builds or runs it and can see real patient data. - AI features labelled as AI, with a person deciding, and nothing that makes a clinical call unless it was scoped as a device from the start. The [health page](https://www.theweb0.com/health) shows how I handle patient data on a build, and what I will not claim about it. [^mdcg]: Medical Device Coordination Group, MDCG 2019-11 rev.1, guidance on the qualification and classification of software under the MDR (Regulation (EU) 2017/745) and the IVDR (Regulation (EU) 2017/746). First published October 2019, revised June 2025. The guidance itself says it is not legally binding. [PDF on health.ec.europa.eu](https://health.ec.europa.eu/document/download/b45335c5-1679-4c71-a91c-fc7a4d37f12b_en?filename=mdcg_2019_11_en.pdf), checked 11 November 2026. [^list]: The Commission's list of MDCG guidance has MDCG 2025-6 under its full title, "FAQ on Interplay between the Medical Devices Regulation (MDR) & In vitro Diagnostic Medical Devices Regulation (IVDR) and the Artificial Intelligence Act (AIA)". It also has the infographic "Is your software a Medical Device?" (March 2021), MDCG 2025-4 on medical device apps on online platforms (June 2025) and MDCG 2019-16 rev.1 on cybersecurity. [health.ec.europa.eu](https://health.ec.europa.eu/medical-devices-sector/new-regulations/guidance-mdcg-endorsed-documents-and-other-guidance_en), checked 11 November 2026. [^gdpr9]: GDPR, Article 9, "Processing of special categories of personal data". [gdpr-info.eu](https://gdpr-info.eu/art-9-gdpr/), checked 11 November 2026. [^be]: Wet van 30 juli 2018 betreffende de bescherming van natuurlijke personen met betrekking tot de verwerking van persoonsgegevens, artikel 9. [Justel](https://www.ejustice.just.fgov.be/eli/wet/2018/07/30/2018040581/justel), checked 11 November 2026. [^gdpr28]: GDPR, Article 28, "Processor". [gdpr-info.eu](https://gdpr-info.eu/art-28-gdpr/), checked 11 November 2026. [^gdpr35]: GDPR, Article 35, "Data protection impact assessment". [gdpr-info.eu](https://gdpr-info.eu/art-35-gdpr/), checked 11 November 2026. [^ehds]: European Commission, "European Health Data Space Regulation (EHDS)". [health.ec.europa.eu](https://health.ec.europa.eu/ehealth-digital-health-and-care/european-health-data-space-regulation-ehds_en), checked 11 November 2026. [^aiact]: European Commission, "AI Act". The dates reflect the AI Omnibus, which entered into force on 27 July 2026. [digital-strategy.ec.europa.eu](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai), checked 11 November 2026. [^art50]: AI Act, Article 50(1). [artificialintelligenceact.eu](https://artificialintelligenceact.eu/article/50/), checked 11 November 2026. [^annex3]: AI Act, Annex III, point 5(d). [artificialintelligenceact.eu](https://artificialintelligenceact.eu/annex/3/), checked 11 November 2026.