5. Benodigdheden voor deelname
Om deel te nemen aan het project, moet aan een aantal voorwaarden voldaan worden. Deze bevinden zich op drie vlakken:
Juridisch
Hard- en software
Data
Deze punten worden hieronder nader toegelicht.
5.1. Juridische zaken
Er moeten afspraken gemaakt worden over …
Verwerking van data door DHD/IKNL/EZA
Aan welke use-cases wel/niet wordt meegewerkt
Wat wel/niet mag op de infrastructuur
Er moeten afspraken gemaakt worden tussen …
DHD en het ziekenhuis
IKNL en het ziekenhuis
EZA en het ziekenhuis
Deelnemende ziekenhuizen onderling?
TODO
Een functionaris gegevensbescherming (FG), information security officer (ISO) of jurist zal deze overeenkomsten moeten beoordelen. Nadat de FG, ISO of jurist van uw ziekenhuis zijn of haar goedkeuring heeft verleend zullen de dienstverlenings- en verwerkersovereenkomsten door de Raad van Bestuur moeten worden ondertekend.
—DHD
…
Notitie
In het kader van het project AI-ondersteund-coderen, heeft DHD met de meeste ziekenhuizen al afspraken gemaakt over het het gebruik van een federatieve infrastructuur voor het trainen van het model.
IKNL beheert de Nederlandse Kankerregistratie (NKR). In dit kader hebben data managers van IKNL reeds toegang tot de EPDs in de (meeste) Nederlandse ziekenhuizen en zijn er (verwerkers)overeenkomsten afgesloten waarin is vastgelegd hoe/welke informatie geregistreerd kan worden in de NKR. Er zal onderzocht moeten worden in hoeverre aanvullende afspraken nodig zijn.
5.2. Installatie hard- en software
Voor de vantage6 node software, is een server nodig die (bij voorkeur) continue aanstaat. Dit mag ook een virtual machine zijn. De belangrijkste voorwaarden zijn dat de machine …
5.2.1. Server/virtual machine
De specificaties voor de server (virtual machine) zijn (bij voorkeur) als volgt:
x86/x64 CPU, ≥ Intel Core i5 8400 Coffee lake, ≥ 4 cores
virtualization enabled
≥ 16 GB RAM
≥ 256 GB SSD
GPU: afhankelijk van algoritme/deelprojecten
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. Voor AI-ondersteund-coderen geldt dat trainingsziekenhuizen deze wél nodig hebben, en ziekenhuizen die het model alleen gebruiken, niet.
5.2.2. Network
≥ 100Mbit ethernet
Port 443/TCP (https) open voor uitgaand verkeer naar …
[websites nodig voor installatie/upgrade Python3, Docker, etc.]
5.2.3. Software
Installatie van de vantage6 node software staat beschreven in de sectie Installatie vantage6.
5.3. 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. Hiervoor zijn op twee vlakken keuzes noodzakelijk:
Op inhoudelijk vlak: hoe medische gegevens gestructureerd, gecodeerd, en geïnterpreteerd dienen te worden.
Op technisch vlak: de wijze van aanlevering en/of het verschaffen van toegang. Bijvoorbeeld, of de data wordt ontsloten via een relationele database, FHIR-server, of via blob storage.
5.3.1. Het inhoudelijk vlak
Op inhoudelijk vlak is gekozen om gebruik te maken van HL7 FHIR. FHIR beschrijft een datamodel dat is opgedeeld in modulaire componenten genaamd.
Op basis van eerdere ervaringen, is de verwachting dat begonnen zal worden met de volgende resources:
Resource |
Omschrijving |
|---|---|
Patient |
|
Bezoeken aan het ziekenhuis: (poli)klinish, dagopnames, etc. |
|
DBCs |
|
Diagnoses (gecodeerd middels ICD-10) |
|
Labuitslagen (gecodeerd middels LOINC?) |
|
Vragenlijsten |
|
Antwoorden op vragenlijsten. Bevatten mogelijk vrije tekst. |
|
Klinische brieven (zie FHIR Documents) |
Aangezien deze standaard relatief flexibel is opgezet, zullen op een aantal punten nog keuzes gemaakt moeten worden. Bijvoorbeeld welke attributen verplicht zijn, welke terminologiestelsels gebruikt zullen worden, of hoe omgegaan wordt met overplaatsingen (tussen (verpleeg)afdelingen binnen het ziekenhuis) tijdens een bezoek. Een eerste aanzet hiervoor staat beschreven in De informatiestandaard.
Belangrijk
Tijdens het project zal de informatiestandaard, samen met de deelnemende ziekenhuizen, verder worden uitgewerkt.
5.3.2. Het technisch vlak
Op technisch vlak zijn er verschillende manieren om de data te ontsluiten in beeld. Dit zijn:
Via een FHIR-server en de bijbehorende REST API, zoals HAPI of Firely Server. Voor efficiente data-overdracht, zou gebruik gemaakt kunnen worden van de bulk data API en nd-json.
Via een relationele database, zoals SQL Server of PostgreSQL, waarbij de FHIR resources óf tabulair worden opgeslagen (met ieder attribuut van een resource in een aparte kolom) óf als document (in een kolom van type JSON-B).
Via een data lake / blob storage, waarbij de resources als nd-json bestanden worden opgeslagen en worden ontsloten via een (in process) database management systeem (zoals DuckDB).
Ongetwijfeld zijn er nog andere opties mogelijk.
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, én 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.
Belangrijk
Tijdens het project zal, samen met de deelnemende ziekenhuizen, worden onderzocht welke vorm van gegevensopslag/-overdracht het meest geschikt is.