Ja. Een ziekenhuis kan AI-ondersteunde diagnostiek bovenop bestaande ZIS/EPD-, PACS- en RIS-systemen invoeren zonder deze eerst te vervangen, mits de benodigde gegevens en context via stabiele, gedocumenteerde extractie-interfaces betrouwbaar beschikbaar zijn. Ontbreekt die toegang, blijven uitzonderingen onzichtbaar of kan de bestaande kern de workflow niet dragen, dan komt kernvervanging nadrukkelijker in beeld.
Kort samengevat: AI-diagnostiek op legacy-systemen
Een API- en workflowlaag kan gerichte AI-vernieuwing mogelijk maken zonder directe vervanging van de kern, maar verplaatst de technische en organisatorische afhankelijkheden niet automatisch. Met retrofit wordt hier zowel een uitlezende, read-only uitbreiding als een uitbreiding met write-back bedoeld; write-back stelt zwaardere eisen aan de bestaande kern.
- Toets eerst of alle benodigde gegevens, context en toegangsrechten daadwerkelijk beschikbaar zijn; een aanwezige koppeling bewijst niet dat de volledige workflow uitvoerbaar is.
- Begin bij voorkeur met een uitlezende route en valideer de gegevensstroom op eigen geanonimiseerde data voordat terugschrijven naar kernsystemen wordt overwogen.
- Organiseer taakvoorbereiding, contextcontrole en verwerking centraal, zodat afzonderlijke subsystemen niet elk eigen koppelingen met AI-toepassingen hoeven te beheren.
- Beoordeel ook afwijkingen zoals time-outs, onvolledige scanseries en AI-indeterminatie: een retrofit is ongeschikt als ontbrekende resultaten geen zichtbare status en vervolgstap krijgen.
- Een tussenlaag maakt afdelingsgerichte innovatie mogelijk, maar laat technische schuld, interfaces en afhankelijkheden van de legacy-kern bestaan.
- Beoordeel de initiële investering samen met de doorlopende kosten voor adapters, monitoring en beheer van de hybride omgeving.
Kan AI-diagnostiek bovenop legacy systemen zonder eerst te vervangen?
Ja, een ziekenhuis kan AI-ondersteunde diagnostiek bovenop bestaande systemen toevoegen zonder die kern direct te vervangen. In dit artikel is een retrofit zo'n toevoeging rond de bestaande kern: de aanvullende laag leest gegevens uit en kan, wanneer de omgeving dat betrouwbaar ondersteunt, resultaten terugschrijven. Dat kan alleen wanneer het ZIS/EPD, PACS en RIS de benodigde gegevens via stabiele, gedocumenteerde extractie-interfaces beschikbaar maken. Ontbreekt die toegang, dan is een extra laag geen oplossing voor een gesloten gegevensstroom.
De vraag is dus niet eerst of een AI-toepassing technisch aantrekkelijk is. De eerste vraag is welke gegevens een workflow nodig heeft, waar die gegevens vandaag staan en langs welke route ze mogen worden uitgelezen. Denk aan HL7 v2-feeds, geautoriseerde SQL-replicatoegang of DICOM C-MOVE- en C-STORE-services. Dit zijn voorbeelden van extractie-interfaces. Zij maken het mogelijk om gegevens uit bestaande kernsystemen beschikbaar te stellen zonder direct de volledige kern te vervangen.
Een retrofit blijft daarmee afhankelijk van de bestaande omgeving. Een PACS kan bijvoorbeeld beelden of bijbehorende informatie via een bruikbare route beschikbaar maken, terwijl een andere bron alleen gegevens bevat die niet op een bruikbare manier zijn te ontsluiten. Ook een interface die op papier bestaat, kan onvoldoende zijn wanneer documentatie ontbreekt, toegang niet stabiel is of de benodigde context niet meekomt. Behandel de aanwezigheid van een koppeling daarom niet als bewijs dat de hele workflow uitvoerbaar is.
Begin read-first. De aanvullende laag leest gegevens uit de bestaande systemen en toont of verwerkt die buiten de kern. Daarmee blijft de eerste toets gericht op de feitelijke beschikbaarheid van gegevens, de volledigheid van de context en de werking van de overdracht. Schrijven naar het EPD of een ander kernsysteem is een afzonderlijke keuze met een zwaardere afhankelijkheid van de bestaande regels en validaties.
Leg vooraf ook een meetlat vast. Bepaal welke gegevens beschikbaar moeten zijn, welke uitzonderingen zichtbaar moeten worden en wanneer de gekozen route voldoende werkt om verder te gaan. Toets die aanname met een Proof of Concept op eigen geanonimiseerde data, vóór een productie-uitrol. Zo wordt duidelijk of de beoogde integratielaag werkelijk past bij de systemen, gegevensstromen, governance en leveranciersafspraken van het ziekenhuis.
Een kernvervanging komt nadrukkelijker in beeld wanneer die basis ontbreekt: wanneer essentiële gegevens niet betrouwbaar zijn uit te lezen, wanneer de benodigde context structureel buiten bereik blijft of wanneer de bestaande kern de gewenste workflow niet kan dragen. De retrofitroute vraagt dus eerst bewijs van gegevensontsluiting.
Waarom een centrale Task Manager losse AI-koppelingen kan beperken
Voor deze integratielaag gaat AI-ondersteunde diagnostiek over de route waarlangs diagnostische context bij een AI-verwerking terechtkomt en weer onderdeel kan worden van de werkstroom. Het gaat hier dus niet om een oordeel over de diagnostische uitkomst, maar om de organisatie van de inferentietaak. IHE AIW-I verdeelt die organisatie over twee rollen: de Task Manager bereidt en routeert de taak, terwijl de Task Performer de inferentie uitvoert.
De Task Manager vormt daarbij het centrale vertrekpunt voor een aanvraag. Deze rol verzamelt de diagnostische context die voor de taak beschikbaar is en brengt die samen met de benodigde invoerparameters. Vóór verzending valideert de Task Manager die parameters. Daardoor is expliciet vastgelegd op welk moment de taak wordt samengesteld en gecontroleerd, voordat de AI-verwerking start. Voor een ziekenhuis dat bestaande EPD-, PACS- of RIS-omgevingen behoudt, maakt dat onderscheid zichtbaar: de systemen die context aanleveren hoeven niet ieder afzonderlijk de volledige taakafhandeling met elke AI-toepassing te organiseren.
Na deze voorbereiding stuurt de Task Manager de inferentietaak asynchroon naar de Task Performer. Het versturen en uitvoeren zijn daarmee afzonderlijke stappen. De centrale rol blijft verantwoordelijk voor het bijeenbrengen en valideren van de taak; de uitvoerende rol verwerkt de inferentie. Die scheiding is relevant wanneer meerdere subsystemen betrokken zijn bij een diagnostische werkstroom. Zij voorkomt dat ieder subsysteem zelf moet bepalen hoe een taak naar elke afzonderlijke AI-toepassing wordt gestuurd.
De waarde van dit patroon zit daarom niet in een extra koppeling op zich, maar in het beperken van een netwerk van directe koppelingen tussen subsystemen. Zonder centrale route kan dezelfde AI-toepassing apart moeten aansluiten op verschillende bronnen en afdelingen. Dan verschilt per koppeling waar context wordt samengesteld, welke invoer wordt gecontroleerd en wie de verwerking aanstuurt. Met een Task Manager liggen deze stappen op één herkenbare plaats in de workflowlaag, terwijl de Task Performer zich richt op de inferentie. Dat geeft besluitvormers een concreet punt om te beoordelen: welke context wordt centraal verzameld, welke parameters worden vóór verzending gevalideerd en welke systemen hoeven daadwerkelijk op de taakstroom aan te sluiten.
Wanneer maakt een onzichtbare uitzonderingsstroom een retrofit onbruikbaar?
Een retrofit wordt pas goed beoordeeld wanneer niet alleen de normale AI-verwerking, maar ook afwijkingen een zichtbare plaats in de diagnostische workflow hebben. Een demonstratie waarin een complete scanserie wordt aangeleverd, de inferentietaak afrondt en een resultaat terugkomt, zegt weinig over de momenten waarop die keten afwijkt. Juist daar kan een koppeling die op papier compatibel lijkt, leiden tot ontbrekende resultaten, navraag tussen afdelingen en een onduidelijke status voor gebruikers.
Neem een time-out na een wijziging in de netwerkroute of segmentatie. De AI-verwerking kan dan niet tijdig terugkomen, terwijl de aanvraag vanuit de bronomgeving wel is verstuurd. Voor alle betrokkenen moet zichtbaar zijn dat de taak niet is afgerond, wie deze opvolgt en welke vervolgstap geldt. Anders raakt de taak uit beeld: er is geen bruikbaar resultaat, maar ook geen duidelijk moment waarop de verwerking als mislukt herkenbaar wordt.
Onvolledige scanseries vragen om dezelfde aandacht. Een inferentietaak kan worden gestart terwijl de benodigde invoer nog niet volledig is. Wanneer de workflow voor die situatie geen herkenbare route bevat, kan een tekortkoming in de invoer pas blijken nadat verwerking is aangevraagd, of buiten het zicht van de dagelijkse werkstroom blijven. Gebruikers moeten dan kunnen vaststellen dat een taak niet verder kan op basis van de beschikbare serie, in plaats van te moeten uitzoeken waarom een verwacht resultaat ontbreekt.
Ook AI-indeterminatie past niet vanzelf in de reguliere stroom. Daarmee wordt bedoeld dat de verwerking technisch is uitgevoerd, maar geen resultaat oplevert dat op de gebruikelijke manier verdergaat. Zonder vooraf bepaalde behandeling blijft de taak tussen twee statussen hangen: afgerond vanuit technisch perspectief, maar zonder duidelijke vervolgstap in de diagnostische workflow. Dat vergroot het risico dat gebruikers en systemen verschillende beelden hebben van wat er met de taak is gebeurd.
De keuze tussen een extra API- en workflowlaag en een bredere verandering van de kern wordt hier praktisch. Kan de gekozen route time-outs, onvolledige series en indeterminatie zichtbaar maken binnen de bestaande processen, of blijft de status van een ontbrekend resultaat afhankelijk van handmatige navraag? Ondersteunt een retrofit alleen de geslaagde route, dan schiet de aansluiting met legacy ziekenhuissoftware juist op deze momenten tekort.
Wat wint een API-tussenlaag en wat blijft bij de legacy-kern liggen?
Een API-tussenlaag verschuift de moderniseringskeuze: het ziekenhuis voegt ruimte toe voor diagnostische AI en afdelingsspecifieke functies, terwijl de bestaande kern in gebruik blijft. Dat is iets anders dan directe core replacement. De tussenlaag kan gegevensuitwisseling en aanvullende applicaties rond de legacy-kern organiseren, maar neemt de beperkingen, afhankelijkheden en technische schuld van die kern niet over.
| Vergelijkpunt | API-tussenlaag rond de legacy-kern | Directe vervanging van de kern |
|---|---|---|
| Waar vindt vernieuwing plaats? | Nieuwe AI-toepassingen en functies voor een specifieke afdeling krijgen een plek buiten de bestaande kern. De kern blijft daarbij onderdeel van de dagelijkse zorgverlening. | De vernieuwing concentreert zich op het systeem dat nu de kernfunctie vervult. AI-diagnostiek wordt daarmee onderdeel van een bredere verandering van het fundament waarop bestaande processen steunen. |
| Wat blijft er technisch bestaan? | De legacy-kern blijft aanwezig, inclusief de opgebouwde technische schuld. Ook wanneer een nieuwe laag gegevens ontsluit of functies toevoegt, blijven beperkingen van oudere componenten en bestaande afhankelijkheden relevant. | De bestaande kern wordt zelf het onderwerp van verandering. Dat verlegt de vraag van uitbreiding rond een bestaand systeem naar de gevolgen van een overgang naar een andere kern. |
| Welke architectuur ontstaat? | Een hybride architectuur: de legacy-kern en de aanvullende integratie- of applicatielaag functioneren naast elkaar. De verbinding ertussen blijft een vast onderdeel van de omgeving. | De architectuur wordt rond een andere kern ingericht. De keuze betreft daardoor niet alleen de aansluiting van AI-diagnostiek, maar ook de manier waarop bredere processen opnieuw worden ondergebracht. |
| Wat betekent dit voor afdelingsspecifieke innovatie? | Een afdeling kan aanvullende diagnostische functies laten aansluiten zonder dat de hele ziekenhuisomgeving tegelijk hoeft te veranderen. Dat biedt ruimte voor een gerichte uitbreiding, mits de benodigde gegevensuitwisseling en verantwoordelijkheden aansluiten op de bestaande systemen. | Afdelingsspecifieke wensen worden beoordeeld binnen een veranderprogramma voor de kern. De ruimte voor innovatie hangt dan samen met de inrichting van die nieuwe kern en de overgang van bestaande processen. |
| Welke compatibiliteitsvraag blijft open? | Een extra laag lost niet vanzelf op hoe resultaten, gegevens en verantwoordelijkheden tussen bestaande systemen blijven bewegen. Het ziekenhuis moet daarom blijven toetsen welke grenzen de legacy-kern stelt aan de aanvullende route. | Vervanging verandert de kern van het landschap, maar neemt niet weg dat omliggende processen, systemen en afhankelijkheden op de nieuwe situatie moeten aansluiten. |
| Waar past een workflowportaal? | Een workflowportaal kan als gebruikerslaag binnen deze route worden ingezet. Het is geen vervanging voor de integratielaag en heft de technische schuld in de legacy-kern niet op. | Ook bij een nieuwe kern kan een portaal naast het kernsysteem bestaan. De aanwezigheid ervan bepaalt op zichzelf niet of kernvervanging nodig is. |
Lagere instapkosten maken de hybride beheerlast niet kleiner
Een retrofit verschuift kosten vooral tussen het begin en de periode daarna. De initiële kapitaalinvestering kan lager uitvallen dan bij directe kernvervanging, terwijl adapters en interfacemonitoring een doorlopende beheer- en onderhoudscomponent vormen. Deze vergelijking beschrijft een kostenstructuur; zij bepaalt niet welke route in iedere situatie goedkoper is.
| Kosten- en beheerpunt | Retrofit bovenop de legacy-kern | Betekenis voor de routekeuze |
|---|---|---|
| Initiële Capex | De kapitaalinvestering aan het begin kan lager zijn, omdat de bestaande kern niet direct wordt vervangen. | Een lagere instap verandert de vraag van een grote vervanging naar een afgebakende toevoeging. Dat zegt nog niets over de totale beheerlast over langere tijd. |
| Adapters | Adapters verbinden de aanvullende laag met bestaande systemen en blijven onderdeel van de hybride architectuur. | Iedere adapter is een blijvende afhankelijkheid van de interfaces, gegevens en veranderingen aan beide kanten van de koppeling. |
| Interfacemonitoring | De koppelingen vragen doorlopende aandacht om te zien of de uitwisseling nog werkt zoals de workflow verwacht. | Monitoring is geen eenmalige opleveractiviteit. Zij hoort bij de operationele kosten van een route die meerdere lagen naast elkaar houdt. |
| Doorlopende Opex | Beheer en onderhoud van adapters en interfacemonitoring vormen een terugkerende operationele component. | Neem deze component mee naast de initiële investering. Anders lijkt een retrofit alleen op het moment van aanschaf licht, terwijl de beheeropgave later pas zichtbaar wordt. |
| Hybride beheerlast | De bestaande kern, de nieuwe laag en de verbinding ertussen blijven samen functioneren. | De keuze gaat daardoor niet alleen over aanschaf. Zij gaat ook over wie het beheer draagt wanneer leveranciers, interfaces of werkprocessen veranderen. |
| Vergelijking met vervanging | Een retrofit legt de nadruk op toevoeging en blijvend beheer van de verbindingen. | Directe vervanging is niet per definitie duurder. De passende route hangt af van de bestaande kern, de benodigde koppelingen en de capaciteit om de gekozen architectuur te beheren. |
Hoe past u de keuze toe op uw AI-voorstel?
Gebruik het voorstel om niet alleen functies te vergelijken, maar ook de vrijheid en beheerlast die de gekozen architectuur meebrengt. Beoordeel de onderstaande punten als één samenhangende afweging: meer ruimte voor eigen selectie en schermen op maat staat tegenover de eenvoud van een suite en de afhankelijkheid die daarmee kan ontstaan.
- Welke AI-toepassing blijft selecteerbaar? Breng in kaart of de route ruimte laat om een AI-toepassing te kiezen die past bij de beoogde workflow. Bij een best-of-breedbenadering is selectievrijheid een expliciet onderdeel van de keuze. Die vrijheid is alleen bruikbaar wanneer de bestaande systemen en de integratielaag de benodigde gegevens en context daadwerkelijk kunnen leveren.
- Welke schermen kunnen op maat worden ingericht? Vraag of gebruikersschermen kunnen aansluiten op de manier waarop afdelingen informatie moeten zien en gebruiken. Op maat gemaakte schermen kunnen binnen een best-of-breedroute onderdeel zijn van de aanvullende laag. Zij lossen echter niet automatisch beperkingen in het ZIS/EPD, PACS of RIS op.
- Wat neemt een alles-in-één softwaresuite over? Een alles-in-één suite kan de operationele beheereenvoud vergroten. De organisatie werkt dan met minder afzonderlijke keuzes rond applicaties en gebruikerslagen. Leg daarbij concreet vast welke onderdelen de suite omvat en welke bestaande systemen of koppelingen daarnaast blijven bestaan.
- Welke leveranciersafhankelijkheid ontstaat? Beheereenvoud kan samengaan met zware leveranciersafhankelijkheid. Beoordeel daarom niet alleen welke functies nu beschikbaar zijn, maar ook welke ruimte overblijft om later een andere AI-toepassing, een ander scherm of een aanvullende koppeling te kiezen. Leveranciersafhankelijkheid is geen losse contractvraag; zij beïnvloedt de dagelijkse beheer- en veranderingsruimte.
- Waar blijft de integratiegrens liggen? Benoem welke gegevens uit de legacy-kern komen, welke stappen in een aanvullende laag plaatsvinden en welke functies binnen een suite blijven. Daarmee wordt zichtbaar of het voorstel een bestaande beperking omzeilt, beheersbaar maakt of slechts naar een andere laag verplaatst.
- Wie draagt het beheer na ingebruikname? Koppel de keuzevrijheid aan eigenaarschap. Bij meerdere toepassingen en schermen op maat ontstaat een andere beheeropgave dan bij een suite. Leg vast welke partij verantwoordelijk is voor de koppelingen, wijzigingen in interfaces en de gevolgen daarvan voor de workflow.
Read-only of write-back: waar zit het verschil in de dagelijkse workflow?
De keuze gaat over waar een AI-resultaat landt. Read-only houdt de aanvullende laag los van het terugschrijven naar het EPD. Write-back brengt het resultaat terug in de bestaande workflow, maar vergroot daarmee de validatieopgave en de gevolgen wanneer de koppeling niet werkt zoals verwacht.
Is read-only een geschikte eerste stap?
Read-only kan een geschikte eerste stap zijn wanneer u eerst wilt beoordelen of gegevens, context en presentatie buiten de kern goed samenwerken. Deze route is sneller en veiliger realiseerbaar dan diepe write-back-integratie, omdat de aanvullende laag geen gegevens terugschrijft in het EPD. Dat betekent niet dat read-only zonder risico is of dat daarmee alle workflowvragen zijn opgelost.
De keerzijde is contextschakeling. Gebruikers kunnen tussen de bestaande werkomgeving en een aparte presentatielaag moeten wisselen. De workflow blijft daardoor verdeeld over meer dan één scherm of toepassing. Beoordeel dus waar het resultaat zichtbaar wordt, welke context daar beschikbaar is en welke handeling daarna nog in de bestaande kern moet plaatsvinden.
Waarom is write-back niet automatisch beter?
Write-back kan de workflow stroomlijnen doordat het resultaat terugkomt in de omgeving waar de dagelijkse registratie plaatsvindt. Die aansluiting is echter niet alleen een vormgevingskeuze. Zij verbindt de aanvullende laag directer met de regels, gegevens en verwerking van het EPD.
Daardoor is zwaardere validatie nodig en zijn de afbreukrisico's groter. Een fout, ontbrekende context of afwijkende verwerking raakt niet alleen de presentatielaag, maar ook de terugschrijfroute. Write-back is daarom niet automatisch de volgende stap na een read-only proef. De route past pas wanneer het ziekenhuis de gegevensstromen, bestaande validaties, uitzonderingen en verantwoordelijkheden rond die terugkoppeling concreet kan beoordelen.
De passende route houdt interoperabiliteit én keuzevrijheid overeind
Interoperabiliteit moet een zichtbaar architectuurkenmerk zijn, geen algemene belofte in een voorstel. Voor modulaire zorg-API's vormt HL7 FHIR een anker voor gegevensuitwisseling. IHE AIW-I beschrijft op zijn beurt rollen voor het orkestreren van AI-workflows, waaronder de Task Manager en Task Performer.[1][2][3]
Die twee onderwerpen beantwoorden verschillende vragen. Een modulaire API-laag gaat over de manier waarop gegevens en functies kunnen worden ontsloten. Workfloworkestratie gaat over hoe een AI-taak context ontvangt, wordt gevalideerd en naar verwerking wordt gestuurd. Een route die beide onderwerpen expliciet behandelt, maakt duidelijker waar de grenzen tussen kernsystemen, integratielaag en aanvullende toepassingen liggen.
Standaarden ontsluiten gegevens niet automatisch. De bestaande systemen, versies, leveranciersafspraken en interne governance bepalen nog steeds of een interface beschikbaar is en welke context werkelijk kan worden gebruikt. Daarom blijft een API-laag alleen passend wanneer de feitelijke gegevensstroom vooraf is aangetoond. Een workflowportaal verandert die afhankelijkheid niet; het kan hooguit een plek bieden waar gebruikers de uitkomst zien of ermee werken.
Keuzevrijheid verdient dezelfde aandacht als de eerste aansluiting. Een alles-in-één route kan beheer vereenvoudigen, maar leveranciersafhankelijkheid kan de ruimte beperken om later een andere AI-toepassing, gebruikerslaag of koppeling toe te voegen. Een best-of-breedroute houdt meer keuzeruimte, maar vraagt beheer van de verbindingen tussen de afzonderlijke delen.
Daarmee verschuift de besluitvraag van welke route het modernst oogt naar wat aantoonbaar uitwisselbaar blijft. Leg vast welke afhankelijkheden contractueel en operationeel blijven bestaan, wie de verbindingen beheert en hoe afwijkingen zichtbaar blijven wanneer de normale stroom faalt. Zo wordt de routekeuze toetsbaar op de dagelijkse werking van de architectuur.
Leg eerst de procesvraag en meetlat vast
Begin met een gesprek van een half uur over het bestaande proces: waar ontstaat vertraging, welke handelingen kosten onnodig aandacht en welk beslismoment verdient ondersteuning? Shazzoo kan helpen om vooraf één afgebakende use-case en een heldere meetlat vast te leggen. Daarna kan een Proof of Concept op eigen data een passende vervolgstap zijn, zodat de aannames in de dagelijkse context kunnen worden onderzocht voordat hardening, integratie en een gefaseerde uitrol worden besproken.