You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/applicatie/index.md
+10-10Lines changed: 10 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,7 +3,7 @@
3
3
4
4
Dit document richt zich op de uitwerking van een gelaagde, decentraal netwerk van BVOs, wat in TEHDAS2 een federatieve BVO wordt genoemd (_federated SPE_). De EHDS is in essentie federatief ontworpen: we willen uiteindelijk gezondheidsgegevens uit heel Europa kunnen aanwenden voor secundair gebruik. Tegelijkertijd willen we dat gezondheidsgegevens zoveel mogelijk binnen de landsgrenzen blijven. Om dit mogelijk te maken is **ten minste een architectuur nodig voor decentrale gegevensverwerking tussen landen**. Hierin is voorzien dat landelijke knooppunten gezamenlijk analyses kunnen uitvoeren, onder regie van een centraal knooppunt op Europees niveau. Deze aanpak is uitgewerkt in [TEHDAS2 M7.4](../appendix/tehdas2-spe.md) hoofdstuk 5 (_SPE federation_ p. 42) en hoofdstuk 6 (_Implementing federated computing_ p. 50). In dit document passen wij dezelfde ontwerpprincipes toe om **binnen een land een LDN voor decentrale informatieverwerking** mogelijk te maken.
5
5
6
-
Decentrale gegevensverwerking gaat uit van een netwerk van data stations die met elkaar verbonden zijn. De manier waarop deze data stations zijn verbonden (de zogenaamde netwerk topologie) is bepalend voor de architectuur van de federatieve BVO. We kennen grofweg drie netwerk topologieën[@baran1964distributed]: centraal, decentraal en gedistribueerd.
6
+
Decentrale gegevensverwerking gaat uit van een netwerk van datastations die met elkaar verbonden zijn. De manier waarop deze datastations zijn verbonden (de zogenaamde netwerk topologie) is bepalend voor de architectuur van de federatieve BVO. We kennen grofweg drie netwerk topologieën[@baran1964distributed]: centraal, decentraal en gedistribueerd.
7
7
8
8
9
9
@@ -13,8 +13,8 @@ Soorten netwerken: a) centraal, b) decentraal, c) distribueerd.
13
13
14
14
Federatieve BVOs kennen twee archetypes:[@rieke2020future]
15
15
16
-
1.Data stations zijn verbonden met één centrale server, met andere woorden een federatie BVO met een centraal netwerk (ook wel bekend als een _hub-and-spoke_ netwerk).
17
-
2.Data stations zijn met elkaar verbonden door middel van een een distribueerd netwerk (ook wel _peer-to-peer_ genoemd).
16
+
1.Datastations zijn verbonden met één centrale server, met andere woorden een federatie BVO met een centraal netwerk (ook wel bekend als een _hub-and-spoke_ netwerk).
17
+
2.Datastations zijn met elkaar verbonden door middel van een een distribueerd netwerk (ook wel _peer-to-peer_ genoemd).
18
18
19
19
20
20
@@ -23,27 +23,27 @@ Federatieve BVOs kennen twee archetypes:[@rieke2020future]
23
23
Gefedereerde gegevensverwerking met een a) centrale aggregatie server, en b) _peer-to-peer_ netwerk.
24
24
///
25
25
26
-
De meest gebruikte vorm van gefedereerde gegevensverwerking gaat uit van een centrale server die de data stations aanstuurt. Het concept een _Federated Database System (FDBS)_ is 1985 beschreven en wordt al jaren gebruikt voor het uitvoeren van gefedereerde analyse (_queries_) over meerdere databases.[@heimbigner1985federated] Het concept van gefedereerd leren zoals in 2017 door Google is geintroduceerd[@mcmahan2017communication] maakt ook gebruik van een centrale server.
26
+
De meest gebruikte vorm van gefedereerde gegevensverwerking gaat uit van een centrale server die de datastations aanstuurt. Het concept een _Federated Database System (FDBS)_ is 1985 beschreven en wordt al jaren gebruikt voor het uitvoeren van gefedereerde analyse (_queries_) over meerdere databases.[@heimbigner1985federated] Het concept van gefedereerd leren zoals in 2017 door Google is geintroduceerd[@mcmahan2017communication] maakt ook gebruik van een centrale server.
27
27
28
-
In de beschrijving van data stations gaan we dus uit van een centrale server, waarop de data gebruiker inlogt om toegang te krijgen tot de federatieve BVO. Federatieve BVOs met een _peer-to-peer_ netwerk zijn expliciet niet in scope van de architectuur zoals hier beschreven is.
28
+
In de beschrijving van datastations gaan we dus uit van een centrale server, waarop de data gebruiker inlogt om toegang te krijgen tot de federatieve BVO. Federatieve BVOs met een _peer-to-peer_ netwerk zijn expliciet niet in scope van de architectuur zoals hier beschreven is.
29
29
30
30
Daarnaast moet het in de context van de EHDS mogelijk zijn om te werken met _federations of federations_. De decentrale BVO die we voor ogen hebben kent een gelaagdheid van knooppunten. Denk bijvoorbeeld aan een zorginstelling die participeert in een regionale federatieve BVO, waarbij vervolgens verschillende regionale knooppunten opgaan in een landelijke federatief netwerk. Daarbovenop kunnen landelijke knooppunten onderdeel uitmaken van een Europese federatie. In de uitwerking van de architectuur gaan we daarom uit van een _decentraal netwerk_ dat een gelaagdheid kent van meerdere netwerken van BVOs (netwerk type b in bovenstaande illustratie).
31
31
32
32
## De componenten van een decentraal netwerk van BVOs
33
33
34
-
In de uitwerking van de architectuur voor een decentraal netwerk van BVOs staan **het datastation** en de **processing hub** centraal. Deze twee applicatie componenten realiseren gezamenlijk de functionaliteit die nodig is in een decentrale BVO. In relatie tot het FAIR zandloper model, is het data station onderdeel van laag 3, terwijl de FPH onderdeel is van laag 4. Conceptueel plaatsen we de verschillende vormen van gefedereerde gegevensbewerking in laag 5. Voortbouwend op TEHDAS2 maken we onderscheid tussen drie (arche)typen:
34
+
In de uitwerking van de architectuur voor een decentraal netwerk van BVOs staan **het datastation** en de **processing hub** centraal. Deze twee applicatie componenten realiseren gezamenlijk de functionaliteit die nodig is in een decentrale BVO. In relatie tot het FAIR zandloper model, is het datastation onderdeel van laag 3, terwijl de FPH onderdeel is van laag 4. Conceptueel plaatsen we de verschillende vormen van gefedereerde gegevensbewerking in laag 5. Voortbouwend op TEHDAS2 maken we onderscheid tussen drie (arche)typen:
35
35
36
-
1.**Gefedereerde analyse**: statistieken worden lokaal berekend in een netwerk van data stations. Alleen geaggregeerde resultaten of samenvattende statistieken worden uit de data stations geëxporteerd, met bijbehorende waarborgen dat geen persoonsgegevens worden onttrokken. Gefedereerde analyse is in principe hetzelfde als een _Federated Database System_. Gefedereerde analyse is bij uitstek geschikt om gegevensverzoeken in de zin van [EHDS artikel 69](https://eur-lex.europa.eu/legal-content/NL/TXT/HTML/?uri=OJ:L_202500327&qid=1764922416982#art_69) uit te voeren. [KIK-V](../implementaties/KIK-V/index.md) zien wij als een referentie implementatie voor gefedereerde analyse.
37
-
2.**Gefedereerd leren**: modellen worden getraind en gevalideerd op de data stations zonder dat de ruwe data wordt gedeeld tussen de data stations. In plaats daarvan worden alleen de model updates gedeeld met de FPH om daarmee betere dataprivacy en beveiliging te bereiken. [PLUGIN](../implementaties/PLUGIN/index.md) zien wij als een referentie implementatie voor gefedereerd leren.
38
-
3.**Data pooling**: de data stations kunnen worden gebruikt om data (tijdelijk) naar een andere BVO of daartoe bevoegd systeem te sturen, wat ook wel gegevensuitwisseling wordt genoemd. De [EOSC-ENTRUST Blueprint](https://zenodo.org/records/14362388) geeft een gedetaileerde architectuctuur weer hoe data stations kunnen integreren met dergelijke _Trusted Research Environment_. Het mechanisme van data pooling kan ook gebruikt worden om data aan te leveren naar kwaliteitsregistraties. Strikt genomen is data pooling geen vorm van federated processing, maar meer een hybride BVO. Omdat er zoveel raakvlakken zijn en mogelijke toepassingen zijn is het in de scope van dit document meegenomen.
36
+
1.**Gefedereerde analyse**: statistieken worden lokaal berekend in een netwerk van datastations. Alleen geaggregeerde resultaten of samenvattende statistieken worden uit de datastations geëxporteerd, met bijbehorende waarborgen dat geen persoonsgegevens worden onttrokken. Gefedereerde analyse is in principe hetzelfde als een _Federated Database System_. Gefedereerde analyse is bij uitstek geschikt om gegevensverzoeken in de zin van [EHDS artikel 69](https://eur-lex.europa.eu/legal-content/NL/TXT/HTML/?uri=OJ:L_202500327&qid=1764922416982#art_69) uit te voeren. [KIK-V](../implementaties/KIK-V/index.md) zien wij als een referentie implementatie voor gefedereerde analyse.
37
+
2.**Gefedereerd leren**: modellen worden getraind en gevalideerd op de datastations zonder dat de ruwe data wordt gedeeld tussen de datastations. In plaats daarvan worden alleen de model updates gedeeld met de FPH om daarmee betere dataprivacy en beveiliging te bereiken. [PLUGIN](../implementaties/PLUGIN/index.md) zien wij als een referentie implementatie voor gefedereerd leren.
38
+
3.**Data pooling**: de datastations kunnen worden gebruikt om data (tijdelijk) naar een andere BVO of daartoe bevoegd systeem te sturen, wat ook wel gegevensuitwisseling wordt genoemd. De [EOSC-ENTRUST Blueprint](https://zenodo.org/records/14362388) geeft een gedetaileerde architectuctuur weer hoe datastations kunnen integreren met dergelijke _Trusted Research Environment_. Het mechanisme van data pooling kan ook gebruikt worden om data aan te leveren naar kwaliteitsregistraties. Strikt genomen is data pooling geen vorm van federated processing, maar meer een hybride BVO. Omdat er zoveel raakvlakken zijn en mogelijke toepassingen zijn is het in de scope van dit document meegenomen.
39
39
40
40
In dit hoofdstuk beschrijven we de applicatie componenten van een federatieve BVO, zijnde de drie soorten toepassingen in laag 5, de Processing Hub en het datastation. Daarbij gaan we ook expliciet in op de verschillende [TEHDAS2 vereisten](../appendix/tehdas2-requirements.md) die zijn geformuleerd. Voor de andere, meer generieke componenten, gaan we uit van de beschrijving in TEHDAS2 en voeren we een kortere _fit-gap_ analyse uit in hoeverre deze componenten passen in een federatieve BVO. Onderstaand tabel geeft een overzicht van de belangrijkste applicatie componenten binnen het FAIR zandloper vijf-lagen model.
Voor gedetailleerde technische specificaties van de gegevenscatalogus verwijzen we naar TEHDAS2.
4
-
5
-
TO DO:
6
-
7
-
- benadrukken wat hierin belangrijk is in relatie tot data station
8
-
- eventuele discrepanties aanstippen
3
+
Voor gedetailleerde technische specificaties van de gegevenscatalogus verwijzen we naar TEHDAS2. In een volgende versie zal in meer detail worden ingegaan op de afhankelijkheden en eventuele discrepanties tussen de catalogus en het datastation.
Voor gedetailleerde technische specificaties van DAAMS verwijzen we naar TEHDAS2.
4
-
5
-
TO DO:
6
-
7
-
- benadrukken wat hierin belangrijk is in relatie tot data station
8
-
- eventuele discrepanties aanstippen
3
+
Voor gedetailleerde technische specificaties van het DAAMS verwijzen we voor nu naar TEHDAS2. In een volgende versie zal in meer detail worden ingegaan op de afhankelijkheden en eventuele discrepanties tussen het DAAMS en het datastation.
Ten tijde van het schrijven van de eerste versie van deze specificatie zijn er wezenlijke verschillen geconstateerd hoe bijvoorbeeld de processing hub van KIK-V is geimplementeerd in vergelijking met die van PLUGIN/vantage6. Dit is ook een van de kernvragen van het lopende [Health-AI](https://www.clinicaldatascience.nl/health-ai) doorbraakproject.
4
+
5
+
Voor nu verwijzen we daarom naar de sectie over deze twee [implementaties](../../implementaties/index.md) hoe dat tot op heden in de praktijk is uitgewerkt. We streven ernaar om op een later moment meer inzichten en lessen te kunnen beschrijven en daarmee tot verdere standaardisatie van de processing hub te komen.
0 commit comments