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
Dit document geeft een beschrijving van een decentrale BVO, met het [datastation](../applicatie/laag-3/data-station.md) en de [processing hub](../applicatie/laag-4/processing-hub.md) als de meest kenmerkende componenten. Zoals eerder gesteld is de EHDS onvoldoende expliciet over de nut en noodzaak van decentrale architecturen, wat de aanleiding was voor een van de onderzoeksvragen:
4
+
5
+
> Op welke manier kunnen hybride BVOs, zijnde een synergie tussen centrale en decentrale BVOs, gerealiseerd worden en welke mogelijkheden zijn er om hierin tot standaardisatie te komen?
6
+
7
+
In het onderstaande wordt ingegaan op deze vraag.
8
+
9
+
## 7.1.1. De nut en noodzaak van een hybride oplossing
10
+
11
+
In dit document hebben we beargumenteerd dat een decentrale oplossing voordelen biedt op het gebied van security, privacy en data governance. Tegelijkertijd realiseren wij ons dat er usecases zullen zijn waarbij decentrale processing niet mogelijk is. Denk hierbij aan verticaal gepartitioneerde data of het doorleveren van gegevens aan een landelijke kwaliteitsregistratie.
12
+
13
+
Wij stellen daarom voor een hybride oplossing waarbij federated processing ingezet kan worden wanneer de usecase het toelaat en daarnaast de datastations data kunnen doorzetten naar een centrale BVO.
14
+
15
+
## 7.1.2. Formele status van een datastation als decentrale BVO
16
+
17
+
De EHDS verplicht dat secundair gebruik van gezondheidsdata plaatsvindt binnen een BVO. Gegeven de rol en functionaliteit van een datastation, gaan wij er vanuit dat een datastation formeel onder de definitie van een BVO valt. Het is echter nog onduidelijk hoe de certificering van decentrale BVOs, zijnde de datastations zoals in dit document zijn beschreven, eruit zou kunnen zien. De benadering van de EHDS leunt sterk op regie door een HDAB. Als de HDAB enkel centrale BVOs erkent of faciliteert, vormt dit een directe tegenstrijdigheid met de decentrale opzet voor datastations secundair gebruik, waar data bij de bronhouder blijft.
18
+
19
+
Om dit punt te adresseren zou een (inter)nationaal certificeringskader komen waarbij de BVOs die gekoppeld zijn aan (of onderdeel zijn van) een decentrale federerated processing infrastructuur worden erkend als een valide EHDS-verwerkingsomgeving.
20
+
21
+
22
+
## 7.1.3. Geautomatiseerde controle van vergunningen en gegevensverzoeken
23
+
24
+
De grondslag voor secundair gebruik in de EHDS is gebaseerd op een vergunning of een gegevensverzoek. De HDAB is verantwoordelijk voor de uitgifte van de attestatie dat een datagebruiker beide vormen van secundair gebruik.
25
+
26
+
In het geval dat een centrale BVO wordt gebruikt om uitvoering te geven aan de vergunning of gegevensverzoek, zullen de autorisatie mechanismen ook in het centrale systeem geimplementeerd moeten worden. Dit zou bijvoorbeeld kunnen met een persoonsgebonden credential waarmee de gebruiker toegang krijgt tot de BVO.
27
+
28
+
Het autorisatiemechanisme is voor een decentrale BVO complexer: er zal een mechanisme moeten worden geimplementeerd waarbij het datastation kan verifieren of een bepaald algoritme daadwerklijk uitgevoerd mag worden. Binnen KIK-V wordt het NUTS framework gebruikt om de vertrouwensrelaties digitaal vast te leggen binnen het netwerk. Deze oplossingsrichting is generaliseerbaar op termijn dit te combineren met de eIDAS business wallet.
29
+
30
+
Kijkend naar PLUGIN en het onderliggende vantage6 framework zien wij dat een dergelijk _trust_ mechanisme nog niet is geimplementeerd. Het belagnrijkste autorisatiemechanisme loopt via de container registry waar goedgekeurde algoritmes in zijn opgeslagen. In het geval van federated processing, met een vergunning als grondslag, zal er dus nog een _trust_ mechanisme geimplementeerd moeten worden waarbij de DAAMS het bronsysteem is dat de (digitale) certificaten uitgeeft. Het concept van _smart contracts_ zou hier een technische oplossing voor kunnen bieden.[@short2021execution] Alhoewel dergelijke oplossingen technisch bewezen zijn, is er nog geen uniforme standaard noch is de technologie voldoende volwassen voor grootschalig gebruik.
31
+
32
+
## 7.1.4. Specificatie van _data visting_ standaarden
33
+
34
+
De benadering van federated processing conform het principe van _data visiting_ is essentieel om op grote schaal gebruik te kunnen maken van decentrale BVOs. Op dit moment zijn hiervoor verschillende technische oplossingen die nog onvoldoende op elkaar aansluiten. Dit is een van de centrale vragen binnen het [Health-AI project](https://www.clinicaldatascience.nl/health-ai). Afhankelijk van de uitkomsten van dit project - en andere vergelijkbare initiatieven, zullen meer gedetailleerde specificaties en standaarden voor federated processing moeten worden opgesteld.
# 7.1. Data stations voor primair vs. secundair gebruik
1
+
# 7.2. Data stations voor primair vs. secundair gebruik
2
2
3
-
Dit document geeft een beschrijving van een federatieve BVO, met het [data station](../componenten/laag-3/data-station.md) en de [Federated Processing Hub](../componenten/laag-4/fph.md) als de meest kenmerkende componenten. In de context van primair gebruik wordt ook gesproken over data stations en centrale integratie componenten zoals bijvoorbeeld de [_Interoperability Layer_](https://guides.ohie.org/arch-spec/openhie-component-specifications-1/openhie-interoperability-layer-iol)in de OpenHIE architectuur. Doel is om een van de onderzoeksvragen hierover te addresseren:
3
+
Dit document geeft een beschrijving van een decentrale BVO, met het [datastation](../applicatie/laag-3/data-station.md) en de [processing hub](../applicatie/laag-4/processing-hub.md) als de meest kenmerkende componenten. In vergelijking met de Cumuluz doelarchitectuur zien we vergelijkbare rollen voor het Cumuluz Datastation respectievelijk de Cumuluz Integrator. Zoals in de inleiding is gesteld, is een vergelijking van de architectuur voor primair vs. secundair een van de centrale onderzoeksvragen:
4
4
5
-
> Zijn er lancunes danwel tegenstrijdigheden in de huidige benadering van de EHDS voor secundair gebruik die het gebruik van federatieve BVOs in de weg staan, met name ook in relatie tot data stations voor primair gebruik? Zo ja, welke oplossingsrichtingen zijn er?
5
+
> Zijn er lancunes danwel tegenstrijdigheden in de huidige benadering van de EHDS voor secundair gebruik die het gebruik van decentrale BVOs in de weg staan, met name ook in relatie tot datastations voor primair gebruik? Zo ja, welke oplossingsrichtingen zijn er?
6
6
7
-
Onderstaande tabellen geven een overzicht van de verschillen en overeenkomst tussen data station voor primair en secundair gebruik, als ook voor de centrale integratie component in laag 4.
7
+
In het onderstaande wordt ingegaan op deze vragen.
8
+
9
+
## 7.2.1. Verschil in grondslag voor geautoriseerde toegang
10
+
11
+
Wanneer we de Cumuluz doelarchitectuur vergelijken met dit document, dan zien we dat beide architecturen streven naar een "eenmalige registratie, meervoudig gebruik" benadering. Er is echter een essentieel verschil in de grondslag:
12
+
13
+
-**Primair gebruik:** gebaseerd op de behandelrelatie en toestemming van de patiënt.
14
+
-**Secundair gebruik:** Gebaseerd op een vergunning uitgegeven door een HDAB.
8
15
9
-
### Overeenkomsten en verschillen data stations
16
+
In het ontwerp van een Cumuluz Datastation is duidelijk gespecificeerd hoe via een centrale toestemmingsvoorziening (MITZ) toegang tot het datastation wordt gegeven. In het geval van secundair gebruik is er nog geen sluitende technische integratie waarbij een decentraal datastation autonoom vergunning die door de HDAB/DAAMS is uitgegeven kan valideren. Dit laatste staat los van MITZ, waarin alleen op de opt-out registratie voor secundair gebruik is vastgelegd.
17
+
18
+
## 7.2.2. Vergelijking primair en secundair datastation
10
19
11
20
???+ success "Overeenkomsten tussen primaire en secundaire data stations"
12
21
| ID | Omschrijving |
13
22
|:-----:|:-------------|
14
-
| DS-O1 | Vergelijkbare, zo niet identieke, ontwerp principes en niet-functionele vereisten op het gebied van authenticatie, localisatie, beveiliging etc. |
15
-
| DS-02 | Een data station valt in het domein van de data houder. |
16
-
| DS-O3 | Een data station gaat uit van conformiteit, waarbij meerdere informatiemodellen worden ondersteund incl. functionaliteit om transformaties tussen deze modellen uit te voeren. |
23
+
| DS-O1 | Vergelijkbare, zo niet identieke, ontwerp principes en niet-functionele vereisten. |
24
+
| DS-02 | Een datastation valt in het domein van de datahouder. |
25
+
| DS-O3 | Een datastation gaat uit van conformiteit, waarbij meerdere informatiemodellen worden ondersteund incl. functionaliteit om transformaties tussen deze modellen uit te voeren. |
17
26
18
27
???+ warning "Verschillen tussen primaire en secundaire data stations"
19
28
| ID | Omschrijving |
@@ -25,13 +34,12 @@ Onderstaande tabellen geven een overzicht van de verschillen en overeenkomst tus
25
34
| DS-V5 | Opslag van data is bij een primair data station optioneel, bij een secondair data stations een vereiste om _data visiting_ te ondersteunen. |
26
35
| DS-V6 | Een primair data station heeft geen voorziening voor het lokaal uitvoeren van berekeningen. Voor een secondair data stations een vereiste om _data visiting_ te ondersteunen. |
27
36
28
-
29
-
### Overeenkomsten en verschillen integratie component in laag 4
37
+
## Vergelijking Integrator (primair) en Processing Hub (secundair)
30
38
31
39
???+ success "Overeenkomsten centrale interatie component in laag 4"
32
40
| ID | Omschrijving |
33
41
|:-----:|:-------------|
34
-
| L4-O1 | Vergelijkbare, zo niet identieke, ontwerp principes en niet-functionele vereisten op het gebied van authenticatie, localisatie, beveiliging etc. |
42
+
| L4-O1 | Vergelijkbare, zo niet identieke, ontwerp principes en niet-functionele vereisten. |
35
43
| L4-O2 | Data gebruikers (systemen of personen) krijgen toegang tot data via één centrale ingang, er wordt gebruik gemaakt van een _hub-and-spoke_ netwerk topologie. |
36
44
| L4-03 | Inrichting van laag 4 gaat uit van het [_four corner model_](https://health-ri.github.io/data-spaces-archimate/?view=id-65fda4e829df4a489df5644ffbbdb0e6): meerdere service providers zijn voorzien in het LDN. |
37
45
@@ -41,6 +49,31 @@ Onderstaande tabellen geven een overzicht van de verschillen en overeenkomst tus
41
49
| L4-V1 | Grondslag en rol van data gebruiker in primair proces is anders voor primair (behandelrelatie) en secundair (vergunning of gegevensverzoek). |
42
50
| L4-V2 | De Processing Hub vervult een belangrijke functie voor output controle c.q. _statistical disclosure control_. Dit is bij primair gebruik niet aan de orde. |
43
51
52
+
53
+
54
+
55
+
56
+
57
+
58
+
59
+
### Geharmoniseerde API voor Permits en Autorisatie:**
60
+
Het Landelijk Afsprakenstelsel (LAS) moet worden uitgebreid met een specifieke "EHDS-connector". Deze API moet het voor een decentraal Datastation mogelijk maken om een digitale permit van de HDAB direct te vertalen naar lokale toegangsrechten in de BVO, vergelijkbaar met hoe de Generieke Functie Autorisatie werkt voor primair gebruik.
61
+
62
+
63
+
***Dual-purpose Adapter Functies:**
64
+
De "Adapter"-rol in de CumuluZ-architectuur moet worden doorontwikkeld naar een dual-purpose component die zowel FHIR (primair) als analytische formaten (secundair) kan uitserveren vanuit dezelfde geabstraheerde datalaag. Dit borgt dat de data-integriteit tussen de patiëntenzorg en onderzoek behouden blijft.
65
+
66
+
67
+
***Eenduidige Governance op "Data Access Committees" (DAC):**
68
+
Het proces voor het verlenen van toegang moet worden gestroomlijnd waarbij de lokale DAC van een ziekenhuis en de nationale HDAB via een federatief model samenwerken. Dit voorkomt dubbele administratieve lasten en zorgt ervoor dat de bronhouder de regie behoudt, conform architectuurprincipe C2.
69
+
70
+
Onderstaande tabellen geven een overzicht van de verschillen en overeenkomst tussen data station voor primair en secundair gebruik, als ook voor de centrale integratie component in laag 4.
0 commit comments