GDPR for HealthTech: What US-Based Health App Companies Need to Know

Introduction

If you built a health app for the US market, you already know HIPAA. You have BAAs in place, your infrastructure runs on HITRUST-certified cloud services, and your team has been through compliance training. That foundation helps, but it does not prepare you for GDPR.

The General Data Protection Regulation (GDPR) is the EU's data protection framework, and it applies the moment your app processes personal data belonging to an EU resident. There is no revenue threshold, no user count minimum, and no exemption for companies based outside Europe. If a person in Berlin or Barcelona downloads your health app and creates an account, GDPR governs how you handle their data.

This guide breaks down what GDPR means for US-based healthtech companies. It covers when the regulation applies, what qualifies as health data, which legal bases support health data processing, what technical requirements you need to meet, and how to architect products that serve both US and EU markets from a single codebase. This is engineering guidance for CTOs and product managers, not a legal opinion. Consult qualified legal counsel for your specific situation.

When GDPR Applies to Your Health Product

GDPR's territorial scope is defined in Article 3, and it is broader than most US regulations. The regulation applies when:

• You offer goods or services to EU residents. If your app is available in the EU App Store or Google Play, accepts EU payment methods, or supports EU languages, you are offering services to EU residents.
• You monitor the behavior of EU residents. If your app tracks health metrics, usage patterns, or location data for users in the EU, you are monitoring behavior under GDPR's definition.

You do not need a European office, European servers, or European employees. The regulation follows the data subject, not the data controller.

Examples That Trigger GDPR

Telehealth platforms. A US-based telehealth app that allows EU-based patients to book consultations with US doctors processes personal data (names, contact info) and health data (symptoms, diagnoses, prescriptions) of EU residents.

Wearable health apps. A fitness-and-health app that collects heart rate, sleep, and activity data from EU users processes health data under GDPR's expanded definition, even if the company considers this "wellness data" under US frameworks.

Patient portals. A hospital system that offers a patient portal accessible to EU nationals (including EU citizens living abroad who access their records while traveling in Europe) falls under GDPR scope.

Clinical trial platforms. Any digital platform managing clinical trial data for participants located in EU member states must comply with both GDPR and the Clinical Trials Regulation.

Health Data as a Special Category

GDPR classifies personal data into two tiers. Standard personal data (names, emails, IP addresses) is governed by the baseline rules. Special category data, which includes health data, genetic data, and biometric data, triggers Article 9's stricter protections. Processing special category data is prohibited by default, with only 10 specific exceptions that permit it.

For most healthtech companies, this means you cannot process health data the same way you process a user's email address. The bar is higher for collection, storage, access, and deletion.

What GDPR Considers "Health Data"

Article 4(15) defines health data as "personal data related to the physical or mental health of a natural person, including the provision of health care services, which reveal information about his or her health status."

In practice, this definition is broad. The European Data Protection Board (EDPB) has interpreted it to include:

Data That Is Clearly Health Data

• Medical records, diagnoses, and treatment histories
• Prescription and medication data
• Lab results and diagnostic imaging
• Mental health assessments, therapy notes, and mood tracking logs
• Genetic sequencing data and biomarker panels
• Disability status and chronic condition records

Data That Becomes Health Data in Context

• Wearable sensor data. Heart rate, blood oxygen, ECG readings, and sleep architecture data collected by smartwatches or fitness bands. Even step counts can qualify when combined with health-related processing (e.g., using activity data to recommend physical therapy exercises).
• App usage patterns that reveal conditions. If someone uses a diabetes management app, the mere fact of their app usage reveals a health condition. Login frequency on a mental health platform can indicate treatment patterns.
• Dietary and nutrition data. Food logging data becomes health data when it is processed in the context of managing a medical condition like celiac disease or phenylketonuria.
• Reproductive health data. Menstrual cycle tracking, fertility window calculations, and pregnancy-related data all qualify.

What Is Typically Not Health Data

General fitness metrics collected without health-related processing context occupy a gray area. A standalone pedometer app that counts steps and has no health features may not process health data. But the moment that step data feeds into a health recommendation, a clinical assessment, or a wellness score correlated with health outcomes, it crosses the threshold.

The safest approach for healthtech companies: if your product relates to health in any way, treat all user-generated data as health data under GDPR. The cost of over-protecting data is lower than the cost of under-protecting it.

The Six Legal Bases (and Which Apply to Health Apps)

GDPR requires a legal basis for processing any personal data. Article 6 lists six options. For health data, you also need to satisfy one of the Article 9(2) exceptions. Here is how they map to healthtech products.

Consent (Article 6(1)(a) + Article 9(2)(a))

This is the most common legal basis for health apps. The user explicitly agrees to the processing of their health data for stated purposes. GDPR consent must be:

• Freely given. You cannot bundle consent with terms of service or make the app unusable without it (unless data processing is genuinely necessary for the app's core function).
• Specific. Each distinct processing purpose needs its own consent. "We process your data to improve our services" is too vague. "We process your heart rate data to generate weekly cardiovascular health reports" is specific.
• Informed. Users must know what data you collect, why, who receives it, and how long you keep it, before they consent.
• Unambiguous. Pre-ticked checkboxes do not count. Consent requires a clear affirmative action.

For health data specifically, consent must be explicit, meaning it must reference the special category data being processed. A general "I agree to the privacy policy" does not qualify.

Contract Performance (Article 6(1)(b))

You can process personal data when it is necessary to fulfill a contract with the user. If someone subscribes to a telehealth service, you can process their name and payment data to deliver that service. However, Article 9 does not list contract performance as an exception for special category data. You still need explicit consent (or another Article 9 exception) for the health data itself.

Legitimate Interest (Article 6(1)(f))

Legitimate interest allows processing when the controller's interest outweighs the data subject's rights. For standard personal data, this can cover fraud prevention, security monitoring, or analytics. For health data, legitimate interest is not listed as an Article 9(2) exception, making it effectively unavailable as a standalone basis for processing health information.

Legal Obligation, Vital Interests, and Public Interest

These three bases apply in narrow circumstances:

• Legal obligation (Article 6(1)(c)): When EU or member state law requires you to process data (e.g., mandatory disease reporting).
• Vital interests (Article 6(1)(d) + Article 9(2)(c)): When processing is necessary to protect someone's life. Relevant for emergency medical situations, but not for routine health app operations.
• Public interest (Article 6(1)(e) + Article 9(2)(g-j)): Covers public health, scientific research, and archiving. Some clinical research platforms may qualify, but commercial health apps generally do not.

Practical Recommendation

For most US-based healthtech companies entering the EU market, explicit consent is the primary path. Design your consent flows to be granular, clear, and revocable. Store consent records with timestamps, version numbers, and the specific text the user agreed to.

Key GDPR Requirements for Health Apps

Beyond establishing a legal basis, GDPR imposes specific operational requirements that affect how you build and run your product.

Data Minimization

Collect only the data you need for the stated purpose. If your app provides medication reminders, you need the medication name and schedule. You do not need the user's diagnosis, their doctor's name, or their insurance provider, unless those are required for a specific, disclosed feature.

Audit your data model. For each field, document why it exists and which processing purpose it serves. If you cannot justify a field, remove it.

Purpose Limitation

Data collected for one purpose cannot be repurposed without new consent. If you collect heart rate data to display health dashboards, you cannot later use that data to train a machine learning model for a B2B analytics product without going back to users for separate consent.

This has architectural implications. Your database schema and API access controls should enforce purpose boundaries. Tagging data with its processing purpose at collection time makes compliance audits and access controls more manageable.

Storage Limitation

GDPR does not specify maximum retention periods, but it requires that you define and enforce them. Health data should have clear retention policies:

• Active account data: retained while the account is active
• Post-deletion retention: define a specific period (e.g., 30 days for recovery, then permanent deletion)
• Regulatory retention: some jurisdictions require retaining medical records for specific periods, which may conflict with deletion requests. Document these conflicts and communicate them to users.

Implement automated data lifecycle management. Manual deletion processes do not scale and are prone to errors.

Data Protection by Design and by Default

Article 25 requires that data protection measures are built into your system architecture, not added afterward. This includes:

• Encryption at rest and in transit (TLS 1.2+ for transit, AES-256 for storage)
• Access controls based on the principle of least privilege
• Pseudonymization where possible (separating identifying information from health data)
• Default privacy settings that favor data protection (e.g., sharing features should be opt-in, not opt-out)

Data Protection Impact Assessment (DPIA)

A DPIA is mandatory when processing is "likely to result in a high risk" to individuals. Processing health data at scale qualifies. Your DPIA should document:

• The processing operations and their purposes
• An assessment of necessity and proportionality
• The risks to data subjects' rights and freedoms
• The measures you have implemented to address those risks

Complete a DPIA before launching in the EU market, not after. Supervisory authorities can request your DPIA at any time.

Records of Processing Activities (ROPA)

Article 30 requires organizations to maintain written records of all processing activities. For a health app, this means documenting every data flow: what data you collect, where it goes, who processes it, what legal basis applies, and how long you retain it.

This is not a one-time exercise. Update your ROPA whenever you add features, change data flows, or onboard new sub-processors.

Patient Rights You Need to Implement

GDPR grants data subjects specific rights that your application must support. For health apps, these rights translate into product features.

Right of Access (Article 15)

Users can request a copy of all personal data you hold about them. Your response must include the data itself, the purposes of processing, the categories of data, recipients who have received the data, and the planned retention period.

Implementation: Build a data export function that compiles all user data into a readable format. A "Download My Data" button in account settings is the standard UX pattern. Response deadline: 30 days.

Right to Rectification (Article 16)

Users can correct inaccurate personal data. For health apps, this includes updating outdated medical information, correcting wrong entries, or adding missing context.

Implementation: Allow users to edit their own records where appropriate. For data generated by clinical processes or connected devices, provide a request mechanism that routes corrections to the right team.

Right to Erasure (Article 17)

Also called the "right to be forgotten." Users can request deletion of their personal data when it is no longer necessary for its original purpose, when they withdraw consent, or when the data was unlawfully processed.

Implementation: Build a complete account deletion flow that removes data from your primary database, backups (within a reasonable timeframe), analytics systems, and third-party sub-processors. Document any legal obligations that require you to retain certain data, and communicate these exceptions clearly during the deletion process.

Right to Data Portability (Article 20)

Users can request their data in a "structured, commonly used and machine-readable format" and transmit it to another controller. This goes beyond a PDF export.

Implementation: Provide data exports in JSON, CSV, or XML formats. For health data specifically, consider supporting FHIR (Fast Healthcare Interoperability Resources) exports, which align with both healthcare interoperability standards and GDPR portability requirements.

Right to Restrict Processing (Article 18)

Users can request that you stop processing their data while a dispute is being resolved (e.g., they contest data accuracy, or they object to processing).

Implementation: Add a processing restriction flag to user accounts. When activated, the system should store but not process the user's data until the restriction is lifted.

Right to Withdraw Consent (Article 7(3))

Withdrawing consent must be as easy as giving it. If users consented through an in-app toggle, they should be able to withdraw through the same toggle.

Implementation: Maintain granular consent controls that map to your processing purposes. When a user withdraws consent for a specific purpose, stop that processing immediately while preserving data needed for other consented purposes.

Data Residency and Cross-Border Transfers

Transferring EU personal data outside the European Economic Area (EEA) requires legal safeguards. For US-based healthtech companies, this is one of the most operationally significant GDPR requirements.

The EU-US Data Privacy Framework

The EU-US Data Privacy Framework (DPF), adopted in July 2023, provides an adequacy basis for transferring personal data to US companies that have self-certified under the framework. If your company is DPF-certified, you can transfer EU personal data to the US without additional safeguards.

However, the DPF's long-term stability is uncertain. Its predecessor, Privacy Shield, was invalidated by the Court of Justice of the EU in the 2020 Schrems II ruling. Many legal experts expect challenges to the DPF as well.

Standard Contractual Clauses (SCCs)

SCCs are pre-approved contractual terms that you include in agreements with EU data exporters or sub-processors. They are currently the most widely used transfer mechanism and serve as a fallback if the DPF is invalidated.

When using SCCs, you must also conduct a Transfer Impact Assessment (TIA) to evaluate whether the laws of the receiving country (in this case, US surveillance laws) provide adequate protection. Document your TIA findings and any supplementary measures you implement.

Practical Cloud Architecture

The most straightforward approach to data residency is to keep EU health data in EU regions. Major cloud providers offer this:

• AWS: eu-central-1 (Frankfurt), eu-west-1 (Ireland), eu-south-1 (Milan)
• Google Cloud: europe-west1 (Belgium), europe-west3 (Frankfurt), europe-west4 (Netherlands)
• Azure: West Europe (Netherlands), North Europe (Ireland), Germany West Central (Frankfurt)

A multi-region architecture lets you serve US users from US regions (satisfying HIPAA requirements) and EU users from EU regions (satisfying GDPR requirements) within the same product. This adds infrastructure complexity, but it eliminates cross-border transfer concerns for health data.

Design your system so that user data is routed to the correct region at account creation based on the user's location. Use separate database instances per region rather than cross-region replication for health data.

Breach Notification: The 72-Hour Rule

GDPR's breach notification requirements are among the most time-sensitive obligations in any data protection framework.

What Counts as a Breach

A personal data breach is "a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data" (Article 4(12)). This includes:

• Unauthorized access to health records (external hack or internal unauthorized access)
• Accidental exposure of patient data through a misconfigured API or storage bucket
• Ransomware that encrypts health data (loss of availability is a breach)
• Lost or stolen devices containing unencrypted health data
• Sending health data to the wrong recipient

The 72-Hour Timeline

Once you become aware of a breach, you have 72 hours to notify the relevant supervisory authority. "Aware" means the point at which you have a reasonable degree of certainty that a security incident has compromised personal data. The notification must include:

• The nature of the breach and approximate number of affected individuals
• The name and contact details of your Data Protection Officer (or contact point)
• The likely consequences of the breach
• The measures taken or proposed to address the breach

If you cannot provide all information within 72 hours, GDPR allows phased notification, but the initial report must go out on time.

Notification to Individuals

If the breach is "likely to result in a high risk" to the rights and freedoms of affected individuals, you must also notify them directly. For health data breaches, this threshold is almost always met. Use clear, plain language, and include specific guidance on what steps affected users should take.

How This Compares to HIPAA

HIPAA requires notification within 60 calendar days of discovering a breach. GDPR's 72-hour window is measured from awareness, not discovery, but it is still dramatically shorter. Companies operating under both frameworks need breach detection and response capabilities that can meet the tighter GDPR timeline.

This means automated breach detection is not optional. Log monitoring, anomaly detection, and clear incident response playbooks should be in place before you serve your first EU user.

How Momentum Builds GDPR-Compliant Health Products

At Momentum, we build health products that operate across regulatory jurisdictions. Our clients include US-based healthtech companies expanding into Europe, and European companies entering the US market. Here is how we approach GDPR compliance as an engineering problem.

Data Residency as Infrastructure

We architect multi-region deployments where EU user data stays in EU cloud regions and US user data stays in US regions. Region assignment happens at the application layer during user registration, and data routing is enforced at the infrastructure level. This eliminates cross-border transfer issues while keeping a single codebase and deployment pipeline.

Consent Management as a Service Layer

Consent is not a checkbox on a signup form. We build consent management as an infrastructure layer that tracks what each user has consented to, when they consented, which version of the consent text they agreed to, and whether they have withdrawn consent for any processing purpose. This consent state gates data processing throughout the application. If a user has not consented to a specific processing purpose, the system does not process their data for that purpose, regardless of what feature code requests.

Patient Rights as Product Features

Data access, portability, rectification, and deletion are built as first-class application features, not as support ticket workflows. Users can export their data in standard formats (JSON, FHIR), correct their records, manage their consent preferences, and delete their accounts through the application interface. Automated pipelines handle downstream deletion across databases, backups, analytics systems, and third-party integrations.

Audit Logging for Accountability

GDPR's accountability principle (Article 5(2)) requires that you can demonstrate compliance, not just achieve it. We implement comprehensive audit logging that records every access to health data: who accessed it, when, from where, and for what purpose. These logs feed into compliance dashboards and are available for supervisory authority requests.

Dual-Compliance Architecture

Many of our clients need both HIPAA and GDPR compliance. Rather than building two separate systems, we architect a single platform that satisfies both frameworks. HIPAA's technical safeguards (encryption, access controls, audit trails) overlap significantly with GDPR's data protection by design requirements. The additional GDPR requirements (consent management, data portability, right to erasure, 72-hour breach notification) are layered on top as configurable features that activate based on the user's jurisdiction.

Get Started with GDPR-Compliant Development

If you are planning EU market entry for your health app, start the compliance conversation early. Retrofitting GDPR compliance into an existing architecture is more expensive and more error-prone than building it in from the beginning.

Explore our GDPR compliance servicesto see how Momentum helps healthtech companies build products that meet European data protection requirements from day one.

For a comparison of GDPR and HIPAA requirements, see our guide on HIPAA vs. GDPR for health dataIf your product incorporates AI, review how the EU AI Act adds additional regulatory requirements on top of GDPR.

‍