Clinical decision support Medicatiebewaking Protocol in de workflow

Klinische beslisondersteuning software laten maken

Beslisondersteunende software attendeert een zorgverlener op het moment dat het uitmaakt: een interactie tussen twee middelen, de protocolstap die bij dit beeld hoort, een labwaarde die buiten de afgesproken bandbreedte valt, een dossier dat niet compleet is. Het uitgangspunt staat vast en verandert nergens op deze pagina: de zorgverlener stelt de diagnose en neemt de behandelbeslissing, de software brengt op het juiste moment informatie onder de aandacht. Appfront bouwt die attenderende laag op maat, naast of bovenop het systeem waarin het werk al gebeurt.

Gratis adviesgesprek Valt dit onder de MDR?

Wat klinische beslisondersteuning wel en niet is

Klinische beslisondersteuning, in het Engels clinical decision support, is de verzamelnaam voor software die vastgelegde kennis en gegevens uit het dossier bij elkaar brengt en daar op een specifiek moment iets zichtbaars van maakt. In de praktijk vallen de toepassingen in vier groepen. Medicatiebewaking controleert een voorschrift op interacties, dubbelmedicatie, dosering, contra-indicaties en overgevoeligheden. Protocollen en richtlijnen brengen de volgende stap in beeld op het moment dat die stap aan de orde is, in plaats van in een document dat iemand achteraf naslaat. Signalering kijkt naar meetwaarden en combinaties van waarden en meldt wanneer die buiten een afgesproken bandbreedte vallen of te snel bewegen. Dossiercontroles zien dat een verplicht veld leeg is, dat een controle is overgeslagen of dat een uitslag nog niet is beoordeeld.

Wat die vier delen is de vorm: op een vast punt in het werkproces vergelijkt het systeem de gegevens van deze patiënt met een set regels en toont het de uitkomst aan de persoon die op dat moment handelt. Wat ze niet delen is het risico dat eraan hangt, en juist dat verschil bepaalt later zowel het ontwerp als het regelgevend kader.

Het speelt bovendien overal net iets anders. In een ziekenhuis zit de meeste winst in het voorschrijfmoment en in de opvolging van uitslagen. Bij een huisartsenpraktijk gaat het vaker om herhaalmedicatie, controlemomenten die verlopen en het signaleren van patiënten die uit beeld raken. In de langdurige zorg draait het om afspraken die over veel medewerkers en veel diensten heen moeten standhouden, waarbij niet de arts maar de verzorgende degene is die de melding ziet. In de geestelijke gezondheidszorg ligt de nadruk vaker op het bewaken van afgesproken stappen in een traject dan op labwaarden. Die verschillen bepalen wie de gebruiker is, en daarmee hoe een melding eruit moet zien en hoeveel er van iemand gevraagd mag worden op het moment dat hij verschijnt.

Even duidelijk is wat het niet is. Beslisondersteuning stelt geen diagnose, neemt geen behandelbeslissing en vervangt geen professionele afweging. Wij claimen op deze pagina ook geen effect op uitkomsten van zorg: wat een melding oplevert hangt af van de inhoud van de regel, van het moment waarop hij verschijnt en van de zorgverlener die ermee werkt. Een leverancier die u wel zo'n effect belooft, belooft iets dat hij niet in software kan leggen.

Zit u hier goed? Deze pagina gaat over de attenderende laag zelf. Zoekt u een breder zorgsysteem, met dossiervoering, planning, declaratie of een cliëntportaal, dan begint u bij zorgsoftware laten bouwen. Draait uw vraag vooral om aantoonbaar voldoen aan eisen, met vastlegging, autorisaties en audittrails als kern, dan is zorgcompliance software de betere ingang.

De zorgverlener beslist, de software niet

De software stelt geen diagnose en neemt geen behandelbeslissing. Zij laat zien wat bekend is en waarom dat nu opvalt. Het oordeel blijft bij de professional die tekent.

Het moment bepaalt de waarde

Dezelfde melding is bruikbaar tijdens het voorschrijven en nutteloos in een overzicht van volgende week. Beslisondersteuning is daarom vooral een vraag over timing.

Zonder bron geen signaal

Wat het systeem niet actueel uit het dossier kan lezen, kan het ook niet beoordelen. De koppeling is hier geen randvoorwaarde maar het halve product.

Waarom het merendeel van de meldingen wordt weggeklikt

Bijna elk project voor beslisondersteuning loopt vroeg of laat vast op hetzelfde punt: er komen meldingen, en die meldingen worden weggeklikt. Niet uit onwil en niet uit onkunde, maar omdat het gedrag klopt bij wat het systeem laat zien. Een regel die waarschuwt bij elke theoretisch mogelijke interactie waarschuwt vooral in situaties die de voorschrijver allang kent, bewust accepteert en al bewaakt. Wie honderd keer een melding krijgt die niet van toepassing is, leert die melding wegklikken voordat hij hem gelezen heeft. Vanaf dat moment kost de honderdeneerste, die er wel toe doet, precies evenveel aandacht als de rest.

De oorzaak zit zelden in de kennisbron en bijna altijd in het gebrek aan context. Een generieke regel weet dat middel A en middel B samen aandacht vragen. Wat de regel niet weet, is dat deze patiënt die combinatie al maanden gebruikt, dat de indicatie de combinatie verklaart, dat de dosering is aangepast, dat de controle waar de melding om vraagt vorige week is gedaan, of dat een collega dezelfde melding een uur eerder al heeft beoordeeld. Al die gegevens staan in het dossier. Ze staan alleen niet in de regel.

Daar komt bij dat het wegklikken zelf meestal nergens heen gaat. In veel systemen verdwijnt een genegeerde melding zonder spoor, hooguit met een teller erachter. Terwijl juist dat de bruikbaarste informatie in het hele systeem is: elke override is een zorgverlener die vertelt dat de regel hier niet klopt. Wordt die reden vastgelegd, gecategoriseerd en periodiek gelezen, dan heeft u een aanscherpingsplan. Wordt zij dat niet, dan is elke discussie over meldingen een kwestie van meningen.

Ook de inhoud van de melding zelf doet ertoe, en daar wordt vaak overheen gestapt. Een bruikbare melding vertelt in één blik wat er aan de hand is, waarom die conclusie is getrokken en op welke gegevens uit dit dossier zij berust, met de bron van de regel erbij voor wie het wil nazoeken. Daarnaast biedt zij de handelingen aan die logisch volgen, zodat de zorgverlener niet eerst drie schermen verder moet om iets met de informatie te doen. En zij vraagt bij afwijzing om een reden uit een korte, betekenisvolle lijst, niet om een leeg tekstveld dat iedereen overslaat. Een melding die alleen zegt dat er iets is, verschuift het werk naar de gebruiker; een melding die laat zien waarop zij zich baseert, geeft die gebruiker iets om mee te oordelen. Ook hier verandert er niets aan de rolverdeling: de software levert de onderbouwing, de zorgverlener trekt de conclusie.

Van meer meldingen naar minder, maar zwaarder

De uitweg is niet slimmer waarschuwen bij hetzelfde volume, maar minder waarschuwen. Dat vraagt om onderscheid in zwaarte. Een klein deel van de regels rechtvaardigt een onderbreking waar de gebruiker niet omheen kan zonder een reden op te geven. Het overgrote deel hoort passief te zijn: een markering in het scherm, een regel in een overzicht, een kleur bij een waarde, iets wat opvalt zonder het werk stil te leggen. Alles wat niet in een van beide categorieën past, hoort niet in de workflow maar in een periodiek overzicht voor wie het dossier nakijkt, bijvoorbeeld de apotheker of de kwaliteitsfunctionaris.

Daarnaast helpt onderdrukking op basis van het dossier: een melding die al beoordeeld is voor deze patiënt en dit voorschrift komt niet terug zolang er niets verandert, en een melding die op afdelingsniveau structureel wordt afgewezen komt op de herzieningslijst in plaats van in het scherm. Dat is geen technische truc maar een inhoudelijke keuze, en dus een keuze die de vakinhoud maakt en niet de bouwer. Meten hoort erbij: per regel hoe vaak hij afgaat, bij hoeveel verschillende patiënten, hoe vaak hij wordt opgevolgd en met welke reden hij wordt afgewezen. Zonder die cijfers over uw eigen systeem is elke uitspraak over het effect ervan een aanname.

Wat een systeem voor beslisondersteuning moet kunnen

Deze onderdelen hangen samen. Bewaking zonder context levert ruis op, regels zonder beheer verouderen, en vastlegging zonder terugkoppeling maakt van een logbestand een archief dat niemand leest. In alle zes gevallen geldt hetzelfde: de uitkomst is informatie voor de zorgverlener, die zelf beslist wat er gebeurt.

Medicatiebewaking met context

Controle op interacties, dubbelmedicatie, dosering en contra-indicaties, waarbij de bekende gegevens van deze patiënt de melding onderdrukken of juist zwaarder maken.

Protocol op het moment van handelen

De stap uit de richtlijn verschijnt in het scherm waar gewerkt wordt, met ruimte om gemotiveerd af te wijken en met de bron erbij.

Signalering van afwijkende waarden

Bandbreedtes per patiëntgroep, de trend naast de losse meting, en een route naar de persoon die er op dat moment iets mee kan.

Dossiercontrole en volledigheid

Ontbrekende velden, niet-beoordeelde uitslagen en overgeslagen controles, gepresenteerd als werklijst en niet als onderbreking.

Regelbeheer met versies

Elke regel heeft een eigenaar, een herleidbare bron, een ingangsdatum en een historie, zodat achteraf te zien is wat er op enig moment gold.

Vastlegging van wat is getoond

Welke melding, aan wie, op welk moment, wat er is gekozen en met welke reden. Dat is de basis voor verantwoording en voor het aanscherpen van regels.

De koppeling met het bronsysteem bepaalt of het werkt

Beslisondersteuning is inhoudelijk niet het moeilijkste deel van zo'n project. De regels zijn meestal ergens beschreven, in een richtlijn, een formularium of een lokale werkafspraak. Waar het op stukloopt is de vraag of het systeem op het juiste moment over de juiste gegevens beschikt, en of het antwoord terechtkomt in het scherm waar iemand op dat moment kijkt. Dat is een koppelingsvraagstuk, en het bepaalt in de praktijk of u een hulpmiddel bouwt of een tweede scherm dat niemand opent.

Er zijn grofweg drie niveaus. Het eerste is een periodieke export uit het bronsysteem: eenvoudig te realiseren, maar per definitie achteraf, dus alleen bruikbaar voor overzichten en nacontrole. Het tweede is gebeurtenisgestuurd: het bronsysteem stuurt een bericht bij een nieuw voorschrift, een nieuwe uitslag of een opname, en de beslislaag reageert daarop. Dat is bruikbaar voor signalering, maar de zorgverlener moet het antwoord ergens anders zien. Het derde is het enige niveau waarop echte beslisondersteuning ontstaat: het bronsysteem roept op het moment van handelen een dienst aan en toont het antwoord in zijn eigen scherm. Dan bepaalt niet uw applicatie de timing, maar het werkproces.

Technisch loopt dat vaak over berichtenverkeer volgens HL7 versie 2, dat in Nederlandse zorginstellingen nog altijd veel aanwezig is, of over FHIR wanneer het bronsysteem dat aanbiedt. Voor het aanroepen vanuit de workflow bestaat met CDS Hooks een open patroon dat precies daarvoor bedoeld is. Belangrijker dan de keuze is de vraag of uw leverancier dit type koppeling toestaat, welke gegevens beschikbaar zijn en of u iets mag terugschrijven. Een leeskoppeling zonder terugschrijfmogelijkheid betekent dat de beoordeling van een melding buiten het dossier belandt, en daarmee onvindbaar wordt voor de volgende behandelaar.

Twee dingen worden stelselmatig onderschat. Het eerste is codering: zolang allergieën, indicaties of laboratoriumuitslagen als vrije tekst binnenkomen, kan geen enkele regel er betrouwbaar op rekenen. Gecodeerde gegevens, met een gedeelde terminologie zoals SNOMED CT voor klinische begrippen en LOINC voor laboratoriumbepalingen, zijn de voorwaarde en niet de bonus. Het tweede is tijd: een aanroep tijdens het voorschrijven heeft een harde grens waarbinnen het antwoord er moet zijn, anders wacht de gebruiker of verdwijnt de melding ongemerkt. Uitblijven van een antwoord hoort daarom zelf zichtbaar te zijn, want een stille storing in een bewakingsfunctie is gevaarlijker dan een storing die iedereen ziet.

Twee dingen horen daarnaast al bij het koppelingsontwerp thuis in plaats van bij de oplevering. Het eerste is autorisatie: een melding bevat patiëntgegevens, dus wie hem te zien krijgt volgt uit de behandelrelatie en de rol, en niet uit het feit dat iemand toevallig het scherm openheeft. Het tweede is beperking: haal op wat de regel nodig heeft en niet het hele dossier, want elk extra veld dat u kopieert wordt een veld dat u moet beveiligen, bewaren en opruimen. Voor de vastlegging geldt het omgekeerde: van de melding zelf legt u juist ruim vast, namelijk wat er is getoond, aan wie, waarop gebaseerd en wat er is gekozen. Dat is precies de informatie die u nodig heeft bij het nakijken van een incident, en tegelijk de informatie die het aanscherpen van regels mogelijk maakt.

Actuele gegevens, niet een export van vannacht
Een aanroep op het moment van handelen, niet erna
Gecodeerde gegevens in plaats van vrije tekst
Terugschrijven van wat getoond en gekozen is
Een harde tijdslimiet voor het antwoord
Zichtbaar falen: geen antwoord is ook een melding
Afspraken met de leverancier van het bronsysteem

Wie beheert de regels als de richtlijn verandert

Een set regels is geen oplevering maar een levend bestand. Richtlijnen worden herzien, formularia worden aangepast, een middel verdwijnt van de markt, een lokale werkafspraak wordt landelijk of juist andersom. Een systeem dat daar niet op is ingericht, veroudert zonder dat iemand het merkt, en dat is de vervelendste vorm van veroudering: de meldingen blijven komen, ze kloppen alleen niet meer. De vraag wie de regels beheert hoort daarom in het ontwerp thuis en niet in het beheercontract achteraf.

Het eerste ontwerpbesluit is de regels uit de code houden. Staat de inhoud van een regel in de programmatuur, dan vraagt elke wijziging in een richtlijn om een softwarerelease, en wordt een ontwikkelaar de poortwachter van klinische inhoud. Dat is voor beide partijen een ongemakkelijke rol. Werkbaar is een scheiding tussen de motor, die gegevens ophaalt, condities evalueert en het resultaat presenteert, en de inhoud, die in een beheerbare vorm staat waar de vakinhoudelijke eigenaar bij kan. Wat die vorm precies wordt hangt af van wie het beheer voert; een apotheker met tijd en affiniteit kan meer aan dan een commissie die twee keer per jaar samenkomt.

Het tweede besluit is eigenaarschap per regel. Niet per systeem, per regel: een naam, een discipline, een bron waar de regel vandaan komt met de versie erbij, een ingangsdatum en een moment waarop hij opnieuw tegen het licht gaat. Verandert de bron, dan verschijnt elke regel die ernaar verwijst op een lijst. Zonder die verwijzing is elke herziening handwerk waarbij iemand uit het hoofd moet weten welke regels geraakt zijn.

Het derde besluit gaat over invoeren. Een nieuwe of gewijzigde regel hoort eerst mee te draaien zonder zichtbaar te zijn, tegen echte gegevens, zodat vooraf duidelijk is hoe vaak hij zou afgaan en bij welk type patiënt. Een regel die in dat schaduwdraaien tientallen keren per dag vuurt, is niet klaar. Daarnaast hoort van elke wijziging vast te liggen wie hem heeft voorgesteld, wie hem heeft goedgekeurd en vanaf wanneer hij gold. Dat laatste is geen bureaucratie: bij het nakijken van een incident is de enige zinnige vraag welke regelversie op dat moment actief was, en welke informatie de zorgverlener toen dus wel of niet voor zich had. Ook hier verandert de rolverdeling niet: het systeem legt vast wat het heeft getoond, de zorgverlener blijft degene die de beslissing nam.

Tot slot een praktische waarschuwing bij de aanbesteding of de projectbegroting. Zelfgebouwde beslisondersteuning gaat zelden mis in de bouw. Zij gaat mis in het jaar erna, wanneer de persoon die de regels kende iets anders is gaan doen en niemand formeel is aangewezen om ze bij te houden. Beleg dat voordat u begint. Loopt het protocol over meerdere stappen en behandelaars heen, dan raakt dit direct aan de inrichting van zorgpadsoftware; ligt het zwaartepunt bij medicatie, dan bij apotheeksoftware.

HL7 versie 2 FHIR CDS Hooks SNOMED CT LOINC Regelversiebeheer Schaduwdraaien Overridebeheer Audittrail

Medisch hulpmiddel of niet, en wat dat betekent

Dit is het deel waar u een specialist bij nodig heeft, en waar wij daarom uitsluitend beschrijven wat op openbare bronnen van de overheid staat. Software met een medisch doel kan onder de Europese regels voor medische hulpmiddelen vallen. De rijksoverheid vat de voorwaarde zo samen: software is een medisch hulpmiddel als de fabrikant omschrijft dat de software rechtstreeks een medisch apparaat bestuurt, informatie geeft over patiëntenzorg die leidt tot betere beslissingen, of ondersteuning biedt bij de behandeling van de patiënt. Beslisondersteuning zit per definitie dicht bij de laatste twee omschrijvingen. Dat is geen detail aan de zijkant van uw project, het is een ontwerpuitgangspunt.

Het kader is de Europese verordening medische hulpmiddelen, Verordening (EU) 2017/745, kortweg de MDR, die volgens de Inspectie Gezondheidszorg en Jeugd op 26 mei 2021 van toepassing is geworden. De wet kent vier risicoklassen: klasse I als lichtste, daarna IIa, IIb en III als zwaarste. De fabrikant is zelf verantwoordelijk voor een juiste bepaling van die klasse. Voor de inhoud van deze pagina is vooral dit van belang, opnieuw in de bewoording van de rijksoverheid: software die informatie levert over beslissingen voor diagnostische of therapeutische doelen valt bijvoorbeeld in klasse IIa, en wanneer beslissingen op basis van die informatie kunnen leiden tot het slechter worden van iemands gezondheidstoestand, valt de software in de hogere risicoklasse IIb. Voor hogere klassen gelden strengere eisen in de procedure voor CE-markering, en beoordeelt een keuringsinstantie, de notified body, het product en geeft daarvoor wel of niet een MDR-certificaat af. Zie de uitleg van de rijksoverheid en het toezicht van de IGJ.

Voor de bouw betekent dat drie dingen. Er komen eisen aan het product zelf: de MDR stelt in bijlage I onder meer dat software wordt ontwikkeld volgens de laatste stand van de techniek en dat daarbij rekening wordt gehouden met risico's en informatiebeveiliging. Er komen eisen aan het dossier eromheen, waaronder risicoanalyse en klinische evaluatie; de IGJ noemt precies die twee als terugkerende zwakke plekken bij fabrikanten. En er komt toezicht: de IGJ ziet toe op naleving en kan handhaven. Praktisch gevolg voor uw planning: dat dossier bouwt u mee vanaf het begin, want achteraf reconstrueren wat er tijdens de ontwikkeling is afgewogen, is aanzienlijk duurder dan het meteen vastleggen.

Er bestaat een aparte route voor zorgaanbieders die hulpmiddelen in eigen huis maken en gebruiken. De IGJ schrijft in haar interventiebeleid dat de vereisten van de MDR en de IVDR niet gelden wanneer in huis vervaardigde medische hulpmiddelen voldoen aan de vereisten van artikel 5 lid 5 van die verordeningen. Dat is nadrukkelijk geen achterdeur: het artikel stelt voorwaarden, en de route gaat over vervaardigen en gebruiken binnen de eigen instelling. Wilt u erop steunen, laat dan vooraf toetsen of u er werkelijk in past.

Werkt uw beslisondersteuning met een model dat uit gegevens leert in plaats van met vastgelegde regels, dan komt daar het Europese kader voor kunstmatige intelligentie bij. Dat is Verordening (EU) 2024/1689, die volgens de Europese Commissie op 1 augustus 2024 in werking is getreden en op 2 augustus 2026 van toepassing is geworden, met een verlengde overgangstermijn tot 2 augustus 2028 voor risicovolle AI die is ingebouwd in producten die al onder Europese productwetgeving vallen. Meer daarover staat bij AI Act compliance software en op de pagina van de Europese Commissie.

Dit is geen juridisch advies. Of uw software kwalificeert als medisch hulpmiddel en in welke klasse zij valt, hangt af van het doel dat u als fabrikant omschrijft en van de manier waarop de software wordt gebruikt. Stem dat af met een notified body of met een specialist in medische hulpmiddelenregelgeving, voordat u bouwt en niet erna. Wat wij aan tafel toevoegen is de vertaling naar het ontwerp: welk deel van de gewenste functionaliteit het risico opdrijft, en of dat deel er werkelijk in hoeft om het probleem op te lossen.

Zelf bouwen naast het zorgsysteem, of erin

De eerste vraag is niet of u bouwt, maar wat uw huidige leverancier al biedt. Medicatiebewaking in een voorschrijfsysteem is een volwassen product met een onderhouden kennisbank erachter. Dat nabouwen is zelden verstandig, al was het maar omdat u dan ook de kennisbank onderhoudt. Hetzelfde geldt voor standaardcontroles die elke instelling nodig heeft.

Naast het bestaande systeem bouwen wordt interessant in vier situaties. Wanneer de regel specifiek is voor uw organisatie of populatie en geen leverancier hem gaat bouwen. Wanneer u gegevens uit meerdere systemen moet combineren en het bronsysteem die andere bron niet kent. Wanneer u sneller wilt bijstellen dan de releasekalender van uw leverancier toelaat. En wanneer de signalering over de grenzen van organisaties heen loopt, waarbij geen van de betrokken systemen het geheel ziet.

Erin bouwen, dus configureren binnen het bestaande systeem, is beter wanneer dat systeem een bruikbare regelmotor heeft, en zeker wanneer de melding in een scherm moet verschijnen waar u van buitenaf niet bij komt. Dat laatste is vaker doorslaggevend dan de functionele vergelijking. Houd hoe dan ook de reikwijdte klein: hoe beperkter het medische doel dat u omschrijft, hoe lichter het traject dat eruit volgt. Een werklijst voor de apotheker heeft andere gevolgen dan een onderbreking in het voorschrijfscherm, ook als de onderliggende regel identiek is. En in beide gevallen blijft de rolverdeling ongewijzigd: de software attendeert, de zorgverlener stelt de diagnose en neemt de behandelbeslissing.

Omschrijf het beoogde doel voordat u functionaliteit kiest
De fabrikant bepaalt de risicoklasse en draagt daarvoor de verantwoordelijkheid
Een hogere klasse betekent een keuringsinstantie in het traject
Risicoanalyse en klinische evaluatie vanaf het begin meebouwen
In huis vervaardigen kent een eigen route met eigen voorwaarden
Leert het model uit gegevens, dan komt het AI-kader erbij
Laat kwalificatie en klasse toetsen door een specialist

Veelgestelde vragen over klinische beslisondersteuning

Nee. De software stelt geen diagnose en neemt geen behandelbeslissing. Zij brengt op het juiste moment informatie onder de aandacht: een mogelijke interactie, een stap uit een protocol, een waarde buiten de afgesproken bandbreedte of een dossier dat niet compleet is. De zorgverlener beoordeelt die informatie, weegt haar tegen alles wat hij verder van deze patiënt weet en beslist. Het systeem legt vast wat het heeft getoond en wat er is gekozen, zodat achteraf te herleiden is welke informatie beschikbaar was. Wij claimen ook geen effect op uitkomsten van zorg: wat een melding oplevert hangt af van de inhoud van de regel, van het moment waarop hij verschijnt en van de professional die ermee werkt.

Dat kan, en bij beslisondersteuning is die vraag zelden theoretisch. De rijksoverheid omschrijft software als medisch hulpmiddel wanneer de fabrikant aangeeft dat de software rechtstreeks een medisch apparaat bestuurt, informatie geeft over patiëntenzorg die leidt tot betere beslissingen, of ondersteuning biedt bij de behandeling van de patiënt. Het kader is de Europese verordening medische hulpmiddelen, Verordening (EU) 2017/745, sinds 26 mei 2021 van toepassing volgens de IGJ. Er zijn vier risicoklassen en de fabrikant bepaalt zelf welke geldt. Software die informatie levert over beslissingen voor diagnostische of therapeutische doelen valt bijvoorbeeld in klasse IIa, en in de hogere klasse IIb wanneer die beslissingen kunnen leiden tot het slechter worden van iemands gezondheidstoestand. Dit is geen juridisch advies: laat kwalificatie en klasse toetsen door een notified body of een specialist.

Door er minder te maken en ze beter te onderbouwen. Een melding hoort de gegevens uit het dossier mee te wegen die de zorgverlener toch al kent: gebruikt deze patiënt de combinatie al langer, verklaart de indicatie haar, is de gevraagde controle vorige week gedaan, heeft een collega dezelfde melding al beoordeeld. Daarnaast helpt onderscheid in zwaarte: een klein deel van de regels rechtvaardigt een onderbreking, het overgrote deel hoort passief te zijn en de rest hoort thuis in een werklijst voor wie het dossier nakijkt. Meet vervolgens per regel hoe vaak hij afgaat, hoe vaak hij wordt opgevolgd en met welke reden hij wordt afgewezen. Elke afwijzing is een zorgverlener die vertelt dat de regel hier niet klopt.

Dat hangt vooral af van wat uw leverancier toestaat. Er zijn drie niveaus. Een periodieke export is eenvoudig maar altijd achteraf, dus alleen bruikbaar voor overzichten. Gebeurtenisgestuurd berichtenverkeer, vaak volgens HL7 versie 2 of via FHIR, is bijna actueel maar toont het antwoord buiten het scherm waarin gewerkt wordt. Alleen bij het derde niveau ontstaat echte beslisondersteuning: het bronsysteem roept op het moment van handelen een dienst aan en toont het antwoord zelf, een patroon waarvoor met CDS Hooks een open standaard bestaat. Voorwaarden zijn gecodeerde gegevens in plaats van vrije tekst, een harde tijdslimiet voor het antwoord en de mogelijkheid terug te schrijven wat er is getoond en gekozen.

Iemand met naam en toenaam, aangewezen voordat het systeem live gaat. Praktisch betekent dat: de inhoud van de regels staat niet in de programmatuur maar in een beheerbare vorm, elke regel heeft een eigenaar en een herleidbare bron met versie, en verandert die bron dan verschijnt elke regel die ernaar verwijst op een herzieningslijst. Een gewijzigde regel draait eerst mee zonder zichtbaar te zijn, tegen echte gegevens, zodat vooraf duidelijk is hoe vaak hij zou afgaan. Van elke wijziging ligt vast wie hem voorstelde, wie hem goedkeurde en vanaf wanneer hij gold, want bij het nakijken van een incident is de vraag welke regelversie toen actief was. Zelfgebouwde beslisondersteuning gaat zelden mis in de bouw, maar in het jaar erna.

Kijk eerst wat uw huidige leverancier al biedt. Medicatiebewaking in een voorschrijfsysteem is een volwassen product met een onderhouden kennisbank erachter, en dat nabouwen betekent dat u die kennisbank er ook bij neemt. Zelf bouwen naast het bestaande systeem wordt interessant als de regel specifiek is voor uw organisatie of populatie, als u gegevens uit meerdere systemen moet combineren, als u sneller wilt bijstellen dan de releasekalender toelaat, of als de signalering over organisatiegrenzen heen loopt. Configureren binnen het bestaande systeem is beter wanneer dat systeem een bruikbare regelmotor heeft of wanneer de melding moet verschijnen in een scherm waar u van buitenaf niet bij komt. Houd de reikwijdte in beide gevallen klein.

Gerelateerde diensten

Zorgsoftware laten bouwen

Gaat uw vraag verder dan de attenderende laag, met dossiervoering, planning, declaratie of een portaal voor cliënten, dan begint u bij zorgsoftware laten bouwen. Daar staat het bredere plaatje; deze pagina gaat alleen over de beslisondersteuning zelf.

Zorgcompliance software

Draait de vraag om aantoonbaar voldoen aan eisen, met vastlegging, autorisaties, bewaartermijnen en audittrails als kern, dan sluit zorgcompliance software daar beter op aan dan een beslislaag.

Patiënten-intakesoftware

Veel controles beginnen bij wat er tijdens de intake wel of niet is uitgevraagd. Ontbreken daar gegevens, dan kan geen enkele regel erop bouwen. Zie patiënten-intakesoftware.

Begin bij de meldingen die u nu al mist

Vertel ons welke drie signalen u vandaag zou willen hebben, uit welk systeem de gegevens daarvoor komen en wie de regels straks beheert. Uit die drie antwoorden blijkt meestal of dit configuratie is in uw huidige systeem, een aparte laag ernaast, of eerst een gesprek over kwalificatie als medisch hulpmiddel. Bij alle drie geldt hetzelfde vertrekpunt: de software attendeert, de zorgverlener stelt de diagnose en neemt de behandelbeslissing.

Plan een adviesgesprek info@appfront.nl