Onderwerp 4.7 — Klinische beslisondersteuning en klinische informatica

Klinische beslisondersteuning is klinische kennis omgezet in software die op het zorgmoment afgaat, dus haar goed doen — de juiste prikkel bij de juiste persoon op het juiste moment, en geen andere — is een discipline van klinische veiligheid, werkstroom en publiek vertrouwen, geen configuratie achteraf.

Waarom dit ertoe doet in gezondheid en zorg#

Elk recept, elke verwijzing, elke onderzoeksopdracht en elke diagnose in een moderne gezondheidsdienst loopt nu door software die de beslissing kan helpen of hinderen. Een goed ontworpen alarm stopt een dodelijke geneesmiddelinteractie voordat zij de patiënt bereikt; een slecht ontworpen alarm gaat zo vaak af dat clinici leren het weg te klikken zonder het te lezen, en op de dag dat het ertoe doet klikken zij het ook weg. Hetzelfde mechanisme dat schade voorkomt kan haar fabriceren. Daarom is beslisondersteuning geen functie die u aanzet maar een geheel van klinische kennis dat u bestuurt, met dezelfde ernst als een geneesmiddel of hulpmiddel.

De inzet is op drie manieren onderscheidend. Ten eerste werkt beslisondersteuning op schaal en met snelheid: één enkele regelwijziging plant zich onmiddellijk voort naar duizenden clinici en miljoenen contacten, dus een subtiele fout is een systemische. Ten tweede is zij door constructie veiligheidskritisch — een alarm dat een echte waarschuwing onderdrukt, of een calculator die een pediatrische dosis verkeerd afrondt, is een gevaar dat de software introduceerde (zie Onderwerp 1.6 — Klinische veiligheid en risicobeheer). Ten derde vormt zij klinisch gedrag of u dat nu bedoelde of niet: wat het systeem gemakkelijk maakt wordt de standaard en wat het onderbreekt wordt gehaat. Beslisondersteuning is dus een oefening in invloed, en invloed in de gezondheidszorg is nooit neutraal.

Achter de software zit een beroepsgroep. Klinische informatica is de discipline die klinische praktijk, informatie en technologie verbindt, en zij is de reden dat beslisondersteuning kan worden geschreven door mensen die zowel de geneeskunde als de machine begrijpen. Zonder die beroepsgroep — zonder chief clinical information officers, klinischeveiligheidsfunctionarissen en in informatica opgeleide clinici in de kamer — drijft beslisondersteuning naar wat een leverancier standaard uitleverde, door niemand afgesteld, door niemand bezeten en door iedereen vertrouwd tot zij faalt. Beslisondersteuning behandelen als technische instelling in plaats van bestuurd klinisch actief is hoe organisaties eindigen met duizenden regels waarvan niemand zich herinnert ze te hebben geschreven en niemand durft uit te zetten.

Kernbegrippen#

Een klinisch beslisondersteunend systeem (clinical decision support system, CDSS of kortweg CDS) is IT voor de gezondheidszorg die clinici, personeel of patiënten kennis en persoonsspecifieke informatie geeft, intelligent gefilterd en op passende momenten gepresenteerd, om een beslissing te verbeteren. De klassieke taxonomie onderscheidt verscheidene vormen. Alarmen en herinneringen onderbreken om te waarschuwen of aan te zetten — een waarschuwing voor een geneesmiddelinteractie, een herinnering aan een achterstallige vaccinatie. Ordersets bundelen de onderzoeken, geneesmiddelen en instructies die bij een situatie passen zodat de juiste dingen samen worden besteld. Zorgpaden coderen een klinisch zorgpad — een gestandaardiseerde, op bewijs gebaseerde reeks van zorg — in de werkstroom. Documentatiesjablonen structureren wat wordt vastgelegd zodat niets essentieels wordt gemist. Diagnostische ondersteuning suggereert of rangschikt mogelijke diagnoses. En calculators implementeren een medisch algoritme — een doseringsberekening, een risicoscore, een eGFR — zodat de rekenkunde consistent wordt gedaan.

Het ordenende idee voor kwaliteit zijn de “vijf juisten” van beslisondersteuning: de juiste informatie leveren, aan de juiste persoon, in het juiste formaat, via het juiste kanaal, op het juiste moment in de werkstroom. Een regel kan klinisch juist zijn en toch elk van deze falen — accurate informatie gegeven aan de verkeerde rol, als harde stop terwijl een passieve weergave volstond, begraven in een scherm dat niemand leest, minuten nadat de beslissing al was genomen. De meeste mislukkingen van beslisondersteuning zijn geen mislukkingen van medische kennis; het zijn mislukkingen van een of meer van de vijf juisten.

De dominante faalwijze heeft een eigen naam. Alarmmoeheid (alarm fatigue, ook alertmoeheid) is de desensibilisatie die intreedt wanneer clinici zoveel waarschuwingen tegenkomen dat zij ophouden erop te letten en het belangrijke samen met het triviale overrulen. Omdat de meeste alarmen in een typisch systeem worden overruled, is het overrulepercentage een vitaal teken van de gezondheid van beslisondersteuning: een hoog percentage betekent dat het systeem zijn gebruikers leert het te negeren. De remedie is niet meer alarmen maar minder, scherpere, beter gerichte.

Twee begrippen bepalen hoe goed beslisondersteuning landt. Beslisondersteuning leeft in het elektronisch gezondheidsdossier (EHR, in de NHS elektronisch patiëntendossier of EPR genoemd) en vaak binnen computergestuurd invoeren van opdrachten door artsen (CPOE), dus zij slaagt of faalt als deel van een breder sociotechnisch systeem — het op elkaar inwerkende web van mensen, taken, technologie en organisatie. Een regel die de echte werkstroom negeert, hoe deugdelijk haar logica ook is, wordt wrijving om omheen te werken. En de inhoud zelf is een kennisactief: de regels coderen evidence-based medicine en een medische richtlijn, die in de tijd veranderen, dus beslisondersteuning moet worden geschreven, getoetst, versioneerd en uitgefaseerd zoals elk ander geheel van klinische kennis (zie Onderwerp 10.3 — Kennismanagement en documentatie).

Gezondheidsinformatica — en haar klinische subdiscipline, klinische informatica — is het vakgebied dat informatie en technologie in de gezondheidszorg bestudeert en toepast. In het VK professionaliseerde dit via de Faculty of Clinical Informatics en rollen als Chief Clinical Information Officer (CCIO) en Chief Nursing Information Officer (CNIO). Historisch werd veel regellogica uitgedrukt in de Arden-syntaxis, een norm om deelbare medische kennis weer te geven als Medical Logic Modules; tegenwoordig beogen normen als HL7 CDS Hooks en op FHIR gebaseerd Clinical Reasoning beslisondersteuning deelbaar te maken over systemen (zie Onderwerp 4.3 — Interoperabiliteit en datastandaarden). Merk ten slotte de grens van dit onderwerp op: het bezit ondersteuning op basis van regels en kennis en de beroepsgroep van de informatica. Statistische en machine learning-benaderingen — inclusief computerondersteunde diagnose en software als medisch hulpmiddel — worden bestuurd als kunstmatige intelligentie (zie Onderwerp 8.4 — Bestuur van AI en opkomende technologie).

Beste praktijken#

1. Ontwerp naar de vijf juisten en behandel het alarm als laatste redmiddel. Vraag vóór u een regel bouwt welke van de vijf juisten zij dient en of een onderbreking werkelijk het juiste instrument is. Geef de voorkeur aan het veilige pad het gemakkelijke pad te maken — een verstandige standaarddosis, een vooraf ingevulde orderset, een sjabloon dat goede documentatie structureert — boven een waarschuwing die het onveilige achteraf straft. Een onderbrekend alarm is de duurste vorm van beslisondersteuning omdat het de schaarste hulpbron in het gebouw besteedt: klinische aandacht. Bewaar het voor gevaren die ernstig, uitvoerbaar en specifiek genoeg zijn om een drukke clinicus te rechtvaardigen te stoppen.

2. Bestuur de inhoud van beslisondersteuning als klinisch kennisactief met een levenscyclus. Elke regel, orderset en elk sjabloon heeft een benoemde klinische eigenaar nodig, een bewijsgrondslag, een toetsdatum, een versiegeschiedenis en een omschreven route voor uitfasering. Richt een bestuursgroep voor klinische inhoud in — clinici, apothekers, informatici en een klinischeveiligheidsfunctionaris — die autoriseert wat live gaat, het volgens schema toetst en uitfaseert wat door het bewijs is ingehaald. Zonder dit stapelt inhoud zich op: regels vermenigvuldigen, spreken elkaar tegen en overleven de richtlijn waarop zij waren gebouwd, en niemand is zeker genoeg om er een uit te zetten.

3. Meet overrulepercentages en jaag de ruis na. Het nuttigste signaal van de gezondheid van beslisondersteuning is hoe vaak clinici elk alarm overrulen, uitgesplitst naar regel, specialisatie en rol. Een regel die bijna elke keer dat zij afgaat wordt overruled beschermt niemand — zij leert gebruikers het hele systeem te negeren, ook de alarmen die ertoe doen. Toets de ergste overtreders regelmatig en handel: faseer ze uit, vernauw hun triggercriteria, verlaag ze van onderbrekend naar passief of herstel het onderliggende dataprobleem dat ze ten onrechte laat afgaan. Ruis verminderen is evenzeer een veiligheidsactiviteit als een nieuwe regel toevoegen.

4. Laag uw alarmen naar ernst en maak de onderbreking evenredig. Niet elke waarschuwing verdient de wereld stil te zetten. Ontwerp een bewuste hiërarchie — een echte harde stop voor het zeldzame, catastrofale gevaar; een onderbrekende maar overrulebare waarschuwing voor ernstige risico’s; en passieve, niet-blokkerende informatie voor het louter nuttige. Stem de wrijving af op de klinische inzet en eis alleen een reden voor overrulen bij de alarmen die ernstig genoeg zijn voor de extra toetsaanslag. Wanneer alles urgent is, is niets dat, en verdrinkt de werkelijk gevaarlijke waarschuwing in het triviale.

5. Bouw beslisondersteuning in de echte werkstroom in, niet erbovenop. Een regel die klinisch perfect is maar op de verkeerde stap, in het verkeerde scherm, voor de verkeerde rol arriveert wordt omzeild of genegeerd (zie Onderwerp 8.3 — Gedragswetenschap en adoptie). Ontwerp met de clinici die haar zullen gebruiken — observeer de werkelijke taak, breng in kaart waar de beslissing werkelijk wordt genomen en plaats de ondersteuning daar. Test haar vóór go-live in een realistische setting en kijk wat mensen doen, want de kloof tussen de ontworpen en de geleefde werkstroom is waar beslisondersteuning stilletjes faalt.

6. Houd een mens stevig in de lus en behoud klinisch oordeel. Beslisondersteuning adviseert; de clinicus beslist en blijft verantwoordelijk. Ontwerp zo dat overrulen mogelijk en snel is en, waar het ertoe doet, met een reden wordt vastgelegd — zowel om professioneel oordeel te respecteren als om de data te genereren die de regel verbeteren. Wees op uw hoede voor automatiseringsbias, de neiging het voorstel van de machine te veel te vertrouwen: een diagnostische prompt die een clinicus op het verkeerde antwoord verankert kan even schadelijk zijn als geen prompt. Het doel is expertise te vergroten, nooit te deskillen of stilletjes aansprakelijkheid aan te nemen die het systeem nooit was gebouwd te dragen.

7. Run beslisondersteuning onder beheer van klinische veiligheid en de beroepsgroep van de informatica. Behandel elke nieuwe regel en elke wijziging als klinisch veiligheidsdossier onder de NHS-normen DCB0129 (fabrikant) en DCB0160 (inzetter), met een klinischeveiligheidsfunctionaris die de gevarenanalyse goedkeurt (zie Onderwerp 1.6 — Klinische veiligheid en risicobeheer). Geef het werk professioneel eigenaarschap: een CCIO of CNIO verantwoordelijk voor de klinische inhoud, in informatica opgeleide clinici die haar schrijven en een route voor personeel in de frontlinie om een alarm te melden dat fout is, ontbreekt of schadelijk is. Beslisondersteuning zonder benoemde klinische eigenaar is een verweesd veiligheidssysteem dat wacht om te falen.

8. Evalueer effectiviteit aan uitkomsten en wees eerlijk wanneer het niet werkt. Het doel van een regel is een beslissing ten goede te veranderen, dus meet of zij dat doet — voorschrijven dat veiliger werd, een onderzoek dat niet meer te vaak werd besteld, een zorgpad dat patiënten werkelijk voltooiden — niet louter dat het alarm afging (zie Onderwerp 8.6 — Onderzoek en evaluatie in de praktijk). Let op onbedoelde gevolgen: alarmen die werk naar een andere rol verschuiven, omwegen die nieuwe gevaren creëren of “juiste” prompts die tijd toevoegen zonder uitkomsten te veranderen. Waar het bewijs zegt dat een regel wrijving toevoegt zonder voordeel, faseer haar uit. Terughoudendheid — dingen uitzetten — is een volwassen vorm van beslisondersteuning, geen terugtocht.

Vragen om met uw team te bespreken#

1. Welke van onze alarmen beschermen patiënten werkelijk, en welke leren onze clinici alleen “overrule” te klikken? Dit doet ertoe omdat een systeem voor beslisondersteuning slechts zo vertrouwd is als zijn slechtste alarmen: een handvol luidruchtige, bijna nutteloze waarschuwingen leert clinici alles reflexmatig weg te klikken, zodat de dag dat een echt gevaar afgaat het samen met de rest wordt overruled. Haal de echte overrulepercentages per regel en rol erbij en wees eerlijk over wat een overrulepercentage van 95% u vertelt — niet dat clinici onzorgvuldig zijn, maar dat de regel verkeerd is voor de werkstroom. Debatteer de moeilijkere afweging: elk alarm dat u uitfaseert haalt een theoretisch vangnet weg, en iemand zal vragen “wat als het ene geval dat we missen het geval is dat we uitzetten?” Een goed, eerlijk antwoord weerstaat die kadering, erkent dat een genegeerd alarm niemand beschermt en verbindt zich ertoe het bestand actief af te stemmen naar beneden — de luidruchtigste regels uitfaseren, vernauwen of verlagen — in plaats van alleen ooit nieuwe toe te voegen. Het noemt ook wie bevoegd is een regel uit te zetten, want als het antwoord “niemand durft” is, zal het systeem alleen maar luidruchtiger worden.

2. Wie bezit onze inhoud voor beslisondersteuning als klinische kennis — en zouden wij weten of een regel was gebaseerd op een richtlijn die twee jaar geleden veranderde? Regels voor beslisondersteuning coderen klinisch bewijs en richtlijnen die verder gaan, maar in veel organisaties werd de inhoud eenmaal bij go-live door een leverancier geconfigureerd en nooit systematisch herzien. Bespreek of elke regel, orderset en elk sjabloon een benoemde klinische eigenaar, een bewijsgrondslag, een toetsdatum en een versiegeschiedenis heeft, of dat grote delen van het bestand feitelijk zonder eigenaar en ongeaudit zijn. Breng de spanning aan het licht tussen de inspanning van behoorlijk bestuur van inhoud en het tempo waarin richtlijnen veranderen: niemand heeft tijd duizenden regels te toetsen, dus het risico is dat toetsing voor geen enkele gebeurt. Overweeg het concrete falen — een doseringslimiet of interactieregel die achterhaalde richtlijnen weerspiegelt, stilletjes fout over elk contact dat zij raakt. Een goed antwoord richt een vaste bestuursgroep voor klinische inhoud in met echt gezag, een op risico gebaseerd toetsschema dat de inhoud met de meeste schade voorrang geeft en een duidelijke route voor uitfasering, en erkent openhartig waar het eerlijke antwoord nu “we weten niet wanneer dit voor het laatst is gecontroleerd” is.

3. Hoe bouwen en evalueren wij beslisondersteuning zodat zij past bij hoe clinici werkelijk werken — en hoe zouden wij weten of zij dingen erger maakte? Een regel kan medisch onberispelijk zijn en toch falen omdat zij op het verkeerde moment arriveert, de verkeerde rol onderbreekt of werk afschuift op iemand stroomafwaarts die er nooit om vroeg. Bespreek of uw beslisondersteuning is ontworpen met clinici in de frontlinie die de echte werkstroom observeren, of geconfigureerd door mensen die een specificatie lezen en de taak nooit hebben zien uitvoeren. Debatteer wat “succes” betekent: aantallen die afgaan en doorklikpercentages zijn gemakkelijk te verzamelen maar vertellen u vrijwel niets, terwijl veranderde uitkomsten en vermeden schade ertoe doen en veel moeilijker te meten zijn (zie Onderwerp 8.6 — Onderzoek en evaluatie in de praktijk). Breng de onbedoelde gevolgen aan het licht waarvoor u blind kunt zijn — omwegen die nieuwe gevaren creëren, automatiseringsbias die een clinicus op een verkeerde prompt verankert of tijd toegevoegd zonder voordeel. Een goed antwoord behandelt elke significante regel als een wijziging om te evalueren, niet een schakelaar om om te zetten, koppelt kwantitatieve signalen aan het observeren van echte gebruikers en is bereid te concluderen dat een goedbedoelde regel moet worden verwijderd.

4. Wanneer wij een regel voor beslisondersteuning wijzigen, behandelen wij dat als wijziging van klinische veiligheid met een gevarenanalyse — of als routinematige configuratiewijziging? Eén enkele regelwijziging plant zich onmiddellijk voort naar duizenden clinici en miljoenen contacten, dus het verschil tussen deze twee kaderingen is het verschil tussen een bestuurd klinisch actief en een onbestuurd. Bespreek eerlijk of elke betekenisvolle wijziging nu door een klinisch veiligheidsdossier onder DCB0129 en DCB0160 loopt, met een klinischeveiligheidsfunctionaris die de gevarenanalyse goedkeurt, of dat wijzigingen worden gemaakt in een configuratiescherm door mensen die ze nooit als veiligheidskritisch zien (zie Onderwerp 1.6 — Klinische veiligheid en risicobeheer). Breng de spanning aan het licht: behoorlijke veiligheidsbeoordeling voegt wrijving toe en vertraagt levering, en onder druk is zij het eerste dat wordt overgeslagen voor de “vanzelfsprekende” oplossing. Toch is het gevaarlijke randgeval — de interactie die de aanpassing stilletjes ontmaskert, de doseringslimiet die de “kleine” wijziging stilletjes verwijdert — precies wat de gevarenanalyse bestaat om te vangen. Een goed antwoord noemt wie verantwoordelijk is wanneer een regel schade veroorzaakt, staat erop dat zelfs minder opvallende aanpassingen een evenredige veiligheidsbeoordeling dragen en kan het controlespoor tonen dat dat bewijst, in plaats van na een incident te ontdekken dat niemand heeft vastgelegd waarom de wijziging werd gemaakt.

5. Werkt onze beslisondersteuning voor elke patiëntgroep even goed — of hebben wij bias geïmporteerd die wij niet kunnen zien? Logica voor beslisondersteuning codeert drempels, risicoscores en aannames over trajecten die vaak zijn afgeleid van bepaalde populaties, en een regel die “gemiddeld” deugdelijk is kan systematisch fout zijn voor groepen die ondervertegenwoordigd zijn in het bewijs waarop zij rust. Bespreek waar uw regels variabelen insluiten — voor etniciteit gecorrigeerde berekeningen, grenzen voor leeftijd of geslacht, aannames over wie zich op welke manier presenteert — en of iemand heeft gecontroleerd hoe ze presteren over de mensen die u werkelijk dient. Breng de moeilijkere spanning aan het licht: een klinisch geldige correctie verwijderen kan evenveel schade doen als een vertekende houden, dus dit gaat er niet om elke demografische variabele weg te halen maar om te weten welke op bewijs berusten en welke geërfde gewoonte zijn. Overweeg de plicht tot billijkheid die een nationaal orgaan of opdrachtgever van u zal verwachten, en de vraag naar transparantie of de logica en haar herkomst publieke toetsing zouden doorstaan. Een goed antwoord verbindt zich ertoe regels met grote impact te auditen op gedifferentieerd effect, behandelt herkomst en uitlegbaarheid als eersteklas eisen en is eerlijk dat voor een groot deel van het bestand het huidige antwoord “we hebben er nooit naar gekeken” is.

6. Waar trekken wij de lijn tussen het oordeel van een clinicus ondersteunen en het stilletjes vervangen — en kweken wij automatiseringsbias? Beslisondersteuning is bedoeld om expertise te vergroten, maar een systeem dat het voorstel van de machine de weg van de minste weerstand maakt kan clinici op een verkeerd antwoord verankeren en na verloop van tijd juist het oordeel uithollen dat het veronderstelt dat zij nog hebben. Bespreek of uw ontwerp overrulen werkelijk gemakkelijk en legitiem houdt, of dat wrijving, standaardwaarden en kadering clinici ertoe aanzetten prompts te aanvaarden die zij niet meer toetsen. Debatteer het risico van deskilling openhartig: als assistenten geneeskunde leren via een systeem dat altijd de volgende stap suggereert, wat gebeurt er dan op de dag dat het systeem fout is, of niet beschikbaar? Weeg dit af tegen het even grote gevaar van alarmmoeheid aan het andere uiterste — het doel is gekalibreerd vertrouwen, niet blinde naleving of blinde weerstand. Een goed antwoord behoudt door ontwerp betekenisvolle menselijke verantwoording, let op de verraderlijke tekenen van te veel vertrouwen als bijna universele acceptatie van een diagnostische prompt en is duidelijk dat het systeem adviseert terwijl de clinicus beslist en verantwoordelijk blijft.

In de praktijk: een voorbeeld uit gezondheid en zorg#

Kingsmere NHS Foundation Trust, onderdeel van het Riverdale and Vale Integrated Care System, ging twee jaar geleden live met een nieuw elektronisch patiëntendossier. De klinische inhoud kwam grotendeels uit de standaardbibliotheek van de leverancier, licht gelokaliseerd tijdens een gehaaste implementatie. Dit jaar klagen clinici luid: het systeem is “alleen maar pop-ups”, arts-assistenten beschrijven dat zij waarschuwingen wegklikken zonder te lezen en een apotheker heeft een veiligheidszorg geuit nadat een ernstig interactiealarm in een cluster gevallen werd overruled — omdat het er precies uitzag als de tientallen triviale die elke dienst afgaan.

De CCIO van de trust geeft opdracht tot een toetsing van de beslisondersteuning. Het informaticateam haalt overrulegegevens op en vindt dat een klein aantal regels verantwoordelijk is voor het overgrote deel van de alarmen en dat verscheidene bij bijna elk recept afgaan met een overrulepercentage boven de 90%. Een regel voor dubbele therapie gaat af bij legitieme combinaties; een alarm voor nierfunctiedosering gaat af op verouderde creatinine-uitslagen vanwege een probleem met timing van data, niet een echt gevaar. Ondertussen is het werkelijk gevaarlijke interactiealarm begraven, visueel identiek aan de ruis, zonder verplichting een reden voor overrulen vast te leggen.

Een bestuursgroep voor klinische inhoud wordt opgericht, voorgezeten door de CCIO met een klinischeveiligheidsfunctionaris, apothekers, senior verpleegkundigen en een data-analist. Zij handelen op het bewijs in plaats van meer regels toe te voegen. De regel voor nierfunctiedosering wordt bij de bron hersteld door het probleem met timing van data op te lossen. De regel voor dubbele therapie wordt vernauwd zodat zij niet meer afgaat bij legitieme paren. Een gelaagd schema van ernst wordt ingevoerd: de ernstige interactie wordt een onderscheiden, moeilijker weg te klikken alarm dat een gedocumenteerde reden vereist, terwijl een lange staart waarschuwingen van lage waarde wordt verlaagd naar passieve informatie of helemaal wordt uitgefaseerd. Elke wijziging loopt door een beoordeling van klinische veiligheid onder DCB0160.

Zes maanden later is het totale aantal alarmen sterk gedaald terwijl het overrulepercentage op de resterende alarmen met hoge ernst is gedaald, omdat clinici nu erop vertrouwen dat een waarschuwing die hen stopt iets betekent. De bestuursgroep heeft toetsdata gesteld bij elke overgebleven regel, elk een klinische eigenaar toegewezen en begonnen te evalueren of de ordersets het voorschrijven werkelijk ten goede veranderden. Het werk voegde geen nieuwe dramatische capaciteit toe — het zette vooral dingen uit en stemde dingen naar beneden af — maar zette een eigenaarloze, wantrouwde stapel pop-ups om in een bestuurd, vertrouwd klinisch veiligheidssysteem.

Sectorperspectieven#

Startup#

Een startup in digitale gezondheid die beslisondersteuning inbouwt — een triage-instrument, een risicocalculator, een module voor ondersteuning bij voorschrijven — staat gewoonlijk aan de kant van de fabrikant van de lijn en moet haar regels vanaf het begin behandelen als gereguleerde klinische kennis. Zelfs een “eenvoudige” calculator die actie aanbeveelt kan software als medisch hulpmiddel zijn, wat haar onder MHRA-regelgeving brengt en een klinisch veiligheidsdossier onder DCB0129 vraagt (zie Onderwerp 1.5 — Regelgeving en naleving). De verleiding is slimme logica snel uit te leveren; de discipline is de bewijsgrondslag te documenteren, de inhoud te versioneren en te ontwerpen voor soepel overrulen en menselijk toezicht voordat de eerste clinicus erop vertrouwt. De geloofwaardigheid van een startup bij een NHS-koper rust evenzeer op hoe zij haar klinische inhoud bestuurt en bijwerkt als op de slimheid van het algoritme.

Klein bedrijf#

Een gevestigde kleine aanbieder — een huisartsenpraktijk, een gemeenschapsapotheek, een verzorgingshuis of een kliniek met één vestiging — gebruikt vooral beslisondersteuning ingebouwd in het klinische systeem van een leverancier in plaats van haar te schrijven, maar draagt dezelfde plicht haar veilig te gebruiken en klinisch oordeel in de lus te houden. Met weinig of geen toegewijde capaciteit voor informatica zijn de praktische prioriteiten smal maar echt: weet welke alarmen uw systeem laat afgaan en zet de lokale die ruis zijn geworden uit of stem ze af, houd de inhoud van geneesmiddelen en richtlijnen actueel in plaats van bevroren bij installatie en zorg dat iemand — ook een parttime klinisch leider — de veiligheid van elk lokaal maatwerk bezit. Weersta de verleiding waarschuwingen in het geheel uit te zetten alleen omdat ze irritant zijn, omdat dat een ergernis inruilt tegen een gevaar. Waar de standaardregels van een leverancier duidelijk fout zijn voor uw patiënten, breng het bij de leverancier ter sprake en leg de zorg vast, omdat u op hun bestuur leunt in plaats van een intern. De vragen over billijkheid en herkomst gelden nog steeds, ook als ze beantwoorden betekent betere vragen aan uw leverancier stellen in plaats van zelf code te auditen.

Grote onderneming#

Een groot NHS-ziekenhuis of ziekenhuisgroep erft doorgaans duizenden regels uit de standaardbibliotheek van een EHR-leverancier, en zijn centrale uitdaging is bestuur op schaal in plaats van vanaf nul schrijven. Het realistische doel is een vaste functie voor bestuur van klinische inhoud, betrouwbare analyse van overrulen, een gelaagd alarmschema en de discipline om uit te faseren en af te stemmen in plaats van alleen op te hopen — geen perfect maatwerkregel voor elke situatie. Bouw wijzigingen in beslisondersteuning in klinisch wijzigingsbeheer en het managementsysteem voor klinische veiligheid in, met een CCIO of CNIO verantwoordelijk en in informatica opgeleide clinici die het werk doen (zie Onderwerp 4.6 — Elektronische patiëntendossiers en klinische systemen). Op deze schaal komen de grootste veiligheidswinsten van ruis verminderen en inhoud bezitten, niet van steeds meer alarmen toevoegen.

Overheid#

Een nationaal orgaan — NHS England, de MHRA, NICE — vormt de omgeving voor beslisondersteuning waarin elke aanbieder werkt. Het kan deelbare kennis cureren en op kwaliteit borgen (richtlijnen van NICE, de BNF en medicijndata van dm+d), de normen voor klinische veiligheid DCB0129 en DCB0160 vaststellen en rentmeester zijn van normen voor interoperabiliteit zodat een regel die eenmaal is geschreven kan worden vertrouwd en hergebruikt in plaats van in elk ziekenhuis herbouwd (zie Onderwerp 9.1 — Werken met lokale en nationale overheden). Haar hefboom is goed bestuurde, aan bewijs gekoppelde beslisondersteuning de marktstandaard te maken via normen, inkoopkaders en professionele infrastructuur als de Faculty of Clinical Informatics. De overheid draagt ook de plichten voor billijkheid en transparantie: zorgen dat de logica van beslisondersteuning geen bias tegen bepaalde groepen codeert en dat haar herkomst controleerbaar en openbaar is.

Veelvoorkomende faalpatronen#

• Alarmoverbelasting. Een waarschuwing laten afgaan voor elk denkbaar risico desensibiliseert clinici totdat zij alles overrulen, ook de alarmen die ertoe doen. Laag naar ernst, meet overrulepercentages en snij de ruis agressief weg.
• Inhoud zonder eigenaar en ongetoetst. Regels die eenmaal bij go-live zijn geconfigureerd en nooit herzien driften weg van actuele richtlijnen en coderen stilletjes achterhaald bewijs. Geef elke regel een benoemde eigenaar, een bewijsgrondslag en een toetsdatum.
• Standaardinstellingen van de leverancier niet afgestemd. De kant-en-klare regelbibliotheek van de leverancier uitleveren zonder haar te lokaliseren op uw werkstroom en formularium importeert andermans ruis en aannames. Toets en stem af vóór go-live, niet na klachten.
• Logica zonder werkstroom. Een klinisch juiste regel op de verkeerde stap, het verkeerde scherm of de verkeerde rol wordt wrijving waar clinici omheen werken. Ontwerp en test met gebruikers in de frontlinie in de echte taak.
• Aantallen die afgaan aangezien voor effectiviteit. “Het alarm ging 10.000 keer af” zegt niets over of enige beslissing verbeterde. Evalueer aan veranderde uitkomsten en vermeden schade en let op onbedoelde gevolgen.
• Geen veiligheidsdossier. Een regelwijziging behandelen als routinematige configuratiewijziging in plaats van wijziging van klinische veiligheid slaat de gevarenanalyse over die het gevaarlijke randgeval vangt. Leid elke wijziging door DCB0160.
• Automatiseringsbias en deskilling. De prompt van de machine te veel vertrouwen kan een clinicus op het verkeerde antwoord verankeren of het oordeel uithollen dat het systeem veronderstelt. Behoud betekenisvol menselijk toezicht en ontwerp zodat overrulen gemakkelijk en legitiem is.

Volwassenheidsmodel#

Checklist#

• Elke regel, orderset en elk sjabloon voor beslisondersteuning heeft een benoemde klinische eigenaar, een bewijsgrondslag, een versiegeschiedenis en een toetsdatum.
• Een vaste bestuursgroep voor klinische inhoud autoriseert, toetst en faseert inhoud uit volgens een op risico gebaseerd schema.
• Alarmen zijn gelaagd naar ernst, met onderbreking evenredig aan de klinische inzet en harde stops gereserveerd voor het zeldzame catastrofale gevaar.
• Overrulepercentages worden gemonitord per regel, specialisatie en rol, en de luidruchtigste regels worden actief uitgefaseerd, vernauwd of verlaagd.
• Beslisondersteuning is vóór go-live ontworpen en getest met clinici in de frontlinie in de echte werkstroom.
• Elke nieuwe regel en wijziging loopt door een klinisch veiligheidsdossier onder DCB0129/DCB0160 met goedkeuring van een klinischeveiligheidsfunctionaris.
• Een CCIO, CNIO of gelijkwaardige is verantwoordelijk voor de klinische inhoud, ondersteund door in informatica opgeleide clinici.
• Clinici kunnen met betekenisvol gemak overrulen, en er bestaat een route om een alarm te melden dat fout is, ontbreekt of schadelijk is.
• Effectiviteit wordt geëvalueerd aan veranderde beslissingen en uitkomsten, niet aan aantallen afgaan, met oog voor onbedoelde gevolgen.
• De grens met ondersteuning op basis van AI/ML is expliciet, en elke statistische of lerende component wordt bestuurd onder AI-bestuur (zie Onderwerp 8.4).

Belangrijkste bronnen#

• NHS England / NHS Digital — normen voor klinische veiligheid DCB0129 (fabricage van IT-systemen voor gezondheidszorg) en DCB0160 (inzet van IT-systemen voor gezondheidszorg), en richtlijnen voor klinischeveiligheidsfunctionarissen.
• Faculty of Clinical Informatics — professionele normen en het Core Competency Framework voor beoefenaars van klinische informatica; roldefinities van CCIO en CNIO.
• Osheroff e.a. — Improving Outcomes with Clinical Decision Support: An Implementation Sourcebook (HIMSS) — oorsprong van het kader van de “vijf juisten” voor CDS.
• NICE — bewijs, richtlijnen en het Evidence Standards Framework for Digital Health Technologies; door NICE geaccrediteerde kennis gebruikt als CDS-inhoud.
• HL7 International — normen CDS Hooks en FHIR Clinical Reasoning; de Arden-syntaxis voor deelbare Medical Logic Modules.
• De Topol Review (Preparing the healthcare workforce to deliver the digital future) — personeel en capaciteit in klinische informatica.
• MHRA — richtlijnen over software en kunstmatige intelligentie als medisch hulpmiddel, voor ondersteuning die de regelgevende drempel overschrijdt.

Referenties#

1. Clinical decision support system — Wikipedia — https://en.wikipedia.org/wiki/Clinical_decision_support_system
2. Health informatics — Wikipedia — https://en.wikipedia.org/wiki/Health_informatics
3. Alarm fatigue — Wikipedia — https://en.wikipedia.org/wiki/Alarm_fatigue
4. Computerized physician order entry — Wikipedia — https://en.wikipedia.org/wiki/Computerized_physician_order_entry
5. Clinical pathway — Wikipedia — https://en.wikipedia.org/wiki/Clinical_pathway
6. Medical algorithm — Wikipedia — https://en.wikipedia.org/wiki/Medical_algorithm
7. Medical guideline — Wikipedia — https://en.wikipedia.org/wiki/Medical_guideline
8. Evidence-based medicine — Wikipedia — https://en.wikipedia.org/wiki/Evidence-based_medicine
9. Electronic health record — Wikipedia — https://en.wikipedia.org/wiki/Electronic_health_record
10. Sociotechnical system — Wikipedia — https://en.wikipedia.org/wiki/Sociotechnical_system
11. Arden syntax — Wikipedia — https://en.wikipedia.org/wiki/Arden_syntax
12. Machine learning — Wikipedia — https://en.wikipedia.org/wiki/Machine_learning
13. Computer-aided diagnosis — Wikipedia — https://en.wikipedia.org/wiki/Computer-aided_diagnosis
14. Knowledge management — Wikipedia — https://en.wikipedia.org/wiki/Knowledge_management
15. NHS England — Clinical Risk Management Standards DCB0129 and DCB0160 — NHS England — https://www.england.nhs.uk/long-read/clinical-risk-management-standards/
16. Faculty of Clinical Informatics — Core Competency Framework and professional standards — FCI — https://facultyofclinicalinformatics.org.uk/
17. National Institute for Health and Care Excellence — Evidence Standards Framework for Digital Health Technologies — NICE — https://www.nice.org.uk/about/what-we-do/our-programmes/evidence-standards-framework-for-digital-health-technologies
18. Health Level Seven International — CDS Hooks and FHIR Clinical Reasoning — HL7 — https://cds-hooks.hl7.org/
19. Health Education England — The Topol Review: Preparing the healthcare workforce to deliver the digital future — NHS — https://topol.hee.nhs.uk/
20. Medicines and Healthcare products Regulatory Agency — Software and AI as a Medical Device — GOV.UK — https://www.gov.uk/government/publications/software-and-artificial-intelligence-ai-as-a-medical-device