European Health Data Space
View source on GitHubThis interactive demo is an EHDS integration platform you can run, fork, and wire into your own stack. It shows how the EHDS regulation enables secure cross-border health data sharing across Europe: publishing clinical datasets, negotiating access contracts under ODRL, and transferring FHIR / OMOP data through the Dataspace Protocol. Every flow is exposed as a REST API you can exercise from Swagger, Scalar, Bruno, or your own client.
Why the European Health Data Space Matters
The EHDS regulation creates a unified framework for sharing health data across EU member states while safeguarding patient rights under GDPR. It distinguishes between primary use (patients accessing their own records) and secondary use (research, policy, innovation), each with strict governance and oversight.
For Researchers
Cross-border access to standardised health datasets in FHIR R4 and OMOP CDM format, ending bilateral negotiations with each hospital. The health data access body decides on one application under Art. 67 and 68, cutting months of bureaucracy to weeks.
For Hospitals
A clear legal basis for sharing data with researchers while staying GDPR-compliant. Publish datasets once via HealthDCAT-AP catalogues, manage access through standardised DSP contracts, and let the health data access body handle regulatory approval, reducing legal risk and administrative burden.
For Patients
Full control over your health records across borders. Access your data from any EU provider via EEHRxF (European Electronic Health Record exchange Format), with GDPR Art. 15-22 rights to access, rectify, and control how your data is used for research.
For Regulators
Issue and enforce EHDS data permits (Art. 68) as the health data access body. Audit compliance via verifiable credentials, ensure protocol conformance, and govern trust anchors across the dataspace.
Standards & Interoperability
The EHDS builds on established open standards to ensure interoperability across all EU member states. This demo implements each standard end-to-end.
EU regulation establishing rules for primary use (patient access) and secondary use (research) of electronic health data across member states.
HL7 FHIR R4Fast Healthcare Interoperability Resources, the global standard for exchanging clinical data (Patient, Condition, Observation, Medication).
OMOP Common Data ModelObservational Medical Outcomes Partnership CDM v5.4. Standardises clinical data for large-scale observational research and cohort analytics.
HealthDCAT-APHealth extension of DCAT-AP, a metadata standard for publishing and discovering health datasets in federated catalogues across the EU.
Dataspace ProtocolEclipse Dataspace Protocol 2025-1. Governs catalogue federation, contract negotiation, and secure data transfer between dataspace participants.
Decentralised Claims ProtocolVerifiable credential issuance and presentation. Enables trust anchors, membership credentials, and data access permits without central authority.
Learn the New Principles: Dataspaces & Data Mesh
Health data is no longer moved by point-to-point integrations. The EHDS is built on dataspace and data mesh principles: sovereign participants own their data domains, publish them as data products, and exchange them through open protocols instead of bulk copies. Use this demo to get hands-on with the four building blocks every implementer needs to understand.
Data Domains & Data Products
Each hospital, registry, or research org is a domain that owns its data end-to-end. A data product packages a dataset with metadata (HealthDCAT-AP), contract terms (ODRL), and an access endpoint (FHIR / OMOP). Browse them in the catalogue to see what federated ownership actually looks like.
Explore the catalogueDataspace Protocol (DSP): Exchange
DSP 2025-1 standardises the four exchange phases, catalogue → negotiation → agreement → transfer, so any two participants can trade data without bilateral glue code. Walk through a full negotiation and watch the state transitions in the live graph.
Run a DSP negotiationW3C DID & Verifiable Credentials: Authentication
Participants identify themselves with did:web identifiers and prove membership, health data access body approval, or researcher status with W3C Verifiable Credentials issued via the Decentralised Claims Protocol (DCP). No central identity broker: trust is federated and cryptographically verifiable.
Inspect credentialsW3C ODRL Policies: Authorization
Every data product is governed by a machine-readable ODRL 2.2 policy declaring permissions, prohibitions, and duties (purpose limits, retention, geographic scope, anonymisation). Policies travel with the contract and are enforced at the data plane, not as free-text T&Cs.
Edit ODRL policiesIntegrate It: REST API Tools
Every endpoint is documented in OpenAPI 3.1 and can be exercised from three interactive explorers, a portable Bruno collection, or any HTTP client. Use them to test flows, build integrations, or wire the platform into a downstream system.
Modern API reference with try-it-now requests, language samples, and schema navigation. Powered by Scalar.
Classic OpenAPI explorer for testing endpoints against the live instance with OIDC auth.
Raw YAML spec for codegen, Postman import, or custom tooling. Source of truth for every route.
Git-friendly, offline-capable API client. Clone the repo and run every DSP, FHIR, and OMOP journey locally.
Klarbefund: real data for the dataspace, held by the patient
Health dataspaces run on synthetic patients, this one included. That shows the plumbing, not the rules: GDPR, the EHDS and the AI Act are about data that belongs to a person. Real data is what is missing, and it is the hardest to bring in lawfully.
Klarbefund brings it in from the person's side. Scan a paper lab report or import the PDF, and the iPhone turns it into LOINC-coded values set against published reference ranges, each marked with its source. They reach the dataspace only when the person decides.
- GDPR. Values stay on the phone, encrypted, until the person sends them (Art. 25). Export as PDF, FHIR and OMOP (Art. 20); delete the account in the app (Art. 17).
- EHDS. The person creates an account on this hub and adds their values to their own record: FHIR R4 Observations, LOINC-coded, marked preliminary and with their source. Research use is a separate consent.
- AI Act. An AI answers only when asked, names provider and model each time, and never calls it a diagnosis (Art. 50).
The app is in a public TestFlight beta for iPhone with iOS 26. Join with one tap.
Tap the button on your iPhone, or scan the code with its camera. TestFlight is Apple's app for trying apps before release. Up to 200 testers, iOS 26 or later.
How the EHDS Demo Works
Sign in as one of the demo personas and follow their journey through the dataspace. Each role sees different pages, data, and actions, mirroring real EHDS workflows.
Patient
AlphaKlinik Berlin · login as patient1
View your EHR: conditions, medications, observations
/patient/profile
See which research programmes use your data
/patient/research
Review AI-generated health insights
/patient/insights
Explore your clinical data in the knowledge graph
/graph
Researcher
PharmaCo Research AG · login as researcher
Search the federated HealthDCAT-AP catalogue
/data/discover
Request data access via DSP 2025-1 contract
/negotiate
Receive approved FHIR R4 bundles
/data/transfer
Run OMOP CDM cohort analytics
/analytics
Hospital
AlphaKlinik Berlin · login as clinicuser
Publish FHIR datasets as HealthDCAT-AP entries
/catalog
Register data assets in the dataspace
/data/share
Review and approve incoming data requests
/negotiate
Manage verifiable credentials and DID identity
/credentials
Regulator
MedReg DE (HDAB) · login as regulator
Review health data access applications (Art. 67)
/compliance
Audit ODRL policies and compliance rules
/admin/policies
Issue and verify participant credentials
/credentials
Inspect trust anchors in the knowledge graph
/graph
Admin
Dataspace Operator · login as edcadmin
Manage participants, connectors, and topology
/admin
Explore all 5 architecture layers at once
/graph
Onboard new participants with DID:web
/onboarding
Configure connector endpoints and policies
/settings
Explore
The persona overview, the HealthDCAT-AP dataset catalogue, FHIR patient journeys, OMOP analytics, EEHRxF profile coverage and natural language queries. On the live demo, each opens after you sign in.
One view per persona: what is out of range, due, broken, and what to do next
HealthDCAT-AP metadata for all published datasets
FHIR R4 clinical timeline with OMOP CDM mapping
Cohort-level research analytics dashboard
EU FHIR profile alignment and EHDS coverage gap analysis
Federated Cypher queries via natural language interface
Exchange · Transfer · Negotiate
The DSP data exchange lifecycle: hospitals publish datasets, researchers discover and request access, contracts are negotiated under ODRL policies, and approved FHIR/OMOP data is transferred securely.
Publish and register health data assets for the dataspace
Search the federated catalog for available datasets
Negotiate data usage contracts with providers via DSP
Transfer FHIR/OMOP data and inspect FHIR R4 bundles
Track data access permit tasks and approval workflows
Govern · Manage · Docs
EHDS compliance monitoring, DCP verifiable credentials, participant onboarding with DID:web identities, portal administration, and architecture documentation.
EHDS compliance, data permits, and protocol conformance testing
Manage MembershipCredential, EHDS participant, and data permits
Register new participants and generate DID identities
Participant profile, connector endpoints, and credentials
Tenant management, policies, component topology, and audit logs
User guide, developer docs, and architecture reference
Demo Users & Roles
Sign in as any persona to explore role-specific views. Password = username · Keycloak realm: EDCV
Feedback & Contributions
Found a bug, have a feature idea, or want to discuss the EHDS architecture? We'd love to hear from you.
Latest updates
The documentation in five languages
Every docs page, the 17 published documents, their screenshots and their diagrams follow the language picker. A translation that falls behind the English says so.
Every page of the hub in five languages
The pages of the health data access body, the health data holder, the health data user and the patient, the explore pages, the administration and the wallet's phone screens follow the picker too, with one word for credentials in each language.
ODRL policies in plain language
Every policy on the policies page is explained in plain sentences and checked against ODRL 2.2 and the EHDS rules for secondary use: valid, with warnings or with errors.
A criticality for every access
The access log rates each access low, medium or high and says why, and accesses made by automated tests carry a Test badge.
Confidential SPEs attest on Azure
Both SPE workspaces on Azure confidential containers get their data key from Trustee only after AMD SEV-SNP hardware attestation, checked against Microsoft's endorsed measurement.
Patients see their own insights and studies
A signed-in patient's insights and research pages read their own record, and the recommendations follow their own conditions.
In German, French, Dutch and Spanish
Pick a language in the menu bar: the menus, the sign-in page, this start page and the catalogue switch with it. Every dataset is described in German and Spanish, some in French and Dutch, and legal terms are the Regulation's own, checked against the Official Journal.
National EHDS rules for six member states
How Germany, Austria, Belgium, France, the Netherlands and Spain implement secondary use: the access body's legal role, the national law, the opt-out, fees and dates, each with its official source.
Confidential secure processing environments
Two SPE workspaces as Azure confidential containers, which get their data key only after attesting to the access body's Trustee. The administration shows where each runs; bringing them up on Azure is under way.
Safer natural language questions
Cypher written by the language model runs in a read-only session, and k-anonymity applies to federated questions as it does to federated Cypher.
Klarbefund deletes everywhere
"Delete all my data" in the iPhone app now deletes the account and its values on the hub too, and the app's menu shows trends, the record and duplicates.
Sign in with an EUDI wallet
The hub runs its own verifier for d-you, the German EUDI wallet. A PID signs in to, links to or creates a sandbox account by a secure hash, never by the person's name.
HealthDCAT-AP Release 8, validated
Every dataset description passes the official Release 8 SHACL the way the HealthData@EU validator checks it, and the Art. 71 opt-out filters every secondary-use query.
Security and operations, published
The threat model, the security test report, the production readiness assessment and the load test results with their dashboards are under Docs.