Update pages PLUGIN

Author: dkapitan

docs/applicatie/laag-5/federatieve-analyse.md

@@ -53,19 +53,19 @@ Federatieve databases systemen worden al geruime tijd gebruikt door organisaties
 
     === "Federated Database Systeem"
 
-    Nagenoeg alle volwassen database systemen ondersteunen federatieve analyse. ZO heeft PostgreSQL, een van de meest gebruikte open source relationele database systemen, de [_foreign data wrapper_ extensie](https://www.postgresql.org/docs/current/postgres-fdw.html) waarmee federatieve queries kunnen worden uitgevoerd over een netwerk van PostgreSQL databases. In het geval van MongoDB, de meest gebruikte open source document database, wordt federated queries ondersteund via [Atlas](https://www.mongodb.com/docs/atlas/data-federation/query/query-federated-database/).
+        Nagenoeg alle volwassen database systemen ondersteunen federatieve analyse. ZO heeft PostgreSQL, een van de meest gebruikte open source relationele database systemen, de [_foreign data wrapper_ extensie](https://www.postgresql.org/docs/current/postgres-fdw.html) waarmee federatieve queries kunnen worden uitgevoerd over een netwerk van PostgreSQL databases. In het geval van MongoDB, de meest gebruikte open source document database, wordt federated queries ondersteund via [Atlas](https://www.mongodb.com/docs/atlas/data-federation/query/query-federated-database/).
 
     === "Multistore system"
 
-    Veel volwassen databaseplatformen bieden functionaliteit om verschillende database formats te queryen via één query-interface. Een voorbeeld hiervan is Microsoft PolyBase, waarmee relationele data, document data en data op cloud storage bevraagd kan worden met T-SQL (de SQL dialect van Microsfot SQL Server).
+        Veel volwassen databaseplatformen bieden functionaliteit om verschillende database formats te queryen via één query-interface. Een voorbeeld hiervan is Microsoft PolyBase, waarmee relationele data, document data en data op cloud storage bevraagd kan worden met T-SQL (de SQL dialect van Microsfot SQL Server).
 
     === "Polyglot systeem"
 
-    Spark SQL was een van de eerste federatieve polyglot systemen. Met deze open source technlogie kunnen verschillende relationele data bevraagd worden met ofwel een SQL interace (Spark SQL) of met een dataframe interface (Spark DataFrames). Sindsdien zijn veel data analyse platformen polyglot geworden. De Python data stack is inmiddels ook volledig polyglot: gebruikers kunnen met open source libraries als DuckDB, polars en Ibis vrijelijk switchen tussen een SQL of een dataframe interface
+        Spark SQL was een van de eerste federatieve polyglot systemen. Met deze open source technlogie kunnen verschillende relationele data bevraagd worden met ofwel een SQL interace (Spark SQL) of met een dataframe interface (Spark DataFrames). Sindsdien zijn veel data analyse platformen polyglot geworden. De Python data stack is inmiddels ook volledig polyglot: gebruikers kunnen met open source libraries als DuckDB, polars en Ibis vrijelijk switchen tussen een SQL of een dataframe interface
 
     === "Polystore systeem"
 
-    TO DO: er zijn nog niet echt polystore systemen die op grote schaal gebruikt worden?!
+        TO DO: er zijn nog niet echt polystore systemen die op grote schaal gebruikt worden?!
 
 De huidige generatie federatieve systemen (zoals BigDAWG, CloudMdsQL en Myria) richt zich op het integreren van relationele data met diverse NoSQL- en bestandsformaten.
 

docs/implementaties/PLUGIN/informatie.md

@@ -1,28 +1,3 @@
-# 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/infrastructuur.md

@@ -4,44 +4,50 @@ Onderscheid wordt gemaakt tussen *trainingsziekenhuizen* en *inferentieziekenhui
 
 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
+## Hard- & software
 
-### Data Station Hardware
+PLUGIN gaat uit van een Linux server als de fysieke machine waarop alle applicatie componenten draaien. Dit mag ook een virtual machine zijn. De belangrijkste voorwaarden zijn dat de machine:
 
-PLUGIN verwacht bij voorkeur de volgende hardware-specificaties:
+* in staat is om [Docker](https://www.docker.com) te draaien.<br>**NB:** Om de PLUGIN infrastructuur te gebruiken is het noodzakelijk om Docker Engine en niet Docker Desktop te installeren. Docker desktop maakt gebruik van een virtuele machine die niet compatibel is met de PLUGIN infrastructuur.
+* toegang heeft tot de data (zie ook [hieronder](#technisch-vlak-target))
 
-* ≥ 16 cores, x86/x64 CPU
-* ≥ 56 GB CPU RAM
-* ≥ 360 GB SSD
+De specificaties van de Linux server zijn als volgt:
+
+* \>= 16 cores, x86/x64 CPU
+* \>= 56 GB CPU RAM
+* \>= 360 GB SSD
 * virtualization enabled
-* GPU (voor trainingsziekenhuizen):
-    * CUDA compatible NVIDIA kaart
-    * 16 GB GPU RAM
+* GPU (optioneel, maar aanbevolen):
+    - [CUDA compatible](https://developer.nvidia.com/cuda-gpus) NVIDIA kaart
+    - 16 GB GPU RAM
 
-Specificaties zijn echter sterk afhankelijk van de uit te voeren algoritmen.
+Indien voor (iets) lagere specificaties van CPU of RAM gekozen wordt, zal het systeem nog steeds werken, maar duren berekeningen mogelijk wat langer. Qua SSD-opslag wordt minder capaciteit afgeraden. Of een **GPU** nodig is, is afhankelijk de use cases waaraan deelgenomen wordt. In het algemeen is het zo een GPU vereist is als datastation deelnemen in het trainen van algoritmes. Als een ziekenhuis alleen een getraind model wil gebruiken op haar eigen data (_inference_), dan is dat mogelijk zonder GPU.
 
-### Netwerk
+## Netwerk
 
-* ≥ 100Mbit ethernet
-* Poort 443/TCP (https) open voor **uitgaand** verkeer naar de server
-* Een Publiek IP-adres voor whitelisting bij de server
+* \>= 100Mbit ethernet
+* Port 443/TCP (https) open voor _uitgaand_ verkeer naar ...
+    * DHD
+        * vantage6 server: [https://plugin.dhd.nl](https://plugin.dhd.nl)
+        * Docker registry: [https://plugindhd.blob.core.windows.net](https://plugindhd.blob.core.windows.net)
+        * Docker registry (voor updates van vantage6): [https://harbor2.vantage6.ai](https://harbor2.vantage6.ai)
+        * blob storage: [https://plugindhd.azurecr.io](https://plugindhd.azurecr.io)
+    * IKNL
+        * vantage6 server: [https://cotopaxi.vantage6.ai](https://cotopaxi.vantage6.ai)
+        * Docker registry: [https://harbor2.vantage6.ai](https://harbor2.vantage6.ai)
+    * [websites nodig voor installatie/upgrade Python3, Docker, etc.]
 
-### Software
+## Toegang tot data
 
-* Besturingssysteem: Ubuntu 22.04+, Windows 10 of hoger, macOS 13.x of hoger
-* Docker of Docker Desktop
-* Python versie 3.10+
+## Beschikbaar stellen van data
+Om federatieve toepassingen mogelijk te maken, is het belangrijk dat iedere deelnemer zijn/haar klinische data op dezelfde manier aan het platform aanbiedt. Naast eerder genoemde syntactische en semantische interoperabiliteit, is het noodzakelijk op ook technische standaarden af te spreken. Indien bijvoorbeeld wordt gekozen voor FHIR als informatiestandaard, dan kan de technische interface op verschillende manieren worden geimplementeer:
 
-## 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.
+1. Via een FHIR-server en de bijbehorende [REST API](https://hl7.org/fhir/http.html), zoals [HAPI](https://hapifhir.io/hapi-fhir/) of [Firely](https://fire.ly/products/firely-server/) Server. Voor efficiente data-overdracht, zou gebruik gemaakt kunnen worden van de [bulk data API](https://hl7.org/fhir/uv/bulkdata/) en [nd-json](https://hl7.org/fhir/nd-json.html).
+2. Via een relationele database, zoals [SQL Server](https://www.microsoft.com/en-us/sql-server/sql-server-2022) of [PostgreSQL](https://www.postgresql.org), waarbij de FHIR resources ofwerl i) tabulair worden opgeslagen (met ieder attribuut van een resource in een aparte kolom), ofwerl als document (in een kolom van type JSON-B).
+3. Via een data lake / blob storage, waarbij de resources als [nd-json](https://hl7.org/fhir/nd-json.html) bestanden worden opgeslagen en worden ontsloten via een (in process) database management systeem (zoals [DuckDB](https://duckdb.org)).
 
-![AIOC bestand flow](../../assets/aioc-bestand-flow.png)
+Ongetwijfeld zijn er nog andere opties mogelijk.
 
-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.
+De eerste optie heeft als voordeel dat andere applicaties binnen het ziekenhuis gebruik kunnen maken van dezelfde server. Bijvoorbeeld voor Clinical Decision Support. De tweede optie sluit goed aan bij de technology stack die al in veel ziekenhuizen beschikbaar is, en wordt reeds toegepast door het LUMC, ErasmusMC en UMCUtrecht. De derde optie is waarschijnlijk (financieel) het voordeligst, omdat alleen data-opslag nodig is; een database of app server is niet noodzakelijk.
 
-* **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/index.md

@@ -68,10 +68,12 @@ Deze specificatie is opgesteld in opdracht van Health-RI door:
 
 Daarnaast hebben de volgende personen een bijdrage geleverd aan de eerste versie:
 
+- [René Houwen](https://www.linkedin.com/in/renehouwen/) (in opdracht van Zorginstituut Nederland): beschrijving KIK-V implementatie
 - [Maarten Kollenstart](https://www.linkedin.com/in/maarten-kollenstart-a08429146/) (TNO): review algehele architectuur van data spaces, detaillering gebruik DCAT standaard,  _verifiable credentials_
-- [Tim Hendriks](https://www.clinicaldatascience.nl/Staff/tim-hendriks) (Medical Data Works): federated learning, beschrijving PLUGIN/vantage6 implementatie
 - [Madou Derksen](https://www.linkedin.com/in/madou-derksen/) (Dutch Hospital Data): beschrijving PLUGIN/vantage6 implementatie
-- [René Houwen](https://www.linkedin.com/in/renehouwen/) (in opdracht van Zorginstituut Nederland): beschrijving KIK-V implementatie
+- [Yannick Vinkesteijn](https://www.linkedin.com/in/yvinkesteijn/) (Dutch Hospital Data): beschrijving PLUGIN/vantage6 implementatie, met name datastation en infrastructuur
+- [Tim Hendriks](https://www.clinicaldatascience.nl/Staff/tim-hendriks) (Medical Data Works): federated learning, beschrijving PLUGIN/vantage6 implementatie
+
 
 **:material-creative-commons: Dit werk is gelicenseerd onder een [Creative Commons Naamsvermelding 4.0 Internationaal licentie](https://creativecommons.org/licenses/by/4.0/).**