This 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 (HDAB) provides a single-window approval process under Art. 46, 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 HDAB 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
Enforce EHDS Art. 46-51 data access permits through 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, HDAB 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
All 36 endpoints are 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 5 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 data access permit applications (Art. 46)
/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
A living body on the start page
The hero now shows the body as a network of organs, walking in place, beside the introduction.
Static analysis on every change
Semgrep runs before every commit with a rule against Cypher built from request input, CodeQL checks every pull request, and all 20 images running on Azure are scanned for CVEs every week.
Every API route needs a sign-in
Only the sign-in flows and the health probe answer anonymously. The registers and the graph moved behind a session, and the API collection checks each 401.
The API collection, by EHDS persona
132 Bruno requests, one folder per role in the regulation, run against this demo on every change to the UI.
An overview for every persona
Every sign-in lands on a 3D overview made for its role: the patient, the access body, the data holder and the researcher.
Klarbefund, the iPhone app
Published reference ranges for 57 more analytes, microbiome organisms named by their NCBI Taxonomy id, and a full export or deletion of everything the app holds.