The European Health Data Space: what health and wellness app developers actually need to build

Why this matters now 

Regulation (EU) 2025/327 on the European Health Data Space (EHDS) entered into force on 26 March 2025. Most health and wellness app developers focus on the Medical Devices Regulation (EU) 2017/745 (MDR) and the AI Act but end up neglecting EHDS. EHDS notably adds a parallel, overlapping regime with obligations that apply whether or not the product is a medical device. 

The application of EHDS is staggered through to 2031, so this should be thought as a "build the process now" piece rather than a "you are already in breach" piece. But getting the classification and the processes right takes longer than most teams expect. 

Are you a "health data holder"? 

The starting question is whether the app developer qualifies as a health data holder under Art. 2(2)(t) EHDS. Either of the below two routes suffice. 

The first, Art. 2(2)(t)(i) qualifies anyone who has the right or obligation, as a GDPR controller or joint controller, to process personal electronic health data for healthcare or care, public health, reimbursement, research, innovation, policymaking, official statistics, patient safety or regulatory purposes. 

The second Art. 2(2)(t)(ii) catches anyone with the ability to make available non-personal electronic health data through control of the technical design of a product, including by registering, providing, restricting access to or exchanging that data. No controller status is required under this. Even a developer exposing aggregated or anonymised usage data through its platform can be caught via this route alone. 

Health apps and wellness apps are not the same thing 

"Health app" is not a defined term under EHDS. The Regulation only defines "wellness application" under Art. 2(2)(ab). Everything else falls back on the undefined Art. 2(2)(t) "products or services intended for the health, healthcare or care sectors". A product belongs to one group or the other, and that membership, together with limb (i) or (ii), determines holder status. 

The practical dividing line is the purpose. A wellness application is defined as a software, or a combination of hardware and software, intended by the manufacturer to be used by a natural person for processing electronic health data specifically for providing information on that person's health, or for the delivery of care, or the delivery of care for purposes other than the provision of healthcare. A product that provides or supports healthcare itself (for instance, a teleconsultation platform, a medication adherence tool within an active care pathway) sits in the health, healthcare or care category, even if it is not a medical device. 

The label decides which Art. 51(1) secondary use category applies (wellness application data is listed at point (i)) and whether the Art. 51(4) option for stricter national safeguards is available, which it is for wellness data but not for health or healthcare product data generally. 

A step-counting fitness app is a wellness application. A symptom diary that a treating clinician uses to adjust a patient's care plan sits in the health or healthcare product category and, depending on the intended purpose claimed, may also be an MDR device. A diagnostic algorithm is an MDR device outright and, if AI-driven, is automatically a high-risk system under the AI Act. Three "apps about your health", three labels, three compliance stacks. Classifying at the design stage saves considerable rework. 

The MDR and wellness application overlap 

MDR status is a separate axis that can overlap with the wellness label. Both turn on intended purpose, but ask different questions. Art. 2(1) MDR requires an intended medical purpose, and Recital 19 MDR is explicit that software intended for lifestyle and well-being purposes is not a medical device. The EHDS wellness definition captures processing "for purposes other than the provision of healthcare". Because the tests differ, a product performing distinct functions can carry both labels. A sleep tracker that also generates a clinically validated apnoea risk score is a plausible example. 

EHDS has no conflict rule for this overlap. Its interface provision is Art. 27: a medical device, IVD or high-risk AI system claiming interoperability with the harmonised software components of EHR systems must also meet the interoperability and logging requirements in Annex II, Section 2, and the Art. 36 common specifications. Recital 42 keeps MDR, IVDR and AI Act certification and asks Member States to coordinate assessments, leaving the mechanics to potentially twenty-seven national approaches. The combined declaration of conformity in Art. 39(2) is framed for EHR systems. A wellness application self-issues an Art. 47 label instead, so for a wellness app that is also a device the EHDS and MDR streams run in parallel. 

Issue of interpretation: a product can satisfy both tests at once, and a recent peer-reviewed analysis of the app market concludes that a single app can be an MDR device and an EHDS wellness application simultaneously. That is unproblematic for secondary use, where both are mandatory Art. 51 categories. For primary use, devices and wellness applications follow different routes into EHR data sharing (discussed below) and the text does not say which a dual-status product takes. The developer of a class I menstrual-cycle app used entirely self-directedly, with no clinician in the loop, cannot say which route applies, and the authors of that analysis argue the confusion could have been avoided with a tighter wellness definition or express guidance on how MDR status maps onto EHDS obligations. 

Secondary use: where the labels stop mattering, and where they do not 

Art. 51(1) sets out the minimum categories of electronic health data that a holder must make available for secondary use. It separately lists personal electronic health data automatically generated through medical devices (point (h)), data from wellness applications (point (i)) and other health data from medical devices (point (n)). All are mandatory, so the label makes no difference to the underlying obligation. 

It does matter for what Member States can add. Art. 51(4) allows stricter national measures and additional safeguards, for example a consent requirement, but only for human genetic, epigenomic and genomic data (point (f)), other human molecular or "omic" data (point (g)), wellness application data (point (i)) and biobank data (point (q)). Any such measure must be notified to the Commission. Device data at points (h) and (n) is pointedly excluded. 

Two GDPR points follow. First, Art. 71 EHDS gives natural persons a right to opt out of secondary use. It is distinct from the Art. 6 and 9 GDPR legal basis for primary processing of the same data, and the two must be documented and operationalised separately, not treated as interchangeable consent mechanisms. Second, Arts. 65 and 74 EHDS (GDPR authorities and secondary use controllership) matter where the developer becomes joint controller with an access body or data user. 

Operational duties under Article 60 

Art. 60 EHDS sets out what has to be built. Where a request is backed by a data permit under Art. 68 or an approved health data request under Art. 69, the holder must make the Art. 51 data available to the health data access body (Art. 60(1)) within a reasonable time and no later than three months from receipt, a period the access body, not the holder, may extend by up to three further months in justified cases (Art. 60(2)). The holder must also communicate a dataset description in accordance with Art. 77 and check at least annually that the national catalogue entry remains accurate (Art. 60(3)), document any Art. 78 data quality and utility label (Art. 60(4)) and provide non-personal data through trusted open databases (Art. 60(5)). Art. 52 requires it to identify and justify any parts protected by IP rights or trade secrets. 

In practice that means a request-handling process with a three-month clock, a maintained dataset description and documentation anticipating an IP review. The Commission recently adopted Implementing Regulation (EU) 2026/2098 under Art. 77(4) which lays down minimum metadata elements and their characteristics that health data holders must provide when describing datasets for secondary use. What is still being settled is the precise boundary of the Art. 51 categories, worked out in TEHDAS2 guidance; and even with metadata standard in place, for many health data holders the heavier heavier burden will be describing datasets accurately and consistently rather than extracting the records. Separately, Art. 52 is frequently misread as a right to withhold. The better view, reflected in Recital 60, is that identifying protected material triggers protective handling (contractual terms, permit conditions, pre-processing or configuration of the secure processing environment), so it shapes how data is shared, not whether. These duties sit alongside cybersecurity obligations under the Cyber Resilience Act, Regulation (EU) 2024/2847 (amended by Art. 104 EHDS), and, depending on entity status, NIS2. 

If the product claims EHR interoperability, there is a separate track 

A wellness application claiming interoperability with EHR systems faces a further layer under Arts. 47 to 49. Full certification was considered disproportionate (Recital 49), so the regime is self-declared. Where the manufacturer claims interoperability with the harmonised software components of EHR systems, and thus compliance with the Art. 36 common specifications and Annex II, it must issue a label attesting that compliance (Art. 47(1)). The label is valid for at most three years (Art. 47(5)). Market surveillance authorities check compliance after the fact (Art. 47(7)). 

Two points are easily missed. First, the European digital testing environment is mandatory only "before placing EHR systems on the market" (Art. 40(3)). A wellness application does not, on the face of the text, have to be run through it. Second, claiming interoperability does not authorise data flows. Users must be informed of the interoperability and its effects (Art. 48(1)), and wellness data may never flow automatically to an EHR system. Transfer requires compliance with Art. 5 and consent, with the user choosing which categories are inserted and when (Art. 48(2)). T

he label must be registered in the EU database for EHR systems and wellness applications before market placement (Art. 49(1) and (2)), with the precise data still to be fixed by delegated act (Art. 49(4)). If the product is itself an EHR system, the heavier regime applies in full: the digital testing environment (Art. 40(3)), an EU declaration of conformity (Art. 39), CE marking (Art. 41) and registration including the test results (Art. 49(2)). 

This is where the dual-status ambiguity becomes concrete. Medical device manufacturers must prove compliance with the Annex II, Section 2 interoperability requirements (Art. 27), whereas wellness application manufacturers self-declare through the label. Which route a dual-status product must follow remains the central open question for primary-use EHR sharing, pending guidance. 

Where a product already qualifies as an MDR device, an embedded AI component is automatically classified as high-risk under the AI Act. The result is a triple stack of MDR conformity assessment, AI Act high-risk obligations (limited after the equivalence test with MDR as per the Digital Omnibus but human oversight, data governance related provisions will most likely apply), and EHDS health data holder and, where applicable, interoperability duties. This area is in active flux. The DG SANTE MDR/IVDR proposal notably aims to reduce this overlap, so the applicable regulations should not be assumed as fixed. 

Timeline: when do these duties actually bite 

Application is staggered by chapter and, within Chapter II, by data category (Art. 105). General application begins on 26 March 2027. Primary use obligations for the first priority categories (patient summaries, electronic prescriptions and electronic dispensations) apply from 26 March 2029, with medical imaging, examination results and discharge reports following from 26 March 2031. The secondary use chapter, including the Art. 51 and Art. 60 duties, generally applies from 26 March 2029, with a longer run-in to 26 March 2031 for more sensitive categories such as genetic, genomic and other omic data, and biobank data. The processes need to exist well before those dates, not immediately. 

A cross-border note 

Developers with non-EU infrastructure or group structures should note Art. 75 EHDS (HealthData@EU) and Arts. 88 to 91, covering third-country transfers of non-personal electronic health data (Art. 88), international governmental access to such data (Art. 89), additional conditions for transferring personal electronic health data to a third country or international organisation (Art. 90) and access applications and requests from third countries (Art. 91). Pertinently, Art. 90 is additional to, and not a substitute for Chapter V GDPR. Territorial reach was contested during the legislative process and the text does not fully settle it. The Commission's March 2026 FAQs indicate that holder obligations do not extend to non-EU holders without an established presence in the Union. But "establishment" is hard to pin down when a developer operates through EU subsidiaries or group entities, and any de facto "Brussels effect" on providers that merely make their app available to EU users is untested. The establishment analysis should be resolved deliberately and not assumed.

Enforcement 

Under Art. 63 EHDS, health data access bodies may request all information needed to verify compliance, must give the holder up to four weeks to respond to a finding of non-compliance, and must alert the GDPR supervisory authorities to possible GDPR breaches (Art. 63(2)). Where a holder withholds data with the manifest intention of obstructing its use, or misses the Art. 60(2) deadlines, the access body may impose a periodic penalty payment for each day of delay and, on repeated breaches, exclude the holder for up to five years from submitting its own access applications, while the holder remains obliged to make its data available (Art. 63(4)).

Administrative fines under Art. 64 follow familiar GDPR lines. Art. 60 infringements fall under Art. 64(4), with fines of up to EUR 10 000 000 or, for an undertaking, up to 2 % of total worldwide annual turnover in the preceding financial year, whichever is higher. The higher tier of EUR 20 000 000 or 4 % is reserved mainly for health data user misconduct such as prohibited purposes or re-identification (Art. 64(5)). Linked infringements from the same permit or request are capped at the most serious (Art. 64(3)). 

This exposure is additional to any GDPR fine for the same conduct. Art. 64(2) treats penalties imposed elsewhere as one factor, not a bar, and with the Art. 63(2) alert duty and Art. 65 the same conduct can draw two regulators. How double counting is avoided will be resolved only through practice and guidance, with Commission enforcement guidance due by 26 March 2032 (Art. 63(8)). The Art. 60 processes are therefore about avoiding quantifiable financial exposure, not simply good practice. 

Takeaways 

Developers should first classify the product, function by function, as a wellness application, a health or healthcare product, an MDR device or a combination of these, as this determines the applicable obligations and conformity track. They should then test holder status under both limbs of Art. 2(2)(t) and map any AI Act exposure. Because Art. 51(4) allows stricter national rules for wellness application data but not for medical device data, developers should check the national safeguard measures in each Member State where they operate. The Art. 60 request-handling and dataset description processes should be built well ahead of the 2029 application date. 

Several concepts remain unsettled, including the route for dual-status products, the mechanics of the secondary-use opt-out, the content of the dataset description and the territorial reach of holder status. Developers should build to the existing text and track the Commission’s FAQ, the implementing and delegated acts, and the TEHDAS2 and EDPB guidance that will resolve these questions.