Merge pull request #36 from Health-RI/translation-and-fl-additions

Translation and fl additions

Author: tim-hendriks

docs/assets/aioc-bestand-flow.png

@@ -42,7 +42,6 @@ In **laag 2** wordt een begin gemaakt met het standaardiseren van de data. Het i
 
 **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.
 
-
 ??? 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/data-stations-als-hoeksteen.md

@@ -23,11 +23,11 @@ Om dit punt te adresseren zou een (inter)nationaal certificeringskader komen waa
 
 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.
 
-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.
+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 geïmplementeerd moeten worden. Dit zou bijvoorbeeld kunnen met een persoonsgebonden credential waarmee de gebruiker toegang krijgt tot de BVO.
 
-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.
+Het autorisatiemechanisme is voor een decentrale BVO complexer: er zal een mechanisme moeten worden geïmplementeerd waarbij het datastation kan verifieren of een bepaald algoritme daadwerkelijk 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.
 
-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.
+Kijkend naar PLUGIN en het onderliggende vantage6 framework zien wij dat een dergelijk _trust_ mechanisme nog niet is geïmplementeerd. Het belangrijkste 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 geïmplementeerd 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.
 
 ## 7.1.4. Specificatie van _data visting_ standaarden
 

docs/discussie/centraal-vs-decentraal.md

@@ -25,6 +25,8 @@ Het datastation (links) en de federated processing hub (rechts) vormen de twee-e
         Voor een maximale flexibiliteit in het soort uit te voeren taak, wordt in Vantage6 gebruik gemaakt van [Docker images](https://docs.docker.com/get-started/docker-concepts/the-basics/what-is-an-image/). Een sjabloon-image bevat vereiste logica zoals het verwerken van inputs en terugsturen van resultaten. Deze kan vervolgens worden uitgebreid met de specifieke logica voor de use-case, zoals bijvoorbeeld een federatieve query of een federated learning algoritme. Het Docker image dat hieruit resulteert wordt opgeslagen in een centrale [Docker registry](https://docs.docker.com/get-started/docker-concepts/the-basics/what-is-a-registry/) (een bibliotheek voor Docker images).
 
 
+Wanneer gesproken wordt over specifieke implementaties wordt vaak de term *Aggregator Node* gebruikt. Hiermee wordt de node bedoeld waar aggregatie van deelresultaten plaats vindt. Hoewel het mogelijk is deze node op een aparte locatie te realiseren, verschilt deze technisch gezien niet van andere Vantage6 nodes. Elke Vantage6 Node is dus in potentie een aggregator node. Uitzondering hierop is de [*Secure Aggregator Node*](https://ai.jmir.org/2025/1/e60847). Deze oplossing wordt niet gebruikt binnen PLUGIN, maar bij specifieke use-cases om datalek problematiek tegen te gaan.
+
 
 ## Federatief leren met PLUGIN/vantage6
 

docs/implementaties/PLUGIN/applicatie.md

@@ -1,8 +1,8 @@
 # PLUGIN Healthcare
 
-Het Platform voor Uitwisseling en Hergebruik van Klinische Data Nederland (PLUGIN) beoogt klinische data in de  Elektronische Patiëntendossiers (EPDs) van Nederlandse ziekenhuizen te ontsluiten op een veilige, schaalbare en duurzame wijze. PLUGIN is van oorsprong een initiatief van [Dutch Hospital Data](https://www.dhd.nl/), [Integraal Kankercentrum Nederland](https://iknl.nl/) en [Expertisecentrum Zorgalgoritmen](https://zorgalgoritmen.nl/) De basis infrastructuur maakt gebruik van [vantage6](https://vantage6.ai/) en maakt het mogelijk medische data decentraal beschikbaar te stellen voor zowel algemene gegevensuitwisseling als federatief leren en analyseren. 
+Het Platform voor Uitwisseling en Hergebruik van Klinische Data Nederland (PLUGIN) beoogt klinische data in de  Elektronische Patiëntendossiers (EPDs) van Nederlandse ziekenhuizen te ontsluiten op een veilige, schaalbare en duurzame wijze. PLUGIN is van oorsprong een initiatief van [Dutch Hospital Data](https://www.dhd.nl/), [Integraal Kankercentrum Nederland](https://iknl.nl/) en [Expertisecentrum Zorgalgoritmen](https://zorgalgoritmen.nl/) De basis infrastructuur maakt gebruik van [vantage6](https://vantage6.ai/) en maakt het mogelijk medische data decentraal beschikbaar te stellen voor zowel algemene gegevensuitwisseling als federatief leren en analyseren.
 
-Met use-cases [AI-ondersteund coderen](https://www.dhd.nl/producten-diensten/registratie-data/ondersteuning-bij-medische-codering/ai-ondersteund-coderen) en [het vullen en verrijken van de NKR](https://www.icthealth.nl/nieuws/veilig-en-efficient-data-delen-dankzij-het-plugin-initiatief) is aangetoond dat de infrastructuur schaalbaar in kan worden gezet voor de drie soorten van gefedereerde gegevensbewerking:
+Met use-cases [AI-ondersteund coderen](https://www.dhd.nl/producten-diensten/registratie-data/ondersteuning-bij-medische-codering/ai-ondersteund-coderen) en [het vullen en verrijken van de NKR](https://www.icthealth.nl/nieuws/veilig-en-efficient-data-delen-dankzij-het-plugin-initiatief) is aangetoond dat de infrastructuur schaalbaar in kan worden gezet voor de drie soorten van gefedereerde gegevensbewerking.
 
 De PLUGIN infrastructuur implementeert verschillende componenten zoals in onderstaand diagram en tabel is weergegeven en worden in de volgende pagina's uitgelegd.
 
@@ -21,7 +21,7 @@ De PLUGIN infrastructuur implementeert verschillende componenten zoals in onders
     | Docker registry | containers die zijn geautoriseerd om decentraal op de datastations uit te voeren |
     | Algorithm store | de metadata over de (algoritme) containers, inclusief ondersteuning van goedkeuringsproces |
     | vantage6 node | decentrale component van processing hub die de lokale berekeningen uitvoert |
-    | algoritme container | tijdelijke lokale kopie van het algoritme dat wordt uitgevoeerd, wordt aangemaakt en verwijderd door de vantage6 node |
+    | algoritme container | tijdelijke lokale kopie van het algoritme dat wordt uitgevoerd, wordt aangemaakt en verwijderd door de vantage6 node |
     | PLUGIN-Lake | Lakehouse voor serverless opslag en ETL transformaties op het datastation |
 
 

docs/implementaties/PLUGIN/architectuur.md

@@ -1,3 +1,28 @@
+# Informatie
+
+## Use Cases
+
+Een vijftal use cases worden in PLUGIN uitgewerkt:
+
+* [AI-ondersteund coderen](https://www.dhd.nl/producten-diensten/registratie-data/ondersteuning-bij-medische-codering/ai-ondersteund-coderen)
+* [het vullen en verrijken van de NKR](https://www.icthealth.nl/nieuws/veilig-en-efficient-data-delen-dankzij-het-plugin-initiatief)
+* Signalering van metastasen op afstand
+* Dashboard voor de Palliatieve Zorg
+* Voorspellen klinische verslechtering, delier, en kwetsbaarheid na ontslag
+
+### AIOC
+
+Medisch codeurs leggen de aandoeningen waaraan patiënten lijden vast in ICD-10 codes. Leidend hierbij zijn de brieven en verslagen die medisch specialisten hebben geschreven over de patiënt, de aandoeningen waaraan de patiënt lijdt en de behandelingen die de patiënt ondergaat. vanaf 2023 is de codering van dagopnamen verplicht. Echter, de kwaliteit en uniformiteit van de diagnoseregistratie van dagopnamen in de LBZ nam al jaren af. Daarnaast neemt het aantal medisch codeurs in ziekenhuizen drastisch af.
+
+Daarom is besloten om een AI-model te ontwikkelen dat automatisch dagopnamen kan voorzien van een ICD-10 codering. Het NLP-model (AI) is ontwikkeld op ongestructureerde data (ontslabrieven, polibrieven, OK-verslagen en PA-verslagen). Het model is momenteel (okt 2023) in staat om 70% van de dagopnamen te voorzien van een automatische codering. Het AI-model heeft aan de hand van honderdduizenden opnamen, ICD-10 coderingen en miljoenen brieven en verslagen verbanden leren leggen tussen de termen die medisch specialisten gebruiken om de aandoeningen van de patiënten te omschrijven en de ICD-10 codes waarmee deze aandoeningen dienen te worden gecodeerd. Het AI-model is nu in staat om een substantieel deel (gemiddeld 65%) van de codering van de dagopnamen van medisch codeurs uit handen te nemen. Hierdoor krijgen medisch codeurs meer ruimte om zich te richten op ingewikkelder codeerwerk, zoals dat van de klinische opnamen.
+
+## Data
+
+Om de interoperabiliteit van data te garanderen (zie Semantische en syntactische interoperabiliteit) voor het trainen en toepassen van modellen binnen PLUGIN, wordt EPD-data gestandaardiseerd naar een landelijk model, uitgedrukt in [FHIR profielen](https://plugin.healthcare/fhir/artifacts.html#plugin-profielen). Vereiste data wordt door middel van extractiescripts en handmatig werk klaar gezet in een uniforme standaard, en in een vaste folderstructuur. De gefedereerde analyses, modellen en vragen kunnen hierdoor uitgaan van vaste terminologie en locaties van data, ongeacht op welke node ze worden uitgevoerd. Dankzij deze standaardisering is data hierna voor meerdere doeleinden bruikbaar.
+
+### Data-extractie
+
+De extractie en standaardisering van EPD-data naar de gewenste FHIR profielen is afhankelijk van de EPD-leverancier. In het geval van Chipsoft Hix is scripting beschikbaar. In het geval van dagopname gerelateerde brongegevens biedt Epic functionaliteit aan voor het exporteren hiervan.Data dient te worden gepseudonimiseerd voordat het beschikbaar wordt gemaakt in het data station. Hiervoor zijn voor zowel EPIC als Chipsoft HiX scripts. In het geval van AIOC worden gegevens beschikbaar gesteld op het niveau van de individuele opname, informatie over zorgactiviteiten en ongestructureerde data. Deze data is afkomstig uit ontslagbrieven, polibrieven, operatieverslagen en de PA-verslagen.
 # Gebruik van informatiemodellen en thesauri in PLUGIN
 
 

docs/implementaties/PLUGIN/index.md

@@ -1,16 +1,23 @@
-### Datastation Hardware
+# Infrastructuur
+
+Onderscheid wordt gemaakt tussen *trainingsziekenhuizen* en *inferentieziekenhuizen*. Bij inferentieziekenhuizen wordt wel gebruik gemaakt van het AI-model, maar hier vindt geen training plaats. Deze ziekenhuizen leveren dus geen data waarmee het model wordt ontwikkeld. In dit geval zijn er lichtere systeemeisen voor het datastation.
+
+Het datastation voor PLUGIN is te realiseren als een standaard Linux server. Dit mag ook een VM zijn. Hierop wordt een Vantage6 Node geinstalleerd, een aantal gebruikersaccounts aangemaakt en een standaard folderstructuur ingesteld. Zowel de Node zelf als de daarop uitgevoerde algoritmen zoals de PLUGIN-ML pipeline worden gedraaid binnen Docker.
+
+## Benodigdheden
+
+### Data Station Hardware
 
 PLUGIN verwacht bij voorkeur de volgende hardware-specificaties:
 
 * ≥ 16 cores, x86/x64 CPU
 * ≥ 56 GB CPU RAM
 * ≥ 360 GB SSD
 * virtualization enabled
-* GPU (optioneel, maar aanbevolen):
+* GPU (voor trainingsziekenhuizen):
     * CUDA compatible NVIDIA kaart
     * 16 GB GPU RAM
 
-
 Specificaties zijn echter sterk afhankelijk van de uit te voeren algoritmen.
 
 ### Netwerk
@@ -24,3 +31,17 @@ Specificaties zijn echter sterk afhankelijk van de uit te voeren algoritmen.
 * Besturingssysteem: Ubuntu 22.04+, Windows 10 of hoger, macOS 13.x of hoger
 * Docker of Docker Desktop
 * Python versie 3.10+
+
+## AIOC Folderstructuur
+
+Een eenduidige folderstructuur wordt aangehouden op de geïnstalleerde server voor de werking van het model. In de configuratie wordt per ziekenhuis aangegeven waar het model naar de data moet zoeken. Hiervoor wordt een standaard folderstructuur aangehouden.
+
+![AIOC bestand flow](../../assets/aioc-bestand-flow.png)
+
+De bestanden aangeleverd door het ziekenhuis komen binnen in een map aanleveringen per aanlevering. De resultaten van het model kunnen vanuit de map epd_output opgehaald worden en ingelezen worden in het EPD.
+
+* **aanleveringen** - In deze map levert het ziekenhuis de aanleverfolders aan
+* **coderingen** - De AIOC applicatie maakt hier een werkmap aan waar onder andere een kopie van de aangeleverde data, checkpoint bestanden en resultaten komen te staan. Dit is vooral een werkmap voor de data scientists.
+* **epd_output** - Hier worden de uiteindelijke resultaten/output bestanden klaargezet. Deze bestanden kunnen direct in het EPD geïmporteerd worden.
+* **latest** - In deze map wordt het laatste outputbestand van de AIOC applicatie geplaatst. Het bestand in deze map kan gebruikt worden om de resultaten te importeren in het EPD.
+* **TRAIN_DATA** - In deze map worden de trainingsdata opgeslagen. Deze map is alleen voor trainingsziekenhuizen en bevat data van meerdere jaren met ICD-10 codering om het model te trainen.

docs/implementaties/PLUGIN/informatie.md

@@ -66,6 +66,36 @@ PLUGIN/vantage6 is van oorsprong opgezet voor het ondersteunen van federatief le
 
     Dit sluit direct aan bij de usecase [Geef antwoord op dataverzoek](../../applicatie/laag-3/data-station.md#415-geef-antwoord-op-dataverzoek).
 
+    ```mermaid
+        sequenceDiagram
+            actor Onderzoeker
+            participant Server
+            participant Aggregator as Aggregator-node
+            participant Registry as Docker Registry
+
+            box "Meerdere worker-nodes"
+                participant Node as Node(s)
+            end
+
+            Onderzoeker->>Server: Taak aanmaken (Server API)
+
+            Aggregator->>Server: Hoofdtaak ophalen
+            Aggregator->>Registry: Docker-image ophalen (hoofdtaak)
+
+            Aggregator->>Server: Subtaken aanmaken
+
+            loop Voor elke subtaak (parallel uitgevoerd)
+                Node->>Server: Subtaak ophalen
+                Node->>Registry: Docker-image ophalen (subtaak)
+                Node->>Server: Resultaat van subtaak opslaan
+            end
+
+            Aggregator->>Server: Subtaakresultaten ophalen
+            Aggregator->>Server: Eindresultaat van hoofdtaak indienen
+
+            Onderzoeker->>Server: Eindresultaat ophalen
+    ```
+
 === "Data pooling (doorleveren van data)"
 
     De infrastructuur kan ook worden gebruikt om data te verzamelen op een centrale locatie, zoals een Processing Hub. Dit wordt "Data Pooling" genoemd. Hierbij is het "algoritme" een selectiequery.

docs/implementaties/PLUGIN/infrastructuur.md

@@ -25,7 +25,7 @@ The following are the standards that have been used or are in the process of bei
 
 **Component** | **Purpose**
 :--|:--
-[DuckDB](https://duckdb.org) | **DuckDB** is an in-memory, embeddable, columnar database management system designed for analytical workloads. It is simple to use becasue it requires no external dependencies and data can be stored in a persistent, single-file database. It offers a flexible extension mechanism that allows defining new data types, file formats and SQL syntax.
+[DuckDB](https://duckdb.org) | **DuckDB** is an in-memory, embeddable, columnar database management system designed for analytical workloads. It is simple to use because it requires no external dependencies and data can be stored in a persistent, single-file database. It offers a flexible extension mechanism that allows defining new data types, file formats and SQL syntax.
 [Polars](https://pola.rs) | **Polars** is an open-source library for data manipulation, known for being one of the fastest data processing solutions on a single machine. It features a well-structured, typed API that is both expressive and easy to use.
 [Kuzu](https://docs.kuzudb.com/) | **Kuzu** is an embedded property graph database that supports the Cypher query language. It is optimized for handling complex join-heavy analytical workloads on very large graphs.
 [LanceDB](https://lancedb.com/) | **LanceDB** is an open-source multimodal lakehouse that can be used as a vector database and memory for large-scale Generative AI and Search applications, and as a data management platform for large-scale AI workflows: model fine-tuning and training, feature engineering and explorative data analytics over petabyte-size Lance datasets.