EHDS Specifications: Critical Review | Agile Health Informatics Ltd

The judgement

This review assesses the public specification landscape, its rationale and its suitability for implementation. It distinguishes what sources establish from the conclusions drawn here.

Proceed with controlled implementation. Do not procure against an unqualified “EHDS compliant” claim.

The separation of clinical content, exchange, discovery, access decisions and protected processing is sound. Maturity differs across those layers. The largest risks lie less in any single specification than between them: no one owns the transformation from care records to analytical data, and the live cross-border network must move from CDA to FHIR without a published path. A defensible implementation needs a declared use case, an applicable legal baseline, exact artefact versions and evidence that the whole service behaves as intended.

Review judgement, not a regulatory certification.

Coherence

Strong in purpose, weak between routes

Direct care and secondary use have different actors and authorisation routes, and are rightly specified apart. The bridge from clinical record to analytical variable is not specified by either side.

Maturity

Uneven across components

Adopted implementing acts coexist with trial-use guides, ballot documents and changing technical builds. A release number alone does not establish legal authority or operational readiness.

Suitability

Useful for staged delivery

The materials support architecture, prototyping and specification of national services. Claims about production compliance need narrower scope and stronger evidence than a successful payload validation.

Where the risk concentrates

Priority issues, ranked by how likely each is to stall a national programme

Ranking is the reviewer’s judgement of schedule and rework exposure, not a measure of specification quality. Two publication-governance issues are recorded separately as hygiene issues (F18, F19).

The semantic bridge from care records to analysis has no ownerF01 · Both use
A live CDA network must move to FHIR without a published migration pathF02 · Primary use
There is no single settled EHDS implementation packageF03 · Both use
Mappings need permanent owners, licences and evidenceF04 · Primary use
Patient rights become distributed enforcement requirementsF05 · Primary use
The access decision must become enforceable behaviourF06 · Secondary use
Search and imaging exchange still contain design decisionsF07 · Primary use
Comparable conformance depends on a testing environment not yet observedF08 · Primary use

Scope boundary. This is a targeted architectural and specification-status review of public evidence. It is not a clause-by-clause legal opinion, a full audit of every profile or a test of deployed national systems. Access and review-depth limitations are recorded in the source register.

Two purposes, distinct routes

Select a route, then a layer. Each step explains the responsibility, the rationale and the assurance boundary. These are conceptual responsibilities, not a claim that every country must deploy the same software topology.

Shared foundations, separate authority: identity, terminology, provenance and security support both routes. A clinical exchange through MyHealth@EU does not itself grant secondary-use access through HealthData@EU. The national architecture must implement the relevant route and safeguards. [1] [16]

Why several standards instead of one common schema?

Clinical models describe the meaning and context of a record. Exchange profiles define interactions. Catalogue metadata describes a dataset as an asset. Access and processing specifications govern what can be done with it. These are different abstraction levels, and combining them would create ambiguity.

The architectural implication is to manage relationships between artefacts. A national programme should be able to trace a clinical concept through its local representation, exchange mapping, derived dataset, catalogue description and access conditions. This traceability is a recommendation of this review, not a claim that EHDS prescribes one national metadata platform.

The weakest link in that chain is the step from clinical model to analytical dataset. Neither the primary-use nor the secondary-use specifications own it, which is why it is the review’s lead finding (F01).

Adopted is not the same as applicable

Select a milestone. The dates describe selected EU-level phases, not a complete national delivery plan or a guarantee that all services will be ready.

Check each instrument and provision before assigning a deadline. Publication, entry into force, general application and service-specific obligations can have different dates. [1] [2]

The specification register

Search by name, version, purpose or limitation. Open an entry for its rationale and evidence. “Adoption not verified” means this review did not establish an adopted baseline; it is not proof that no such instrument exists.

Adopted lawPublished trial use / ballotDraft / evolving / unverified

Search specificationsUsePublication status

Critical findings

Each finding separates an observation, its architectural interpretation and a proposed response. Priority issues identify implementation risk, not a finding of legal non-compliance.

What implementers should do now

These are architectural recommendations derived from the findings. They distinguish durable preparation from choices that need a confirmed release baseline.

Decision area	Commit now	Control or defer
Care-to-analysis bridge	Name an owner for transforming clinical-model content into the analytical model(s) in use. Version those mappings and publish them with HealthDCAT variable descriptions.	Do not let each data holder choose and map to its own analytical model independently.
CDA-to-FHIR transition	Inventory CDA dependencies. Define where format transformation happens and who owns its clinical-safety case.	Keep CDA capability in scope until MyHealth@EU publishes a migration timetable and equivalence mappings.
Semantic governance	Assign ownership of clinical definitions, terminology mappings and change approval. Preserve source meaning and provenance.	Do not freeze an entire national persistence model around one evolving exchange profile.
Primary-use implementation	Inventory priority-category data, assess source quality and test mappings against named published or pilot artefacts.	Keep draft-dependent interfaces replaceable. Obtain the authorised MyHealth@EU release and national connection requirements before production acceptance.
Secondary-use services	Connect dataset stewardship, catalogue publishing, access management, preparation and secure processing through explicit responsibilities.	Do not treat HealthDCAT validation as evidence that the underlying dataset is interoperable, lawful to use or fit for analysis.
Procurement	Specify supported actors, categories, versions, terminology, tests, defects and upgrade obligations. Require reusable evidence and exportability.	Reject undated blanket compliance statements. Separate conformity of a product component from acceptance of an integrated clinical service.
Patient rights	Design restriction, opt-out and access-information handling as one service with a defined interface, including cross-border access logging and emergency override.	Avoid embedding rights logic separately inside each source system.
Change and operations	Create a dependency register, named owners, incident routes and a process for assessing upstream changes.	Treat changing CI builds as engineering inputs. Approve a reproducible baseline before claiming conformance.

Worked example: a baseline manifest

F03 recommends a baseline manifest. In practice it is a lock file: one record per claimed capability, stating exactly what was built and tested against. The fhir block mirrors ImplementationGuide.dependsOn and can be generated from the package dependency graph; the legal, network, terminology and test blocks are governed by hand.

{
  "baseline": "ps-crossborder-pilot-2027-01",
  "scope": { "useCase": "Patient summary, outbound", "actor": "Country of affiliation NCPeH",
             "category": "patient-summary", "paradigm": "document" },
  "legal": [
    { "act": "Regulation (EU) 2025/327", "provisions": "Arts 8-10, 14-15", "appliesFrom": "2029-03-26" },
    { "act": "Implementing Regulation (EU) 2026/2083", "appliesFrom": "2027-03-26" }
  ],
  "network": { "release": "<authorised MyHealth@EU release id>",
               "wireFormat": "CDA R2 (current service)", "targetFormat": "FHIR R4 document" },
  "fhir": {
    "core": "hl7.fhir.r4.core#4.0.1",
    "dependsOn": [ "<IPS package>#<published version>", "<EPS package>#<published version>" ],
    "rule": "No ci-build or ballot package in a production baseline"
  },
  "container": { "profile": "PDF/A-3 (ISO 19005-3)", "attachment": "FHIR Bundle, AFRelationship declared" },
  "transport": { "profile": "IHE MHD / XDS.b", "revision": "<ITI Technical Framework revision>" },
  "terminology": { "snomedCT": "<edition URI + version>", "loinc": "<version>",
                   "valueSets": "<MVC release>", "licenceCoverage": "confirmed per jurisdiction" },
  "tests": { "suite": "<id + version>", "results": "<location>", "openDefects": "<register ref>" },
  "approval": { "clinicalOwner": "<name>", "technicalOwner": "<name>", "date": "<yyyy-mm-dd>" }
}

The example is a structured clinical document: an IPS FHIR document carried inside a PDF/A-3 container and shared over XDS/MHD. It is a useful test because it touches every layer the manifest must pin: content packages, the container profile and its attachment relationship, the transport profile, terminology releases, and the CDA-versus-FHIR position of the live network. A demonstrator of this design is a good place to prove the manifest works before procurement depends on it. Placeholders in angle brackets must be filled from authorised releases, not CI builds.

Implications for a national health service

A national health service needs an implementation architecture that joins local data stewardship to European obligations. The common services should include governed definitions, terminology, identity, mappings, catalogue publication and evidence management. These can be federated organisationally while maintaining national accountability for the exchange boundary.

For Ireland, this suggests separating the primary-use connection to MyHealth@EU from the secondary-use connection to HealthData@EU, with shared semantic and governance capabilities underneath. This is a proposed architectural approach, not a statement about the current designation or readiness of Irish authorities.

An HSE baseline would need clear answers to the following. Each maps to a finding above.

Contact point. Who operates the national contact point for eHealth, which MyHealth@EU services it runs or plans, and in which format (F02)?
Terminology. Which body owns the national terminology function, mapping maintenance for the priority categories and licence coverage, including SNOMED CT (F04)?
Source mapping. For each priority category, which source systems hold the data, who owns the mapping to the EEHRxF models, and what evidence exists of its clinical fidelity (F04)?
Patient rights. Where will restriction, opt-out and access-information services live, and how will they reach cross-border access (F05)?
Identity. How do national patient and professional identifiers and eID connect to the cross-border identity rules and the EUDI wallet (F17)?
Secondary use. Which body is or will be the HDAB, how does it relate to the HSE as a data holder, and who owns the transformation from care records to the analytical model (F01, F06)?

These are questions for a programme baseline, not assumptions about current arrangements. National responsibilities and statutory arrangements require their own review.

EEHRxF: European Electronic Health Record Exchange Format: content structures, coding and technical exchange specifications.
Implementation guide (IG): A constrained use of a base standard for specified actors and purposes. Publication by an SDO is distinct from legal adoption.
CI build / ballot / STU: Continuous integration build; consultation or voting edition; Standard for Trial Use. These are different publication states.
CDA: HL7 Clinical Document Architecture R2: the document format on which current MyHealth@EU services run.
CDM / OMOP: Common data model for analysis; OMOP is one widely used example. EHDS, as reviewed, prescribes none.
MVC: Master Value Set Catalogue: the value sets and translations used in the current cross-border network.
HDAB / SPE: Health data access body / secure processing environment. One manages access decisions; the other provides controlled processing capabilities.

Build an evidence request

Use this planner to structure a supplier or programme review. Tick an item only when you have identified the evidence. This is a completeness prompt, not a compliance score, and no data is sent anywhere.

Evidence identified

0 / 9

Evidence has not been recorded in this session.

Review notes
Record the system, use case, versions and outstanding questions. Export before closing; entries are not saved automatically.

Sources, method and limits

The evidence cut-off is 15 October 2026. Sources are official EU publications and the organisations publishing the technical specifications. Version labels are those observed on the linked pages; mutable URLs may subsequently show newer material. The register reports observed releases, not a guarantee of the newest unpublished work.

The review examines purpose, architectural boundaries, publication maturity, traceability and implementation suitability. It does not assign numerical maturity scores, because they would suggest precision unsupported by this heterogeneous evidence. Findings labelled as interpretations and recommendations are the reviewer’s analysis.

Revision 1.1 (16 October 2026). Adds a ranked list of priority issues and makes the care-to-analysis bridge the lead finding. Adds findings on the CDA-to-FHIR transition, patient rights, the Article 40 testing environment and the interplay with device, AI and identity regimes, and reframes the FHIR-version finding around documents versus resources. Merges the two mapping findings. Reclassifies two publication-governance findings as hygiene issues and renumbers all findings in reading order. Adds register entries, a worked baseline manifest, an Ireland question set, a ninth evidence category and full timeline and architecture content in print. Sources [27]–[34] are new. The judgement is unchanged in direction.

Coverage limits: EU legal pages were intermittently accessible; some provisions were verified through official indexed extracts. The Xt-EHR deliverables site and published-model history returned access errors. Detailed imaging and medication workflow profiles, restricted contact-point artefacts, all TEHDAS2 guidelines, national legal choices and deployed-system conformance remain outside the completed audit. Articles 8–10, 27 and 40 were checked through unofficial article-level renderings and should be confirmed against the Official Journal text. eIDAS 2, the OMOP CDM and DARWIN EU are cited for context only. The 2026 implementing regulations [3]–[5] and [26] should be spot-checked against EUR-Lex before citation. No formal completeness claim is made.

Law

EHDS specifications:critical review and explainer