Merge pull request #44 from Health-RI/small-corrections

Small corrections

Author: dkapitan

docs/applicatie/index.md

@@ -23,15 +23,15 @@ Federatieve BVOs kennen twee archetypes:[@rieke2020future]
 Gefedereerde gegevensverwerking met een a) centrale aggregatie server, en b) _peer-to-peer_ netwerk.
 ///
 
-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.
+De meest gebruikte vorm van gefedereerde gegevensverwerking gaat uit van een centrale server die de datastations aanstuurt. Het concept van een _Federated Database System (FDBS)_ is in 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.
 
 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.
 
-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).
+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 landelijk 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).
 
 ## De componenten van een decentraal netwerk van BVOs
 
-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:
+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](../data-stations-als-hoeksteen.md#122-de-vijf-lagen-van-het-zandloper-model-als-denkraam), 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:
 
 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.
 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.

docs/applicatie/laag-3/index.md

@@ -20,7 +20,7 @@ Uitgangspunt is dat dataleveranciers een proces doorlopen om deelnemer te worden
 
 !!! info "Afsprakenstelsels en dataspaces"
 
-    In de tekst wordt zowel de term afsprakenstelsel als dataspace gebruikt. Een dataspace definiëren we als een afsprakenstelsel voor databeschikbaarheid, het maakt een betrouwbare gegenvensuitwisseling mogelijk tussen deelnemers. Afsprakenstelsels kunnen met andere woorden over vele onderwerpen gaan, dataspaces beperken het onderwerp tot gegevensuitwisseling en databeschikbaarheid. 
+    In de tekst wordt zowel de term afsprakenstelsel als dataspace gebruikt. Een dataspace definiëren we als een afsprakenstelsel voor databeschikbaarheid, het maakt een betrouwbare gegevensuitwisseling mogelijk tussen deelnemers. Afsprakenstelsels kunnen met andere woorden over vele onderwerpen gaan, dataspaces beperken het onderwerp tot gegevensuitwisseling en databeschikbaarheid. 
 
 ## Model met dienstverleners
 

docs/data-stations-als-hoeksteen.md

@@ -40,7 +40,7 @@ In **laag 2** wordt een begin gemaakt met het standaardiseren van de data. Het i
 
 ### 1.2.2.2. Het datastation in het hart van de zandloper
 
-**Laag 3 is het hart van de zandloper** en fungeert als een brug tussen de twee onderste en twee bovenste lagen. In deze laag worden de data en metadata (1) klaargezet voor gebruik en FAIRificatie proces en (2) verbonden aan het netwerk van beveiligde verwerkingsomgevingen. Deze laag is het meest cruciale om interoperabiliteit te realiseren. Daarvoor wordt een set van minimale, open en technologie-neutrale standaarden gedefinieert. Het idee van een datastation sluit aan bij het concept van data producten in de DSSC.
+**Laag 3 is het hart van de zandloper** en fungeert als een brug tussen de twee onderste en twee bovenste lagen. In deze laag worden de data en metadata (1) klaargezet voor gebruik en FAIRificatie proces en (2) verbonden aan het netwerk van beveiligde verwerkingsomgevingen. Deze laag is het meest cruciale om interoperabiliteit te realiseren. Daarvoor wordt een set van minimale, open en technologie-neutrale standaarden gedefinieerd. Het idee van een datastation sluit aan bij het concept van data producten in de DSSC.
 
 ??? abstract "Data product"
     Primair gebruik heeft betrekking op de directe zorgverlening aan een patiënt, terwijl secundair gebruik betrekking heeft op het hergebruik van gegevens voor onder andere onderzoek, beleid en innovatie.

docs/discussie/index.md

@@ -11,6 +11,6 @@ Voorlopige conclusie:
 
 - Eenheid van techniek is al mogelijk om technische interoperabiliteit te realiseren
     - Een datastation is in feit een 'mini-BVO' c.q. decentrale BVO en dient daarom aan alle vereisten van de EHDS te voldoen
-    - Dit is haalbaar, maar er zijn een paar lancunes (die [voorstel ontwikkelagenda](ontwikkelagenda.md))
+    - Dit is haalbaar, maar er zijn een paar lacunes (die [voorstel ontwikkelagenda](ontwikkelagenda.md))
 - Eenheid van taal duurt langer (semantische interoperabilteit) --> binnen datastations maximaal inzetten op effectief en efficient ondersteunen van data transformaties met de composable data stack
 - Groot deel van technische vereisten van TEHDAS2 zijn nu al gerealiseerd in KIK-V en PLUGIN. 

docs/discussie/permit-vs-request.md

@@ -15,6 +15,6 @@ EHDS maakt onderscheidt tussen:
 
 ## Praktijk beproeving universeel datastation
 
-In december 2023 tot april 2024 is onderzoek gedaan naar databeschikbaarheid via eenfederatief netwerk van datastations en herbruikbaarheid van KIK-V producten in deAchterhoek.
+In december 2023 tot april 2024 is onderzoek gedaan naar databeschikbaarheid via een federatief netwerk van datastations en herbruikbaarheid van KIK-V producten in de Achterhoek.
 
 ![Alt text](<../appendix/KIK-V/praktijkbeproeving-universeel-datastation-met-hergebruik-van-kik-v-producten.pdf>){ type=application/pdf style="min-height:100vh;width:100%" }

docs/discussie/primair-vs-secundair.md

@@ -2,7 +2,7 @@
 
 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: 
 
-> 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?
+> Zijn er lacunes 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?
 
 In het onderstaande wordt ingegaan op deze vragen.
 

docs/implementaties/KIK-V/index.md

@@ -22,7 +22,7 @@ KIK-V implementeerd een vorm van federated analytics, waarbij de volgende compon
 
 - Informatie:
     - De **ontologie** is het centrale gegevensmodel waarmee KIK-V werkt
-    - De **uitwisselprofielen** definieren de verschilende gegevensverzoeken die via het platform kunnen worden ingediende en verwerkt. Deze profielen worden opgesteld via een gestructureerd matchingsproces
+    - De **uitwisselprofielen** definiëren de verschillende gegevensverzoeken die via het platform kunnen worden ingediende en verwerkt. Deze profielen worden opgesteld via een gestructureerd matchingsproces
 - Applicatie:
     - **laag 4 | KIK-Starter** is de applicatie waarmee datagebruikers hun gegevensverzoeken kunnen uitvoeren.
     - **laag 4 | Credentialsplatform** vervuld een functie vergelijkbaar met de DAAMS, waarbinnen goedgekeurde uitwisselprofielen worden beheerd en beschikbaar gesteld voor datagebruikers.

docs/index.md

@@ -2,7 +2,7 @@
 
 ## De noodzaak voor een landelijk dekkend netwerk in de zorg
 
-Het verlenen van zorg vindt vaak plaats in een netwerk van zorgaanbieders uit verschillende sectoren. Digitalisering, gegevensuitwisseling en databeschikbaarheid vervullen hierin een cruciale rol. Om dit mogelijk te maken, wordt in Nederland gewerkt aan de realisatie van een Landelijke Dekkend Netwerk (LDN). Het LDN is een overkoepelende term en omvat:
+Het verlenen van zorg vindt vaak plaats in een netwerk van zorgaanbieders uit verschillende sectoren. Digitalisering, gegevensuitwisseling en databeschikbaarheid vervullen hierin een cruciale rol. Om dit mogelijk te maken, wordt in Nederland gewerkt aan de realisatie van een Landelijk Dekkend Netwerk (LDN). Het LDN is een overkoepelende term en omvat:
 
 - een LDN van **infrastructuren**, dat zorgaanbieders met elkaar verbindt voor het uitwisselen en beschikbaar stellen van gezondheidsgegevens;
 - een bijbehorend **vertrouwensstelsel** met technische, organisatorische en juridische afspraken die nodig zijn om te zorgen dat burgers en zorgverleners kunnen vertrouwen op de data en op het veilige en verantwoorde gebruik ervan;
@@ -36,7 +36,7 @@ Het werk aan het LDN is onderdeel van de implementatie van de European Health Da
     De belangrijkste concepten rondom secundair gebruik zijn gedefinieerd in de nieuwe Europese wetgeving, met name de EHDS (hoofdstuk IV, artikel 50 t/m 81) en de Data Governance Act (DGA).
 
     === "**Beveiligde verwerkingsomgeving (BVO)**"
-        Een beveiligde omgeving waarin gezondheidsgegevens verwerkt kunnen worden voor bijvoorbeeld wetenschappelijk onderzoek. Dit kan een centrale BVO zijn, zoals bijvoorbeeld de [CBS Microdata omgeving](https://www.cbs.nl/nl-nl/onze-diensten/maatwerk-en-microdata/microdata-zelf-onderzoek-doen), een gefedereerde BVO of een hybride combinatie daarvan. Dit focus van deze specificatie is dat datastations als hoeksteen kunnen fungeren voor een netwerk van BVOs.
+        Een beveiligde omgeving waarin gezondheidsgegevens verwerkt kunnen worden voor bijvoorbeeld wetenschappelijk onderzoek. Dit kan een centrale BVO zijn, zoals bijvoorbeeld de [CBS Microdata omgeving](https://www.cbs.nl/nl-nl/onze-diensten/maatwerk-en-microdata/microdata-zelf-onderzoek-doen), een gefedereerde BVO of een hybride combinatie daarvan. De focus van deze specificatie is dat datastations als hoeksteen kunnen fungeren voor een netwerk van BVOs.
 
     === "**Datagebruiker**" 
         Een persoon of organisatie die toegang heeft gekregen tot elektronische gezondheidsgegevens voor secundair gebruik. Bijvoorbeeld een onderzoeker, een beleidsmederwerker of een ontwikkelaar van commerciële producten. In EHDS-terminologie: de gebruiker van gezondheidsegegevens (_Health Data User_).
@@ -55,7 +55,7 @@ Het werk aan het LDN is onderdeel van de implementatie van de European Health Da
 
 ## Scope van dit specificatie document
 
-Dit specificatie document beschrijft een architectuur voor een landelijke gezondheidsdata-infrastructuur voor secundair gebruik. Het gaat uit van het concept van datastations als hoeksteen om syntactische en semantische interoperabiliteit te realiseren. Deze specificatie is opgesteld in opdracht van Health-RI, als onderdeel van haar kerntaak om secundair van gezondheidsgegevens mogelijk te maken. Verschillende experts en ervaringsdeskundigen zijn vanaf het begin betrokken bij het schrijven en uitwerken van dit document. Het is de bedoeling dat de specificatie begin 2026 ter consultatie wordt voorgelegd aan het werkveld via een nog nader te kiezen proces.
+Dit specificatie document beschrijft een architectuur voor een landelijke gezondheidsdata-infrastructuur voor secundair gebruik. Het gaat uit van het concept van datastations als hoeksteen om syntactische en semantische interoperabiliteit te realiseren. Deze specificatie is opgesteld in opdracht van Health-RI, als onderdeel van haar kerntaak om secundair gebruik van gezondheidsgegevens mogelijk te maken. Verschillende experts en ervaringsdeskundigen zijn vanaf het begin betrokken bij het schrijven en uitwerken van dit document. Het is de bedoeling dat de specificatie begin 2026 ter consultatie wordt voorgelegd aan het werkveld via een nog nader te kiezen proces.
 
 Vragen, reacties en feedback op dit document zijn van harte welkom. Gebruik hiervoor het commentaar veld onder aan elke pagina.
 

docs/informatie/index.md

@@ -31,7 +31,7 @@ Om gegevens technisch uit te wisselen, hebben we standaarden nodig die de **stru
 
 === "openEHR"
 
-    openEHR is vooral gericht op het langdurig en zeer gedetailleerd vastleggen van medische dossiers, onafhankelijk van leveranciers. Ook openEHR werkt met het concept van informatiebouwstenen, maar doet dit om een meer geavanceerde manier dan FHIR of OMOP. Zo worden niet alleen elementaire bouwstenen gedefinieert, maar kunnen samengestelde medische concepten worden gedefineerd met zogenaamde archetypen. Qua syntactische interoperabiliteit richt openEHR zich vooral op de structuur voor **opslag**. Waar FHIR zich richt op het *versturen* van de brief, richt openEHR zich op hoe je het dossier in de kast *archiveert* zodat het over 20 jaar nog steeds leesbaar is.
+    openEHR is vooral gericht op het langdurig en zeer gedetailleerd vastleggen van medische dossiers, onafhankelijk van leveranciers. Ook openEHR werkt met het concept van informatiebouwstenen, maar doet dit om een meer geavanceerde manier dan FHIR of OMOP. Zo worden niet alleen elementaire bouwstenen gedefinieerd, maar kunnen samengestelde medische concepten worden gedefineerd met zogenaamde archetypen. Qua syntactische interoperabiliteit richt openEHR zich vooral op de structuur voor **opslag**. Waar FHIR zich richt op het *versturen* van de brief, richt openEHR zich op hoe je het dossier in de kast *archiveert* zodat het over 20 jaar nog steeds leesbaar is.
 
 === "OMOP"
 

docs/informatie/syntactisch.md

@@ -40,7 +40,7 @@ Implementaties zijn de uitvoeringsmotoren (engines) die de formele specificaties
 
 === "**OMOPonFHIR**"
 
-    Het [OMOPonFHIR](https://github.com/omoponfhir) project levert de softwarecomponenten (servers, adapters) die de bidirectionele FHIR interface realiseren bovenop het OMP CDM. Deze oplossing volgt een facade-patroon: wanneer een client een FHIR `Observation` opvraagt via een REST API, onderschept de facade-laag het verzoek, voert een query uit op de onderliggende OMOP `MEASUREMENT`-tabel in real-time, en transformeert het resultaat naar een FHIR JSON-resource middels de formele specificatie. Middels dit facase patroon kunnen FHIR berichten ook worden opgeslagen in de OMOP database. OMOPonFHIR gaat uit van OMOP CDM 5.4 en FHIR v4 en is geimplementeerd in Java. Het is ontwikkeld voordat de HL7 FHIR-OMOP IG beschikbaar was en heeft daarom de mappings zelf gedefinieerd.
+    Het [OMOPonFHIR](https://github.com/omoponfhir) project levert de softwarecomponenten (servers, adapters) die de bidirectionele FHIR interface realiseren bovenop het OMP CDM. Deze oplossing volgt een facade-patroon: wanneer een client een FHIR `Observation` opvraagt via een REST API, onderschept de facade-laag het verzoek, voert een query uit op de onderliggende OMOP `MEASUREMENT`-tabel in real-time, en transformeert het resultaat naar een FHIR JSON-resource middels de formele specificatie. Middels dit facade patroon kunnen FHIR berichten ook worden opgeslagen in de OMOP database. OMOPonFHIR gaat uit van OMOP CDM 5.4 en FHIR v4 en is geimplementeerd in Java. Het is ontwikkeld voordat de HL7 FHIR-OMOP IG beschikbaar was en heeft daarom de mappings zelf gedefinieerd.
 
 === "**EOS**"