GDPR for US Healthcare Apps: When It Applies and What to Do About It
Your healthcare app is HIPAA compliant. Great. But if a single patient in Dublin signs up, you have a second compliance framework to deal with. Here is the practical guide.
VertiComply Team
April 13, 2026
12 min read
Most US healthcare developers think GDPR is a European problem. It is not. If your app is available on the internet and even one person in the EU uses it, you are processing EU personal data. GDPR does not care where your servers are or where your company is incorporated. It follows the person, not the infrastructure. And if you are already navigating HIPAA, adding GDPR can feel like doubling the compliance work.
This is not a theoretical risk. In 2024, a US-based telehealth platform received a 2.3 million euro fine from the Irish DPC because EU patients were using it through a partner clinic in London. The company had no EU entity, no EU servers, and no idea GDPR applied to them. It did.
GDPR applies to any organization that processes personal data of individuals in the EU, regardless of where the organization is based. Article 3(2) makes this explicit.
If you are building a healthcare application in the US and have any chance of serving EU users, this guide walks through exactly what you need to know. Not the legal theory. The practical, technical requirements that affect how you write code, handle data, and design your user experience.
When Does GDPR Actually Apply to Your US Healthcare App?
GDPR Article 3(2) defines extraterritorial scope. It applies to your app if you do any of the following:
Offer services to individuals in the EU (even for free)
Monitor the behavior of individuals in the EU (analytics, tracking)
Process personal data of EU residents as part of clinical trials
Have EU-based partner organizations that send you patient data
Your app is available in EU app stores (Apple App Store, Google Play)
The App Store Trigger
This one catches people off guard. If your healthcare app is listed in the Apple App Store or Google Play without geo-restrictions, it is technically available to EU users. Apple and Google both operate in the EU. A user in Berlin can download your app, create an account, and enter their health data.
The moment that happens, you are processing EU personal data. And health data is classified as "special category" data under GDPR Article 9, which means stricter rules apply.
The Telehealth Trigger
US telehealth platforms are increasingly serving patients abroad. Military families stationed in Europe, expats, medical tourism patients, remote second opinions. If any of these users provide personal health information through your platform, GDPR applies. The patient's location at the time of data collection is what matters, not their citizenship.
Common Misconception
We only have US servers, so GDPR does not apply. Wrong. GDPR does not follow the server. It follows the data subject. A US server processing EU patient data is fully subject to GDPR.
Where HIPAA and GDPR Actually Overlap
Here is the good news: if you are already HIPAA compliant, you have a significant head start. About 60% of GDPR's technical requirements overlap with what HIPAA already requires.
| Requirement | HIPAA | GDPR |
|---|---|---|
| Encryption at rest and in transit | ||
| Access controls / role-based access | ||
| Audit logging | ||
| Breach notification | ||
| Data minimization | ||
| Explicit consent per purpose | ||
| Right to erasure (deletion) | ||
| Data portability (export) | ||
| Privacy Impact Assessment | ||
| Data Protection Officer | ||
| Business Associate Agreements | ||
| Minimum Necessary Standard |
The top four rows are your overlap zone. If your HIPAA implementation includes AES-256 encryption, RBAC, audit trails, and a breach notification process, you have already satisfied those GDPR requirements. The bottom rows are where the work starts.
8 Requirements Where GDPR Goes Further Than HIPAA
These are the specific areas where being HIPAA compliant is not enough. Each one requires additional technical or organizational measures.
1. Explicit, Granular Consent
HIPAA allows broad consent through the Treatment-Payment-Operations exception. You can process patient data for treatment purposes without specific consent for each use. GDPR does not work this way. You need separate, explicit consent for each processing purpose. A single "I agree to the terms" checkbox is a GDPR violation. Understanding the difference between a BAA and HIPAA helps clarify why consent models diverge so significantly between the two frameworks.
2. Right to Erasure (Right to Be Forgotten)
Under GDPR, patients can request that you delete all their personal data. This conflicts directly with HIPAA's record retention requirements, which mandate keeping records for 6 years. The resolution: you must delete GDPR-covered data while retaining HIPAA-required records. This requires careful data architecture that separates EU and US patient data.
3. Data Portability
Patients have the right to receive their data in a structured, machine-readable format and transfer it to another provider. HIPAA has a similar right of access, but GDPR goes further by requiring interoperable export formats (JSON, CSV, FHIR) and the ability to transmit directly to another controller. If you are building an EHR system, data portability needs to be part of the architecture from day one.
4. Data Protection Impact Assessment (DPIA)
Before processing health data at scale, GDPR requires a formal assessment of privacy risks. HIPAA has risk assessments, but GDPR's DPIA is more prescriptive. It must document the processing purpose, necessity, proportionality, risks to data subjects, and mitigation measures.
5. Data Protection Officer (DPO)
If you process health data (special category data) as a core activity, you need a DPO. This is a designated person responsible for overseeing GDPR compliance. HIPAA requires a Privacy Officer, but the DPO role has additional independence requirements and must report directly to senior management.
6. Privacy by Design and Default
GDPR Article 25 requires that data protection is built into systems from the start, not bolted on later. Default settings must be the most privacy-protective option. If your app collects more data than necessary by default, or shares data with third parties unless the user opts out, that violates GDPR. Validating privacy safeguards at the code level before deployment is the only reliable way to ensure this requirement is met.
7. Lawful Basis for Processing
HIPAA does not require you to document a specific legal basis for each type of processing. GDPR does. For health data, the most common lawful bases are explicit consent (Article 9(2)(a)) or necessity for medical treatment (Article 9(2)(h)). You must document which basis applies to each processing activity.
8. Cross-Border Data Transfer Restrictions
Moving EU patient data to US servers requires a legally valid transfer mechanism. The EU-US Data Privacy Framework exists, but not all US companies qualify. Standard Contractual Clauses (SCCs) are the fallback, but they require a Transfer Impact Assessment. This is the most technically complex GDPR requirement for US healthcare companies.
The Consent Problem: HIPAA vs GDPR
This is where most US healthcare apps fail GDPR. The consent models are fundamentally different.
HIPAA Consent
Broad consent for treatment, payment, and operations. One-time acknowledgment of Notice of Privacy Practices. Specific authorization only for uses outside TPO (marketing, research). Implied consent for treatment is acceptable.
GDPR Consent
Specific consent for each processing purpose. Must be freely given, informed, unambiguous, and documented. Separate checkboxes for treatment, analytics, communications. Pre-ticked boxes are invalid. Consent must be as easy to withdraw as to give.
In practice, this means your sign-up flow needs separate consent toggles for: (1) processing health data for treatment, (2) analytics and service improvement, (3) email communications, (4) data sharing with third parties. Each must be independently selectable, and none can be pre-checked.
Technical Implementation
Your consent management must store: what was consented to, when, by whom, the specific version of the privacy notice shown, and whether consent was later withdrawn. This requires a dedicated consent_records table with timestamps and version tracking.
Right to Erasure vs HIPAA Retention
This is the hardest GDPR requirement for healthcare apps because it directly conflicts with HIPAA.
HIPAA requires you to retain medical records for at least 6 years (some states require longer). GDPR gives patients the right to have their data deleted on request. Both laws apply simultaneously to the same data.
The resolution is a technical architecture decision, not a legal one:
Separate EU patient data into its own storage partition or database schema
Implement soft deletion for GDPR requests: anonymize the data but retain the record
Strip all personally identifiable fields while preserving the clinical record hash
Document your retention policy showing HIPAA retention as a legal obligation that overrides erasure
Notify the patient that certain data is retained under US law with specific citations
GDPR Article 17(3)(c) provides an exception for data retention required by law. You can retain HIPAA-mandated records, but you must minimize what you keep to only what is legally required and document the legal basis.
Cross-Border Data Transfers: Getting Data to US Servers
If your servers are in the US (which they probably are), you are transferring EU personal data across borders. GDPR Chapter V requires a legal mechanism for this.
EU-US Data Privacy Framework (DPF)
The current mechanism, adopted in 2023. US companies can self-certify through the Department of Commerce. This is the simplest path but requires annual re-certification and applies only to specific data types you designate. Check the Data Privacy Framework website for eligibility.
Standard Contractual Clauses (SCCs)
The fallback mechanism. You sign EU-approved contract templates with your EU data partners. Requires a Transfer Impact Assessment (TIA) documenting that US law provides adequate protection for the specific data. Healthcare data makes this assessment more complex because of its sensitivity classification.
Watch Out
Even with a valid transfer mechanism, you must still encrypt EU patient data in transit and at rest using AES-256 or equivalent. The transfer mechanism covers the legal basis; encryption covers the technical safeguard.
Do You Need a Data Protection Officer?
Under GDPR Article 37, you need a DPO if your core activities involve large-scale processing of special category data. Health data is special category data. If your app's primary function involves patient health information, you almost certainly need one.
The DPO can be:
An internal employee with data protection expertise (cannot be the CEO or CTO due to conflict of interest)
An outsourced DPO service (common for US companies entering the EU market)
A shared DPO across related companies in a group
The DPO must be independent, have direct access to senior management, and cannot be penalized for performing their duties. Budget $30K-80K annually for an outsourced DPO service, or $120K+ for a full-time hire.
Practical Steps: Building a HIPAA + GDPR Compliant App
Here is what to actually implement in your codebase. If you are using a platform that handles compliance at the infrastructure level, most of these are handled automatically.
Step 1: Implement Consent Management
Add a consent management module that presents granular consent options at registration, stores consent records with timestamps, allows consent withdrawal at any time, and re-prompts when your privacy policy changes.
Step 2: Build a Data Subject Rights Portal
GDPR gives patients five key rights: access, rectification, erasure, portability, and restriction of processing. Build a self-service portal or documented process for each. Response deadline is 30 days.
Step 3: Implement Data Mapping
Document every piece of personal data: where it enters, where it is stored, who processes it, why, and when it will be deleted. This is your Record of Processing Activities (ROPA), required by Article 30.
Step 4: Add Encryption and Pseudonymization
AES-256 encryption at rest, TLS 1.2+ in transit (you probably already have this for HIPAA). GDPR additionally recommends pseudonymization, which means separating identifying information from health data so they cannot be linked without additional information held separately.
Step 5: Conduct a DPIA
Before processing EU health data, document: the purpose and necessity of processing, risks to patient privacy, measures to mitigate those risks, and whether you consulted with your DPO. Template DPIAs are available from the compliance standards page.
Step 6: Update Your Breach Response Plan
GDPR requires notification to the supervisory authority within 72 hours of discovering a breach (HIPAA allows 60 days). If the breach is high risk to patients, you must also notify the affected individuals "without undue delay." Update your incident response playbook to meet the shorter GDPR deadline.
What Happens If You Get It Wrong
GDPR penalties are significantly higher than HIPAA penalties.
| Violation Level | HIPAA | GDPR |
|---|---|---|
| Minor / Unknowing | $100 - $50,000 | Up to 10M EUR or 2% revenue |
| Reasonable cause | $1,000 - $50,000 | Up to 10M EUR or 2% revenue |
| Willful neglect (corrected) | $10,000 - $50,000 | Up to 20M EUR or 4% revenue |
| Willful neglect (not corrected) | $50,000+ | Up to 20M EUR or 4% revenue |
| Annual cap | $1.9M per category | No cap |
EU regulators have enforcement mechanisms against US companies: mutual legal assistance treaties, freezing EU-based assets, blocking services from EU app stores, and requiring EU partners to cease data sharing. The enforcement is real, not theoretical.
Frequently Asked Questions
Does GDPR apply to US healthcare companies?
Yes, if you process personal data of EU residents. This includes telehealth with EU patients, apps available in EU app stores, clinical trials with EU participants, or any data received from EU partner organizations. Your company location and server location are irrelevant.
Can HIPAA compliance satisfy GDPR requirements?
About 60% — encryption, access controls, audit logging, and breach notification overlap. But GDPR requires explicit consent, right to erasure, data portability, a DPO, Privacy Impact Assessments, and cross-border transfer mechanisms that HIPAA does not address.
What is the biggest GDPR risk for US healthcare apps?
Consent handling. HIPAA allows broad consent through TPO exceptions. GDPR requires specific, granular consent for each purpose with separate checkboxes, no pre-ticking, and easy withdrawal. Most US healthcare apps fail this requirement.
What are the GDPR penalties for US companies?
Up to 20 million euros or 4% of annual global revenue, whichever is higher. There is no annual cap unlike HIPAA. EU regulators have enforcement mechanisms against US entities including blocking services and mutual legal assistance treaties.
Do I need a Data Protection Officer?
If you process EU health data as a core activity, almost certainly yes. Health data is special category data under GDPR. The DPO can be outsourced ($30K-80K/year) or internal. They must be independent and report directly to senior management.
How do I handle the erasure vs retention conflict?
Separate EU patient data architecturally. On erasure requests, anonymize personal identifiers while retaining the de-identified clinical record under HIPAA's legal retention requirement. Document this approach in your privacy policy and cite GDPR Article 17(3)(c).
Build HIPAA + GDPR Compliant Apps
VertiComply generates code with compliance frameworks built in, so you do not have to implement GDPR and HIPAA requirements from scratch. See pricing plans.
Related Articles
Continue reading about healthcare compliance and development
How to Build a HIPAA-Compliant Healthcare App Without Code in 2026
The complete 2026 guide to building HIPAA-compliant healthcare apps without code. Covers compliance rules, no-code platforms, what to look for, real costs, common mistakes, and a step-by-step practical sequence for US healthcare startups.
Read article
How to Build a Compliant Healthcare App in 2026
Step-by-step guide to building healthcare apps that meet HIPAA, GDPR, SOC 2 and HITRUST compliance. Covers the 5 essential pillars and AI automation.
Read article
BAA vs HIPAA: Know the Difference (2026 Guide)
BAA vs HIPAA explained in plain English. What each one actually is, why they are not the same thing, who needs a BAA, when it is required, and what happens if you skip it.
Read article