HealthDCAT-AP is a health-related extension of the DCAT application profile for sharing information about Catalogues containing Datasets and Data Services descriptions in Europe (DCAT-AP) [DCAT-AP]. DCAT-AP is maintained by the SEMIC action, Interoperable Europe.
While DCAT-AP provides a minimal common basis within Europe to share Datasets and Data Services cross-border and cross-domain, HealthDCAT-AP introduces a refined RDF vocabulary to accommodate the unique requirements of electronic health data.
The proposal for a regulation on the European Health Data Space [EUR-Lex - 52022PC0197], aims to establish a unified framework to facilitate the sharing and exchange of electronic health data across Europe. It aligns with European standards for data privacy and security and specifically addresses the challenges and obstacles for the secondary use of health data—data repurposed from its original collection for research, innovation, or policymaking – in Europe by outlining specific rules and processes for data availability, usage conditions, and supporting these efforts through a common European infrastructure, healthdata@EU.
Key articles within the regulation proposal detail operational mandates: Article 33 identifies the types of health data that must be made available for secondary use; Article 57 tasks the European Commission to develop an EU dataset catalogue, federating the catalogues of Member states and other authorised participants into HealthData@EU; and Article 55 commissions health data access bodies to provide metadata about available datasets, detailing their source, scope, main characteristics, data nature, and access conditions.
The development of a healthDCAT application profile, as an extension of the DCAT application profile, aims to standardize health metadata within the scope of EHDS, fostering greater interoperability, findability and accessibility of electronic health data across the EU.
Introduction
Context
The European Health Data Space (EHDS) regulation [EUR-Lex - 52022PC0197] is designed to address the significant fragmentation in accessing electronic health data across EU Member States. This fragmentation has hindered researchers, innovators, policymakers, and regulators from fully utilizing data to advance their objectives. The EHDS regulation seeks to eliminate these barriers, setting a framework to minimize legal uncertainties and ease the access and use of health data. By promoting a cohesive approach, the regulation aims to unlock the intrinsic value of electronic health data for secondary purposes such as research and innovation.
To facilitate the implementation of the EHDS regulation, the EHDS2 pilot project [EHDS2] has been launched. This project is pivotal in constructing a prototype of the "HealthData@EU" infrastructure, which is intended for the secondary use of health data. This infrastructure will connect various national data platforms into a unified network, enhancing the ease of conducting cross-border health research and innovation. The project not only aims to streamline the user journey for accessing and utilizing health data but also to establish robust guidelines concerning data standards, security, and transfer protocols. Such guidelines are crucial for maintaining the integrity and security of data within this cross-border framework.
In alignment with the European Commission's broader data strategy, which includes horizontal frameworks like the Data Governance Act [EUR-Lex - 32022R0868] and the Data Act [EUR-Lex - 32023R2854], the EHDS is part of a wider initiative to create sector-specific European data spaces, such as those for space, finance, energy, and health. A critical aspect of the EHDS project involves the development of national and EU dataset catalogues, providing a standardized language tailored to the specifics of electronic health data and user needs. This standardisation will be achieved through the creation of a dedicated healthDCAT application profile, an extension of the DCAT used widely across open data portals in Europe. This profile will ensure that data cataloguing and metadata practices are harmonized, enhancing interoperability and accessibility across the EU.
The use of DCAT Application Profile for data portals in Europe (DCAT-AP) as baseline specification for metadata records is explored as cornerstone for semantic interoperability in the EHDS and with other European data spaces.
This document details the specifications for the HealthDCAT-AP extension, a specialised adaptation of the EU DCAT Application Profile. This extension refines the DCAT data model to better support the discovery of health data, thus improving the accessibility and understanding of electronic health records. It places a strong emphasis on privacy and security, ensuring that sensitive information is discoverable and shared in a responsible and efficient manner.
This initiative is part of the broader European Health Data Space (EHDS) and aligns with the goals of the EU4Health Programme to strengthen health systems. By fulfilling the specific objectives set forth in Regulation (EU) 2021/522 [EUR-Lex - 32021R0522], this project plays a critical role in developing a robust, accessible, and effective health data infrastructure across Europe. The enhanced infrastructure is expected to drive the digital transformation of healthcare within the EU, fostering a more data-driven, efficient, and patient-centered approach. Ultimately, this will significantly improve public health outcomes and healthcare delivery across member states.
This document is a deliverable of the Work Package 6 of the EHDS2 pilot project [EHDS2] consortium.
The development of the HealthDCAT extension is an ongoing iterative process that will extend beyond the pilot project, incorporating continuous feedback and contributions from the stakeholder community. This document specifies a first iteration of the HealthDCAT-AP extension, a customised adaptation of the EU DCAT Application Profile. It adapts the DCAT data model specifically for health-related catalogued resources, in alignment with the Regulation proposal on the European Health Data Space [EUR-Lex - 52022PC0197]. This customisation facilitates the management and dissemination of health data within the regulatory framework, enhancing its accessibility and utility for health data users.
A DCAT-AP extension: Enhancing DCAT-AP for the secondary use of health data
The HealthDCAT-AP designed as an extension of the DCAT-AP incorporates its principal classes such as dcat:Catalog, dcat:CatalogRecord, dcat:Dataset, dcat:Distribution, and dcat:DataService.
This extension leverages RDF's flexible architecture to enhance metadata capabilities without compromising the stability of existing or under-development catalog systems. By integrating new metadata elements as triples, the extension enriches the metadata model without altering established structures.
To ensure interoperability, the extension adheres to several principles:
It meets the minimal conformance criteria of DCAT-AP.
Newly introduced classes and properties must not replicate the functionality of existing DCAT-AP components.
It incorporates mandatory controlled vocabularies from DCAT-AP and may introduce additional vocabularies.
Modifications to property cardinalities are allowed under the following conditions:
- Mandatory properties retain their required status.
- Recommended properties may be classified as optional or mandatory.
- Optional properties can be made mandatory
- Recommended and optional properties may be removed based on the extension's specific needs.
To effectively extend DCAT-AP, several best practices are recommended:
Reviewing and potentially integrating metadata properties from related extensions such as StatDCAT-AP for statistical data and GeoDCAT-AP for geospatial data.
Prioritizing vocabularies used in DCAT-AP for metadata property selection, with key vocabularies such as Dublin Core-DCMI Metadata Terms, Asset Description Metadata Schema (ADMS), PROV-O: The PROV Ontology, ODRL Information Model, as well as considering Data Privacy Vocabulary (DPV), Schema.org, and Data Quality Vocabulary (DQV).
Using EU-controlled vocabularies maintained by the Publications Office to define metadata property values, which should be:
- Openly licensed.
- Managed by a reputable institution.
- Well-documented.
- Multi-lingual, ideally covering all official EU languages.
- Comprising a manageable number of terms to facilitate broad resource classification.
- Identified by URIs, with each URI directing to detailed documentation about the term.
- Supported by clear persistence and versioning policies.
This structured approach to developing HealthDCAT-AP ensures that the metadata model is enhanced while maintaining interoperability and compliance with established standards, thereby supporting a more interconnected and accessible digital health ecosystem.
Status of This Document
This application profile was published by the Work Package 6 of the EHDS2 pilot project as a Recommendation on December 22th, 2023. It has no official standing of any kind and does not represent the support or consensus of any standards organisation.
The structure and content of this document are partially derived from the [DCAT-AP-v3.0] and [DCAT-AP High Value Dataset] specifications. This approach ensures a consistent document format across all DCAT-AP specifications.
Information about the process and the decisions involved in the creation of this specification are consultable at the Changelog.
For applications to comply with HealthDCAT-AP, they MUST first conform to DCAT-AP. Additionally, these applications MUST adhere to the specified constraints and usage guidelines, following conformance statements similar to those outlined in DCAT-AP.
Provider requirements
In order to conform to this Application Profile, an application that provides metadata MUST:
Provide a description of the Catalogue, including at least the mandatory properties specified for the class Catalogue.
Provide descriptions of Datasets in the Catalogue, including at least the mandatory properties for the class Dataset.
Provide descriptions of Distributions of Datasets in the Catalogue, including at least a distribution for the Health Data Access Body responsible for providing access to health data and including at least the mandatory properties for the class Distribution.
Provide descriptions of all other classes such as Agents, Contact Points, Access Rights, etc.
The application of the controlled vocabularies as described in section [[[#controlled-vocs]]].
Receiver requirements
In order to conform to this Application Profile, an application that receives metadata MUST be able to:
Process information for all classes and properties specified in section [[[#quick-reference]]].
Process information for all controlled vocabularies specified in section [[[#controlled-vocs]]].
"Processing" refers to the requirement that receivers accept incoming data and seamlessly deliver it to applications and services. This term does not dictate or specify the final actions that applications and services perform with the data, such as parsing, converting, storing, making searchable, or displaying to users.
Terminology used in this application profile
An Application Profile is a specification that reuses terms from one or more base standards, and adds more specificity by identifying mandatory, recommended and optional elements for a particular application, as well as advising on the use of controlled vocabularies.
A Dataset is a collection of data featuring a data catalogue that describes datasets and offers services to facilitate their discovery and reuse.
In the context of the EHDS Regulation proposal [EUR-Lex - 52022PC0197 (Art.44)], accessing these datasets must comply with the principles of data minimization and purpose limitation. This ensures that only data relevant and necessary for the intended processing purpose are provided, in either anonymised or pseudonymised form, depending on what is feasible for meeting the processing objectives.
A Data holder means, in the context of the EHDS Regulation proposal [EUR-Lex - 52022PC0197 (Art.2 (y))], any natural or legal person, which is an entity or a body in the health or care sector, or performing research in relation to these sectors, as well as Union institutions, bodies, offices and agencies who has the right or obligation, in accordance with this Regulation, applicable Union law or national legislation implementing Union law, or in the case of non-personal data, through control of the technical design of a product and related services, the ability to make available, including to register, provide, restrict access or exchange certain data.
Article 32a: Applicability to health data holders
1. The following categories of health data holders shall be exempted from the obligations incumbent on health data holders laid down in this Chapter:
(a) individual researchers and natural persons;
(b) legal persons that qualify as micro-enterprises as defined in Article 2 of the Annex to Commission Recommendation 2003/361/EC.
Member States may, by virtue of national legislation, provide that the obligations of health data holders laid down in this Chapter shall apply to the health data holders referred to in paragraph 1 which fall under their jurisdiction.
Member States may, by virtue of national legislation, provide that the duties of certain categories of data holders shall be fulfilled by health data intermediation entities. In that case, the data shall still be considered as being made available from several data holders.
National legislation defined under paragraphs 2, 3 and 4 of this Article shall be notified to the Commission by [date of applicability of Chapter IV]. Any subsequent law or amendment affecting them shall be notified to the Commission without delay.
A Data Portal is a Web-based system that contains a data catalogue with descriptions of datasets and provides services enabling discovery and reuse of the datasets.
In the context of the EHDS Regulation proposal [EUR-Lex - 52022PC0197 (Art.57)], Data Portals are managed by the European Commission, Health Data Access Bodies and other authorised participants.
The Common European data spaces [Shaping Europe’s digital future (europa.eu)] are a key component of the European strategy for data.
Their aim is to make more data available for access and reuse. This will be done in a trustworthy and secure environment for the benefit of European businesses and citizens.
DCAT-AP supports the implementation of the 14 sector data spaces by providing a standardised framework for cataloging datasets, thereby enhancing data interoperability and accessibility across different data spaces in Europe.
A Catalogue is a curated collection of metadata about datasets.
A Catalogue Record is a set of statements about the description of a dataset in the catalogue, e.g. providing information about when a dataset was entered in the catalogue or when its description was modified.
A Distribution is a specific available form of a dataset. If a dataset is published in multiple formats (e.g. Excel, CSV, Data Cube) these are described as separate distributions.
In the context of the EHDS Regulation proposal [EUR-Lex - 52022PC0197 (Art.54)], all secondary use access to requested electronic
health data SHOULD be done through a secure processing environment.
Health Data Access Body: According to the EHDS Regulation proposal [EUR-Lex - 52022PC0197], a Health Data Access Body for secondary use of electronic health data is an organisation designated by EU Member States that ensures that electronic health data are made
available by data holders for data users.
A Uniform Resource Identifier - URI is an Internet Engineering Task Force (IETF) Request
for Comments (RFC)21 specifying a compact
sequence of characters that identifies an abstract or
physical resource. URLs on the Web are a subset of
URIs and are often called HTTP URIs.
Personal electronic health data means data concerning health and genetic data as
defined in Article 4, points (13) and (15), of Regulation (EU) 2016/679, processed
in an electronic form. [EUR-Lex - 32016R0679 (Art.4(13)(15))]
Non-personal electronic health data
means electronic health data other than
personal electronic health data, encompassing both data that has been
anonymised so that it no longer relates to an identified or identifiable natural
person and data that has never related to a data subject.
Namespaces
The namespace for healthDCAT-AP is: (to create)
The suggested namespace prefix is: healthdcatap
This specification uses the following prefixes to shorten the URIs for readibility.
Prefix
Namespace IRI
adms
http://www.w3.org/ns/adms#
dcat
http://www.w3.org/ns/dcat#
dcatap
http://data.europa.eu/r5r/
dct
http://purl.org/dc/terms/
dpv
https://w3id.org/dpv#
dpv-pd
https://w3id.org/dpv/dpv-pd#
dqv
https://www.w3.org/TR/vocab-dqv/
foaf
http://xmlns.com/foaf/0.1/
rdf
http://www.w3.org/1999/02/22-rdf-syntax-ns#
rdfs
http://www.w3.org/2000/01/rdf-schema#
skos
http://www.w3.org/2004/02/skos/core#
vcard
http://www.w3.org/2006/vcard/ns#
xsd
http://www.w3.org/2001/XMLSchema#
Abbreviations
AP: Application Profile CSV: Comma-separated values CSVW: CSV on the Web DCAT: Data Catalog Vocabulory UML: Unified Modeling Language URI: Uniform Resource Identifier
healthDCAT-AP Overview
HealthDCAT-AP is an application profile to DCAT-AP. The healthDCAT-AP specific requirements are compatible with the release of DCAT-AP 2 and release of DCAT-AP 3.0.0.
This application profile is meant to provide a DCAT-AP-conformant representation of metadata specific to health datasets in scope of the EHDS Regulation proposal [EUR-Lex - 52022PC0197] as listed in Article 33.
HealthDCAT-AP extends DCAT-AP by including:
additional classes and properties;
additional recommendations on the use of classes and properties;
additional controlled vocabularies.
Application profile diagram
An overview of healthDCAT-AP is shown by the UML diagram below. The UML diagrams illustrate the specification described in this document.
For readability purposes, the representation has been condensed as follows:
The figure contain the key classes (highlighted in blue), Catalogue, Catalogue Record, Dataset and Distribution with some important supporting classes. Other object properties (relationships) are listed as properties on the UML class with their target range.
New properties and updated cardinalities are highlighted in green.
All other DCAT-AP properties are highlighted in red.
Colors are employed in the diagram to simplify and streamline its presentation, reducing the complexity of relationships to enhance the diagram's clarity and interpretability.
Figure 1 HealthDCAT-AP UML Class Diagram (extending DCAT-AP 3.0) for Sensitive health Data
Figure 2 HealthDCAT-AP UML Class Diagram (extending DCAT-AP 3.0) for Protected health Data
Figure 3 HealthDCAT-AP UML Class Diagram (extending DCAT-AP 3.0) for Open health Data
Main Entities
The main entities are those that form the core of the Application Profile.
The properties and their associated constraints that apply in the context of this profile are listed in a tabular form.
Each row corresponds to one property.
In addition to the constraints also cross-references are provided to DCAT and DCAT-AP. For the last, to save space, the following abbreviations are used:
A: reused as-is defined and expressed in DCAT-AP
E: reused with additional usage notes or additional restrictions compared to DCAT-AP
P: profile specific extension where DCAT-AP had no requirements earlier on specified
This reuse qualification assessment refers to a specific version of DCAT-AP.
Therefore it may vary over time when new versions of DCAT-AP are created.
A email address via which contact can be made.
This property SHOULD be used to provide the email address of the Agent, specified using fully qualified mailto: URI scheme [RFC6068]. The email SHOULD be used to establish a communication channel to the agent.
As empty Catalogues are usually indications of problems, this property should be combined with the property service to implement an empty Catalogue check.
A site or end-point (Data Service) that is listed in the Catalogue.
As empty Catalogues are usually indications of problems, this property should be combined with the property dataset to implement an empty Catalogue check.
A knowledge organisation system used to classify the Catalogue's Datasets.
This property refers to a knowledge organisation system used to classify the Catalogue's Datasets. It must have at least the value NAL:data-theme as this is the mandatory controlled vocabulary for dcat:theme.
A link to the Dataset, Data service or Catalog described in the record.
A catalogue record will refer to one entity in a catalogue. This can be either a Dataset or a Data Service. To ensure an unambigous reading of the cardinality the range is set to Catalogued Resource. However it is not the intend with this range to require the explicit use of the class Catalogued Record. As abstract class, an subclass should be used.
The legislation that mandates the creation or management of the Dataset.
RDF example: dcatap:applicableLegislation
For health datasets, the value must include the ELI of the EHDS Regulation.
As multiple legislations may apply to the resource the maximum cardinality is not limited.
Publishers are encouraged to provide URLs pointing to API endpoints or document repositories where users can access or request associated resources such as technical reports of the dataset, quality measurements, usability indicators,... or analytics services.
The health category to which this dataset belongs as described in the Commission Regulation on the European Health Data Space laying down a list of categories of electronic data for secondary use, Art.33.
RDF example: healthdcatap:healthCategory
A mandatory controlled vocabulary denoting health data within the scope of the Commission Regulation is provided.
A statement related to quality of the Dataset, including rating, quality certificate, feedback
that can be associated to the dataset.
RDF example: dqv:hasQualityAnnotation
A category of the Dataset.
RDF example: dcat:theme
A Dataset may be associated with multiple themes.
The authority table for Data Themes, maintained by the Publications Office of the European Union is the mandatory controlled vocabulary for dcat:theme. It must have at least the value NAL:data-theme "HEAL" to annotate health datasets.
A recommended controlled vocabulary data-type is foreseen. For health datasets containing personal level information, the type of the dataset MUST take the value "personal data".
It can be represented using a controlled vocabulary or with geographic coordinates. In the latter case, the use of the Core Location Vocabulary is recommended, following the approach described in the GeoDCAT-AP specification.
Properties
For this entity the following properties are defined: bbox
, centroid
, geometry
.
A statement about the intellectual property rights (IPR) held in or over a resource, a legal document giving official permission to do something with a resource, or a statement about access rights.
This property MUST be used to indicate the conditions if any contracts, licences and/or are applied for the use of the dataset. The conditions are declared on an aggregated level: whether a free and unrestricted use is possible, a contract has to be concluded and/or a licence has to be agreed on to use a dataset.
The supportive entities are supporting the main entities in the Application Profile.
They are included in the Application Profile because they form the range of properties.
An activity is something that occurs over a period of time and acts upon or with entities; it may include consuming, processing, transforming, modifying, relocating, using, or generating entities.
Properties
This specification does not impose any additional requirements to properties for this entity.
An established (technical) standard to which the Data Service conforms.
The standards referred here SHOULD describe the Data Service and not the data it serves. The latter is provided by the dataset with which this Data Service is connected.
For instance the data service adheres to the OGC WFS API standard, while the associated dataset adheres to the INSPIRE Address data model.
A description of the services available via the end-points, including their operations, parameters etc.
The property gives specific details of the actual endpoint instances, while dct:conformsTo is used to indicate the general standard or specification that the endpoints implement.
This property can be repeated for parallel language versions.
It is recommended to provide an indication about the dimensions the Dataset Series evolves.
A geographic region that is covered by the Dataset Series.
When spatial coverage is a dimension in the dataset series then the spatial coverage of each dataset in the collection should be part of the spatial coverage. In that case, an open ended value is recommended, e.g. EU or a broad bounding box covering the expected values.
An entity (organisation) responsible for ensuring the coherency of the Dataset Series
The publisher of the dataset series may not be the publisher of all datasets.
E.g. a digital archive could take over the publishing of older datasets in the series.
The date of formal issuance (e.g., publication) of the Dataset Series.
The moment when the dataset series was established as a managed resource.
This is not equal to the release date of the oldest dataset in the collection of the dataset series.
When temporal coverage is a dimension in the dataset series then the temporal coverage of each dataset in the collection should be part of the temporal coverage. In that case, an open ended value is recommended, e.g. after 2012.
The locn:Geometry class provides the means to identify a location as a point, line, polygon, etc. expressed using coordinates in some coordinate reference system.
Properties
This specification does not impose any additional requirements to properties for this entity.
An identifier in a particular context, consisting of the string that is the identifier; an optional identifier for the identifier scheme; an optional identifier for the version of the identifier scheme; an optional identifier for the agency that manages the identifier scheme.
Properties
For this entity the following properties are defined: notation
.
Legal basis used to justify processing of data or use of technology in accordance with a law.
Usage Note
Legal basis (plural: legal bases) are defined by legislations and regulations, whose applicability is usually restricted to specific jurisdictions which can be represented using dpv:hasJurisdiction or dpv:hasLaw. Legal basis can be used without such declarations, e.g. 'Consent', however their interpretation will require association with a law, e.g. 'EU GDPR'.
Properties
This specification does not impose any additional requirements to properties for this entity.
This class represents the legislation, policy or policies that lie behind the Rules that govern the service.
Usage Note
The definition and properties of the Legal Resource class are aligned with the ontology included in "Council conclusions inviting the introduction of the European Legislation Identifier (ELI)". For describing the attributes of a Legal Resource (labels, preferred labels, alternative labels, definition, etc.) we refer to the ELI ontology.
In this data specification the use is restricted to instances of this class that follow the ELI URI guidelines.
Properties
This specification does not impose any additional requirements to properties for this entity.
A literal value such as a string or integer; Literals may be typed, e.g. as a date according to xsd:date. Literals that contain human-readable text have an optional language tag as defined by BCP 4715 [[rfc5646]].
Properties
This specification does not impose any additional requirements to properties for this entity.
Data directly or indirectly associated or related to an individual.
Usage Note
This definition of personal data encompasses the concepts used in GDPR Art.4-1 for 'personal data' and ISO/IEC 2700 for 'personally identifiable information (PII)'.
Properties
This specification does not impose any additional requirements to properties for this entity.
A statement of any changes in ownership and custody of a resource since its creation that are significant for its authenticity, integrity, and interpretation.
Properties
This specification does not impose any additional requirements to properties for this entity.
This class represents the Purpose or Goal of processing data or using technology.
Usage Note
The purpose or goal here is intended to sufficiently describe the intention or objective of why the data or technology is being used, and should be broader than mere technical descriptions of achieving a capability. For example, "Analyse Data" is an abstract purpose with no indication of what the analyses is for as compared to a purpose such as "Marketing" or "Service Provision" which provide clarity and comprehension of the 'purpose' and can be enhanced with additional descriptions.
Properties
This specification does not impose any additional requirements to properties for this entity.
An annotation that associates a resource (especially, a dataset or a distribution) to another resource (for example, a document) that certifies the resource's quality according to a set of quality assessment rules.
Usage Note
Instances of this class are annotations pointing to quality certificates.
Properties
This specification does not impose any additional requirements to properties for this entity.
rdfs:Literal encoded using the relevant ISO 8601 Date and Time compliant string and typed using the appropriate XML Schema datatype (xsd:gYear, xsd:gYearMonth, xsd:date, or xsd:dateTime).
Decimal represents a subset of the real numbers, which can be represented by decimal numerals. The ·value space· of decimal is the set of numbers that can be obtained by multiplying an integer by a non-positive power of ten, i.e., expressible as i × 10^-n where i and n are integers and n >= 0.
Duration represents a duration of time. The ·value space· of duration is a six-dimensional space where the coordinates designate the Gregorian year, month, day, hour, minute, and second components defined in § 5.5.3.2 of [[ISO8601]], respectively.
Number derived from integer by setting the value of minInclusive to be 0.
Controlled Vocabularies
The usage of controlled vocabularies in HealthDCAT-AP conforms and extends the usage defined by DCAT-AP.
Requirements for controlled vocabularies
According to the generic DCAT-AP guidelines for publishing controlled vocabularies, controlled vocabularies SHOULD:
Be published under an open licence.
Be operated and/or maintained by an institution of the European Union, by a recognised standards organisation or another trusted organisation.
Be properly documented.
Have labels in multiple languages, ideally in all official languages of the European Union.
Contain a relatively small number of terms (e.g. 10-25) that are general enough to enable a wide range of resources to be classified.
Have terms that are identified by URIs with each URI resolving to documentation about the term.
Have associated persistence and versioning policies.
Provide a human readable representation.
Provide a machine readable representation.
Controlled vocabularies to be used
In the table below, a number of properties are listed with controlled vocabularies that MUST be used for the listed properties. The declaration of the following controlled vocabularies as mandatory ensures a minimum level of interoperability.
The Corporate bodies NAL must be used for European institutions and a small set of international organisations. In case of other types of organisations, national, regional or local vocabularies should be used.
The EU Vocabularies Name Authority Lists must be used for continents, countries and places that are in those lists; if a particular location is not in one of the mentioned Named Authority Lists, Geonames URIs must be used.
This list of terms provide types of datasets. Its main scope is to support dataset categorisation of the EU Open Data Portal. (To create a new entry for PERSONAL_DATA)
In addition to the proposed common controlled vocabularies, which are mandatory to ensure minimal interoperability, healthDCAT-AP relies on [Wikidata] as large-scale, human-readable, machine-readable, multilingual, multidisciplinary, centralised, editable, structured, and linked knowledge-base.
Wikidata URIs MUST be used for the following properties coding system, code values, conform to, health theme.
Support for implementation
This section provides recommendations for implementers on how to catalogue health resources required by the EHDS Regulation proposal [EUR-Lex - 52022PC0197] as a DCAT-AP metadata structure.
In scope of EHDS
The EHDS Regulation proposal defines the minimum categories of electronic data for secondary use. A Dataset is in scope of the EHDS Regulation proposal if and only if it is included in the categories listed under Article 33:
Minimum categories of electronic data for secondary use
1. Data holders shall make the following categories of electronic data available for secondary use in accordance with the provisions of this Chapter:
(a) electronic health data from EHRs;
(b) data on factors impacting on health, including socio-economic, environmental and
behavioural determinants of health;
(ba) aggregated data on healthcare needs, resources allocated to healthcare, the
provision of and access to healthcare, healthcare expenditure and financing;
(c) pathogen data, impacting on human health;
(d) healthcare-related administrative data, including dispensation, claims and
reimbursement data;
(e) human genetic, epigenomic and genomic data;
(ea) other human molecular data such as proteomic transcriptomic, metabolomic,
lipidomic and other omic data;
(f) automatically generated personal electronic health data, through medical devices;
(fa) data from wellness applications;
(g) data on professional status, specialisation and institution of health professionals
involved in the treatment of a natural person;
(h) population-based health data registries (public health registries);
(i) data from medical registries and mortality registries;
(j) data from clinical trials, clinical studies and clinical investigations subject to
Regulation (EU) 536/2014, Regulation [SOHO], Regulation (EU) 2017/745 and
Regulation (EU) 2017/746, respectively;
(k) other health data from medical devices;
(ka) data from registries for medicinal products and medical devices;
(l) data from research cohorts, questionnaires and surveys related to health, after the
first publication of results;
(m) health data from biobanks and associated databases.
Denoting a health Dataset
Each Dataset that is identified by a Health Data Access Body in scope of the EHDS Regulation proposal MUST provide the European Legislation Identifier (ELI) (to create) of the future EHDS Regulation for the property applicable legislation.
Health data categories
When a Dataset is within the scope of the EHDS Regulation proposal, it is mandatory that the property theme takes the value http://publications.europa.eu/resource/authority/data-theme/HEAL of the Dataset Theme Vocabulary of the Publications Office.
The EHDS Regulation proposal defines 15 electronic health data categories in its Article 33. HealthDCAT-AP introduces a new property health category to indicate the category to which a dataset, belongs. A controlled vocabulary (to create) with all possible values MUST be used for the property health category.
Access rights
When a dataset falls under the purview of the EHDS Regulation Proposal, it is imperative for data holders to clearly specify to the Health Data Access Body the conditions under which the dataset can be accessed. Specifically, the Access Rights property is required to adopt one of the predefined values listed in the Access Rights Named Authority List provided by the Publications Office. This designation informs data users whether the dataset is considered open data or is classified as non-public.
Non-personal electronic health data
According to Article 41 of the EHDS Regulation proposal, "data holders of non-personal electronic health data shall ensure access to data through trusted open databases to ensure unrestricted access for all users and data storage and preservation".
For non-personal electronic health data, it is mandatory that the property Access Rights takes the value http://publications.europa.eu/resource/authority/access-right/PUBLIC of the Access Rights Named Authority List provided by the Publications Office.
Data holders are further obliged to declare that the dataset contains personal data:
This is achieved by utilising the 'dct:type' property
and associated Dataset-type authority table with value "PERSONAL_DATA" (to create)
to describe the dataset's classification type, thereby ensuring a comprehensive understanding of its accessibility and sensitivity.
Data holders are also further encouraged to detail the sensitive nature of the dataset:
This is achieved by utilising the personal data property and providing the list of key elements that represent an individual in the dataset.
It is required to adopt the predefined classes listed in the extension of the Data Privacy Vocabulary (DPV) Specification "Extended Personal Data categories for DPV" (DPV-PD). The DPV-PD provides additional concepts regarding Personal Data categories.
Distribution
When a health Dataset is categorised as personal electronic health data, HealthDCAT-AP, in accordance with the National Single Information Points [NSIP] requirements, mandates that applications MUST include at least one distribution with the following essential properties:
access URL
, byte size
, format
, rights
.
Moreover Access URL MUST be the landing page of the Health Data Access Body presenting the dataset.
And the applicable legislation MUST be the ELI URI of the EHDS Regulation proposal.
When a health Dataset is categorised as non-personal electronic health data, implementers MUST provide descriptions for, at least, one distribution of the dataset according to Article 41 of the EHDS Regulation.
Sample distribution
When a health Dataset is categorised as personal electronic health data, implementers MUST provide descriptions for, at least, one sample Distribution of the dataset.
This rule consisting in providing open access subsets ensure meaningful use and interpretation of non-public datasets.
These samples could be anonymised or synthetic subsets that retain the original dataset's essential characteristics without revealing any personal information, or it might solely exhibit the dataset's structure [Best Practice 3: Provide structural metadata].
Providing such a sample as a downloadable file can offer insights into the data's format and structure, aiding in understanding and utilisation while ensuring privacy and security.
Subsets can be presented as RDF, RDF-izing variable descriptions using vocabularies like the [CSVW] Namespace Vocabulary Terms and Term definitions used for creating Metadata descriptions for Tabular Data.
Identifiers as persistent URIs
As DCAT-AP is a Semantic Web data specification, persistence is associated with the use of persistent URIs (PURIs) for the metadata descriptions.
A general advice for DCAT-AP implementers is to use PURIs for all entities, but mostly for Datasets and Data Services.
In the context of healthDCAT-AP, the practice of employing Persistent Uniform Resource Identifiers (PURIs)
is mandatory endorsed for the primary identifier property identifier (see example: dct:identifier), as well as for all properties within DCAT that are of range the classes Dataset and Resource (has version, source, is referenced by, related resource, related resource).
This approach aligns with best practices of DCAT-AP on identifiers, ensuring that DCAT metadata records and metadata descriptions are not only uniquely
identifiable but also consistently and reliably accessible over time. By adhering to this standard, healthDCAT-AP facilitates the precise linking and retrieval of datasets and resources,
enhancing interoperability and the utility of health data within the healthdata@EU infrastructure and beyond.
DCAT-AP best practices on identifiers :
Identifiers for the main entities (Catalogue, Dataset, Data Service and Distribution) are managed URIs.
These URIs are dereferenceable, i.e. users are redirected to the metadata describing the entity.
URIs are well defined, i.e. follow the 10 principles for good URIs.
Data portals and harvesters implement the identifier guidelines in order not to lose information of alternative identifiers.
When the metadata in DCAT-AP originates from other metadata (e.g. INSPIRE) then a cross-reference to that original metadata is included. This can be done by using the same identifiers, but also using another relation like the one expressed using dct:source.
RDF Examples
In this section we illustrate the healthDCAT-AP specifications with an example for the LINK-VACC dataset;
the sole purpose is to illustrate the metadata of the mains classes dataset [EXAMPLE 2] and distributions [EXAMPLES 3,4,5] .
,
Validation
To support the assessment if a metadata satisfies healthDCAT-AP, the following SHACL templates are provided.
base.ttl (to create): all base constraints expressed in this document.
ranges.ttl(to create): all the class range constraints expressed in this document.
The SHACL templates assume that all resources are subject to healthDCAT-AP.
It is future work to provide a conditional approach which would support catalogues mixing healthDCAT-AP compliant metadata and metadata records compliant to other application profiles but categorised as Health related.
Quick Reference of Classes and Properties
This section provides a condensed tabular overview of the mentioned classes and properties in this specification.
The properties are indicated as mandatory, recommended, optional and deprecated. These terms have the following meaning.
Mandatory property: a receiver MUST be able to process the information for that property; a sender MUST provide the information for that property.
Recommended property: a receiver MUST be able to process the information for that property; a sender SHOULD provide the information for that property if it is available.
Optional property: a receiver MUST be able to process the information for that property; a sender MAY provide the information for that property but is not obliged to do so.
Deprecated property: a receiver SHOULD be able to process information about instances of that property; a sender SHOULD NOT provide the information about instances of that property.
DCAT-AP 2.x vs 3.0 deprecated properties and classes
The following URIs used in DCAT-AP release 2.x for properties have been deprecated in DCAT-AP 3.0 [[vocab-dcat-3]] in favor for the URIs within the DCAT namespace.
dct:hasVersion is replaced by dcat:hasVersion.
dct:isVersionOf is replaced by dcat:isVersionOf.
owl:versionInfo is replaced by dcat:version.
To identify these deprecations, a SHACL shape is provided.
Acknowledgments
The author extends sincere gratitude to all members of the WP6 Technical Working Group [June 2023-December 2023] for their invaluable contributions to the design of the healthDCAT-AP. Special appreciation is directed towards Pavlina Fragkou, Makx Dekkers, and Bert Van Nuffelen from Interoperable Europe of the European Commission for their exceptional technical support. Additionally, heartfelt thanks go to Andrea Perego, whose vision inspired the EU Health Information System unit at Sciensano to embark on the HealthDCAT Application Profile project during its nascent stages.
