1. Introduction
The increasing digitalisation of healthcare has led to the generation of vast amounts of health-related data from multiple sources, including clinical records, wearable devices, and patient-generated data. However, the fragmentation and complexity of these data sources poses significant challenges in achieving interoperability and data integration across healthcare systems. Addressing these challenges is crucial to ensuring that health data can be effectively shared and utilized while maintaining its accuracy and accessibility across different platforms and stakeholders. Beyond interoperability, the reusability of health data plays a pivotal role in advancing public health initiatives, healthcare delivery, and health-related research and development.
In this context, ensuring that health data can be repurposed for 'altruistic' activities, such as for improving healthcare or performing scientific research for the general interest, as specified in the EU’s Data Governance Act [DGA] and further specified in the newly-enforceable European Health Data Space Regulation [EHDS], e.g., for the improvement and optimisation of personalised treatment delivery or for purposes of development of health-related products or services or training new algorithms for medical devices, is of the utmost importance and requires robust mechanisms for data governance and regulatory compliance. Moreover, both of the previously mentioned regulations build their health data processing requirements over the EU’s General Data Protection Regulation [GDPR], which sets the regulatory framework for the processing of personal data related to EU citizens, and categorises health data as a special category of personal data and places additional constraints to its processing. Thus, compliance with these frameworks is essential to fostering trust among stakeholders, including patients, healthcare providers, researchers, and policymakers.
Given these considerations, it is imperative to develop a common framework to facilitate the interoperable and legally compliant exchange of health data. For designing such a framework, data exchange conditions must be expressed and shared amongst involved parties via interoperable, machine-readable policies that are expressive enough to address technical and legal frameworks. In this context, the usage of semantic standards, such as the Open Digital Rights Language (ODRL) [ODRL-model] [odrl-vocab] or the Data Privacy Vocabulary [DPV], are well-suited solutions for policy expression and data protection requirement modelling, that enable a shared understanding for interpreting and enforcing health data sharing conditions. As such, this document proposes a framework for modelling such conditions, aligned with legal requirements from the EU’s GDPR and EHDS regulation, which utilises ODRL and DPV to model requirements for health data sharing. The following requirements were identified to develop the framework:
-
R1. Ability to model policies for both data subjects/holders and data controllers/users
-
R2. Support legal requirements for health data exchange
-
R3. Define the necessity, e.g., mandatory or optional, of these requirements according to the identified legal framework
-
R4. Specify 'pre-defined' templates for common exchanges, e.g., patient-doctor, citizen-research organisation
-
R5. Generate agreements for specific health-related data exchanges between 2 parties
2. Used standards/specifications
The following standards and specifications are being used to develop HEDGE. In the Namespaces section, there are links to each solution.
-
ODRL: W3C standard for policy expression [ODRL-model] [odrl-vocab]
-
DPV-ODRL mapping: ODRL profile for using DPV’s terms in ODRL policies
-
-
DPV: W3C specification, developed by the W3C DPVCG, for the expression of data protection-related terms [DPV]
-
EU-GDPR: DPV extension for the expression of concepts related to the EU’s General Data Protection Regulation
-
EU-EHDS: DPV extension for the expression of concepts related to the EU’s European Health Data Spaces
-
SECTOR-HEALTH: DPV extension for the expression of concepts related to the healthcare sector
-
PD: DPV extension for the expression of concepts related to personal data categories, including health data categories
-
The usage of provenance-related vocabularies, such as DCTerms, PROV, should also be explored. Furthermore, DCAT, and its specialization HealthDCAT-AP, will be explored to formalise policy catalogs.
2.1. Namespaces
Commonly used namespace prefixes used in this specification:
@prefix dcat: <hhttp://www.w3.org/ns/dcat#> . @prefix dcterms: <http://purl.org/dc/terms/> . @prefix dpv: <https://w3id.org/dpv#> . @prefix dpv-odrl: <https://w3id.org/dpv/mappings/odrl#> . @prefix eu-ehds: <https://w3id.org/dpv/legal/eu/ehds#> . @prefix eu-gdpr: <https://w3id.org/dpv/legal/eu/gdpr#> . @prefix odrl: <http://www.w3.org/ns/odrl/2/> . @prefix ex: <https://example.com/> . @prefix pd: <https://w3id.org/dpv/pd#> . @prefix report: <https://w3id.org/force/compliance-report#> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix sector-health: <https://w3id.org/dpv/sector/health#> . @prefix skos: <http://www.w3.org/2004/02/skos/core#> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
3. Policy requirements
3.1. Subject/Holder policies
The minimal set of terms to define data subject or holder policies, identified in Table 1, is still work-in-progress.
| Term | Concept | Relation / Constraint | Necessity |
|---|---|---|---|
| Data subject | URI | odrl:assigner | Mandatory |
| Personal data | URI / subclass of dpv:PersonalData | odrl:target | Mandatory |
| Processing operation | subclass of odrl:Action or dpv:Processing | odrl:action | Mandatory |
| Purpose | subclass of dpv:Purpose | dpv-odrl:Purpose | Mandatory |
| Pseudo/Anonymisation | dpv-odrl:Pseudonymise, dpv-odrl:Anonymise | odrl:action | Optional |
| Recipient | URI / subclass of dpv:Organisation | dpv-odrl:Recipient | Optional |
| Duration | xsd:duration | dpv-odrl:Duration | Optional |
| Frequency | xsd:positiveInteger | dpv-odrl:Frequency | Optional |
| Data source | URI / subclass of dpv:Entity | dpv-odrl:DataSource | Optional
|
DPV’s organisation taxonomy already has some concepts for this, are they enough?
We should be able to allow both or just one of them
In the absence of this information, should we assume by default only retrospective data or retrospective+prospective data?
3.2. Requests
The minimal set of terms to define requests, identified in Table 2, and respective mapping into legal requirements, e.g., from the GDPR and EHDS, is still work-in-progress.
| Term | Concept | Relation / Constraint | Necessity | Legal requirements |
|---|---|---|---|---|
| Data controller | URI | odrl:assignee | Mandatory | GDPR |
| Data subject (type) | URI / subclass of dpv:HumanSubject | odrl:assigner | Mandatory | GDPR |
| Personal data | subclass of dpv:PersonalData | odrl:target | Mandatory | GDPR |
| Personal electronic health data | subclass of pd:MedicalHealth | odrl:target | Mandatory | EHDS |
| Non-personal electronic health data | *** | odrl:target | Mandatory | EHDS |
| Processing operation | subclass of odrl:Action or dpv:Processing | odrl:action | Mandatory | GDPR |
| Purpose | subclass of dpv:Purpose | dpv-odrl:Purpose | Mandatory | GDPR |
| Primary/Secondary use | *** | *** | Mandatory | EHDS |
| Legal basis | subclass of dpv:LegalBasis | dpv-odrl:LegalBasis | Mandatory | GDPR |
| Pseudo/Anonymisation | dpv-odrl:Pseudonymise, dpv-odrl:Anonymise | odrl:action | Optional | GDPR |
| Recipient | URI / subclass of dpv:Organisation | dpv-odrl:Recipient | Mandatory | GDPR |
| Data source | subclass of dpv:DataSource | dpv-odrl:DataSource | Mandatory | GDPR |
| Duration | xsd:duration | dpv-odrl:Duration | Mandatory | GDPR |
| Frequency | xsd:positiveInteger | dpv-odrl:Frequency | Optional | GDPR |
| Events/Activities | *** | odrl:event | Mandatory | GDPR
|
EHDS "lays down common rules and mechanisms for primary use of electronic health data and secondary use of electronic health data", and "'electronic health data’'means personal or non-personal electronic health data".
Use case for complex right operands? (Where more than one value is needed to assess the left/right operand relation)
In case there’s joint-controllership and/or data processors involved in the processing, then policies must be specified for that as well including each parties responsibilities.
We can use odrl:event or look into how to use DPV’s justifications to do it.
Though, at this moment, DPV’s justifications don’t have any concepts for this.
See https://w3c.github.io/dpv/2.1/dpv/modules/legal_basis.html#desc-vital-interest
4. Agreement Instantiation
ODRL policy instantiation specification being developed at https://w3id.org/force/policy-instantiation.
ODRL policy instantiation implementation being developed at https://w3id.org/force/policy-instantiation/poc.
The final agreement instantiation, that results from the matching of a concrete request with the set of policies that determine the access/usage of a certain target resource, should include the following terms:
-
Validate the proper modelling of the
odrl:Policy,odrl:Requestand SoTW information -
Convert compact policies into their atomic equivalents
-
Remove the rules that are not relevant for the request
-
Reference the ODRL request that triggered the agreement instantiation and the policies from the data subject/holder
-
The policies associated with the data subject/holder data exchange conditions should only be directly accessible by the data subject/holder to mitigate privacy concerns, e.g., to avoid requesters targeting concrete 'personal data-purpose' exchange scenarios
-
Data subjects/holders should be able to set these policies as public if that is their wish
-
-
Instantiate the concrete assigner and assignee of the agreement
-
Include relevant rules with concrete actions, targets and constraints
4.1. Examples
5. Using different legal grounds
Which GDPR legal grounds make sense for the sharing of health data? Consent, vital interest, more?
How do we justify that something is of vital interest to use vital interest as the legal ground
6. Health data sharing policy catalogs
6.1. Alignment with HealthDCAT-AP
See https://github.com/w3c/dpv/issues/201
HealthDCAT-AP draft spec available at https://healthdcat-ap.github.io