Health-RI wiki v4.0 -> consultatie (open tot 03-12-2024)

Metadata rondom gebruiksvoorwaarden, authenticatie / autorisatie en ELSI aspecten

Owned by Health-RI
Nov 18, 2024
6 min read

datum: 14-11-2024 Status: TER REVIEW

GBFlag48x34.png

 

Dit artikel beschrijft een voorstel voor ‘ELSI metadata’ waarmee bedoeld wordt: metadata over de voorwaarden en restricties die gelden bij hergebruik van data, ELSI elementen die belangrijk zijn in een data-aanvraag en ELSI elementen die belangrijk zijn bij goedkeuring van een aanvraag met een focus op authenticatie en autorisatie.

Metadata voor autorisatie en ELSI-aspecten zijn van belang in verschillende delen van de Health-RI infrastructuur. Hierbij hebben we gekeken naar de volgende user stories:

  1. Datasets vinden

  2. Datasets aanvragen

  3. Datasets analyseren

  4. Datasets publiceren in de catalogus

Het is belangrijk om hierbij wettelijke verplichtingen zowel op nationaal niveau als op Europees niveau mee te nemen. Er is voornamelijk gekeken naar de volgende wet-, en regelgeving: AVG, WMO, EHDS en de Gedragscode gezondheidsonderzoek. Daarnaast is gekeken naar de NFU template MTA/DTA en consentformulieren van verschillende ziekenhuizen.

We stellen de volgende metadata-elementen voor en geven hierbij waar mogelijk alvast een suggestie voor de geschikte ontologie systemen. 

Catalogus

Het is van belang om in de catalogus aan te geven wat de voorwaarden voor gebruik zijn zodat een gebruiker in een vroeg stadium kan beoordelen of een aanvraag van deze dataset kansrijk is. Daarnaast is het voor het proces van belang om informatie te hebben over wie kan beslissen over een aanvraag.

Voorwaarden voor gebruik zijn gebaseerd op wet en regelgeving (UAVG, Data Governance Act, Wet hergebruik overheidsinformatie, databankenwet, AVG, EHDS, Data Act,  etc.) en voorwaarden die gesteld worden op basis van controle van intellectueel eigendom (bijv. copyright en databankrechten) en de rechten van de burger (consent (opt-in) en/of bezwaar (opt-out)). Veel van deze elementen (vetgedrukt) worden in HealthDCAT-AP al vastgelegd en hiervoor hebben we maar beperkte ruimte om een eigen invulling te geven.

Metadata-element

Uitleg

Aanbevolen codering

Voorbeelden/ opmerkingen

dct:Publisher

Publisher

Wie is de aanbieder van de data?

foaf:Agent

Het ziekenhuis, dit zal meestal ook de data controller zijn.

dpv:hasLegalBasis

Grondslag

De categorie grondslag op basis waarvan de data verzameld is (zoals in de AVG art 6.1 a t/m f).

dpv:LegalBasis

 

Bijvoorbeeld consent (bijv. bij wetenschappelijk onderzoek) of wettelijke verplichting (bijv. bij de kwaliteitsregisters).

dcatap:applicableLegislation

dpv:hasApplicableLaw

Wettelijke basis

Als de grondslag (zie boven) een wettelijke verplichting is kan hiermee aangegeven worden op basis van welke wetgeving.

Persistent URL voor de wet

Alternatief is dpv:hasApplicableLaw maar dcatap:applicableLegislation is onderdeel van HealthDCAT-AP.

dpv:hasJurisdiction

Jurisdictie

Jurisdictie waaronder de dataset valt.

dpv:Location

Binnen Nederland zal dit waarschijnlijk NL en EU zijn.

dpv:hasPersonalData

Bevat persoonsgegevens 

Data categorieën (die eventueel gelinkt kunnen worden naar een persoon) die deze dataset bevat.

dpv:PersonalData

Location, SexualOrientation, MedicalHistory

dct:accessRights

Access Rights

Indicatie of een dataset open is of niet. Indien een dataset niet openbaar toegankelijk is, kunnen de onderstaande velden gebruikt worden om de voorwaarden of restricties verder te specificeren.

dct:RightsStatement

 

 

Restricted of sensitive (in geval van identificerende data). In dat geval onderstaande velden gebruiken voor specificering van voorwaarden/restricties.

Public (in geval van anonieme data).

In HealthDCAT-AP beperkt tot de opties uit de EU-Voc access rights vocabulary.

 

Voorwaarden voor gebruik

De belangrijkste voorwaarden gecodeerd in een machine leesbaar formaat. Bruikbaar om te filteren of om op basis hiervan aanvullende vragen te stellen in tijdens de aanvraag.

Bijvoorbeeld of er kosten gerekend worden.

DUO, DUC/CCE of ODRL

 

DUO of DUC/CCE kunnen ook als ‘syntactic sugar’ dienen en onder water naar ODRL geconverteerd worden, predicate moet nog gedefinieerd worden.

Link naar voorwaarden document

Denk hierbij aan MTA, Consent formulieren.

Persistent URL

Predicate moet nog gedefinieerd worden. Eventueel foaf:Page gebruiken?

Bevat intellectueel eigendom

Bevat de dataset intellectueel eigendom dat bescherming behoeft?

 

Boolean

 

Dit zal bijna altijd nee zijn, maar wordt in de EHDS gedefinieerd, omdat er maatregelen genomen mogen worden om intellectueel eigendom te beschermen. Dit kan later van belang zijn in het aanvraagproces. Predicate moet nog gedefinieerd worden.

healthdcatap:hdab

Health Data Access Body 

Health Data Access Body die goedkeuring kan geven voor secundair gebruik onder de voorwaarden van de EHDS.

foaf:Agent

 

Dit veld wordt pas geïmplementeerd zodra HDAB er is. Tot die tijd is data controller de contactpersoon omtrent toetsing.

Koppelsleutels

Koppelsleutels die beschikbaar zijn om eventueel te linken met andere datasets.

 

Deze kunnen beschikbaar zijn naast de dataset en niet uitgeleverd worden.

Bijv. directe of indirecte identifiers, zoals NAW-gegevens. Predicate en range voor object moeten nog gedefinieerd worden.

Aanvraagprocedure

Voor de aanvraagprocedure hebben we geprobeerd om een logische workflow te definiëren waarin zaken gevraagd worden (hier niet gepubliceerd omdat dit ondertussen verouderd is). Op basis van die voorlopige workflow is gekeken naar mogelijke metadata elementen.

Metadata-element

Uitleg

Aanbevolen codering

Doelbinding

Doel waarvoor de data aangevraagd wordt.

 

DPV.

Categorieën uit EHDS 34, AVG 5.1 en daarnaast vrije tekst voor doelen daarbuiten.

Op basis van de doelbinding kan getoetst worden of EHDS mogelijk van toepassing is.

Doel/onderzoeksvraag

Beschrijving van het doel/onderzoeksvraag waarvoor de data wordt gevraagd.

Tekst of een document

Aanvrager

Gegevens van de persoon (zie metadata beschrijving hieronder).

 

Aanvraag uit functie of als individu

Relevant om te weten wie tekenbevoegd is.

Boolean waarde

Organisatie

Indien de aanvraag uit hoofde van de rol van de aanvrager binnen een organisatie is.

ROR identifier, foaf:Agent

Functie

Functie van de persoon binnen de organisatie (zie metadata beschrijving hieronder).

 

Persoonsgegevens contactpersoon voor controle bevoegdheid van de aanvrager

Gegevens van de persoon (zie metadata beschrijving hieronder).

 

Hoofdonderzoeker (Principal Investigator)

Gegevens van de persoon (zie metadata beschrijving hieronder).

 

dpv:hasImpactAssessment

DPIA

Data Privacy Impact Analyse, alleen noodzakelijk indien de aangevraagde dataset persoonsgegevens bevat in de zin van de AVG bevat (gevraagd in EHDS).

dpv:PIA

Data Management plan

Data management plan (gevraagd in EHDS).

 

Gewenste formaat

Vanuit de EHDS gevraagd.

 

Specificatie

Vanuit de EHDS gevraagd. Belangrijkste aantal personen / distributie. Variabelen.

 

Financiële gegevens

Indien er kosten worden berekend (te specificeren in de catalogus onder use conditions) vragen.

 

Authenticatie en autorisatie metadata

Het is van belang om eenduidig vast te stellen wie een aanvraag doet en toegang heeft tot data. Voor het vaststellen van de identiteit zijn verschillende mogelijkheden. Wat van toepassing is hangt samen met de mate van zekerheid die vereist is en is een afweging die gemaakt moet worden door Health-RI en de betrokken datahouders. In de onderstaande tabel staan een aantal metadata-velden gedefinieerd die bruikbaar zijn om hier controle over te houden. Deze lijst is nadrukkelijk geen datamodel. Bij het modelleren dient men er rekening mee te houden dat mensen verschillende rollen in verschillende aanvragen kunnen hebben en zich mogelijk op verschillende manieren authentiseren afhankelijk van de rol.

Authenticate metadata

Metadata-element

Uitleg

Aanbevolen codering

Volledige naam

Volledige naam van de persoon in de gebruikelijk schrijfwijze.

N.B. Namen zijn niet uniek en kunnen over de tijd veranderen.

 

Identifier

Unique identifier van de persoon binnen het systeem.

 

Rol

Rol van de persoon binnen het proces, bijvoorbeeld Aanvrager, PI, Data Manager, Privacy officer.

EHDS vereist dat de mensen met toegang tot de data vermeld worden in de aanvraag en data permit.

DPV mogelijk uitbreidingen nodig

E-mailadres

Contact e-mail adres van de persoon. Dit moet een persoonsgebonden adres zijn, geen groepsadres.

FOAF of vCard, DCAT gebruikt beide op verschillende plaatsen

Telefoonnummer

Contact telefoonnummer, bij voorkeur een rechtstreeks nummer.

 

Authenticatie methode

Manier waarop de persoon is ingelogd voor deze sessie (bijv. username/password, gefedereerde login).

 

Tijdstip van inloggen

Het moment van inloggen.

ISO 8601

Methode van vaststellen van de identiteit

Methode waarmee de identiteit is vastgesteld, bijv. via online methodes zoals federated login, of offline methodes als controle van paspoort.

Hiervoor moet een codelijst vastgesteld worden.

Autorisatie/data permit

Indien een persoon geautoriseerd is om de gevraagde data te gebruiken kan dit vastgelegd worden in een data permit (EHDS). De EHDS beschrijft in artikel 46.6 wat hierin vastgelegd moet worden. Het voorstel is om deze structuur mutatis mutandis altijd te gebruiken.

Metadata-element

Uitleg

Aanbevolen codering

Categorieën

 

Vanuit de EHDS is een lijst van categorieën gezondheidsdata vastgelegd.

 

Specificatie

Specificatie van de data. Selectiecriteria, variabelen en aantal datapunten. Eventueel ook distributie.

 

Formaat

Formaat waarin de data beschikbaar gesteld is.

 

Gepseudonimiseerde data?

Betreft het identificerende data of gepseudonimiseerde of geanonimiseerde data?

Antoinette Vlieger stelde voor om uit te gaan van vier categorieën:

  1. Niet identificerend

  2. Waarschijnlijk niet identificerend

  3. Waarschijnlijk wel identificerend

  4. Zeker wel identificerend

Dit gaat dan om de context waarin de data gebruikt wordt. Data kan in de context van een ziekenhuis identificerend zijn, maar in de context van onderzoek niet identificerend zijn omdat de koppelsleutel daar niet bekend is.

Beschrijving van het doel

Beschrijving van het doel  waarvoor de data is aangevraagd, kan overgenomen worden uit de aanvraag zelf.

 

Geautoriseerde personen

EHDS vraagt een lijst van alle geautoriseerde personen die toegang hebben tot de secure processing environment, maar de PI is al een goed begin.

 

Tijdsduur dat de data permit geldig is

 

ISO begin / end datum of tijdsduur vanaf akkoord

Informatie over de in de Secure Processing Environment beschikbare tools en hun karakteristieken

EHDS vraagt om details van de omgeving, maar in eerste instantie lijkt het ons voldoende om aan te geven welke SPE gebruikt wordt. Eventueel verwijzen naar een beschrijving van de SPE elders. Alleen als er voor de gebruiker extra tools geïnstalleerd worden dit expliciet opnemen.

 

Kosten

 

 

Aanvullende voorwaarden

Afgesproken voorwaarden, bijvoorbeeld uit een MTA/DTA of DAA.

 

Link naar MTA/DTA/DAA

Link naar de documenten.

 

Datum van akkoord

Datum waarop de permit geaccordeerd is door alle partijen.

 

Resources