3.3. Metadata interoperabiliteit

3.3.1. Waarom metadata essentieel is voor datastations

Metadata speelt een cruciale rol in een datastation. Zonder goede metadata weten onderzoekers en systemen niet welke data beschikbaar is, wat de kwaliteit ervan is, en onder welke voorwaarden deze gebruikt mag worden. Metadata maakt het mogelijk om:

Datasets te vinden: Een onderzoeker kan in een catalogus zoeken naar datasets over hartfalen in een bepaalde leeftijdsgroep.
Datasets te begrijpen: De beschrijving vertelt welke variabelen er zijn, hoe de data is verzameld, en welke beperkingen er gelden.
Datasets automatisch te verwerken: Systemen kunnen op basis van gestandaardiseerde metadata beoordelen of een dataset geschikt is voor een bepaalde analyse.

Voor het realiseren van interoperabiliteit tussen datastations is het van groot belang dat metadata op een gestandaardiseerde manier wordt beschreven. Hiervoor zijn internationale standaarden en profielen ontwikkeld.

DCATDCAT-APHealthDCAT-APHealth-RI metadata schema

DCAT (Data Catalog Vocabulary) is een W3C-standaard die oorspronkelijk is ontworpen voor het beschrijven van datasets in datacatalogi. Het biedt een gemeenschappelijk vocabulaire waarmee organisaties hun datasets kunnen beschrijven, ongeacht het domein. DCAT versie 3 (2024) introduceert onder andere de DatasetSeries klasse voor het beschrijven van gerelateerde datasets.

DCAT-AP is een Europees applicatieprofiel van DCAT, ontwikkeld door de Europese Commissie. Het verfijnt DCAT met extra verplichte en aanbevolen velden die relevant zijn voor Europese overheidsdata, zoals toegangsrechten en toepasselijke wetgeving. DCAT-AP vormt de basis voor veel nationale datacatalogi.

HealthDCAT-AP is een uitbreiding van DCAT-AP specifiek voor de gezondheidszorgsector. Het voegt metadata-elementen toe die essentieel zijn voor gezondheidsdata, zoals:

Gezondheidscategorieën (EHR, beelden, genomische data)
Populatiekenmerken (leeftijdsbereik, aantal unieke individuen)
Coderingssystemen (SNOMED CT, ICD-10, LOINC)
Retentieperiodes en bewaartermijnen
De verantwoordelijke Health Data Access Body (HDAB)

Het Health-RI metadata schema is een Nederlands profiel gebaseerd op DCAT-AP en HealthDCAT-AP, met specifieke aanpassingen voor de Health-RI Datacatalogus. Dit schema definieert welke metadata-elementen verplicht, aanbevolen of optioneel zijn voor Nederlandse gezondheidsdata.

3.3.2. DCAT-klassen in een datastation

In DCAT worden verschillende klassen gebruikt om de structuur van een datacatalogus te beschrijven. Voor datastations zijn de volgende klassen het meest relevant.

De catalogus: dcat:Catalog

Een dcat:Catalog vertegenwoordigt het datastation zelf als een verzameling van datasets en dataservices. De catalogus fungeert als het toegangspunt voor gebruikers en systemen die willen weten welke data beschikbaar is. De catalogus beschrijft niet alleen welke datasets er zijn, maar ook via welke services deze toegankelijk zijn. De volgende eigenschappen zijn essentieel voor een catalogus:

Eigenschap	Beschrijving	Voorbeeld
`dct:title`	Naam van de catalogus	"Data Catalogus Ziekenhuis X"
`dct:description`	Beschrijving van de inhoud	"Catalogus met klinische datasets voor onderzoek"
`dct:publisher`	Organisatie die de catalogus publiceert	Ziekenhuis X
`dcat:dataset`	Verwijzingen naar datasets	Links naar beschikbare datasets
`dcat:service`	Verwijzingen naar dataservices	Links naar API-endpoints

In de praktijk kan één organisatie meerdere catalogi hebben. Bijvoorbeeld een ziekenhuis kan een catalogus hebben voor beeldvormende data (MRI, CT, PET) en een aparte catalogus voor klinische data uit het EPD.

De dataset: dcat:Dataset

Een dcat:Dataset vertegenwoordigt een logische verzameling van gegevens die als eenheid wordt beschreven en beschikbaar gesteld. De granulariteit van een dataset is niet technisch voorgeschreven, maar wordt bepaald door de organisatie van de dataleverancier en de manier waarop onderzoekers de data willen kunnen vinden en aanvragen. Datasets kunnen bijvoorbeeld worden georganiseerd:

Per ziektebeeld: "COVID-19 opnamegegevens 2020-2024"
Per domein: "Cardiologie patiëntgegevens"
Per onderzoeksproject: "IMPROVE-studie diabetes cohort"

Voor datasets in de gezondheidszorg zijn de volgende metadata-elementen in het bijzonder relevant:

Categorie	HealthDCAT-AP elementen	Doel
Populatie	`numberOfUniqueIndividuals`, `numberOfRecords`, `populationCoverage`, `minTypicalAge`, `maxTypicalAge`	Inzicht in omvang en samenstelling
Terminologie	`hasCodingSystem`	Welke coderingssystemen worden gebruikt (SNOMED, ICD-10, LOINC)
Juridisch	`accessRights`, `applicableLegislation`	Toegangsvoorwaarden en wetgeving (EHDS, AVG)
Kwaliteit	`hasQualityAnnotation`	Verwijzing naar kwaliteitsrapportage
Privacy	`retentionPeriod`, `hdab`	Bewaartermijn en verantwoordelijke instantie

De dataset serie: dcat:DatasetSeries

De klasse dcat:DatasetSeries is bedoeld voor het beschrijven van verzamelingen van gerelateerde datasets die afzonderlijk worden gepubliceerd maar logisch samenhangen. Dit is bijzonder geschikt voor:

Periodieke cohorten: Jaarlijks gepubliceerde extracties van dezelfde patiëntpopulatie
Versies van onderzoeksdatasets: Opeenvolgende versies van een cohort na correcties of uitbreidingen
Longitudinale data: Meetmomenten in een follow-up studie

De serie definieert gemeenschappelijke metadata (zoals toegangsrechten en coderingssystemen), terwijl individuele datasets hun specifieke kenmerken behouden (zoals het aantal records en de temporele dekking).

De distributie: dcat:Distribution

Een dcat:Distribution beschrijft een concrete realisatie van een dataset: hoe de data daadwerkelijk kan worden verkregen of benaderd. Eén dataset kan meerdere distributies hebben:

Type distributie	Beschrijving	Typisch gebruik
Bulk export	Eenmalige download van de volledige dataset	Onderzoek in een centrale BVO
API-toegang	Programmatische toegang via een service	Federatieve analyse
Synthetische sample	Representatieve testdata	Ontwikkeling en validatie van algoritmes
View/subset	Voorgedefinieerde selectie	Specifiek onderzoeksdoel

De distributie specificeert technische details zoals het bestandsformaat (dcat:mediaType), de toegangs-URL (dcat:accessURL), en eventueel een verwijzing naar de onderliggende dataservice.

De dataservice: dcat:DataService

Een dcat:DataService beschrijft een operationele service die toegang biedt tot datasets. Waar een distributie een statische momentopname of downloadbaar bestand vertegenwoordigt, biedt een dataservice dynamische toegang tot de onderliggende data. De service kan realtime queries uitvoeren, actuele data opvragen, of zelfs berekeningen uitvoeren zonder dat de data het datastation verlaat. Verschillende typen dataservices zijn mogelijk, bijvoorbeeld:

Type dataservice	Voorbeeld	Beschrijving
FHIR API	`https://fhir.example.org/`	REST API volgens HL7 FHIR standaard
OMOP query service	SQL-interface voor OMOP-CDM	Gestandaardiseerde queries op OMOP-database
DICOM WADO-RS	Web access voor medische beelden	Ophalen van beelden via web protocol
Federatief endpoint	KIK-V of PLUGIN-node	Ontvangst en uitvoering van algoritmes

Voor automatische verwerking door systemen is het essentieel dat de dataservice duidelijk maakt hoe deze benaderd kan worden. Dit wordt gedaan via:

dcat:endpointURL: Het basisadres van de service
dcat:endpointDescription: Link naar de technische documentatie (bijv. OpenAPI specificatie of FHIR CapabilityStatement)
dct:conformsTo: De standaard waaraan de service voldoet

3.3.3. Statische versus dynamische databronnen

Een belangrijk onderscheid bij het modelleren van databronnen is het verschil tussen statische en dynamische databronnen. Dit onderscheid heeft directe gevolgen voor hoe metadata wordt beheerd en hoe versiebeheer wordt toegepast.

Statische databronnen: cohorten en extracties

Statische databronnen zijn datasets die op een bepaald moment zijn gedefinieerd en geëxtraheerd. De data verandert na extractie niet meer, wat zorgt voor reproduceerbaarheid van onderzoeksresultaten. Dit type databron is gebruikelijk bij onderzoeksprojecten waar een vaste populatie en observatieperiode worden gedefinieerd. Typische voorbeelden van statische databronnen zijn:

Onderzoekscohorten: Een vooraf gedefinieerde groep patiënten voor een specifieke studie
Periodieke snapshots: Jaarlijkse of kwartaal-extracties van een bronsysteem
Geanonimiseerde datasets: Eenmalig gegenereerde datasets voor open onderzoek

Voor statische databronnen is expliciet versiebeheer essentieel:

Eigenschap	Gebruik	Voorbeeld
`dcat:version`	Versienummer van de dataset	"2024.1"
`dct:issued`	Datum van publicatie	"2024-03-15"
`dct:modified`	Datum van laatste wijziging	"2024-03-20"
`dcat:inSeries`	Koppeling aan een serie	Link naar de overkoepelende DatasetSeries
`dcat:prev`	Verwijzing naar vorige versie	Link naar vorige dataset

De DatasetSeries klasse is bijzonder nuttig voor statische databronnen wanneer:

Er periodiek nieuwe versies van dezelfde soort data worden gepubliceerd
Onderzoekers de mogelijkheid moeten hebben om specifieke versies te selecteren
Er gemeenschappelijke metadata is die op serie-niveau kan worden gedefinieerd

Dynamische databronnen: actieve databases

Dynamische databronnen zijn databases die continu worden bijgewerkt, zoals EPD-systemen, OMOP-CDM databases of XNAT-omgevingen. Het is hier niet zinvol om bij elke data-wijziging een nieuwe versie aan te maken.

Voor dynamische databronnen adviseren we de volgende aanpak:

Aspect	Aanbeveling
De database als geheel	Beschrijf als `dcat:Dataset` met `dcat:accrualPeriodicity` om de update-frequentie aan te geven
Versiebeheer	Gebruik `dcat:version` alleen voor structurele wijzigingen (bijv. upgrade van OMOP CDM v5.3 naar v5.4)
Temporele dekking	Gebruik `dct:temporal` met alleen een startdatum (geen einddatum) om aan te geven dat de data actief groeit
Statistieken	Update periodiek de populatiestatistieken (`numberOfRecords`, `numberOfUniqueIndividuals`) met bijbehorende `dct:modified`
Schema-documentatie	Beschrijf via `dcat:Distribution` met verwijzing naar schema-documentatie

Praktijkvoorbeeld: versioning strategie

Een ziekenhuis heeft een OMOP-CDM database die dagelijks wordt bijgewerkt met nieuwe patiëntgegevens. De metadata wordt als volgt beheerd:

Schema-versie: dcat:version = "OMOP CDM v5.4" – wijzigt alleen bij upgrade van het datamodel
Update-frequentie: dcat:accrualPeriodicity = DAILY – geeft aan dat data dagelijks wordt toegevoegd
Statistieken: numberOfRecords en numberOfUniqueIndividuals worden maandelijks bijgewerkt, met dct:modified op de bijgewerkte datum
Temporele dekking: dct:temporal met startdatum 2018-01-01 en geen einddatum

3.3.4. Metadata voor primair versus secundair gebruik

Bij het beschrijven van metadata is het belangrijk om onderscheid te maken tussen primair en secundair gebruik van gegevens. Dit onderscheid beïnvloedt welke metadata-elementen de nadruk krijgen.

Primair gebruik: focus op de service

Voor primair gebruik (directe zorgverlening) blijven bronsystemen leidend. In DCAT wordt vooral beschreven wat er beschikbaar is en hoe het kan worden geraadpleegd. Omdat niet voor elke individuele patiënt een dataset wordt aangemaakt, ligt de nadruk op het beschrijven van het bronsysteem en de bijbehorende dataservice.

De dcat:DataService speelt hier een centrale rol. Het is van belang dat de service goed wordt beschreven, zodat een vragend systeem (bijvoorbeeld een ander EPD of een zorgapplicatie) de data correct kan opvragen en gebruiken.

Secundair gebruik: focus op inhoud en context

Voor secundair gebruik (onderzoek, beleid, innovatie) verschuift de nadruk naar de inhoud en kwaliteit van de data, evenals de context waarin de gegevens zijn verzameld. HealthDCAT-AP maakt expliciete modellering van deze aspecten mogelijk:

Aspect	HealthDCAT-AP elementen
Toegangsrechten	`NON_PUBLIC`, `RESTRICTED`, `PUBLIC`
Wetgeving	Verwijzingen naar EHDS, AVG, nationale wetten
Doelbinding	`dpv:hasPurpose` (bijv. academisch onderzoek, volksgezondheid)
Rechtmatige grondslag	`dpv:hasLegalBasis` (bijv. publiek belang, toestemming)
Kwaliteit	Verwijzing naar kwaliteitsrapportages via `dqv:hasQualityAnnotation`
HDAB	`healthdcatap:hdab` – de verantwoordelijke Health Data Access Body

Endpoint descriptions voor automatische verwerking

Wanneer een catalogus browser of federatieve query-engine automatisch de mogelijkheden van een dataservice wil bepalen, moet bekend zijn welk type specificatie de dcat:endpointDescription bevat. Een FHIR CapabilityStatement heeft bijvoorbeeld een andere structuur dan een OpenAPI specificatie, en systemen moeten weten hoe ze deze moeten interpreteren. Door het type specificatie expliciet te maken met dct:conformsTo, kan een systeem de juiste keuze maken en de beschikbare mogelijkheden ontdekken.

Combineren van endpointDescription met conformsTo

Combineer dcat:endpointDescription altijd met dct:conformsTo om het type specificatie expliciet te maken:

<https://example.org/service/fhir-api> a dcat:DataService ;
    dcat:endpointURL <https://fhir.example.org/> ;
    dcat:endpointDescription <https://fhir.example.org/metadata> ;
    # Expliciet aangeven dat het een FHIR CapabilityStatement betreft
    dct:conformsTo <http://hl7.org/fhir/StructureDefinition/CapabilityStatement> .

<https://example.org/service/rest-api> a dcat:DataService ;
    dcat:endpointURL <https://api.example.org/> ;
    dcat:endpointDescription <https://api.example.org/openapi.json> ;
    # Expliciet aangeven dat het een OpenAPI specificatie betreft
    dct:conformsTo <https://spec.openapis.org/oas/v3.1.0> .

3.3.5. Voorbeelden van metadata voor een datastation

De volgende voorbeelden illustreren hoe verschillende typen databronnen in een datastation kunnen worden beschreven met DCAT en HealthDCAT-AP. Elk voorbeeld demonstreert specifieke aspecten van de standaard.

Voorbeeld 1: FHIR-systeem (dynamische databron)

Een FHIR-systeem in een ziekenhuis kan op verschillende manieren worden ontsloten. In dit voorbeeld wordt een COVID-19 dataset beschreven die dynamisch groeit naarmate er nieuwe opnames worden geregistreerd.