User Guide

The landing page presents a high-level overview of the dataspace: active participants, registered datasets, and recent transfers. Quick-action cards let you jump to common tasks.

Example: PharmaCo Research AG logs in and sees 5 active participants, 3 published datasets, and a pending contract negotiation with AlphaKlinik Berlin.

The onboarding wizard guides new participants through dataspace registration: creating a DID identity, registering with the Credential Federated Manager, and enrolling in the federated catalog. This process implements the EHDS requirement for authorised participation (Art. 75) with verifiable credentials.

Example: Limburg Medical Centre joins the EHDS dataspace by providing its organization details, generating did:web:lmc.nl:clinic, and obtaining a MembershipCredential.

View and manage your participant profile, verifiable credentials (MembershipCredential, EHDSParticipantCredential), connector endpoints, and Keycloak SSO configuration.

Example: AlphaKlinik Berlin checks that both its MembershipCredential and EHDSParticipantCredential are active and not expired before publishing a new dataset.

A patient signs in with the person identification data (PID) in an EUDI Wallet, such as the German d-you wallet, instead of a password: the sign-in page shows a QR code, the wallet presents the PID over OpenID4VP, and the hub checks it with its own verifier (EHDS Art. 16, eIDAS). An account the Klarbefund app created can be linked to a PID once under My Health, Connect your EUDI wallet; the hub keeps a keyed fingerprint of the PID, never the name or birth date.

Example: A patient scans the QR code with d-you, approves the presentation and lands in their own record at assurance level high. The static demo shows the flow with a simulated phone.

One view per role that answers the role's primary question. On the left, what needs attention right now, most urgent first, each with the article of Regulation (EU) 2025/327 it concerns. On the right, a layered 3D scene of the knowledge graph behind it: the role's own decisions and their clocks, credentials, permits and contracts, data users and holders, datasets, and the months unfolded over time.

• Tabs for Patient, Researcher, Access body and Data holder
• Click a finding to select its node in the scene and unfold what lies behind it
• Turn the scene off (or ask your system for reduced motion) and the list on the left is the full view

Example: MedReg DE sees that three applications passed the three-month decision deadline of Art. 68(4) and opens the queue by month.

Browse and search HealthDCAT-AP metadata records for all published datasets. Each entry shows title, description, publisher, temporal/spatial coverage, and distribution formats. The catalog implements the EHDS metadata requirements (Art. 77) for discoverable, machine-readable dataset descriptions.

• Filter by publisher, theme, or keyword
• View distribution endpoints (FHIR, OMOP, bulk export)
• Check data quality metrics (DQV dimensions)
• Initiate data access requests from catalog entries

Example: PharmaCo Research AG searches for “diabetes” datasets and finds AlphaKlinik Berlin's Type 2 Diabetes Cohort with FHIR R4 and OMOP CDM distributions.

Data holders create and edit their dataset descriptions here. The hub serves them as HealthDCAT-AP Release 8, the form Implementing Regulation (EU) 2026/2098 sets for every dataset description. Mandatory fields are marked, and a saved entry carries what Release 8 requires (access body, distribution, variables, contact point), so it passes the official validation at once.

Example: AlphaKlinik Berlin adds its Type 2 Diabetes Cohort with an Art. 68 data permit as the legal basis, then exports the catalogue as Turtle.

View the clinical timeline for synthetic patients, showing FHIR R4 resources (Encounters, Conditions, Observations, Medications, Procedures) mapped to their OMOP CDM equivalents. This dual-view demonstrates how primary-use clinical data (EHDS Chapter II) can be transformed for secondary-use analytics while preserving semantic integrity.

• Select patients from the patient list
• Timeline displays events chronologically
• Toggle between FHIR and OMOP views
• Explore SNOMED/LOINC/RxNorm concept mappings

Example: A data steward reviews the timeline for a synthetic patient with hypertension, verifying that the FHIR Condition correctly maps to OMOP condition_occurrence with SNOMED code 38341003.

Cohort-level research analytics powered by the OMOP CDM layer. Run aggregate queries across conditions, measurements, drug exposures, and procedures. This implements the EHDS secondary-use analytics capability (Art. 53) where researchers work with de-identified, standardised data.

• View condition prevalence and demographics
• Analyse drug exposure patterns
• Run cohort characterisation queries
• Export results for further analysis

Example: PharmaCo Research AG runs a cohort query to identify patients with Type 2 Diabetes who received Metformin, showing age and gender distribution across the cohort.

A researcher with a data permit asks a question in plain language. A prepared question, a fulltext search or, where one is configured, a language model turns it into Cypher, which runs inside the secure processing environment; the page shows the Cypher, the permit it ran under and the rows that came back. The Federated button asks every SPE and merges the answers. Every answer about persons is k-anonymous: a count below 5 is shown as <5, and a share computed from it with it.

Example: A researcher asks “What is the age distribution?”; the 0-17 group holds one person and comes back as <5, with a k = 5 badge saying how many values were suppressed.

European EHR Exchange Format profile alignment view. Analyse which FHIR profiles satisfy EHDS priority categories (Patient Summary, ePrescription, Laboratory Results, Medical Imaging, Hospital Discharge) and identify coverage gaps. The EEHRxF is mandated by EHDS Art. 15 to ensure interoperability of primary-use health data across Member States.

Example: MedReg DE reviews AlphaKlinik Berlin's profile coverage and sees that Patient Summary and Laboratory Results are fully aligned, while ePrescription has one missing profile.

A natural-language question over the patient's own record (EHDS Art. 3, GDPR Art. 15): trends from fitness, lab and nutrition data, together with the relevant ePA events, computed only from that patient's data.

Example: A patient asks how their cholesterol has changed since their last check-up.

The patient's health profile and risk assessment, derived from their own record.

Example: A patient reviews the risk factors the profile derives from their last lab results.

The opt-out from all secondary use (EHDS Art. 71), at any time and reversible, and, separately, the research programmes the patient can join or leave, with the history of every consent given or withdrawn (GDPR Art. 7(3)).

Example: A patient opts out of secondary use; from then on every new research query leaves them out, and the opt-out is kept with its date until they opt back in.

What research using the patient's data found, and the recommendations that follow for them.

Example: A patient reads an insight from a diabetes study they contributed to.

Klarbefund turns a paper lab report into checkable values on the phone. Connected to the hub, it either creates its own sandbox account with an empty record (gated by Apple App Attest) or connects to an existing one: Health Profile shows a QR code, the app scans it and is connected. It sends the reports, vaccinations and medication plan the person chooses, and weekly device means behind a switch of their own. Delete all my data in the app also deletes the account it created on the hub. The beta is open through TestFlight.

Example: A patient photographs a lab report, checks the values Klarbefund read, and sends the report to their record, where it appears under Patient Journey.

Publish datasets with HealthDCAT-AP metadata and ODRL access policies for the federated catalog. Define distribution endpoints, data quality attributes, and usage constraints. Data holders use this page to fulfil their obligation under EHDS Art. 60 to make data available for secondary use.

Example: AlphaKlinik Berlin publishes a “Synthetic Diabetes Cohort” dataset with FHIR R4 bulk export distribution, EHDS Art. 33 usage policy, and spatial coverage set to DE.

Search the federated catalog across all connected dataspace participants. Results aggregate datasets from multiple EDC connectors, showing availability and access terms. The federated catalog enables cross-border dataset discovery without centralising metadata.

Example: PharmaCo Research AG discovers 3 datasets across 2 participants for “cardiovascular” research: one from AlphaKlinik Berlin and two from Limburg Medical Centre.

Initiate and track DSP contract negotiations with data holders. View negotiation state (REQUESTED, AGREED, VERIFIED, FINALIZED), ODRL policy terms, and counter-offer history. Contract negotiation ensures that data access terms are mutually agreed before any transfer occurs, as required by EHDS Art. 34.

Example: PharmaCo Research AG initiates a contract negotiation with AlphaKlinik Berlin for the diabetes cohort. The negotiation progresses to FINALIZED with an EHDS Art. 33(c) research use policy.

Monitor the task queue for pending and active data transfer operations. Tasks track the full lifecycle from initiation through provisioning to completion, providing the audit trail required by EHDS for accountability.

Example: The operator monitors a bulk FHIR export task from AlphaKlinik Berlin to PharmaCo Research AG, currently at the provisioning stage with an estimated 2-minute completion time.

View the complete history of data transfers, both initiated and received. Each entry includes timestamps, transfer size, protocol used, and a link to the audit trail. Transfer logging implements the EHDS requirement for full traceability of all health data movements across the dataspace.

Example: PharmaCo Research AG reviews its transfer history showing a completed 12 MB FHIR bulk export from AlphaKlinik Berlin, transferred via HTTP-PUSH with full W3C PROV audit trail.

The admin dashboard shows system health at a glance: connector uptime, active participants, recent negotiations, transfer throughput, and credential status.

Example: The operator sees all 5 participants are online, 3 contract negotiations are active, and 12 transfers completed in the last 24 hours with no failures.

Inspect the runtime status of Eclipse Dataspace Connector components: Control Plane, Data Plane, Identity Hub, Issuer Service, and the Connector Fabric Manager. View health checks, versions, and configuration details.

Example: The operator checks that the Control Plane (port 11003), the FHIR Data Plane (port 11002) and the Identity Hub (port 11005) all report healthy on the local stack.

The evidence behind each secure processing environment's label, for the operator (EDC_ADMIN): the verdict, who verified it (the access body's Trustee), what was proven and what was not, the measurements, and the chain from the data permit to its policy hash, the Trustee's key release and the loaded workspace, with the SPE's last audit events. Each SPE on the operator dashboard links to it.

Example: the operator checks that SPE-2 of Limburg Medical Centre got its key for MedReg DE's permit, and reads why an earlier attempt was refused.

The participants' tenants in the Connector Fabric Manager: their virtual participant agents and provisioning state.

Example: The operator checks that a newly onboarded clinic's tenant finished provisioning.

Every participant in the dataspace with its DID and credentials; the operator can add or remove one.

Example: The operator adds Limburg Medical Centre and confirms its DID resolves.

The ODRL policies each participant offers its data under, grouped by participant. New policies start from a template for a permitted purpose of Art. 53 (scientific research, public health, official statistics, AI training and more), with the permitted purposes, the duration of use and the duties attached; the JSON can be edited directly.

Example: the operator gives Limburg Medical Centre a policy for scientific research only, valid one year, that forbids re-identification.

The audit log and provenance trail, with the retention settings. Shared with the access body, which uses it for supervision.

Example: MedReg DE traces which queries touched a dataset in the last month.