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


Gezamenlijk gezondheidsdata architectuurmodel

datum: 23-08-2024 Status: VASTGESTELD

Vanuit het narratief “Elk relevant gezondheidsdatapunt en de daarbij behorende context zijn voor iedere bevoegde binnen gestelde gebruiksvoorwaarden beschikbaar”, is in de periode zomer 2022 tot maart 2023 samen met vooraanstaande partijen in de zorg, waaronder VWS, ZN, VZVZ, Nictiz, IHE, NFU/ AcZie en Twiin, gewerkt aan het gezamenlijk gezondheidsdata architectuurmodel.

Dit hoofdstuk beschrijft het gezamenlijk gezondheidsdata architectuurmodel. Dit is een algemeen architectuurmodel waarop de architectuur van het Health-RI ecosysteem is gebaseerd.

1. Primair en secundair gebruik van zorgdata en andere gezondheidsdata

Vooraanstaande partijen in de zorg, waaronder VWS, ZN, VZVZ, Nictiz, IHE, NFU/ AcZie, Twiin en Health-RI streven naar een eenduidige nationale gezondheidsdata ecosysteem voor gebruik in zowel de zorg zelf als daarbuiten.  

  • Real World Care Data uit de zorg (primair) t.b.v. zorg (primair) 

  • Real World Care Data uit de zorg (primair) t.b.v. andersoortig gebruik zoals onderzoek (secundair) 

  • Andere gezondheidsdata, zoals onderzoeksdata (secundair) t.b.v.  andersoortig gebruik zoals onderzoek (secundair) 

  • Andere gezondheidsdata, zoals onderzoeksdata (secundair) t.b.v.  zorg (primair) 

image-20240404-081531.png
Datastromen gezamenlijk gezondheidsdata architectuurmodel

2. Modulair ontwerp

Het gezamenlijk gezondheidsdata architectuurmodel bestaat uit 3 onderdelen 

  1. Module Meervoudig gebruik: Onderdeel waarin data geschikt gemaakt wordt voor meervoudig gebruik 

  2. Module Toepassen: Onderdeel met de verschillende toepassingsgebieden 

  3. Module Generieke Functies: Onderdeel met generieke functies op het gebied van vertrouwen, vindbaarheid en beheer

3. Module Meervoudig gebruik: onderdeel waarin data geschikt gemaakt wordt voor meervoudig gebruik 

De nummers in de tekst refereren naar de nummers in de afbeeldingen.

Het betreft hier zowel Real World Healthcare Data bronnen (4), zoals bv. Elektronische Patiënten Dossiers (EPDs), als andere gezondheid databronnen, zoals onderzoek databronnen, of Electronic Data Capturing tools (EDCs) (5). Deze willen we data-centrisch benaderen, waarbij we de data scheiden van de functionaliteit in een persistent dataplatform (7). Hierdoor:

  • Kan de levensloop cyclus van de burger ondersteund worden 

  • Kan data gecodeerd, gemodelleerd en FAIR gemaakt worden in een omgeving die bedoeld is om data te ‘kneden’ 

  • Wordt de afhankelijkheid van de roadmap van de verschillende softwareleveranciers verkleind 

  • Kan een integraal beeld van de patiënt /burger gevormd worden (netwerkzorg)

3.1 Databevrijdingscommunities

Door samenwerkingsverbanden, bij voorkeur inclusief de softwareleverancier zelf, worden koppelvlakken met de verschillende systemen (6) ontwikkeld om dataveranderingen in de originele databronnen in het persistent dataplatform (7) te krijgen. Erasmus MC, LUMC en UMCU zijn een voorbeeld van zo’n samenwerkingsverband (CumuluZ), waar near-real time het HiX EPD ontsloten wordt in een persistent dataplatform. Door dit soort oplossingen en samenwerkingsverbanden te stimuleren, voorkomen we dat het wiel op verschillende plaatsen uitgevonden wordt en kunnen we het proces versnellen. In eerste instantie zal dit vooral resulteren in kennisdeling, maar er wordt ook gewerkt aan een gemeenschappelijke roadmap en hergebruik waar mogelijk.

3.2 Gestandaardiseerde opslag en interfaces

De data in het persistente dataplatform (7) zal middels de grondlegger eenheid van taal (RIVM Rapport 2018-0081) gecodeerd en gemodelleerd worden. De grondlegger eenheid van taal schrijft niet voor dat iedere doelgroep dezelfde wijze van coderen en modelleren dient te gebruiken. Kwaliteitsverlies bij het mappen van de verschillende toegepaste coderingen en modelleringen dient zoveel mogelijk te worden voorkomen door de verschillende coderingen en modelleringen te harmoniseren of indien nodig te standaardiseren. Het persistente dataplatform (7) dient te beschikken over versiebeheer (10), om in de toekomst de situatie, zoals een onderzoek, of zorgview activiteit te kunnen reproduceren.  Meervoudig gebruik van de data wordt verder geborgd door deze FAIR te maken (8). 

In de gestandaardiseerde API (9) wordt bepaald welke vragen gesteld mogen worden over de data en hoe deze gepresenteerd worden (volgens grondlegger eenheid van taal).

 

3.3 Dienstverleners Meervoudig gebruik: (regionale) knooppunten

Niet iedere gezondheidsinstelling is in staat om databronnen (4) en (5) te ontsluiten (6) en in een persistent dataplatform (7) te coderen, modelleren en FAIR (8) te maken, om vervolgens middels een standaard API (9) te presenteren aan verschillende toepassingen. Een groter (regionaal) knooppunt kan dan, vanuit voldoende economy of scale, als een shared service centre fungeren, welke deze diensten levert t.b.v. (kleinere) zorginstellingen (in de regio). Hierbij is er sprake van een gezoneerd persistent dataplatform waarin de verschillende zorginstellingen hun eigen stukje data hebben, die door datastewards uit het shared service centre voor hen verwerkt worden tot herbruikbare data. 

4. Module Toepassen: onderdeel met de verschillende toepassingsgebieden 

Verschillende toepassingsgebieden, zoals zorgtoepassingen (11), registratietoepassingen (12) en onderzoektoepassingen (13) kunnen zich identificeren/ authenticeren bij de API (evt. in combinatie met een Data Access Commitee) om data in te mogen zien. De autorisatie metadata (8) geeft aan wie wat mag doen met de data onder welke omstandigheden. Zo kan bijvoorbeeld een arts, die aan kan tonen dat er een behandelrelatie met de persoon is, ongepseudonimiseerde data via de API inzien; een onderzoeker bijvoorbeeld, die aan kan tonen dat namens een UMC ziekenhuis een analyse, goedgekeurd door de relevante toetsingscommissie van het UMC ziekenhuis, in een veilige analyse omgeving verwerkt gaat worden, data gepseudonimiseerd inzien en eventueel verwerken in een geschikte analyseomgeving.

Hierbij zal de data zo veel mogelijk alleen ingezien worden en niet gedupliceerd worden (11 t/m 13). Uitzonderingen zouden kunnen zijn (14): 

  • Doorverwijs actie tussen verschillende zorgdienstverleners; waarbij de zorgverlener een eigen dossier gaat opbouwen waarvoor de basisgegevens overgenomen kunnen worden 

  • Centrale analysemethode, waar data gedurende het onderzoek naar een veilige verwerkingsomgeving gedupliceerd wordt; na het onderzoek zal de data verwijderd worden 

5. Module Generieke functies: onderdeel met de generieke functies 

Generieke functies dienen generiek, zowel voor gebruik in de zorg (primair) als daarbuiten (secundair) geschikt te zijn.

15. Identificatie, Authenticatie en Autorisatie; In een vertrouwensmodel moet vastgelegd kunnen worden dat een persoon vanuit een bepaalde rol functioneert; aan betreffende rol kunnen autorisaties toegekend worden. Deze rol gebaseerde authenticatie moeten domein overstijgend gestandaardiseerd worden, zodat zowel aan de verschillende zorgverleners rollen, als beleidsmakers rollen, als burgers rollen, als onderzoekers rollen verschillende autorisaties toegekend kunnen worden over organisaties (bv RIVM, kwaliteitsregisters) heen.

16. Metadata sjablonen: Aandoening specifieke domeinexpertise van datastewards bij (kwaliteit)registratie is waardevol bij het initieel coderen, modelleren en FAIR maken van aandoening specifieke domein data. Het landelijke implementatieproces wordt versneld met een generieke functie, die deze code- en modelleringsboeken met FAIRificering als herbruikbare templates beschikbaar stelt. 

17. Mapping; Zowel datahouders als datagebruikers gebruiken de data volgens een codering en modellering van de grondlegger eenheid van taal. Als deze verschillend zijn zorgt een generieke functie voor de juiste mapping;  

18. Pseudonimisering; Gepseudonimiseerde sleutels moeten over organisaties heen gebruikt kunnen worden om te identificeren, om data van een zelfde persoon te kunnen linken (bv. in een databron overstijgend onderzoek) 

19. Lokalisatie; momenteel met name voor gebruik in de zorg; hiermee is van één persoon bepaalde data uit verschillende bronnen op te vragen; de vraag is in hoeverre dit verschilt, of van dezelfde technieken gebruik kan maken als de zoek en aanvraag catalogus functie (23), waar van een groep personen bepaalde data uit verschillende bronnen opgevraagd wordt. 

20. Zeggenschap; ook wel toestemming genoemd; het streven is om personen transparant één plek te geven waar ze zowel ten behoeve van primaire als secundair gebruik 

  • Aan kunnen geven wie toegang heeft tot de data

  • Inzicht krijgen wie toegang heeft gehad tot de data

21. Adressering; juist kunnen adresseren van databronnen zowel voor primair als secundair gebruik 

6. Totaalplaatje gezamenlijk gezondheidsdata architectuurmodel

Wanneer de opbouw van de 3 verschillende modules wordt gecombineerd ontstaat het volgende totaalbeeld: