Short answer: software that touches health data answers to four families of rules at once. Data protection says what you may do with personal health data: the GDPR's Article 9 in the EU, HIPAA and a patchwork of state laws in the US. Health-system rules say how data must move and be shared: the European Health Data Space (EHDS) in the EU, TEFCA, USCDI and the information-blocking rules in the US. Product safety applies when the software does something medical: the Medical Device Regulation (MDR) and the In Vitro Diagnostic Regulation (IVDR) in the EU, FDA rules in the US, with IEC 62304 and ISO 13485 as the engineering and quality standards behind them. Security sets the baseline everyone must meet: ISO 27001 and 27799, NIS2 for critical sectors, the HIPAA Security Rule. Identity (eIDAS and the EU Digital Identity Wallet, NHS login, national IDs) cuts across all four.
The map
The health data regulation map groups the rules for software handling health data into families: data protection (GDPR Article 9, HIPAA, US state laws), health-system rules (EHDS, Cures Act, TEFCA), product safety (MDR, IVDR, FDA), engineering and quality standards (IEC 62304, ISO 13485), security (ISO 27001, ISO 27799, NIS2, HIPAA Security Rule) and identity (eIDAS 2).
| Family | Rule | Applies to | What it asks |
|---|---|---|---|
| Data protection | GDPR, Art. 9 and Art. 35 | Anyone processing EU residents' health data | A legal basis from Art. 9(2), a DPIA, a DPO for large-scale processing, rights, breach notification in 72 h |
| Data protection | HIPAA (Privacy, Security, Breach Rules) | US covered entities and their business associates | Permitted uses, safeguards, breach notification; does not cover most consumer apps |
| Data protection | US state laws (CCPA/CPRA, Washington My Health My Data…) | Businesses handling residents' data | Consent for consumer health data, deletion rights, sale restrictions |
| Health system | EHDS, Regulation (EU) 2025/327 | EHR systems, wellness apps claiming interoperability, data holders, health data access bodies | Patient access and portability in the European exchange format, mandatory MyHealth@EU, secondary-use permits |
| Health system | 21st Century Cures Act, ONC HTI rules, TEFCA | US certified health IT, providers, networks | FHIR APIs, USCDI data, no information blocking, nationwide exchange |
| Product safety | MDR 2017/745, IVDR 2017/746 | Software with a medical purpose for EU patients | Classification, conformity assessment, clinical evaluation, post-market surveillance, CE marking |
| Product safety | FDA (21 CFR 820/QMSR, 510(k), De Novo, PMA) | Software as a medical device for the US | Premarket pathway by class, quality system, cybersecurity documentation |
| Engineering | IEC 62304, IEC 82304-1, ISO 14971 | Medical device software teams | Software lifecycle by safety class, risk management |
| Quality | ISO 13485 | Device manufacturers | A quality management system covering design, production, complaints |
| Security | ISO/IEC 27001, ISO 27799, ISO 27701 | Any organisation; health-specific guidance | An information security management system, health controls, privacy extension |
| Security | NIS2, Directive 2022/2555 | Healthcare providers, device makers, cloud and digital providers above size thresholds | Risk measures, incident reporting in 24/72 h, management liability |
| Security | HIPAA Security Rule | US covered entities and business associates | Administrative, physical and technical safeguards; risk analysis |
| Identity | eIDAS 2 and the EU Digital Identity Wallet | Services that verify EU citizens' identity | Acceptance of the wallet for strong identification from 2026–2027 |
Who is in scope for what
Which health data rules apply depends on what the software does. A consumer app without medical claims answers to GDPR Article 9, a DPIA and security practice; adding interpretation makes it a medical device under the MDR; a FHIR platform is a GDPR processor and sometimes under NIS2; a hospital carries all of these plus NIS2 as an essential entity.
- A consumer health app with no medical claims (a diary of symptoms, a record of lab reports): GDPR Article 9 with explicit consent, a DPIA, security practice at ISO 27001 level, and the EHDS wellness-app label if it claims to connect to EHR systems. Not a medical device, as long as its intended purpose stays non-medical. In the US: FTC rules and state health-privacy laws rather than HIPAA.
- The same app with an interpretation feature ("your result suggests…"): a medical device under MDR Rule 11, usually class IIa, with IEC 62304 and ISO 13485 behind it. See Is a health app a medical device? and SaMD classes.
- A FHIR platform or integration vendor: GDPR as processor (Article 28 contracts), ISO 27001, possibly NIS2 as a digital infrastructure or ICT service provider, EHDS obligations when it is part of an EHR system, HIPAA as a business associate in the US.
- A hospital: everything above as controller and operator, plus NIS2 as an essential entity, national health-record laws, and the EHDS deadlines for connecting to national infrastructure.
- A research platform: GDPR Article 9(2)(j) and Article 89, the EHDS secondary-use chapter (permits from a health data access body, secure processing environments), and anonymisation standards. See Secondary use of health data.
In what order
Health data compliance is best approached in a fixed order: first write the intended purpose, because it decides whether the software is a medical device; then data protection (legal basis, DPIA, processor contracts); then a security baseline along ISO 27001; then interoperability mandates such as FHIR and EHDS or USCDI; then the device route, if any; finally cross-border questions.
- Decide the intended purpose in writing. It determines whether you are a medical device, and everything else follows from it.
- Data protection first: legal basis, DPIA, processor contracts, DPO. These are needed before the first real user, in every scenario. See GDPR Article 9 for health data and DPIA for a health app.
- Security baseline: an ISMS along ISO 27001, mapped to the health controls of 27799; this also answers most of NIS2 and the HIPAA Security Rule. See ISO 27001 vs ISO 27799 and NIS2 for hospitals and vendors.
- Interoperability mandates: FHIR and the exchange format of your market (EHDS, USCDI/US Core) so the product is not locked out of national infrastructure. See USCDI explained and TEFCA explained.
- Device route, if any: classification, quality system, lifecycle, notified body or FDA pathway. Budget a year.
- Cross-border: HIPAA vs GDPR differences when serving both markets (HIPAA vs GDPR), transfer mechanisms, hosting location.
Where Anpheros stands
Anpheros Daily is a personal health record with a stated non-medical intended purpose: it stores, shows and shares, and it does not interpret or recommend. Anpheros Platform is a FHIR R4 backend offered to clinics and developers as a processor under GDPR Article 28, with patient-controlled consent and access logs. The regulation pages in this cluster describe the rules as they apply to any product of this kind; the transparency page describes how Anpheros applies them to itself.
This page explains regulation for product and engineering teams. It is not legal advice; the texts linked under Sources are the authority, and your data protection officer, notified body or counsel decides for your case. Last reviewed: October 2026.
Related pages
- Is a health app a medical device? EU MDR Rule 11
- Your medical data in the EU: GDPR, EHDS and your rights
- GDPR Article 9 for health data
- DPIA for a health app
- HIPAA vs GDPR
- NIS2 for hospitals and health-tech vendors
- Healthcare interoperability standards: the map
- GDPR for developers (developer site)
- National electronic health records in Europe and the US
- MyHealth@EU and the cross-border patient summary
- The EU AI Act and health AI
- Secondary use of health data
- Security and identity in health apps
Sources
- Regulation (EU) 2016/679 (GDPR), EUR-Lex
- Regulation (EU) 2025/327 (European Health Data Space), EUR-Lex
- Regulation (EU) 2017/745 (MDR), EUR-Lex
- Regulation (EU) 2017/746 (IVDR), EUR-Lex
- Directive (EU) 2022/2555 (NIS2), EUR-Lex
- HHS: HIPAA for professionals
- ASTP/ONC: Trusted Exchange Framework and Common Agreement
- ISO/IEC 27001:2022
Frequently asked questions
Does GDPR apply to a US company with EU users?
Yes, under Article 3(2), as soon as it offers services to people in the EU or monitors their behaviour, regardless of where the servers are. It then needs an EU representative, a legal basis under Article 9 and a lawful transfer mechanism.
Is HIPAA stricter than GDPR?
Neither is strictly stricter. HIPAA is narrower in scope (covered entities and business associates only) and more prescriptive about safeguards; GDPR is broader (anyone processing EU residents' data), rights-based and requires a legal basis for every use. A product in both markets must meet both.
Does the EHDS replace GDPR for health data?
No. The EHDS builds on the GDPR and adds obligations for EHR systems, patient access, cross-border exchange and secondary use. GDPR remains the basis for every processing operation.
Where do I start if I have no compliance team?
Write the intended purpose, run a DPIA with a template, adopt an ISO 27001-style security baseline, and use FHIR with your market's profiles. Those four steps cover most of what a first audit or a first hospital customer will ask for.
Try it free in the sandbox
Your first FHIR call in 5 minutes. An HL7 FHIR R4 API with the patient's consent built in: try it in the sandbox, then connect your own app or clinic system.
Free · 30 synthetic patients · no card
Anpheros builds a medical record that the patient controls and can share with any clinic, on an HL7 FHIR R4 platform, based in the EU. These guides help you understand and organise your health; they do not replace your doctor.
About Anpheros →
AnpherosThe more you log, the clearer your record
Your health history in one place, under your control.
Free · Works in your browser · No card
