EHDS Secondary Use for Pharma: Readiness Blueprint

The European Health Data Space (EHDS) converts secondary use of electronic health data from an ad hoc disclosure exercise into a regulated operating model. For pharmaceutical, biotechnology, medical-technology, contract research, registry, and real-world-data organisations, the threshold question is functional: an entity can be a health data holder when it controls, is obliged to process, or can make available electronic health data while developing products or services for the health sector (^[1]). Natural persons and qualifying microenterprises are generally exempt, but Member States may bring them back into scope (^[2]). Consequently, applicability must be assessed by legal entity, dataset, processing role, and Member State, not by industry label alone.

The critical planning fact is that March 2029 is not a universal data deadline. Chapter IV generally applies from 26 March 2029, while determinants of health, genetic and other omic data, regulated clinical-trial and study data, and research-cohort, questionnaire, and survey data are deferred to 26 March 2031 (^[3]). Implementing acts due by 26 March 2027 will specify dataset-description elements, application templates, data-quality labels, secure processing environments, and HealthData@EU architecture (^[4]). As of 19 September 2026, an EHDS Board act had been adopted, but the located HealthData@EU instrument was still marked as a draft (^[5]). Designs should therefore use replaceable policy and metadata layers.

The minimum viable holder capability is a governed inventory, machine-readable catalogue metadata, a repeatable extract and preparation pipeline, pseudonymisation or anonymisation, protected-rights tagging, opt-out handling, provenance, and response management. Requested data are normally due within three months, extendable once by up to three months (^[6]). Permit-based analysis occurs in a secure processing environment, with named users, unique identities, logs retained for at least one year, reviewed exports, and deletion within six months after permit expiry (^[7]). A statistical request is different: the user receives only an anonymised statistical response and no underlying data.

The recommended investment sequence is inventory first, policy second, automation third. Build the holder-side evidence and orchestration layer now, preserve flexibility around national access-body interfaces, and decide separately whether to operate an Article 73 environment. This is material infrastructure, not a narrow privacy project: EU funding covered 68 EHDS-supporting projects worth EUR 105,206,061 as of March 2025 (^[8]), and TEHDAS2 spans 29 European countries (^[9]). National variation and unfinished implementing acts make Member-State monitoring and legal review continuing controls. This report is an implementation analysis, not legal advice.

The EHDS creates a common framework for primary use of health data in care and secondary use for research, innovation, policy, regulation, and other defined purposes. The Council adopted the law on 21 January 2025 (^[10]), and Regulation (EU) 2025/327 was published on 5 March 2025 (^[11]).

For life-science leaders, secondary use has two faces. An organisation may be a holder, required to describe and prepare data for an access body. It may also be a user, meaning an organisation granted lawful secondary-use access (^[12]), seeking data for research, product development, algorithm training, testing, or evaluation. TEHDAS2 guidance covers the regulation's six allowed secondary-use purposes (^[13]). A company can occupy both roles for different projects without collapsing the legal and technical responsibilities between them.

This matters because the underlying estate is broad. The EU Clinical Trials Register displayed 44,409 EudraCT-protocol trials as of the access date (^[14]), while BBMRI-ERIC reports nearly 700 biobanks, more than 2,500 collections, and over 100 million samples in its directory (^[15]). Its directory uses the MIABIS 2.0 Core data model (^[16]). Readiness therefore has to connect legal classification to data engineering, clinical context, privacy operations, intellectual-property controls, and service management.

For an adjacent adviser such as IntuitionLabs, the relevant perspective is the information layer: authoritative sources connected with identity, permissions, retrieval, citations, evaluation, and accountable operation (^[17] and the supporting data pipelines, integration, warehousing, and business intelligence (^[18]). That is an operating-model viewpoint, not a claim that the consultancy is a health data access body or an EHDS software product.

A phased secondary-use obligation, not one go-live date

The EHDS general application date is 26 March 2027 (^[19]), but Chapter IV on secondary use generally starts on 26 March 2029 (^[20]). Five Article 51 groups are deferred to 26 March 2031: factors affecting health, human genetic and epigenomic data, other human molecular data, regulated trial and study data, and research cohorts, questionnaires, and surveys after first publication (^[3]). Third countries and international organisations may apply to join HealthData@EU from March 2035 (^[21]).

This staging changes portfolio priorities:

• 2027 gate: monitor binding specifications for metadata, labels, templates, secure environments, and HealthData@EU. The adopted EHDS Board act requires a work plan every two years (^[22]).

• 2029 scope: operationalise electronic health record, administrative, device, wellness-app, registry, medicinal-product registry, mortality, pathogen, health-professional, and biobank data that the organisation holds.

• 2031 scope: add determinants, genomics, epigenomics, proteomics and other omics, regulated clinical studies, and qualifying research cohorts.

The national overlay must track extensions to exempt holders, additional categories, stricter safeguards, and opt-out exceptions in every relevant Member State.

Discoverability becomes an affirmative data-product duty

A holder must communicate a description of each dataset and check at least annually that the national-catalogue description remains accurate (^[23]). The health data access body publishes standardised, machine-readable catalogue metadata describing source, scope, main characteristics, nature, and access conditions. TEHDAS recommends that access bodies publish and maintain metadata catalogues (^[24]). The Commission will connect national catalogues through an EU dataset catalogue.

This is more than a registry entry. HealthDCAT-AP Release 7 is an extension of DCAT-AP (^[25]), and the current profile introduces controlled public, restricted, and non-public access values (^[26]) and a mandatory structured-data indicator (^[27]). DCAT-AP 3.0.0 is the current available European profile (^[28]). W3C's Data Catalog Vocabulary is designed to make web catalogues interoperable, and its model applies whether the described data are open or restricted (^[29]).

Access changes from data delivery to controlled computation

Permit-based access must occur through a secure processing environment (SPE). The environment restricts access to authorised people listed in the permit, uses individual unique identities, records access, supports holder upload, and prevents unrestricted extraction. TEHDAS2 describes an SPE as a controlled workspace for authorised health-data analysis (^[7]) and states that individual-level data not sufficiently anonymous stay inside it.

The governing principle is anonymised if sufficient, pseudonymised only if necessary. Access bodies provide anonymised data when the purpose can be achieved that way. An applicant seeking pseudonymised data must justify why anonymised data are inadequate. TEHDAS2 notes that pseudonymisation supports detailed secure-environment analysis (^[30]) and recommends privacy-risk assessment and disclosure control for anonymised, synthetic, and permit-generated outputs (^[31]).

IP and trade secrets become structured decision inputs

Intellectual property, trade secrets, and specified regulatory data protection do not create a blanket exclusion. The holder must identify protected portions and justify the protection need. The access body then determines proportionate legal, organisational, and technical safeguards, potentially including contracts between holder and user. It must refuse access if a serious residual risk cannot be addressed (^[32]).

Existing regulatory-publication practice is useful but not identical. EMA publishes clinical data submitted by pharmaceutical companies (^[33]) and requires companies to justify proposed commercially confidential redactions (^[34]). Holder readiness should reuse the discipline of locating, classifying, justifying, and versioning protected content, while treating the EHDS access body as the decision-maker for EHDS safeguards.

Is a pharma, biotech, medtech, or CRO organisation a holder?

The answer depends on four tests:

• Entity: identify the legal person that controls or can make data available, not only the group brand.

• Activity: determine whether the entity processes electronic health data while providing care, conducting research, or developing health-sector products or services.

• Data: map each source to an Article 51 category and the relevant 2029 or 2031 phase.

• Jurisdiction: record national additions, stricter safeguards, intermediary models, and any use of the microenterprise option.

Natural persons and legal persons that qualify as microenterprises are generally exempt. The referenced EU definition uses fewer than 10 persons and annual turnover or balance-sheet total not exceeding EUR 2 million (^[2]). Member States may nevertheless apply holder duties to those categories, and they must notify national choices concerning exemptions and intermediaries by 26 March 2029. A group-level policy should not assume every small affiliate is exempt.

Table 1 converts Article 51 into a life-science inventory and avoids treating all categories as due at once.

Article 51 inventory group	Typical life-science source systems	Likely owner and preparation focus	Application phase
EHR and healthcare administration	RWD lakehouse, claims, dispensation, care-partner feeds	RWD or market-access data owner; lineage, terminology, lawful provenance	26 March 2029 ([3])
Device-generated and other device data	Connected-device cloud, telemetry, vigilance or product registries	Medtech product data owner; device identity, calibration context, time series	26 March 2029 ([3])
Population, medical, mortality, product registries	Disease registry, post-authorisation registry, product master	Registry custodian; cohort rules, event definitions, version history	26 March 2029 ([3])
Biobank health data	Laboratory information system, sample catalogue, consent registry	Biobank custodian; sample linkage, material metadata, consent and opt-out	26 March 2029 ([3])
Determinants and human genetics	Social or environmental linkage, genomics, epigenomics	Data-science and translational owner; sensitivity, provenance, national safeguards	26 March 2031 ([3])
Other molecular or omic data	Proteomics, transcriptomics, metabolomics, lipidomics	Bioinformatics owner; workflow version, reference build, assay quality	26 March 2031 ([3])
Regulated trials and studies	CTMS, EDC, eCOA, statistical repository, device study	Clinical data custodian; study status, pseudonymisation, first-use restrictions	26 March 2031 ([3])
Research cohorts, questionnaires, surveys	Cohort platform, research database, survey system	Principal data custodian; first-publication date and cohort documentation	26 March 2031 ([3])

The 2031 timing for regulated trial data is explicit, and research-cohort data enter scope only after first publication of related results. By contrast, biobank health data fall in the 2029 group. This distinction should be represented as a machine-readable applicability date on every catalogue record, not buried in policy prose.

What every inventory record should contain

A practical record should capture:

• Identity: persistent dataset identifier, title, legal holder, business owner, technical custodian.

• Classification: Article 51 category, personal or non-personal state, special sensitivity, country coverage.

• Lifecycle: collection period, refresh cadence, retention, first publication where relevant, decommissioning state.

• Semantics: data model, code systems, variable dictionary, units, reference populations, transformations.

• Quality: completeness, uniqueness, accuracy, validity, timeliness, consistency, known limitations.

• Rights: IP owner, trade-secret fields, regulatory data protection basis, contractual restrictions.

• People controls: opt-out applicability, consent or other provenance, pseudonym key custodian.

• Delivery: estimated extraction cycle, preparation dependencies, size band, preferred SPE tools.

FAIR principles reinforce this approach: data should have rich metadata, persistent identifiers, and detailed provenance (^[35]). Metadata should remain accessible even after underlying data are unavailable (^[36]). ELIXIR similarly recommends standardised life-science formats, metadata, vocabularies, and identifiers (^[37]). Catalogue readiness should therefore be treated as data-product management, not a one-time compliance spreadsheet.

The end-to-end flow

The operating sequence is:

1. Discover: the applicant searches public national or EU catalogue metadata.

2. Apply: the applicant submits a permit application, or a request for an anonymised statistical answer.

3. Decide: the health data access body evaluates purpose, necessity, data scope, safeguards, protected rights, and opt-outs.

4. Call for data: after approval, the access body asks the holder for the relevant Article 51 data.

5. Prepare: the holder extracts, validates, documents, filters, and pseudonymises or anonymises as instructed.

6. Load: the holder or access body places the data in the approved SPE.

7. Analyse: only authorised people use approved tools for the permitted purpose.

8. Review output: disclosure controls ensure only non-personal output leaves the environment.

9. Publish and close: the user publishes anonymous results, then the environment deletes data according to the permit lifecycle.

The access body must decide a complete permit application within three months, with a possible extension of up to three months. After receiving holder data, it normally has two months to make them available (^[38]). A permit can last no more than 10 years, with one possible extension of up to another 10 years. These are maximum legal windows, not service-level targets for internal teams.

Table 2 separates operational responsibility and General Data Protection Regulation controller or processor posture across the flow.

Actor	Core responsibility	Personal-data posture in the EHDS flow	Capability implication
Health data holder	Describe datasets and make approved data available	Controller for making personal data available to the access body	Evidence-backed catalogue, repeatable preparation, rights and opt-out controls
Health data access body	Decide applications, obtain data, provide SPE access, supervise output	Controller for the processing of personal electronic health data when fulfilling its tasks pursuant to this Regulation	Case management, secure exchange, SPE, audit, disclosure review
Health data user	Define purpose, justify necessity, analyse only as permitted, publish anonymous results	Controller for permit-based analysis or request output	Research protocol, named-user governance, tool and compute specification
Trusted health data holder	May assess and prepare applications and provide its compliant environment	Controller for its provision tasks; processor for the user when providing data through its SPE	Requires designation, expertise, guarantees, and an Article 73 environment
Commission and national contact points	Operate and participate in HealthData@EU	Commission acts as processor for the central platform; participating contact points are joint controllers for network operations	Federated routing, identity, messaging, status and permit exchange

The matrix shows why a single blanket data-processing agreement is inadequate. In the specific situations described in Article 74, the access body acts as a processor on behalf of the health data user when providing data through the secure processing environment or when generating the response to an approved health data request (^[39]). Trusted-holder status is optional under national procedure, not a default label an enterprise can self-assign.

Permit versus anonymised statistical request

A data permit authorises analysis of specified data for a specified purpose. The user receives controlled access inside an SPE, potentially to pseudonymised data where necessity is demonstrated. A health data request returns only an anonymised statistical response, and the user receives no access to the underlying data (^[40]). The request path is assessed within three months and, where possible, answered within a further three months.

For users, the selection rule is straightforward:

• Choose a request when a predefined aggregate, count, rate, or model-independent statistic answers the question.

• Choose a permit when iterative analysis, linkage, model development, subgroup exploration, or validated code execution requires record-level structure.

• Do not over-request: an application should minimise persons, variables, geography, time, and granularity.

• Budget for output review: even a successful analysis is not useful until non-personal output passes disclosure control.

Cross-border HealthData@EU routing

An applicant seeking data from more than one Member State submits a single cross-border application, commonly through the access body where its main establishment is located. The application is forwarded to relevant authorised participants and national access bodies, but each retains authority to grant or deny access within its remit. Mutual recognition may simplify permits, but it does not erase local decision authority.

Each Member State designates a national secondary-use contact point as its organisational and technical gateway. The Commission develops and operates the central platform. TEHDAS2's application-management design exchanges statuses, decisions, and permits through national contact points (^[41]). A 2025 platform release used AS4 for external inbound and outbound flows and released software components as open source (^[42]) (^[43]). Organisations should treat that as implementation evidence, not as a substitute for the final Article 75 implementing act.

Secure processing environment control matrix

Table 3 translates legal and TEHDAS2 requirements into controls that architecture and assurance teams can test.

Control domain	Required or recommended behaviour	Evidence to retain
Identity and access	Named permit users only; individual unique identities; strict multifactor authentication	Permit-to-account mapping, approvals, authentication logs
Workspace isolation	No user administration; controlled web or virtual-desktop access; approved tools and compute	Build baseline, image inventory, network policy, tool approvals
Data ingress	Holder uploads only permit-scoped data through controlled transfer	Manifest, checksums, source lineage, receipt confirmation
Pseudonymisation	Reversal information held only by the access body or recognised trusted party	Key custody record, separation-of-duty test, risk assessment
Logging and monitoring	Log all access; retain access logs for at least one year ([7])	Immutable event records, alert rules, review sign-off
Egress and disclosure	Export only non-personal data after anonymity and disclosure review	Output request, review worksheet, approved artefact hash
Audit	Regular audits, including third-party audits, with corrective action	Audit plan, report, action tracking, closure evidence
Closure	Delete environment data within six months after permit expiry ([7])	Expiry trigger, deletion log, residual-storage verification

TEHDAS2 calls for strict multifactor authentication and says all SPE access should be logged and monitored (^[7]). EDPB pseudonymisation guidance adds network segmentation, protected key storage, secured interfaces, rate limiting, and logging (^[44]). ENISA recommends selecting pseudonymisation techniques and parameters after a risk-impact assessment, rather than standardising blindly on one technique (^[45]).

IP, regulatory protection, and opt-out workflow

A defensible protected-rights workflow should:

• Tag early: identify field, file, table, document section, owner, right type, territory, and expiry.

• Justify specifically: explain the protected element and risk instead of labelling an entire dataset confidential.

• Propose safeguards: masking, reduced fields, aggregation, restricted tooling, separate review, or contractual terms.

• Preserve authority: record the access body's decision separately from the holder's recommendation.

• Version decisions: carry approved controls into the extraction manifest, SPE configuration, and output review.

Natural persons have a reversible right to opt out at any time without giving a reason (^[46]). Identifiable opted-out data are excluded from new permits and requests after exercise, but earlier approved processing is not retroactively affected. A Member State may create a tightly conditioned public-interest exception, including research for important public-interest reasons where equivalent data cannot be obtained in time by alternative means. The policy is therefore jurisdictional and temporal, not a static global suppression flag.

Build, buy, or managed service

The decision should be decomposed by layer:

• Build the differentiating core: dataset inventory, ownership, source lineage, transformation logic, quality rules, protected-rights mapping, and opt-out orchestration are organisation-specific.

• Buy commodity controls: identity, privileged access, key management, immutable logging, secure file transfer, workflow, and policy enforcement are usually established platform capabilities.

• Use managed operations selectively: catalogue stewardship, extraction support, pseudonymisation operations, SPE administration, and output review can be managed where responsibilities, evidence, data location, and exit plans are explicit.

• Defer irreversible network coupling: isolate national and HealthData@EU interfaces behind adapters until final implementing specifications stabilise.

Operating an SPE is not automatically a holder duty. An access body normally provides it; a designated trusted holder may provide one if it meets Article 73. Most holders should first make their data SPE-ready through manifests, portable transformations, controlled pseudonymisation, and documented compute dependencies, then decide whether enough expected volume justifies operating the environment.

Cost model without invented benchmarks

Use reader-supplied quantities and internal unit costs:

Annual readiness cost = catalogue stewardship + request preparation + platform controls + access support + assurance.

Calculate it as:

• Catalogue: number of datasets × metadata review cycles × hours per review × loaded labour rate.

• Preparation: requests × datasets per request × extraction and quality hours × loaded rate.

• Privacy: requests × pseudonymisation or anonymisation runs × unit run cost, plus specialist review.

• Platform: annual storage + compute + identity + logging + secure transfer + retention.

• Output: projects × output-review events × reviewer hours × loaded rate.

• Change: implementing-act releases + national-law changes × impact-assessment and remediation effort.

Fees charged by access bodies or trusted holders must be proportionate to the cost of making data available (^[47]); chargeable activities can include consolidation, preparation, pseudonymisation, anonymisation, and provision. That supports activity-based internal cost accounting, but it does not establish a market price or allow invented benchmark rates.

EHDS readiness is justified by observable programme scale and data complexity, not a speculative market-size forecast. As of March 2025, the Health and Digital Executive Agency managed 68 projects supporting EHDS implementation (^[48]) and 65 direct grants, including 12 grants focused on semantic interoperability (^[49]). The earlier pilot brought together 17 partners and tested five use cases (^[50]) (^[51]). Research on the implementation received 20 responses from 18 national authorities (^[52]). A separate ECDC description counted eight national infrastructures, two EU agencies, and nine use cases, reflecting a different pilot framing and date rather than a number to merge silently (^[53]) (^[54]).

The surrounding life-science data estate is already large. EMA reported 5,088 trials transferred into the Clinical Trials Information System (CTIS) (^[55]), with about 200 initial applications per month (^[56]), around 80 of them multinational, during the stated 2023 to 2025 period (^[57]). Adult trial results are due within 12 months, and paediatric results within six months (^[58]) (^[59]). These figures show why organisation, country, study, and dataset identifiers must remain consistent across submissions and EHDS records.

Real-world evidence is also scaling. EMA's 2026 DARWIN EU page reports about 40 data partners (^[60]), about 110 studies delivered since 2022 (^[61]), and coverage of approximately 250 million European patients (^[62]). Its partners standardise data in the Observational Medical Outcomes Partnership model (^[63]). This does not make DARWIN EU equivalent to HealthData@EU, but it demonstrates the value of a common model, distributed stewardship, and repeatable analysis.

Data quality remains the harder constraint. A 2024 study of health-data reusers found 70% performed their own validation (^[64]), almost 20% did not know whether dataset-quality information existed (^[65]), 71% used or created contextual documentation, and 69% used a data dictionary (^[66]). A separate study of 5,700 repository URLs (^[67]) reported a mean FAIR compliance score of 9.4 out of 22 (^[68]), with moderate or advanced performance of 100.0% for findability, 21.5% for accessibility, 46.7% for interoperability, and 61.3% for reusability (^[69]). Findability alone is therefore not evidence of analytical readiness.

Standards proliferation reinforces the point. The original FAIR paper counted more than 600 life-science content standards (^[70]). A 2026 measurement review extracted 72 publications representing 60 surveys, but only six had enough information for formal assessment (^[71]) (^[72]). EMBL-EBI described Omics Discovery Index as one interface to 81,000 datasets from 11 repositories, enabled by common metadata and exchange standards (^[73]) (^[74]). The implication is concrete: record the exact standard, profile, version, mappings, and validation outcome. A metadata field that merely says “standardised” is not auditable.

The wider evidence points to governance effort as well as scale. BBMRI-ERIC developed a quality self-assessment tool with 106 European experts (^[75]). A peer-reviewed EHDS analysis organised 14 identified risks into five concern categories and proposed seven governance and technical solution directions (^[76]) (^[77]). The Clinical Trials Register separately counted 7,418 trials involving participants under 18 and information on 18,700 older paediatric trials (^[78]) (^[79]). These results support multidisciplinary stewardship and explicit data context, not catalogue automation alone.

A 2026 to 2029 readiness roadmap

Now through early 2027: establish governance and prove inventory coverage.

• Name executive, legal, privacy, clinical, data, security, and service owners.

• Classify entities and datasets against Articles 50 and 51.

• Pilot metadata on representative trial, registry, device, omics, and RWD datasets.

• Measure extraction, quality, pseudonymisation, rights review, and output-review effort.

• Establish a national-law register and implementing-act watch.

After the 2027 implementing acts: freeze interface contracts only after an impact assessment.

• Map final templates, catalogue properties, label specifications, and SPE controls to internal schemas.

• Update threat models, identity federation, audit evidence, and disclosure rules.

• Test one permit-style workflow and one statistical-request workflow end to end.

• Validate cross-border status, decision, permit, and data-routing messages.

During 2028 and before March 2029: industrialise the first category wave.

• Remediate catalogue gaps and produce machine-readable records.

• Contract for surge preparation capacity and specialist privacy review.

• Run service-level, evidence, deletion, and disaster-recovery exercises.

• Confirm each Member State's holder scope, opt-out mechanism, and added safeguards.

From 2029 through March 2031: operate, learn, and onboard the deferred wave.

• Use actual request volumes and preparation cycles to refine costs.

• Extend pipelines to genetics, other omics, trials, and research cohorts.

• Maintain first-publication dates and regulatory-protection metadata.

• Reassess whether trusted-holder status or an owned SPE is economical.

The 2027 checkpoint is especially important. The Commission must specify core secure-environment and network architecture, while TEHDAS2 runs through December 2026 (^[80]). Its 2026 SPE work defines minimum technical, functional, and security capabilities (^[81]). Existing TEHDAS2 material is valuable design input, but final binding specifications should control production acceptance criteria.

Metrics for the steering committee

Track a compact readiness scorecard. Coverage measures candidate source systems assessed and in-scope datasets catalogued. Metadata measures records passing the current HealthDCAT-AP validation profile. Quality measures datasets with current completeness, validity, consistency, and provenance evidence. Rights measures reviewed IP, trade-secret, regulatory-protection, and opt-out attributes. Preparation records median elapsed time and effort per dataset cycle. Privacy measures pipelines with tested pseudonym-key separation and disclosure control. Operations measures evidence controls passing exercise, including logging, output, and deletion. Change counts unresolved requirements from EU acts and relevant national laws.

These measures support a build, buy, or managed-service decision with internal evidence. They also prevent the roadmap from being reduced to a single platform procurement.

Does EHDS secondary use require a pharma company to disclose every dataset in 2029?

No. Scope depends on whether the entity is a holder, whether it holds an Article 51 category, and the category's phase. Regulated clinical-trial data, genetics, other omics, determinants, and qualifying research cohorts start in 2031, while many EHR, device, registry, administrative, and biobank categories begin in 2029. National additions and safeguards still require review.

Must data be transferred directly to the applicant?

No. Permit-based analysis occurs in an approved SPE. Only non-personal output may leave after review. A statistical request is narrower: it supplies an anonymised statistical response and no access to the underlying data.

How quickly must a holder respond?

The normal holder deadline is three months after receipt of the access body's request, with a justified extension of at most another three months. The organisation should use shorter internal targets for triage, rights review, extraction, quality checks, privacy transformation, and delivery.

Can IP or trade secrets block access automatically?

No. The holder identifies and justifies protected parts. The access body selects proportionate legal, organisational, and technical measures and can condition access. Refusal is available where a serious residual risk cannot be satisfactorily addressed, so field-level evidence is more useful than blanket confidentiality labels.

Can EHDS data support AI development?

Potentially. Permitted research can include algorithm training, testing, and evaluation for medical devices, in vitro diagnostics, AI systems, and digital-health applications. The user still needs an allowed purpose, necessary data, a permit, an SPE, and compliance with prohibited-use and output rules.

Does an opt-out erase ongoing approved research?

Not automatically. The opt-out affects identifiable personal data under permits or requests approved after exercise; it does not retroactively undo processing already approved. National public-interest exceptions may differ and need local legal review.

Should every holder build its own secure processing environment?

No. The access body normally provides the environment. A trusted holder may provide one only under a Member State designation procedure and with Article 73 capabilities. Most organisations should first make datasets portable, documented, privacy-ready, and tool-aware.

EHDS secondary-use readiness for pharma is a data operating-model programme with a legal clock. It starts by determining which legal entity holds which Article 51 dataset, in which Member State, and for which phase. It succeeds when catalogue metadata, data quality, provenance, privacy transformation, protected-rights review, opt-out handling, delivery, and evidence retention operate as one repeatable service.

The priority sequence is clear. Build the dataset and ownership inventory now. Use 2027 implementing acts as a controlled update gate. Industrialise 2029 categories first, while preparing the more specialised genetics, omics, trial, and cohort estate for 2031. Keep HealthData@EU and national interfaces modular, and separate holder duties from user, access-body, and trusted-holder responsibilities.

Organisations should not wait for every technical detail before improving metadata, lineage, preparation pipelines, and security evidence. They also should not hard-code provisional specifications into an inflexible platform. A measured programme, using internal workload quantities and clear decision rights, can meet both constraints. Final applicability, national variation, protected rights, and project-specific roles require qualified legal review.

The most useful near-term deliverable is not a finished platform. It is an evidence-backed map connecting entities, datasets, owners, rights, transformations, controls, application dates, and national dependencies. That map lets counsel test applicability, architects preserve replaceable interfaces, and data teams prioritise remediation using measured preparation effort rather than assumptions.