This guide explains what your organization actually needs to do to comply with DCAT-AP and HealthDCAT-AP ahead of EHDS secondary use ("EHDS2") — the concepts, the timeline, the mandatory fields, and the quality label. Every practical step can be carried out with nothing more than Katrion Metadata Editor.
EHDS (Regulation (EU) 2025/327) makes metadata catalogs mandatory for health data that may be subject to secondary use. HealthDCAT-AP is the technical profile (built on DCAT-AP/DCAT) that describes the catalog (the collection your organization publishes), each dataset (the logical body of information), and its distributions (the concrete ways the dataset can be accessed). The groundwork — categorizing your data under Article 51, describing the catalog, and preparing the Article 78 quality label — needs to be in place from 2027, not only by 2029 when the Health Data Access Bodies (HDABs) and HealthData@EU become fully operational. All of this is built and exported directly in Katrion.
The European Health Data Space (EHDS) Regulation — formally Regulation (EU) 2025/327 — was published in the EU Official Journal on 5 March 2025 and entered into force on 26 March 2025. The regulation has two main tracks: primary use (Chapters II–III, patients’ own access to and exchange of their records between providers and countries) and secondary use (Chapter IV), commonly referred to as "EHDS2".
Secondary use is about making health data — de-identified or pseudonymized — reusable for research, innovation, policy-making, patient safety, and regulation, through a structured, permit-based system. Each member state must designate one or more Health Data Access Bodies (HDABs) that review applications and grant access to a secure processing environment. The cross-border infrastructure is called HealthData@EU.
For an HDAB or HealthData@EU to find, assess, and grant access to a dataset at all, it must first be described in a metadata catalog — it is this description, not the underlying health data itself, that Katrion helps you produce.
EHDS is rolled out in stages. The key dates for an organization building a metadata catalog:
The regulation enters into force.
Most primary-use provisions start applying. For secondary use, this is when requirements such as describing datasets and preparing the Article 78 quality label kick in — the catalog groundwork needs to be under way from this date, not only by 2029.
Electronic health record (EHR) system manufacturers must meet the regulation’s interoperability and logging requirements.
Secondary use becomes fully operational: HDABs in every member state must be in place, HealthData@EU must be operational, and permits for secondary use of the first data categories must be grantable.
Further data categories become covered, including genomic data.
Extended access for third countries and international organizations starts applying.
Under Article 78(6), the EU must adopt an implementing act no later than 26 March 2027 setting the exact visual and technical format of the quality and utility label. As of this writing (October 2026), the official visual standard has not yet been published — so don’t wait for it before describing quality in text form; structure the information now around the six Article 78 areas (below) so you are ready to apply the official format once it arrives.
The regulation uses a fair number of acronyms. Here are the ones relevant to building the catalog:
DCAT’s (and therefore HealthDCAT-AP’s) core model has three levels, and it is exactly this structure Katrion is built around:
A simple rule of thumb: the catalog answers "which datasets exist and who owns them", the dataset answers "what is this information, and who may access it", and the distribution answers "how do I actually reach it, in practice". In Katrion, the catalog sits at the top, with one or more datasets beneath it, each with its own distributions.
EHDS Article 51 lists 17 categories of health data subject to secondary use (a–q). Each dataset in the catalog should be linked to the category or categories it belongs to. Summarized, in broad terms:
Note that the list above is a summary for overview purposes — the full, legally binding text is found in Article 51 of the regulation. In Katrion, you record the health data category as a text field per dataset, ready to be exported along with the rest of the metadata.
HealthDCAT-AP (release 8) specifies which fields are mandatory at each level. In short:
| Field | Requirement |
|---|---|
| Title | Mandatory |
| Description | Mandatory |
| Publisher | Mandatory, one per catalog |
| Applicable legislation | Mandatory |
| Field | Requirement |
|---|---|
| Access rights | Mandatory (Public / Restricted / Non-Public) |
| Applicable legislation | Mandatory |
| Description | Mandatory |
| Health category | Mandatory, one or more (Article 51) |
| Responsible HDAB | Mandatory, one per dataset |
| Identifier | Mandatory |
| Structured data (yes/no) | Mandatory, boolean field |
| HDAB coordinator | Optional |
For datasets that are not freely public, a distribution describing the path to the responsible HDAB for requesting access is required — even when there is no downloadable file to point to.
Structured data: if a dataset is flagged as containing structured (e.g. tabular) data, you can — since release 7 — attach a variable description following the CSVW pattern: name, readable title, and data type per variable. That is exactly what Katrion’s CSV import/export feature for structured data is built for.
Article 78 introduces a data quality and utility label intended to give a quick, comparable picture of a dataset’s quality. The label is voluntary by default — but becomes mandatory under Article 78(2) if the dataset was collected or processed with public funding (EU or national funds).
The label must cover six areas:
Katrion has a per-catalog admin setting to turn the quality and utility label on. Once enabled, every dataset gets its own tab to fill in the six areas in text form, ready to be exported along with the rest of the metadata and updated once the EU’s official visual standard (expected by 26 March 2027 at the latest, see the timeline above) is in place.
Below are the practical steps for building a HealthDCAT-AP catalog. Every technical step is carried out directly in Katrion Metadata Editor — no other tool is needed to produce a complete, export-ready catalog.
Fill in the title, description, publisher, and applicable legislation for your catalog. If you want the quality and utility label to be available, turn on that admin setting at the same time.
For each logical body of information: enter a description, access rights (Public/Restricted/Non-Public), applicable legislation, health data category under Article 51, the responsible HDAB, and an identifier. Flag whether the dataset contains structured data.
Add at least one distribution per dataset. For data that is not freely public, describe the path to the responsible HDAB for applying for access instead of a download link.
If the label is enabled, work through the six areas (documentation, technical quality, quality management, coverage, access, and modifications) for each dataset — especially important if the dataset is publicly funded, in which case the label is mandatory.
If a dataset has structured data: download the sample file under the "Structured data" tab, fill in the variable name, readable title, and data type per variable in the CSV format, import it, or export the CSV to reuse it in another tool.
Export to JSON-LD, Turtle, or RDF/XML directly in Katrion. The file follows HealthDCAT-AP release 8 and can be sent to your HDAB, shared with colleagues, or read by other DCAT-AP-compatible software.
Katrion stores everything locally in your browser — no cloud service, no third-party account. Export/import is the intended way to back up and share the file between colleagues or devices as the catalog is updated over time — every import is automatically SHACL-validated against HealthDCAT-AP, so any gaps are caught immediately instead of at a later submission.
Note: the above is a technical and practical summary, not legal advice. Your organization still needs to determine its own role (for example, whether you are a data holder under EHDS) and appoint responsible contacts — but the actual catalog work that follows from that determination is done entirely in Katrion.
The catalog is the entire collection of metadata your organization publishes. A dataset is the description of a logical body of information within the catalog (e.g. a registry). A distribution is the concrete way the dataset can be reached, such as a file, an API, or a description of how to apply via the responsible HDAB. A dataset can have several distributions.
No. Although HDABs and HealthData@EU don’t need to be fully operational until 26 March 2029, several preparatory requirements — including describing datasets and preparing the quality and utility label — already apply from 26 March 2027. Building the catalog well ahead of that is recommended.
It is voluntary by default, but becomes mandatory under Article 78(2) if the dataset was collected or processed with public funding (EU or national funds).
No. Under Article 78(6), the EU must adopt an implementing act by 26 March 2027 at the latest, setting the exact format. As of this writing (October 2026) it has not yet been published. Fill in the six quality areas in text form in the meantime — the structure can be adapted quickly once the format is set.
Release 8, the latest published version (May 2026) of the European Commission’s draft specification. Katrion exports against release 8.
Only for datasets flagged as containing structured (table-like) data — the field is a boolean yes/no. The feature has existed since HealthDCAT-AP release 7.
Yes. Katrion runs entirely in the browser and stores everything locally (localStorage) — nothing is sent to any server until you choose to export the file yourself.
An HDAB (Health Data Access Body) is the national body that reviews secondary-use applications. Yes — HealthDCAT-AP requires every dataset to identify exactly one responsible HDAB.
Katrion produces an export file (JSON-LD, Turtle, or RDF/XML) that follows HealthDCAT-AP. The actual submission process to your national HDAB and HealthData@EU is determined by the HDAB’s own technical systems, which are still being built ahead of 2029 — but the underlying metadata work, describing the catalog, datasets, and distributions correctly, is done entirely in Katrion today.
The legally binding list (a–q) is found in Article 51 of Regulation (EU) 2025/327. See the summary above and the sources below for a link to the official text.
An imported catalog or dataset file can look syntactically correct — valid JSON-LD, Turtle, or RDF/XML — while still missing fields that HealthDCAT-AP requires, such as a health data category, a responsible HDAB, or a distribution. SHACL validation is what catches that kind of error before it carries forward: Katrion checks every imported catalog and dataset against HealthDCAT-AP’s required fields and clearly shows what’s missing, so you can complete or correct it before the catalog is sent on to your HDAB or HealthData@EU. Without that check, errors risk being discovered only at a formal submission, much later in the process.
This page is an informational summary, not legal advice. Always check the binding regulation text and your own legal counsel before decisions regarding your organization’s compliance.
Try Katrion with one example dataset, with no login required, or contact us to get started for real.