Building a healthtech MVP in the EU: health data under GDPR Article 9, when software becomes a medical device under the MDR, the build steps and cost.

Source: https://easifytechnologies.com/healthtech-mvp-development/

Insights Articles

Healthtech MVP Development: Health Data, MDR and Scope

20 October 2026 22 min read

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.

Work with us

Building a health product and need to test it without walking into the medical device rules?

Start a conversation ↗ MVP Development

At a glance

Question

Answer

Typical price with Easify

€8,000 to €25,000 for an MVP outside the medical device rules. Illustrative, not a quote

Timeline

6 to 12 weeks for the build, after the scope is agreed

Health data

A special category under GDPR Article 9: prohibited unless an exception applies

Medical device test

The intended purpose: diagnosis, prevention, monitoring, prediction, prognosis or treatment of disease makes software a device

Ways to start outside the MDR

Booking, administration, messaging, care coordination, well-being, or a clinician-only pilot without a medical claim

Hosting

Hosted in the EU, on EU data-centre regions

If it is a device

Class I can be self-declared; class IIa and above need a notified body. That work is outside our MVP band

First step

The €900 MVP Scoping Sprint, with the intended purpose written down before the features. Credited in full against the build if you build with us

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.

What the feature does

What the MDCG steps point to

Typical version-one move

Books appointments, sends reminders, takes payment

Administration; the guidance names admission, scheduling and billing systems as not devices in themselves

Build it

Stores a symptom diary and shows it back to the patient and clinician unchanged

Storage, archival and display, with the clinician deciding

Build it, with careful wording

Secure chat between patient and clinician

Communication

Build it

Shows population statistics or a generic care pathway

Not directed at individual patients

Build it

Calculates a risk score or flags a patient from their own data

An action on data for an individual patient's benefit: likely a device, and Rule 11 points to class IIa or above

Do it by hand in the pilot

Suggests a diagnosis, triage level, dose or treatment

A medical purpose by definition

Leave it out, or take the device route deliberately

Monitors vital signs and alerts on change

Monitoring physiological processes: class IIa, or IIb where variations could mean immediate danger

Leave it out of version one

Well-being coaching with no claim about disease

Recital 19 excludes lifestyle and well-being purposes

Build it, and keep the marketing consistent

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.

Do not cut in version one

Fine to keep simple in version one

Server-side access control by role and by patient

Visual design polish and animations

Encryption in transit and at rest

Admin tools: a basic table view is enough

Audit log of who viewed or changed health data

Reporting dashboards

Tested backups and a restore you have actually run

Automated onboarding emails beyond the essentials

Consent records with time and version

Multiple languages

A written breach and incident procedure

Native apps, if the browser does the job

Health data kept out of analytics and logs

Performance work for scale you do not have yet

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.

In version one

Left out, and why

Practice and therapist accounts with two-factor sign-in

Automatic plan adjustments from pain scores: an action on data for an individual patient, likely a device

Patient invitation by the therapist, with explicit consent for health data

Wearable or camera tracking of exercises: integration cost and a monitoring purpose

Exercise plan written by the therapist, with videos

Integration with the practice's record system: export a PDF instead

Patient log: done or not, and a free-text note

Second country and second language

Therapist view of each patient's log, unchanged

Native apps: a responsive web app first

Reminders, audit log, export and deletion

Any AI summary of patient notes

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 €4,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.

Scope

What it includes

Price

Time

Booking and intake

Service pages, booking, intake forms with explicit consent, reminders, payments, clinician and admin views

€8,000 to €14,000

6 to 8 weeks

Patient and clinician platform

The above plus secure messaging, documents, role-based access, audit log, export and deletion

€14,000 to €25,000

8 to 12 weeks

Medical device software

Software under a quality management system, with design controls, risk management and clinical evaluation

Above our MVP band

Months

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.

Field

What to write

The question

One sentence: what the MVP must prove, for whom, in which setting

Users and roles

Patients, clinicians, admins, carers: who logs in, and what each one does

Intended purpose

What it is for, and what it explicitly does not do, in your marketing words

Health data

What you collect, from whom, and the Article 9 basis you expect to rely on

Controller or processor

Do patients sign up to you, or does a clinic use you as its tool?

The one flow

The single journey the pilot tests, step by step

Left out on purpose

The features you are deliberately not building yet

Launch country

One country, and its language

Pilot partner

The clinic or user group, if you have one, and what they expect

Integrations

Only those the test cannot run without

Deadline and budget

A date that matters, such as a pilot start or a funding round, and a range

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.

Work with us

Building a health product and need to test it without walking into the medical device rules?

We are a Budapest team that builds MVPs for founders across Europe, working remotely on CET, and we deploy to EU data-centre regions. We have no healthtech case study yet, so we will say clearly where your regulatory adviser has to decide. Send us who the product is for, what it does with health data, what you plan to claim about it and your deadline, or ask for the €900 MVP Scoping Sprint, which is credited in full against the build if you build with us. We reply within one business day.

Start a conversation ↗ MVP Development

Recent builds

• [

  

  Nonstop Nanny · Childcare

  Web MVP and SEO for a Babysitter Booking Platform

  • MVP

  • SEO

  • WordPress

  • WooCommerce

  ](https://easifytechnologies.com/case-study/nonstop-nanny/)

• [

  

  Easify AI · SaaS & AI

  AI MVP Development for a Database Querying SaaS

  • MVP

  • WordPress

  • React

  ](https://easifytechnologies.com/case-study/easify-ai/)

• [

  

  Meetlyr · SaaS & AI

  Product Design and Build for a Social Discovery App

  • UI/UX

  • WordPress

  • React

  ](https://easifytechnologies.com/case-study/meetlyr/)

On this page

• At a glance
• Health data under GDPR Article 9
• When software becomes a medical device
• A feature-by-feature device check
• Ways to start without becoming a medical device
• Consent and EU hosting
• Pilots with clinics and hospitals
• Security you do not cut, and debt you can take
• How to build a healthtech MVP, step by step
• Minimum feature set checklist
• What to leave out of version one
• Worked example: a physiotherapy follow-up MVP
• Typical scope and price
• What drives the cost of a healthtech MVP
• Copy this brief before you talk to anyone
• Questions to ask a healthtech development partner
• Common mistakes
• Pre-launch checklist
• Selling to US providers too: a note on HIPAA
• After the MVP: the device route and reimbursement
• Start with the Scoping Sprint
• When not to hire us

Frequently asked

Is my health app a medical device?

It depends on its intended purpose, which the MDR defines by what you say on the label, in the instructions and in your marketing. Software intended for diagnosis, prevention, monitoring, prediction, prognosis or treatment of disease is a medical device. Software for general purposes, even in a healthcare setting, and software for lifestyle and well-being is not. The MDCG 2019-11 guidance sets out the decision steps. This is orientation, not legal advice.

Can I start a healthtech product without becoming a medical device?

Often, yes. Booking, patient administration, secure messaging, care coordination and well-being products can usually be built and tested without a medical purpose, and the MDCG guidance says hospital information systems for admission, scheduling and billing are not medical devices in themselves. Your wording matters as much as your code: a claim to detect or treat a condition can turn the same software into a device.

What does GDPR require for health data?

Health data is a special category under Article 9, so processing it is prohibited unless an exception applies, such as explicit consent or the provision of health care under a contract with a health professional. You also usually need a data protection impact assessment, security measures such as encryption under Article 32, a plan to report breaches within 72 hours under Article 33, and Member States may add their own conditions for health data.

How much does a healthtech MVP cost?

With Easify, a healthtech MVP outside the medical device rules typically costs €8,000 to €25,000 over 6 to 12 weeks. That is illustrative, not a quote. If the product is a medical device of class IIa or above, the notified body, quality system and clinical evaluation come on top and usually cost far more than the software.

How long does it take to build a healthtech MVP?

With us, the build typically takes 6 to 12 weeks once the scope is agreed, and the scope itself takes about two weeks in the €900 MVP Scoping Sprint, which is credited in full against the build if you build with us. A pilot with real patients or clinicians then needs its own weeks, and a hospital's security and data protection review can take longer than the build.

Do I need to integrate with an EHR or hospital system for my MVP?

Usually not. Each integration is its own procurement and security process. For a first test, export a document or a file the clinician can upload, and keep your data model close to a standard such as HL7 FHIR so that a later integration is a mapping job rather than a rewrite.

Does HIPAA apply to a European health app?

HIPAA is a US law. It applies to covered entities, meaning health plans, health care clearinghouses and providers who send health information electronically for standard transactions, and to their business associates. A product for European users is governed by the GDPR instead. If you also sell to US providers or insurers, you will likely be their business associate, and HIPAA becomes a separate workstream.

Do I need to host health data in the EU?

The GDPR does not strictly require it, but transfers outside the EU need a valid mechanism, and hospitals, insurers and many users will expect EU hosting. We deploy client products to EU data-centre regions, so your product is hosted in the EU.

Keep reading

• [

  

  Edtech MVP Development: Buyers, Children's Data and Scope

  ](https://easifytechnologies.com/edtech-mvp-development/)

• [

  

  Enterprise Ireland Funding for Startups Building an MVP

  ](https://easifytechnologies.com/enterprise-ireland-funding-for-startups/)

• [

  

  EU Funding for Startups: Can It Pay for Your MVP?

  ](https://easifytechnologies.com/eu-funding-for-startups-mvp/)

Want this done properly on your own site?

Start a conversation ↗