Update numbering and renamed processing hub

Author: dkapitan

docs/applicatie/index.md

@@ -1,5 +1,5 @@
-# 4.0. Perspectief: applicatie
-## 4.0.1. Applicatiecomponenten voor gegevenswerking in gelaagde, decentrale netwerken
+# Perspectief: applicatie
+## Applicatiecomponenten voor gegevenswerking in gelaagde, decentrale netwerken
 
 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.
 
@@ -29,20 +29,20 @@ In de beschrijving van data stations gaan we dus uit van een centrale server, wa
 
 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).
 
-## 4.0.2. De componenten van een decentraal netwerk van BVOs
+## De componenten van een decentraal netwerk van BVOs
 
-In de uitwerking van de architectuur voor een decentraal netwerk van BVOs staan **het data station** en de **federated processing hub (FPH)** 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:
+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:
 
 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.
 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.
 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. 
 
-In dit hoofdstuk beschrijven we de applicatie componenten van een federatieve BVO, zijnde de drie soorten toepassingen in laag 5, de Federated Processing Hub en het data station. 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.
+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.
 
 | Laag | Systemen |
 |:----:|:---------|
 | **5** | **> [Gefedereerde analyse](./laag-5/federatieve-analyse.md)**<br>**> [Gefedereerd leren](./laag-5/federatief-leren.md)**<br>**> [Data pooling](./laag-5/data-pooling.md)** |
-| **4** | > [Data Access Application Mgnt System](./laag-4/daams.md)<br>> [Catalogus gezondheidsgegevens](./laag-4/catalogus.md)<br>**> [Federated processing hub](./laag-4/fph.md)** |
+| **4** | > [Data Access Application Mgnt System](./laag-4/daams.md)<br>> [Catalogus gezondheidsgegevens](./laag-4/catalogus.md)<br>**> [Processing hub](./laag-4/fph.md)** |
 | **3** | **> [Data station](./laag-3/data-station.md)** |
 | **2** | > Data ontsluitingssysteem |
 | **1** | > bronsystemen |

docs/applicatie/laag-3/data-station.md

@@ -1,4 +1,4 @@
-# Datastation
+# 4.1. Datastation
 
 In een dataspace voor secundair gebruik is het datastation, naast de processing hub, een essentieel component. Waar de processing hub het component is voor de data-afnemer, is het datastation dat voor de dataleverancier. Beide componenten zijn daarmee elkaars tegenhanger binnen de dataspace-architectuur: voor iedere rol is één kerncomponent gedefinieerd.
 
@@ -30,7 +30,7 @@ In de onderstaande paragrafen worden de eisen aan een datastation beschreven.
     Om die reden wordt in dit hoofdstuk geen gedetailleerde architectuur uitgewerkt. Vanuit de dataspace is het vooral van belang dat de interoperabiliteit met het datastation is geborgd en dat het vertrouwen en de integriteit van de dataspace als geheel worden gewaarborgd, over alle autonome onderdelen heen. De eisen aan een datastation richten zich daarom alleen op interoperabiliteit en vertrouwen.
 
 
-## Beheer catalogus van datasets
+## 4.1.1. Beheer catalogus van datasets
 
 Iedere dataleverancier is zelf verantwoordelijk voor het catalogiseren en publiceren van haar datasets. Dit betekent dat de dataleverancier een eigen datasetcatalogus samenstelt en beheert. In dit document spreken we niet af welke datasets in de catalogus moeten worden opgenomen, maar alleen welk formaat wordt gebruikt. De catalogus moet worden opgesteld in [HealthDCAT-AP Release 5](https://healthdataeu.pages.code.europa.eu/healthdcat-ap/releases/release-5/).
 
@@ -47,7 +47,7 @@ Voor de beheer van de catalogus wordt uitgegaan van een servicemedewerker die de
 Met het vrijgeven wordt bedoeld dat de dataleverancier een versie van de datacatalogus publiceert en daarmee een nieuwe versie beschikbaar stelt. Dit vrijgeven kan periodiek plaatsvinden, bijvoorbeeld meerdere keren per jaar. Het aanmelden van de catalogus hoeft daarentegen slechts eenmalig te gebeuren.
 Na aanmelding is de catalogus van de dataleverancier geregistreerd in het register van de HDAB ten behoeve van de Nationale catalogus van datasets.
 
-## Haal periodiek catalogus van datasets op
+## 4.1.2. Haal periodiek catalogus van datasets op
 
 De Health Data Access Body (HDAB) is met het component voor de Nationale Catalogus volledig autonoom in het bepalen van de frequentie waarmee de Nationale Catalogus wordt bijgewerkt. Dit betekent dat de HDAB kan plannen wanneer de catalogus van een dataleverancier wordt opgehaald, in plaats van dat dit ad hoc door alle leveranciers tegelijk gebeurt.
 
@@ -59,7 +59,7 @@ De Health Data Access Body (HDAB) is met het component voor de Nationale Catalog
 
 Door deze autonomie ontstaat een efficiënte en gecontroleerde updateprocedure, waardoor piekbelasting of “filevorming” wordt voorkomen wanneer meerdere dataleveranciers tegelijk hun catalogus willen bijwerken. Bovendien draagt deze regeling bij aan de betrouwbaarheid en stabiliteit van de Nationale Catalogus, omdat updates gespreid en voorspelbaar plaatsvinden. Dit biedt zowel de HDAB als de dataleveranciers meer controle over het proces en helpt bij het waarborgen van consistente en actuele informatie in de dataspace.
 
-## Maak data beschikbaar voor secundair gebruik
+## 4.1.3. Maak data beschikbaar voor secundair gebruik
 
 Vanuit de HDAB wordt een verzoek gedaan om een dataset beschikbaar te stellen voor secundair gebruik. Dit verzoek kan gebaseerd zijn op een door de HDAB verleende datavergunning of op een goedgekeurd dataverzoek.
 
@@ -95,7 +95,7 @@ In het onderstaande figuur zijn scenario 2 en 3 weergegeven.
 
 Met het beschikbaar stellen van de datasets is het datastation gereed voor de ontvangst van een algoritme of een dataverzoek.
 
-## Verwerk algoritme en geef resultaat terug
+## 4.1.4. Verwerk algoritme en geef resultaat terug
 
 Een datastation kan onder andere worden gebruikt voor het uitvoeren van een federatieve analyse of voor federatief leren, of kort gezegd voor het uitvoeren van een algortime. De datagebruiker geeft via de processing hub een opdracht om een algoritme uit te voeren op een aantal datastations. In het onderstaande diagram zijn de stappen weergegeven die op het datastation worden uitgevoerd nadat de opdracht door het datastation is ontvangen.
 
@@ -141,7 +141,7 @@ Onder andere moeten de volgende aspecten worden gewaarborgd:
 
 Ten aanzien van de resultaten moet besloten worden of deze de beveiligde omgeving van de processing hub mogen verlaten. Hiervoor zal een vrijgaveproces gedefinieerd moeten worden waarin strikte regels voor export en overdracht gelden.
 
-## Geef antwoord op dataverzoek
+## 4.1.5. Geef antwoord op dataverzoek
 
 Wanneer een dataverzoek wordt ontvangen via de processing hub, start het datastation het verwerkingsproces. Als eerste stap worden de authenticiteit en geldigheid van de identiteit van de data-afnemer, de identiteit van de datagebruiker en het akkoord op het dataverzoek geverifieerd op basis van aangeleverde credentials met een hoog betrouwbaarheidsniveau, conform de eIDAS-verordening. Alleen na een succesvolle verificatie wordt het dataverzoek verder verwerkt.
 

docs/discussie/primair-vs-secundair.md

@@ -39,7 +39,7 @@ Onderstaande tabellen geven een overzicht van de verschillen en overeenkomst tus
     | ID    | Omschrijving |
     |:-----:|:-------------|
     | L4-V1 | Grondslag en rol van data gebruiker in primair proces is anders voor primair (behandelrelatie) en secundair (vergunning of gegevensverzoek). |
-    | L4-V2 | De Federated Processing Hub vervult een belangrijke functie voor output controle c.q. _statistical disclosure control_. Dit is bij primair gebruik niet aan de orde. |
+    | 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. |
 
 ## Parking lot
 

includes/woordenlijst.md

@@ -7,7 +7,6 @@
 *[EHDS]: European Health Data Space
 *[FAIR]: Findable, Accessible, Interoperable, Reusable
 *[FDBS]: Federated Database System
-*[FPH]: Federated Processing Hub
 *[HDAB]: Health Data Access Body
 *[LDN]: Landelijke Dekkend Netwerk
 *[primair gebruik]: gebruik van data voor directe behandeling van een persoon