EHDS Implementation Readiness Lab
A small, practical validation exercise for implementers: run a clean FHIR lab-result bundle, run a broken one, inspect the issues, and understand the evidence.
For: EHDS implementers, FHIR trainers, vendor teams, hospital IT teams
Why this lab exists
Interoperability readiness is a skills problem, not only a standards problem.
EHDS implementation depends on people who can turn profile packages, terminology rules, references, and evidence requirements into operational checks. Written standards help, but implementers also need executable examples that show what a good resource looks like, what a broken one looks like, and what evidence a team should preserve.
This lab is deliberately small: one Patient, one laboratory Observation, one clean bundle, one broken bundle, and a sample report shape. It is a teaching asset, not an EHDS certification statement.
What you run
Two fixtures, one pinned validation context.
Clean fixture
records profile install hl7.fhir.eu.base \ --version 2.0.0 --activaterecords validate-file \ ehds-lab-clean-lab-result-bundle.json \ --engine --format jsonBroken fixture
records validate-file \ ehds-lab-broken-lab-result-bundle.json \ --engine --format jsonClean example
Shows a Patient and lab Observation with profile declarations, LOINC code, subject reference, timestamp, and UCUM quantity.
Broken example
Seeds realistic mistakes so implementers can learn how structural, terminology, and reference issues appear.
Pinned context
Uses the same reproducibility idea as Records runs: fixed FHIR version, profile package, terminology context, and thresholds.
Sample evidence
Shows how a run report should explain scope, package pins, issue classes, and boundaries.
What the broken fixture teaches
A useful lab makes the failures explicit.
| Seeded problem | Issue family | Why it matters |
|---|---|---|
| Invalid Patient birth date | Structural date-format issue | Dates must be machine-readable for matching, safety, and exchange. |
| Unsupported Observation status | Required code binding issue | Status codes drive downstream interpretation of clinical observations. |
| Observation references a missing Patient | Reference integrity issue | Cross-resource references must resolve for patient-level interpretation. |
| Wrong UCUM system URL | Terminology/canonical hygiene issue | Canonical systems make quantity validation and downstream filters predictable. |
| Non-UCUM unit code | Terminology unit-code issue | Unit errors can silently break clinical filters and analytics. |
How Records makes the learning visible
The point is not only pass or fail. The point is preserving the measurement context.
Boundary
What this lab does not claim.
This lab does not prove EHDS production readiness. It does not cover all EHDS categories, national overlays, consent, access control, security operations, or legal obligations.
Records preserves validation evidence and lock status for a pinned FHIR context. It does not persist source clinical payloads, certify compliance, or act as the authority for EHDS implementation decisions. A later replay still requires the corresponding source scope.
Use this in an implementation workshop.
We can adapt the lab to a national profile pack, vendor onboarding flow, or EHDS readiness conversation.