Applicatie componenten voor decentrale verwerking
Applicatiecomponenten van PLUGIN
Het datastation (links) en de federated processing hub (rechts) vormen de twee-eenheid van de PLUGIN/vantage6 architectuur. Hieronder wordt de functie van elke component in meer detail beschreven.
Gedetailleerde beschrijving applicatiecomponenten PLUGIN
Om communicatie mogelijk te maken tussen de verschillende nodes, slaat de Vantage6 Server informatie op over onder andere de deelnemende organisaties, de beschikbare nodes, en de invoer en resultaten van alle aangemaakte taken in het systeem. Deze informatie wordt opgevraagd door de nodes met behulp van een REST api en websockets, waardoor het niet nodig is binnenkomende poorten te openen op het datastation.
Door middel van authenticatie en authorisatie op basis van aan te wijzen rollen wordt bijgehouden welke acties toegestaan zijn voor o.a. gebruikers en nodes.
De Vantage6 Node voert openstaande taken uit. Hierbij wordt het aangegeven Docker image uit de bibliotheek gehaald en uitgevoerd, en gekoppeld aan een van de vooraf geconfigureerde databronnen. Voor elke taak wordt door middel van configuratie gecontroleerd of het uitvoeren van de Docker image toegestaan is.
Om het algoritme uit te voeren start de node op basis van het binnengehaalde Docker image een Docker container op het datastation. Communicatie vanuit het algoritme verloopt hierbij altijd via de node naar de server.
Voor een maximale flexibiliteit in het soort uit te voeren taak, wordt in Vantage6 gebruik gemaakt van Docker images. 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 (een bibliotheek voor Docker images).
De PLUGIN-analytics applicatie maakt het mogelijk om gefedereerde analysetaken uit te voeren waarop een geaggregeerd antwoord terug komt. Deze applicatie bestaat onder andere uit een verkennerfunctie met daarin het metadata schema en vooropgestelde analyse vragen.
De PLUGIN-ML applicatie stelt de datagebruiker in staat om federatief een AI-model te ontwikkelen. PLUGIN-ML omvat zowel de machine learning algoritmes die uitgevoerd worden bij de PLUGIN-datastations als de aggregatie algoritmes die de modellen samenvoegen tot een generiek model. Via PLUGIN-ML is een datagebruiker in staat om een pipeline op te zetten gebruik makend van veel gebruikte Machine learning algoritmes.
De PLUGIN-Hub applicatie verstuurd veilig data in bulk vanaf de PLUGIN-datastation naar de centrale processing hub. De datagebruiker dient hierbij een ‘permit’ of grondslag te hebben om deze data te mogen ontvangen.
De PLUGIN-Lake applicatie is een federatieve lakehouse implementatie binnen de PLUGIN-datastations. PLUGIN-Lake ontvangt, transformeert en stelt data beschikbaar aan de bovenstaande 3 applicaties. Hierbij is het o.a. mogelijk om ETL-processen in te richten, zoals het transformeren van data in FHIR formaat naar OMOP.
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. Deze oplossing kan gebruikt worden in specifieke gevallen waarin samengestelde data nog steeds gevoelig kan zijn, om het risico op een datalek verder te verkleinen.
PLUGIN en de European Interoperability Reference Architecture (EIRA)
Om te voldoen aan uiteenlopende databehoeften (zoals klassieke rapportages, analyses, delen van data en data science) wordt door gezondheidsinstellingen veelal gebruik gemaakt van een gescheiden data warehouse, een datalake en andere analytische omgevingen. Deze scheiding leidt tot duplicatie van data, extra complexiteit en uitdagingen op het gebied van data governance. De aanpak van PLUGIN, en meer specifiek het onderdeel PLUGIN-Lake, zet in op een lakehouse architectuur om deze pijnpunten te addresseren. Een lakehouse architectuur kan een oplossing bieden voor deze problematiek door de functionaliteiten van de verschillende omgevingen samen te voegen. Alle data wordt opgeslagen in een flexibel en schaalbaar platform. Er is slechts één opslaglaag op basis van open standaarden, waarbij zowel ongestructureerde als gestructureerde data kan worden opgeslagen, zoals beschreven in hoofdstuk 5.
Deze aanpak en architectuur van PLUGIN is in lijn met de principes van de European Interoperability Reference Architecture (EIRA). EIRA biedt een raamwerk om interoperabele architecturen te ontwerpen door herbruikbare Architectural Building Blocks (ABBs) te identificeren. We hebben de architectuur van PLUGIN vertaald naar de terminologie en concepten van EIRA, met de intentie om bij te dragen aan verdere standaardisatie en het verbeteren van interoperabiliteit. De mapping tussen de belangrijkste componenten van PLUGIN en EIRA AAB is hieronder weergegeven. Daaruit blijk dat de EIRA in feite alle essentiele componenten voor het realiseren van een lakehouse architectuur, en dus PLUGIN-Lake, heeft opgenomen in de referentie architectuur.e belangrijkste componenten, beschouwd als ABBs, zijn hieronder weergegeven.
PLUGIN in termen van EIRA architectural building blocks
Fungeert als een intermediair voor communicatie, beheert metadata van taken en orkestreert de interacties. Dit kan worden gezien als een combinatie van EIRA ABBs gerelateerd aan Message Exchange, Service Registry en Process Control.
De component binnen de jurisdictie van de datahouder (bv. een ziekenhuis). Het voorziet in de rekenkracht voor de lokale analyse en waarborgt dat data de eigen omgeving niet verlaat. Dit komt overeen met EIRA ABBs voor Secure Data Processing en Service Consumption.
Een gespecialiseerde node die verantwoordelijk is voor het veilig aggregeren van de lokale resultaten. Dit is een specifieke invulling van een Data Processing en Security ABB.
Het "treintje" dat de analyse definieert. Het is een zelfstandige, uitvoerbare component die de logica, het model en de API bevat. Dit sluit aan bij het idee van een Business Logic Component of Application Service in EIRA.
De infrastructuur die veilige data-uitwisseling (van geaggregeerde resultaten, niet brongegevens) mogelijk maakt. Dit valt onder EIRA ABBs zoals Secure Communication en Network Infrastructure.