Healthtech MVP Development: Health Data, MDR and Scope

A healthtech MVP in the EU is shaped by two questions before any feature: is the data health data under the GDPR, and is the software a medical device under the MDR? Health data is almost always yes, which means Article 9 conditions, a risk assessment and careful hosting. The medical device question is the one you can often design around in version one, by testing a product without a medical purpose first. With Easify, a healthtech MVP outside the device rules typically costs €8,000 to €25,000 over 6 to 12 weeks.

Below: health data under GDPR Article 9, when software becomes a medical device according to the official texts, a feature-by-feature device check, ways to start without becoming one, pilots with clinics, security, the build step by step, a worked example, cost drivers, a brief template you can copy, questions to ask a partner, common mistakes, a pre-launch checklist, and when not to hire us. This is orientation from the official sources, not legal or regulatory advice.

At a glance

Health data under GDPR Article 9

The GDPR defines data concerning health as personal data about a person's physical or mental health, including the provision of health care services, that reveals information about their health status (Article 4(15)). An appointment with a psychiatrist, a symptom diary and a step count linked to a condition can all qualify.

Article 9(1) prohibits processing it unless one of the exceptions in Article 9(2) applies. The two a startup usually relies on:

• Explicit consent (Article 9(2)(a)), for a specific purpose. Explicit means a clear, separate, affirmative act, not a line in the terms.
• Health or social care (Article 9(2)(h)), on the basis of law or a contract with a health professional, and under an obligation of professional secrecy (Article 9(3)). This fits a product used by or on behalf of clinicians more than a consumer app.

Three more points that change the build:

• National rules. Article 9(4) lets Member States add conditions for health data. Plan for one launch country and check its rules.
• A data protection impact assessment. Large-scale processing of special categories is one of the cases where Article 35(3) requires one. Write it during the scope, not after launch.
• A data protection officer. If processing health data at scale is your core activity, Article 37 may require one.

When software becomes a medical device

The Medical Device Regulation (MDR) defines a medical device as anything, software included, intended by the manufacturer for specific medical purposes, among them diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease (Article 2(1)).

What decides it is the intended purpose: the use the manufacturer states on the label, in the instructions for use, or in promotional or sales materials (Article 2(12)). Recital 19 adds that software for general purposes, even when used in a healthcare setting, and software intended for lifestyle and well-being purposes is not a medical device.

The Medical Device Coordination Group's guidance, MDCG 2019-11 rev.1 (June 2025), sets out decision steps. In short: software that performs an action on data beyond storage, archival, communication, simple search or lossless compression may be medical device software, and the next question is whether that action is for the benefit of individual patients. Software that only aggregates population data or provides generic pathways not directed at individual patients is given as an example that is not. The guidance itself says it is not legally binding.

If the software is a device, Rule 11 in Annex VIII usually classifies it:

• Software that provides information used to take diagnostic or therapeutic decisions is class IIa, rising to IIb or III where those decisions could cause serious deterioration of health or death.
• Software that monitors physiological processes is class IIa, or IIb for vital parameters where variations could mean immediate danger.
• All other software is class I.

The class matters because class I devices can be self-declared by the manufacturer after drawing up the technical documentation (Article 52(7)), while class IIa and above need a notified body (Article 52(3) to (6)). AI that is part of a device needing a notified body is also high-risk under the EU AI Act, and after the 2026 Digital Omnibus on AI those obligations apply from 2 August 2028.

A feature-by-feature device check

Most founders do not have one product; they have a list of features, and the device question can flip on one of them. The table applies the MDCG steps above to features that come up often in health MVPs. It shows the direction the guidance points, not a ruling: your regulatory adviser decides on the actual wording and behaviour.

The pattern is simple: store, show, send and schedule are usually safe; interpret, score, decide and alert are where the device rules start.

Ways to start without becoming a medical device

The aim is not to dodge the rules. It is to answer your first business question with a product that genuinely has no medical purpose, and to take the device route deliberately later if the evidence says so.

• Administration and access. Booking, intake forms, reminders, payments and records that are stored and shown, not interpreted. The MDCG guidance says hospital information systems for admission, scheduling and billing are not medical devices in themselves.
• Communication. Secure messaging between patients and clinicians, where the clinician makes every decision.
• Well-being. Sleep, fitness or stress products that make no claim about disease. Watch the marketing: "helps you relax" and "reduces anxiety symptoms" are different intended purposes.
• Service, not software. A clinician reviews what the user submits and gives advice. The software carries the service; it does not produce the clinical output.
• Manual first. Calculate the score or the recommendation by hand in a pilot, and build the algorithm only when you know it is worth certifying.

Write the intended purpose statement in the scope document, and make your website, app store listing and pitch deck match it. A single sentence in an investor deck can be read as promotional material.

If you build an electronic health record system, or a well-being app that claims to exchange data with one, note the European Health Data Space Regulation. It applies from 26 March 2027 with later dates for parts of it (Article 105), and introduces requirements for EHR systems and a label for well-being apps that claim interoperability with them.

Consent and EU hosting

• Separate consents. Consent to the service, explicit consent for health data, and any consent to research use or marketing should each be their own choice, recorded with a time and a version.
• Withdrawal that works. A user who withdraws consent must stop being processed for that purpose, which reaches backups and analytics as well as the main database.
• Minimise. Collect the health data the flow needs, not what might be interesting later.
• No health data in analytics or logs. Page names, event properties and error reports leak it more often than the database does.
• EU hosting. We deploy client products to EU data-centre regions, so your product is hosted in the EU. Our engineers work from India, so any access they have to production data is a transfer outside the EU that needs a valid mechanism under GDPR Chapter V. For health data we keep that access to a minimum, and use synthetic data during the build.

Pilots with clinics and hospitals

Many health MVPs are tested with one clinic, practice or ward rather than with the public. That changes who is responsible for the data, and what the clinic will ask before it lets you in.

• Controller or processor. If the clinic decides why and how patient data is processed and uses your product as its tool, the clinic is usually the controller and you are its processor. Under Article 28, a controller may use only processors that give sufficient guarantees, and the processing has to be governed by a contract (a data processing agreement) that sets out its subject matter, duration, nature, purpose, types of data and categories of people. Have yours drafted before the pilot, not on the morning it starts. If patients sign up to you directly, you are the controller yourself.
• Your own processors. Your hosting provider, email service and error tracker are processors to you. List them in the scope, check where each one stores data, and keep health data out of the ones that do not need it.
• The security questionnaire. Clinics and hospitals often send one before a pilot. It asks about encryption, access control, backups, logging, incident handling and where data is hosted. A product built to the checklist in this post can answer most of it; the gaps are usually policies on paper, which you write once.
• Integration later, standards now. Do not integrate with the clinic's record system for a first test. Export a PDF or a file the clinician can upload. Design your data model with HL7 FHIR in mind, which HL7 describes as a standard for exchanging healthcare information electronically, built from resources, so that a later integration is a mapping job rather than a rewrite.
• A pilot agreement. Alongside the data processing agreement, agree in writing what the clinic will test, for how long, who the clinical lead is, and what counts as success. That last line is your MVP's question.

Security you do not cut, and debt you can take

An MVP is allowed to be rough. In healthtech, some parts are not. GDPR Article 32 asks for security appropriate to the risk, and names pseudonymisation and encryption, the ongoing confidentiality, integrity, availability and resilience of systems, the ability to restore data after an incident, and a process for regularly testing those measures. Under Article 33, a controller must notify a personal data breach to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to people. A processor must tell the controller without undue delay. That is a process you need on day one of the pilot, not after the first incident.

The left column is expensive to retrofit because it touches every screen and every table. The right column is cheap to add once the pilot says the product is worth it.

How to build a healthtech MVP, step by step

1. Write the question. One sentence: what the MVP must prove, for whom, in which setting. For example: will physiotherapy patients log their home exercises three times a week if their therapist sees the log? Not a feature list.
2. Write the intended purpose. What the product is for, and what it is not for, in the words you will use in marketing. Run it past a regulatory adviser if any feature sits in the lower rows of the device table above.
3. Map the data. Which health data you collect, from whom, on which legal basis under Article 9, where it is stored, and who can see it. Decide whether you are controller or processor in the pilot.
4. Fix the scope. The smallest set of flows that answers the question, the features deliberately left out, and the launch country. This is where the data protection impact assessment starts.
5. Prototype the riskiest flow. A clickable prototype of the one flow patients or clinicians must accept, tested with five or so real users before the build. Cheap to change at this point.
6. Build in short cycles. Weekly or fortnightly demos, synthetic data only, and the security column above in place from the first sprint.
7. Prepare the pilot. Data processing agreement, privacy notice, consent texts, the security questionnaire answered, backups tested, and the breach procedure written.
8. Pilot and measure. Run it with one clinic or one group of users, against the success line in the pilot agreement. Decide from the evidence whether to grow, change course or take the device route.

Minimum feature set checklist

• An intended purpose statement, agreed before design
• Sign-up with strong authentication; two-factor for clinicians and admins
• Explicit, separate, recorded consents, with withdrawal
• The one flow you are testing: booking, intake, messaging, tracking or a clinician review
• Role-based access, enforced on the server, so a user sees only their own data and a clinician only their patients
• Encryption in transit and at rest, and EU-region hosting
• Audit log of who viewed or changed health data
• Data export and deletion on request
• Admin view without access to clinical content unless the role needs it
• Privacy notice, terms and a completed data protection impact assessment

What to leave out of version one

• Diagnosis, triage and treatment recommendations. They make the software a device. Do them by hand in the pilot if you need them.
• Integrations with hospital systems. Each one is a procurement and security process. Export a document instead.
• Several countries. National health data rules differ. Launch in one.
• Wearable and device integrations. Start with manual entry or a single source.
• AI on health data. Add it once the purpose, the data basis and the risk assessment are settled. Our AI MVP guide covers model providers and the GDPR.
• Native apps. A responsive web app is usually enough for a first test, unless the phone's sensors are the product.

Worked example: a physiotherapy follow-up MVP

A fictional product, to show how the pieces fit. It is not a client project.

The question. Will patients do their home exercises more consistently if their physiotherapist can see a simple log between sessions?

Intended purpose. "A tool for physiotherapy practices to share exercise plans written by the therapist and let patients record which exercises they did and how they felt. It does not assess, diagnose or recommend treatment." Every adjustment to the plan is made by the therapist.

Data and roles. The practice is the controller and the product is its processor, under a data processing agreement. Health data: the exercise log and notes. Hosting in an EU region. Synthetic patients during the build.

Where it would fall. In the "patient and clinician platform" row below, likely towards its lower end: around €14,000 to €18,000 and 8 to 10 weeks with us. Illustrative, not a quote; the real figure comes from the scope.

Pilot. One practice, a few therapists and their consenting patients, for a fixed period agreed with the practice, with the success line written down before it starts.

Typical scope and price

Illustrative ranges inside our €5,000 to €25,000 MVP band, not a quote, for products outside the medical device rules. The MVP cost calculator gives a range for your own scope.

The honest note: if the product is a medical device, the software is rarely the largest cost. A quality management system, technical documentation, clinical evaluation and, from class IIa, a notified body come first, and they need a regulatory specialist, which we are not. We can build to their requirements; we cannot replace them.

For how founders fund a build like this, see our guides to MVP grants and funding in Europe and EU funding for startups. For prices across Europe more broadly, see MVP development cost in Europe.

What drives the cost of a healthtech MVP

The price moves with these, roughly in order of how much they move it:

• Number of roles. Patient only is the cheapest. Patient, clinician, practice admin and your own support team each need their own views and their own access rules, tested.
• Who controls the data. A consumer app where you are controller needs your own consent flows and privacy notice. A clinic tool where you are processor needs multi-practice separation, so one clinic never sees another's patients.
• Consent complexity. One explicit consent is simple. Separate consents for care, research and marketing, each with versioning and withdrawal, add screens and logic.
• Audit and export. A proper audit log and complete export and deletion touch every data table.
• Integrations. Payments and calendar sync are routine. Video consultation, record systems, labs and wearables each add a separate piece of work, and the last three often add a procurement process too.
• Native apps. Building for iOS and Android as well as the web adds a second and third front end.
• Languages and countries. Each one adds translation, local rules and testing.
• The device route. Once a feature is a medical device, the work moves under a quality system and out of the MVP band.

Copy this brief before you talk to anyone

Fill this in, even roughly, before you ask a developer for a price. It is the same information we ask for, and any serious partner will need it.

Questions to ask a healthtech development partner

Ask these of anyone you consider, including us:

• Where will the product and its backups be hosted, and who on your team can access production health data, from which country?
• How do you enforce access so that a clinician sees only their own patients? Is it checked on the server?
• What goes into the audit log, and can I export it?
• Will you use real patient data during the build? (The right answer is no.)
• Which of my planned features do you think could make the software a medical device, and what would you do instead?
• Will you sign a data processing agreement, and do you have a breach procedure that fits the 72-hour window?
• Who owns the code, the hosting accounts and the data at the end?
• What is fixed in your price, and what happens when the scope changes?
• Do you have healthtech case studies? If not, say so. (We do not.)

For partner choice in general, see how to choose an MVP development agency and agency vs freelancer vs no-code.

Common mistakes

• Writing features before the intended purpose. The features then decide the regulatory route for you, usually the expensive one.
• Marketing ahead of the product. A landing page that says "detects early signs of" makes the product a medical device candidate, whatever the code does.
• Real patient data in development. Test data, screenshots and bug reports end up holding health data that nobody planned for.
• Analytics on every screen. A screen called "depression check-in" in an analytics tool is health data sent to a third party.
• One consent box for everything. It fails the "explicit" and "specific" tests and cannot be withdrawn for one purpose only.
• Building the integration first. Months go into connecting to a record system before anyone knows whether clinicians want the product.
• Planning for every country. National rules, languages and reimbursement differ. One launch country keeps the test clean.
• Treating the pilot clinic's paperwork as an afterthought. The data processing agreement and security questionnaire can take longer than the build.

Pre-launch checklist

Before the first real patient or clinician signs in:

• Intended purpose statement final, and the website, app store text and deck match it
• Data protection impact assessment written and signed off
• Privacy notice and consent texts final, in the launch language
• Data processing agreement signed with the pilot clinic, if you are their processor
• Your own processors (hosting, email, error tracking) listed, with where each stores data
• Two-factor sign-in on for clinicians and admins
• Access rules tested with two patients and two clinicians who must not see each other's data
• Health data checked absent from analytics, logs and error reports
• Backups running, and one restore tested
• Breach and incident procedure written, with who calls whom
• Export and deletion tested end to end
• Synthetic data removed and the production database clean

Selling to US providers too: a note on HIPAA

Many healthcare MVP guides lead with HIPAA because they are written for the US. It is a US law, and according to the CDC's summary the Privacy Rule applies to covered entities (health plans, health care clearinghouses, and health care providers who send health information electronically for certain standard transactions) and to business associates who handle identifiable health information on their behalf. A product for European users is governed by the GDPR. If you also sell to US providers or insurers, you will likely be their business associate, and HIPAA becomes a separate workstream with its own adviser.

After the MVP: the device route and reimbursement

If the pilot shows that the clinical feature you did by hand is what users value, that is the moment to take the device route on purpose: a regulatory specialist, a quality management system, the classification under Rule 11, and a build under design controls.

Reimbursement can make that route worth it. In Germany, for example, § 33a of the Social Code Book V gives people with statutory health insurance a claim to digital health applications (DiGA): medical devices of class I, IIa or IIb whose main function rests on digital technology and that support the detection, monitoring, treatment or alleviation of disease, and which are already placed on the market. The BfArM assesses applications before listing them in its directory of reimbursable DiGA, through a fast-track procedure. Your MVP, built outside the device rules, is the evidence for whether that investment makes sense.

Start with the Scoping Sprint

For a health product, the €900 MVP Scoping Sprint is the step we recommend first, and the €900 is credited in full against the build if you build with us. In about two weeks you get, in writing: the one question the MVP must answer, the smallest feature set that answers it, what is deliberately left out, the main user flows, the technical and hosting plan, and a fixed price and timeline for the build. For healthtech we also write down the intended purpose the scope assumes and where health data flows, so a regulatory adviser can check both before anything is built. The scope is yours to keep whatever you decide. If you already have a prototype, the €99 Prototype Check gives you its top risks in writing within 48 hours, and is also credited against the build. For general timing, see how long an MVP takes.

When not to hire us

• The product is a medical device from day one. Start with a regulatory consultant and a quality system; bring in developers once the design controls exist.
• You want an agency with healthtech case studies. We have none yet. We take healthtech work and say so plainly.
• You need hospital integrations to test the idea. That is a procurement project before it is a build.
• You are not ready to write the intended purpose. Until you can, any scope is a guess.

For how we run MVPs generally and what you own at the end, see MVP development.