Emne 4.7 — Klinisk beslutningsstøtte og klinisk informatik

Klinisk beslutningsstøtte er klinisk viden omsat til software, der udløses i behandlingsøjeblikket, så det at gøre det rigtigt — det rette puf til den rette person i det rette øjeblik, og ingen andre — er en disciplin inden for klinisk sikkerhed, arbejdsgang og offentlig tillid, ikke en konfigurationseftertanke.

Hvorfor det er vigtigt i sundhed og pleje#

Enhver recept, henvisning, prøvebestilling og diagnose i et moderne sundhedsvæsen passerer nu gennem software, der kan hjælpe eller hæmme beslutningen. En veldesignet alarm stopper en dødelig lægemiddelinteraktion, før den når patienten; en dårligt designet udløses så ofte, at klinikere lærer at klikke den væk uden at læse den, og den dag det betyder noget, afviser de den også. Den samme mekanisme, der forebygger skade, kan fremstille den. Derfor er beslutningsstøtte ikke en funktion, man tænder, men et legeme af klinisk viden, man styrer, med samme alvor, som man bringer til en medicin eller et udstyr.

Indsatsen er særlig på tre måder. For det første opererer beslutningsstøtte i skala og i fart: en enkelt regelændring forplanter sig øjeblikkeligt til tusindvis af klinikere og millioner af møder, så en subtil fejl er en systemisk. For det andet er den sikkerhedskritisk af konstruktion — en alarm, der undertrykker en ægte advarsel, eller en beregner, der afrunder en pædiatrisk dosis forkert, er en fare, softwaren introducerede (se emne 1.6 — Klinisk sikkerhed og risikostyring). For det tredje former den klinisk adfærd, uanset om I havde tilsigtet det: hvad systemet gør let, bliver standarden, og hvad det afbryder, bliver mødt med modvilje. Beslutningsstøtte er derfor en øvelse i indflydelse, og indflydelse i sundhedsvæsenet er aldrig neutral.

Bag softwaren sidder et fag. Klinisk informatik er den disciplin, der forbinder klinisk praksis, information og teknologi, og den er grunden til, at beslutningsstøtte kan forfattes af mennesker, der forstår både medicinen og maskinen. Uden det fag — uden chief clinical information officers, kliniske sikkerhedsansvarlige og informatikuddannede klinikere i rummet — driver beslutningsstøtte mod det, en leverandør leverede som standard, tunet af ingen, ejet af ingen og stolet på af alle, indtil den svigter. At behandle beslutningsstøtte som en teknisk indstilling frem for et styret klinisk aktiv er, hvordan organisationer ender med tusindvis af regler, ingen husker at have skrevet, og ingen tør slukke.

Kernebegreber#

Et klinisk beslutningsstøttesystem (CDSS, eller blot CDS) er sundheds-it, der giver klinikere, personale eller patienter viden og personspecifik information, intelligent filtreret og præsenteret på passende tidspunkter, for at forbedre en beslutning. Den klassiske taksonomi skelner flere former. Alarmer og påmindelser afbryder for at advare eller opfordre — en advarsel om lægemiddelinteraktion, en påmindelse om forfalden vaccination. Ordresæt samler de prøver, lægemidler og instruktioner, der passer til en situation, så de rette ting bestilles sammen. Plejeforløb koder et klinisk forløb — en standardiseret, evidensbaseret rækkefølge af pleje — ind i arbejdsgangen. Dokumentationsskabeloner strukturerer, hvad der registreres, så intet væsentligt overses. Diagnostisk støtte foreslår eller rangordner mulige diagnoser. Og beregnere implementerer en medicinsk algoritme — en dosisberegning, en risikoscore, en eGFR — så regnestykket udføres konsistent.

Den organiserende idé for kvalitet er beslutningsstøttens "fem rigtige": at levere den rigtige information, til den rigtige person, i det rigtige format, gennem den rigtige kanal, på det rigtige tidspunkt i arbejdsgangen. En regel kan være klinisk korrekt og stadig svigte hver eneste af dem — korrekt information givet til den forkerte rolle, som et hårdt stop, når en passiv visning ville række, begravet på en skærm, ingen læser, minutter efter beslutningen allerede var truffet. De fleste svigt i beslutningsstøtte er ikke svigt af medicinsk viden; de er svigt af en eller flere af de fem rigtige.

Det dominerende fejlmønster har sit eget navn. Alarmtræthed (også kaldet alert fatigue) er den afstumpning, der sætter ind, når klinikere møder så mange advarsler, at de holder op med at give dem opmærksomhed og tilsidesætter det vigtige sammen med det trivielle. Fordi de fleste alarmer i et typisk system tilsidesættes, er tilsidesættelsesraten et vitalt tegn på beslutningsstøttens sundhed: en høj betyder, at systemet oplærer sine brugere til at ignorere det. Kuren er ikke flere alarmer, men færre, skarpere, bedre målrettede.

To begreber styrer, hvor godt beslutningsstøtte lander. Beslutningsstøtte lever inde i den elektroniske sundhedsjournal (EHR, i NHS kaldet den elektroniske patientjournal eller EPR) og ofte inde i computerized physician order entry (CPOE), så den lykkes eller fejler som del af et bredere sociotekniske system — det samspillende net af mennesker, opgaver, teknologi og organisation. En regel, der ignorerer den reelle arbejdsgang, uanset hvor sund dens logik er, bliver friktion at arbejde udenom. Og selve indholdet er et vidensaktiv: reglerne koder evidensbaseret medicin og en medicinsk retningslinje, som ændrer sig over tid, så beslutningsstøtte skal forfattes, gennemgås, versioneres og nedlægges som ethvert andet legeme af klinisk viden (se emne 10.3 — Vidensstyring og dokumentation).

Sundhedsinformatik — og dens kliniske underdisciplin, klinisk informatik — er feltet, der studerer og anvender information og teknologi på sundhedspleje. I Storbritannien blev det professionaliseret gennem Faculty of Clinical Informatics og roller som Chief Clinical Information Officer (CCIO) og Chief Nursing Information Officer (CNIO). Historisk blev megen reglogik udtrykt i Arden-syntaksen, en standard til at repræsentere delbar medicinsk viden som Medical Logic Modules; i dag sigter standarder som HL7 CDS Hooks og FHIR-baseret Clinical Reasoning mod at gøre beslutningsstøtte delbar på tværs af systemer (se emne 4.3 — Interoperabilitet og datastandarder). Bemærk endelig dette emnes grænse: det ejer regel- og vidensbaseret støtte og informatikfaget. Statistiske og maskinlæringstilgange — herunder computerstøttet diagnose og software som medicinsk udstyr — styres som kunstig intelligens (se emne 8.4 — Styring af AI og ny teknologi).

Bedste praksis#

1. Design efter de fem rigtige, og behandl alarmen som sidste udvej. Før I bygger en regel, spørg hvilke af de fem rigtige den tjener, og om en afbrydelse virkelig er det rette instrument. Foretræk at gøre den sikre vej til den lette — en fornuftig standarddosis, et forududfyldt ordresæt, en skabelon, der strukturerer god dokumentation — frem for en advarsel, der straffer den usikre bagefter. En afbrydende alarm er den dyreste form for beslutningsstøtte, fordi den bruger den knappeste ressource i bygningen: klinisk opmærksomhed. Forbehold den til farer, der er alvorlige, handlingsbare og specifikke nok til at berettige at stoppe en travl kliniker.

2. Styr beslutningsstøtteindhold som et klinisk vidensaktiv med en livscyklus. Hver regel, hvert ordresæt og hver skabelon har brug for en navngiven klinisk ejer, et evidensgrundlag, en gennemgangsdato, en versionshistorik og en defineret nedlæggelsesvej. Etablér en gruppe for klinisk indholdsstyring — klinikere, farmaceuter, informatikere og en klinisk sikkerhedsansvarlig — der godkender, hvad der går i drift, gennemgår det efter en plan og nedlægger det, evidensen har overhalet. Uden dette akkumuleres indhold: regler formerer sig, modsiger hinanden og overlever den vejledning, de blev bygget på, og ingen er sikre nok til at slukke nogen af dem.

3. Mål tilsidesættelsesrater, og jag støjen. Det mest nyttige enkelte signal om beslutningsstøttens sundhed er, hvor ofte klinikere tilsidesætter hver alarm, opdelt efter regel, speciale og rolle. En regel, der tilsidesættes næsten hver gang, den udløses, beskytter ingen — den oplærer brugere til at ignorere hele systemet, herunder de alarmer, der betyder noget. Gennemgå de værste synderes regelmæssigt og handl: nedlæg dem, indsnævr deres udløsende kriterier, nedgradér dem fra afbrydende til passive, eller ret det underliggende dataproblem, der får dem til at udløses uberettiget. At tune støj ned er lige så meget en sikkerhedsaktivitet som at tilføje en ny regel.

4. Inddel alarmer efter alvor, og gør afbrydelsen forholdsmæssig. Ikke enhver advarsel fortjener at stoppe verden. Design et bevidst hierarki — et ægte hårdt stop til den sjældne, katastrofale fare; en afbrydende, men tilsidesættelig advarsel til alvorlige risici; og passiv, ikke-blokerende information til det blot nyttige. Afstem friktionen efter de kliniske indsatser, og kræv en begrundelse for tilsidesættelse kun for de alarmer, der er alvorlige nok til at berettige det ekstra tastetryk. Når alt er hastende, er intet, og den virkelig farlige advarsel drukner i det trivielle.

5. Byg beslutningsstøtte ind i den reelle arbejdsgang, ikke ovenpå den. En regel, der er klinisk perfekt, men ankommer på det forkerte trin, på den forkerte skærm, for den forkerte rolle, vil blive omgået eller ignoreret (se emne 8.3 — Adfærdsvidenskab og adoption). Design med de klinikere, der skal bruge den — observér den faktiske opgave, kortlæg, hvor beslutningen reelt træffes, og placér støtten dér. Test den i en realistisk setting før idriftsættelse og se, hvad folk gør, fordi kløften mellem den designede arbejdsgang og den levede er der, hvor beslutningsstøtte i det stille svigter.

6. Hold et menneske fast i løkken, og bevar klinisk skøn. Beslutningsstøtte rådgiver; klinikeren beslutter og forbliver ansvarlig. Design, så tilsidesættelse er mulig, hurtig og, hvor det betyder noget, registreret med en begrundelse — både for at respektere fagligt skøn og for at generere de data, der forbedrer reglen. Vogt jer for automatiseringsbias, tilbøjeligheden til at overtro maskinens forslag: en diagnostisk prompt, der forankrer en kliniker på det forkerte svar, kan være lige så skadelig som ingen prompt. Målet er at udvide ekspertise, aldrig at afkvalificere eller i det stille at antage et ansvar, systemet aldrig var bygget til at bære.

7. Kør beslutningsstøtte under klinisk sikkerhedsstyring og informatikfaget. Behandl hver ny regel og hver ændring som et klinisk sikkerhedscase under NHS-standarderne DCB0129 (producent) og DCB0160 (udrulning), med en klinisk sikkerhedsansvarlig, der godkender fareanalysen (se emne 1.6 — Klinisk sikkerhed og risikostyring). Giv arbejdet fagligt ejerskab: en CCIO eller CNIO ansvarlig for det kliniske indhold, informatikuddannede klinikere, der forfatter det, og en vej for frontpersonale til at rapportere en alarm, der er forkert, manglende eller skadelig. Beslutningsstøtte uden en navngiven klinisk ejer er et forældreløst sikkerhedssystem, der venter på at svigte.

8. Evaluér effektiviteten mod udfald, og vær ærlig, når den ikke virker. En regels formål er at ændre en beslutning til det bedre, så mål om den gør det — ordination, der blev sikrere, en prøve, der holdt op med at blive overbestilt, et forløb patienter faktisk gennemførte — ikke blot at alarmen udløstes (se emne 8.6 — Forskning og evaluering i praksis). Hold øje med utilsigtede konsekvenser: alarmer, der flytter arbejde til en anden rolle, omgåelser, der skaber nye farer, eller "korrekte" prompts, der tilføjer tid uden at ændre udfald. Hvor evidensen siger, at en regel tilføjer friktion uden gevinst, nedlæg den. Tilbageholdenhed — at slukke ting — er en moden form for beslutningsstøtte, ikke et tilbagetog fra den.

Spørgsmål at drøfte med dit team#

1. Hvilke af vores alarmer beskytter faktisk patienter, og hvilke oplærer blot vores klinikere til at klikke "tilsidesæt"? Det er vigtigt, fordi et beslutningsstøttesystem kun er så betroet som dets værste alarmer: en håndfuld støjende, næsten ubrugelige advarsler lærer klinikere at afvise alt refleksmæssigt, så den dag en ægte fare udløses, tilsidesættes den sammen med resten. Træk de reelle tilsidesættelsesrater pr. regel og rolle, og vær ærlige om, hvad en tilsidesættelsesrate på 95 % fortæller jer — ikke at klinikere er skødesløse, men at reglen er forkert for arbejdsgangen. Debatter den sværere afvejning: hver alarm, I nedlægger, fjerner et teoretisk sikkerhedsnet, og nogen vil spørge "hvad hvis det ene tilfælde, vi overser, er det, vi slukkede for?" Et godt, ærligt svar modstår den rammesætning, erkender at en ignoreret alarm ikke beskytter nogen, og forpligter sig til aktivt at tune landskabet ned — nedlægge, indsnævre eller nedgradere de mest støjende regler — frem for kun nogensinde at tilføje nye. Det nævner også, hvem der har beføjelse til at slukke en regel, for hvis svaret er "ingen tør", vil systemet kun nogensinde blive mere støjende.

2. Hvem ejer vores beslutningsstøtteindhold som klinisk viden — og ville vi vide, om en regel var baseret på vejledning, der ændrede sig for to år siden? Beslutningsstøtteregler koder klinisk evidens og retningslinjer, der udvikler sig, men i mange organisationer blev indholdet konfigureret én gang ved idriftsættelsen af en leverandør og er aldrig siden systematisk gennemgået. Drøft, om hver regel, hvert ordresæt og hver skabelon har en navngiven klinisk ejer, et evidensgrundlag, en gennemgangsdato og en versionshistorik, eller om store dele af landskabet reelt er ejerløse og urevideret. Bring spændingen frem mellem indsatsen ved ordentlig indholdsstyring og tempoet, hvormed vejledning ændrer sig: ingen har tid til at gennemgå tusindvis af regler, så risikoen er, at gennemgang sker for ingen. Overvej det konkrete svigt — en doseringsgrænse eller interaktionsregel, der afspejler overhalet vejledning, i det stille forkert over hvert møde, den berører. Et godt svar etablerer en stående gruppe for klinisk indholdsstyring med reel beføjelse, en risikobaseret gennemgangsplan, der prioriterer indhold med størst skade, og en klar nedlæggelsesvej, og indrømmer åbent, hvor det ærlige svar i dag er "vi ved ikke, hvornår dette sidst blev tjekket".

3. Hvordan bygger og evaluerer vi beslutningsstøtte, så den passer til, hvordan klinikere faktisk arbejder — og hvordan ville vi vide, om den gjorde tingene værre? En regel kan være medicinsk fejlfri og alligevel fejle, fordi den ankommer på det forkerte tidspunkt, afbryder den forkerte rolle eller skubber arbejde over på en nedstrøms person, der aldrig bad om det. Drøft, om jeres beslutningsstøtte er designet med frontklinikere, der observerer den reelle arbejdsgang, eller konfigureret af mennesker, der læser en specifikation, og aldrig har set opgaven udført. Debatter, hvad "succes" betyder: udløsningstal og klikrater er lette at indsamle, men fortæller næsten intet, mens ændrede udfald og undgået skade er det, der betyder noget, og er langt sværere at måle (se emne 8.6 — Forskning og evaluering i praksis). Bring de utilsigtede konsekvenser frem, I måske er blinde for — omgåelser, der skaber nye farer, automatiseringsbias, der forankrer en kliniker på en forkert prompt, eller tid tilføjet uden gevinst. Et godt svar behandler hver væsentlig regel som en ændring at evaluere, ikke en kontakt at slå om, parrer kvantitative signaler med at se rigtige brugere og er villigt til at konkludere, at en velmenende regel bør fjernes.

4. Når vi ændrer en beslutningsstøtteregel, behandler vi det så som en klinisk sikkerhedsændring med en farenanalyse — eller som en rutinemæssig konfigurationsredigering? En enkelt regelændring forplanter sig øjeblikkeligt til tusindvis af klinikere og millioner af møder, så forskellen mellem disse to rammesætninger er forskellen mellem et styret klinisk aktiv og et ustyret. Drøft ærligt, om hver meningsfuld ændring i dag løber gennem et klinisk sikkerhedscase under DCB0129 og DCB0160, med en klinisk sikkerhedsansvarlig, der godkender fareanalysen, eller om ændringer foretages i en konfigurationsskærm af mennesker, der aldrig ser dem som sikkerhedskritiske (se emne 1.6 — Klinisk sikkerhed og risikostyring). Bring spændingen frem: ordentlig sikkerhedsvurdering tilføjer friktion og bremser levering, og under pres er det det første, der springes over for den "oplagte" rettelse. Alligevel er den farlige kanttilfælde — interaktionen, justeringen i det stille afdækker, doseringsgrænsen den "lille" ændring i det stille fjerner — netop det, fareanalysen findes for at fange. Et godt svar nævner, hvem der er ansvarlig, når en regel forårsager skade, insisterer på at selv små-udseende redigeringer bærer en forholdsmæssig sikkerhedsvurdering og kan vise det revisionsspor, der beviser det, frem for at opdage efter en hændelse, at ingen registrerede, hvorfor ændringen blev foretaget.

5. Virker vores beslutningsstøtte lige godt for hver patientgruppe — eller har vi importeret skævhed, vi ikke kan se? Beslutningsstøttelogik koder tærskler, risikoscorer og forløbsantagelser, der ofte er udledt fra bestemte populationer, og en regel, der er sund "i gennemsnit", kan være systematisk forkert for grupper underrepræsenterede i den evidens, den hviler på. Drøft, hvor jeres regler indlejrer variable — etnicitetsjusterede beregninger, alders- eller kønsgrænser, antagelser om hvem der henvender sig på hvilken måde — og om nogen har tjekket, hvordan de yder på tværs af de mennesker, I faktisk betjener. Bring den sværere spænding frem: at fjerne en klinisk gyldig justering kan skade lige så meget som at beholde en skæv, så det handler ikke om at fjerne hver demografisk variabel, men om at vide, hvilke der er evidensbaserede, og hvilke der er nedarvede vaner. Overvej den ligestillingspligt, et nationalt organ eller en bestiller vil forvente, I opfylder, og gennemsigtighedsspørgsmålet om, hvorvidt logikken og dens proveniens kunne tåle granskning, hvis den blev offentliggjort. Et godt svar forpligter sig til at revidere regler med stor virkning for differentiel effekt, behandler proveniens og forklarlighed som førsteklasses krav og er ærligt om, at for en stor del af landskabet er det nuværende svar "vi har aldrig set efter".

6. Hvor trækker vi linjen mellem at støtte en klinikers skøn og i det stille at erstatte det — og avler vi automatiseringsbias? Beslutningsstøtte er ment til at udvide ekspertise, men et system, der gør maskinens forslag til vejen med mindst modstand, kan forankre klinikere på et forkert svar og med tiden udhule netop det skøn, det forudsætter, de stadig har. Drøft, om jeres design holder tilsidesættelse reelt let og legitim, eller om friktionen, standarderne og rammesætningen nudger klinikere til at acceptere prompts, de er holdt op med at granske. Debatter afkvalificeringsrisikoen ærligt: hvis kandidater lærer medicin gennem et system, der altid foreslår næste skridt, hvad sker der så den dag, systemet tager fejl eller er utilgængeligt? Afvej dette mod den lige så store fare ved alarmtræthed i den anden ende — målet er kalibreret tillid, ikke blanket overholdelse eller blanket modstand. Et godt svar bevarer meningsfuldt menneskeligt ansvar ved design, holder øje med de afslørende tegn på overtillid såsom næsten universel accept af en diagnostisk prompt og er klart på, at systemet rådgiver, mens klinikeren beslutter og forbliver ansvarlig.

I praksis: et eksempel fra sundhed og pleje#

Kingsmere NHS Foundation Trust, en del af Riverdale and Vale Integrated Care System, gik for to år siden i drift med en ny elektronisk patientjournal. Det kliniske indhold kom for det meste fra leverandørens standardbibliotek, let lokaliseret under en forhastet implementering. I år klager klinikere højlydt: systemet er "alt pop-ups", yngre læger beskriver at klikke igennem advarsler uden at læse dem, og en farmaceut har rejst en sikkerhedsbekymring, efter at en alvorlig interaktionsalarm blev tilsidesat i en klynge tilfælde — fordi den lignede præcis de dusinvis af trivielle, der udløses hver vagt.

Hospitalets CCIO bestiller en gennemgang af beslutningsstøtten. Informatikteamet trækker tilsidesættelsesdata og finder, at et lille antal regler tegner sig for langt hovedparten af alarmerne, og at flere udløses ved næsten hver recept med en tilsidesættelsesrate over 90 %. En regel om dobbeltbehandling udløses på legitime kombinationer; en alarm om nyredosering udløses på forældede kreatininsvar på grund af et datatimingsproblem, ikke en reel fare. Imens er den virkelig farlige interaktionsalarm begravet, visuelt identisk med støjen, uden krav om at registrere en begrundelse for at tilsidesætte den.

En gruppe for klinisk indholdsstyring oprettes, ledet af CCIO med en klinisk sikkerhedsansvarlig, farmaceuter, senior sygeplejersker og en dataanalytiker. De handler på evidensen frem for at tilføje flere regler. Nyredoseringsreglen rettes ved kilden ved at løse datatimingsproblemet. Dobbeltbehandlingsreglen indsnævres, så den ikke længere udløses på legitime par. En inddelt alvorlighedsordning indføres: den alvorlige interaktion bliver en tydelig, sværere at afvise alarm, der kræver en dokumenteret begrundelse, mens en lang hale af lavværdiadvarsler nedgraderes til passiv information eller nedlægges helt. Hver ændring gennemgår en DCB0160 klinisk sikkerhedsvurdering.

Seks måneder senere er den samlede alarmvolumen faldet kraftigt, mens tilsidesættelsesraten på de resterende højalvorlighedsalarmer er faldet, fordi klinikere nu stoler på, at en advarsel, der stopper dem, betyder noget. Styringsgruppen har sat gennemgangsdatoer for hver overlevende regel, tildelt hver en klinisk ejer og begyndt at evaluere, om ordresættene faktisk ændrede ordinationen til det bedre. Arbejdet tilføjede ingen dramatisk ny kapabilitet — det slukkede mest ting og tunede ting ned — men det forvandlede en ejerløs, mistroet bunke pop-ups til et styret, betroet klinisk sikkerhedssystem.

Sektorperspektiver#

Startup#

En digital sundheds-startup, der indlejrer beslutningsstøtte — et triageværktøj, en risikoberegner, et ordinationsstøttemodul — står normalt på producentsiden af linjen og må behandle sine regler som reguleret klinisk viden fra starten. Selv en "simpel" beregner, der anbefaler handling, kan være software som medicinsk udstyr, hvilket trækker den ind i MHRA-regulering og kræver et klinisk sikkerhedscase under DCB0129 (se emne 1.5 — Reguleringsbilledet og overholdelse). Fristelsen er at levere smart logik hurtigt; disciplinen er at dokumentere evidensgrundlaget, versionere indholdet og designe til yndefuld tilsidesættelse og menneskeligt tilsyn, før den første kliniker støtter sig til den. En startups troværdighed over for en NHS-køber hviler lige så meget på, hvordan den styrer og opdaterer sit kliniske indhold, som på algoritmens snilde.

Lille virksomhed#

En etableret lille udbyder — en lægepraksis, et lokalt apotek, et plejehjem eller en enkelt klinik — forbruger mest beslutningsstøtte indbygget i en leverandørs kliniske system frem for at forfatte den, men bærer alligevel samme pligt til at bruge den sikkert og holde klinisk skøn i løkken. Med lille eller ingen dedikeret informatikkapacitet er de praktiske prioriteter snævre, men reelle: ved, hvilke alarmer jeres system udløser, og slå de lokale fra eller tun dem, der er blevet støj, hold medicin- og vejledningsindholdet opdateret frem for frosset ved installationen, og sørg for, at nogen — selv en deltids klinisk leder — ejer sikkerheden af enhver lokal tilpasning. Modstå fristelsen til at deaktivere advarsler på bulk, blot fordi de er irriterende, da det bytter en gene for en fare. Hvor en leverandørs standardregler tydeligt er forkerte for jeres patienter, rejs det med leverandøren og registrér bekymringen, fordi I støtter jer til deres styring i stedet for en intern. Lighed- og proveniensspørgsmålene gælder stadig, selv hvis besvarelsen betyder at stille bedre spørgsmål til jeres leverandør frem for selv at revidere kode.

Stor virksomhed#

Et stort NHS-hospital eller en hospitalsgruppe arver typisk tusindvis af regler fra en EHR-leverandørs standardbibliotek, og dets centrale udfordring er styring i skala frem for forfatterskab fra bunden. Det realistiske mål er en stående funktion for klinisk indholdsstyring, pålidelig tilsidesættelsesanalyse, en inddelt alarmordning og disciplinen til at nedlægge og tune frem for kun at akkumulere — ikke en perfekt skræddersyet regel til enhver situation. Indlejr ændringer i beslutningsstøtten i klinisk ændringskontrol og det kliniske sikkerhedsstyringssystem, med en CCIO eller CNIO ansvarlig og informatikuddannede klinikere, der udfører arbejdet (se emne 4.6 — Elektroniske patientjournaler og kliniske systemer). I denne skala kommer de største sikkerhedsgevinster af at skære støj og eje indhold, ikke af at tilføje stadig flere alarmer.

Myndighed#

Et nationalt organ — NHS England, MHRA, NICE — former det beslutningsstøttemiljø, hver udbyder arbejder i. Det kan kuratere og kvalitetssikre delbar viden (NICE-vejledning, BNF og dm+d-lægemiddeldata), fastsætte de kliniske sikkerhedsstandarder DCB0129 og DCB0160 og forvalte interoperabilitetsstandarder, så en regel forfattet én gang kan stoles på og genbruges frem for genopbygges i hvert hospital (se emne 9.1 — Samarbejde med lokale og nationale myndigheder). Dets løftestang er at gøre velstyret, evidensforbundet beslutningsstøtte til markedets standard gennem standarder, indkøbsrammer og faglig infrastruktur som Faculty of Clinical Informatics. Myndigheden bærer også lighed- og gennemsigtighedspligterne: at sikre, at beslutningsstøttelogik ikke koder skævhed mod bestemte grupper, og at dens proveniens er reviderbar og offentlig.

Typiske fejlmønstre#

• Alarmoverbelastning. At udløse en advarsel for enhver tænkelig risiko afstumper klinikere, til de tilsidesætter alt, også de alarmer, der betyder noget. Inddel efter alvor, mål tilsidesættelsesrater, og skær støjen aggressivt.
• Ejerløst, ugennemgået indhold. Regler konfigureret én gang ved idriftsættelsen og aldrig genbesøgt driver ud af trit med aktuel vejledning og koder i det stille overhalet evidens. Giv hver regel en navngiven ejer, et evidensgrundlag og en gennemgangsdato.
• Leverandørstandarder utunede. At levere leverandørens færdige regelbibliotek uden at lokalisere det til jeres arbejdsgang og formularium importerer en andens støj og en andens antagelser. Gennemgå og tun før idriftsættelse, ikke efter klager.
• Logik uden arbejdsgang. En klinisk korrekt regel placeret på det forkerte trin, den forkerte skærm eller den forkerte rolle bliver friktion, klinikere arbejder udenom. Design og test med frontbrugere i den reelle opgave.
• Udløsningstal forvekslet med effektivitet. "Alarmen udløstes 10.000 gange" siger intet om, hvorvidt nogen beslutning blev forbedret. Evaluér mod ændrede udfald og undgået skade, og hold øje med utilsigtede konsekvenser.
• Intet sikkerhedscase. At behandle en regelændring som en rutinemæssig konfigurationsredigering frem for en klinisk sikkerhedsændring springer fareanalysen over, der fanger det farlige kanttilfælde. Led hver ændring gennem DCB0160.
• Automatiseringsbias og afkvalificering. At overtro maskinens prompt kan forankre en kliniker på det forkerte svar eller udhule det skøn, systemet forudsætter. Bevar meningsfuldt menneskeligt tilsyn og design, så tilsidesættelse er let og legitim.

Modenhedsmodel#

Tjekliste#

• Hver beslutningsstøtteregel, hvert ordresæt og hver skabelon har en navngiven klinisk ejer, et evidensgrundlag, en versionshistorik og en gennemgangsdato.
• En stående gruppe for klinisk indholdsstyring godkender, gennemgår og nedlægger indhold efter en risikobaseret plan.
• Alarmer er inddelt efter alvor, med afbrydelse forholdsmæssig i forhold til kliniske indsatser og hårde stop forbeholdt den sjældne katastrofale fare.
• Tilsidesættelsesrater overvåges pr. regel, speciale og rolle, og de mest støjende regler nedlægges, indsnævres eller nedgraderes aktivt.
• Beslutningsstøtte designes og testes med frontklinikere i den reelle arbejdsgang før idriftsættelse.
• Hver ny regel og ændring løber gennem et klinisk sikkerhedscase under DCB0129/DCB0160 med en klinisk sikkerhedsansvarligs godkendelse.
• En CCIO, CNIO eller tilsvarende er ansvarlig for det kliniske indhold, støttet af informatikuddannede klinikere.
• Klinikere kan tilsidesætte med meningsfuld lethed, og en vej findes til at rapportere en alarm, der er forkert, manglende eller skadelig.
• Effektivitet evalueres mod ændrede beslutninger og udfald, ikke udløsningstal, med utilsigtede konsekvenser i vågent øje.
• Grænsen til AI/ML-baseret støtte er eksplicit, og enhver statistisk eller lærende komponent styres under AI-styring (se emne 8.4).

Centrale kilder#

• NHS England / NHS Digital — standarderne for klinisk sikkerhed DCB0129 (fremstilling af sundheds-it-systemer) og DCB0160 (udrulning af sundheds-it-systemer) og vejledning til kliniske sikkerhedsansvarlige.
• Faculty of Clinical Informatics — faglige standarder og Core Competency Framework for kliniske informatikpraktikere; rolledefinitioner for CCIO og CNIO.
• Osheroff et al. — Improving Outcomes with Clinical Decision Support: An Implementation Sourcebook (HIMSS) — oprindelsen af "fem rigtige"-rammeværket for CDS.
• NICE — evidens, vejledning og Evidence Standards Framework for Digital Health Technologies; NICE-akkrediteret viden brugt som CDS-indhold.
• HL7 International — CDS Hooks og FHIR Clinical Reasoning-standarderne; Arden-syntaksen for delbare Medical Logic Modules.
• The Topol Review (Preparing the healthcare workforce to deliver the digital future) — klinisk informatikarbejdsstyrke og kapabilitet.
• MHRA — vejledning om software og kunstig intelligens som medicinsk udstyr, for støtte der krydser den regulatoriske tærskel.

Referencer#

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