Emne 1.6 — Klinisk sikkerhed og risikostyring

I én sætning: Klinisk sikkerhed er den disciplinerede, dokumenterede praksis at finde de måder, hvorpå din digitale teknologi kan skade en patient, og at kontrollere disse farer, før de når nogen – sikkerhed designet ind fra første skitse, ikke boltet på før idriftsættelsen.

Hvorfor det er vigtigt i sundhed og pleje#

I de fleste sektorer er en softwarefejl en ulejlighed: en side indlæses ikke, en ordre dubleres, en rapport er forsinket. I sundhed og pleje kan den samme klasse af fejl slå ihjel. Et medicinfelt, der afkorter et decimalkomma, en resultatskærm, der viser den forkerte patient, en triagealgoritme, der stille og roligt holder op med at markere et symptom, en integration, der lydløst taber allergioplysninger – hver er en softwarefejl, og hver er også en klinisk fare, der kan forårsage alvorlig skade eller død. Derfor er klinisk sikkerhed ikke en kvalitetsfinesse lagt oven på god softwareudvikling; det er en særskilt, reguleret disciplin med egne standarder, roller og evidens.

Indsatsen er asymmetrisk og ofte usynlig. Når et digitalt system virker, ser ingen den skade, det forhindrede; når det svigter, kan skaden være katastrofal, forsinket og spredt ud over tusindvis af patienter, før nogen bemærker et mønster. Den kombination – høj konsekvens, lav synlighed, stor sprængradius – betyder, at du ikke kan stole på, at brugere fanger problemer, eller at hændelser lærer dig alt. Du må ræsonnere proaktivt om skade, før udrulning, og blive ved med at gøre det, mens systemet er i drift. I Storbritannien er denne proaktive ræsonnering ikke valgfri: NHS-organisationer og deres leverandører forventes kontraktligt og fagligt at anvende nationale standarder for klinisk risikostyring og at kunne vise deres arbejde. At få dette rigtigt er uadskilleligt fra evidens (se emne 1.3 — Evidensbaserede beslutninger), fra informationsstyring og cybersikkerhed (se emne 1.7 — Informationsstyring, databeskyttelse og cybersikkerhed) og fra, hvordan du driver tjenester, når de er i drift (se emne 3.8 — Servicestyring og drift).

Kernebegreber#

Patientsikkerhed og risikostyring. Patientsikkerhed er forebyggelse, reduktion, rapportering og analyse af skade på patienter som følge af pleje. Klinisk risikostyring anvender den generelle disciplin risikostyring – identificering, evaluering, prioritering og kontrol af risici – på det specifikke spørgsmål om, hvordan et sundheds-it-system kan bidrage til patientskade. De to nationale standarder, der regulerer dette i England, er DCB0129 og DCB0160 (DCB står for Data Coordination Board; det er standarder fra Standardisation Committee for Care Information / SCCI, påbudt i medfør af Health and Social Care Act 2012). DCB0129 pålægger forpligtelser til producenten eller leverandøren af et sundheds-it-system; DCB0160 pålægger forpligtelser til den sundhedsorganisation, der udruller og bruger det. De er komplementære: en leverandørs rene sikkerhedscase fritager ikke et udrullende hospital for pligten til at vurdere de farer, dets egen konfiguration, arbejdsgang og kontekst introducerer.

Den kliniske sikkerhedsansvarlige (Clinical Safety Officer, CSO). Begge standarder kræver en navngiven, passende kvalificeret og erfaren klinisk sikkerhedsansvarlig – en registreret, aktuelt praktiserende kliniker, der har gennemført anerkendt oplæring i klinisk sikkerhed – til at eje den kliniske risikostyringsaktivitet og personligt godkende sikkerhedscasen. CSO-rollen er et kompetencekrav, ikke en titel, du kan tildele den, der er ledig. CSO’en bekræfter med sin underskrift, at farer er identificeret og kontrolleret til et acceptabelt niveau; det er et fagligt skøn, der bærer fagligt ansvar.

De kliniske risikostyringsartefakter. Tre dokumenter forankrer disciplinen. Den kliniske risikostyringsfil er containeren for al sikkerhedsevidens for et system. Farelogen er det levende register over hver identificeret fare, dens årsager, konsekvenser, risikovurdering, kontroller og restrisiko. Det kliniske sikkerhedscase er det strukturerede argument, understøttet af evidens, for at systemet er acceptabelt sikkert til sit tilsigtede formål i sin tilsigtede kontekst – ledsaget af en sikkerhedscase-rapport, der opsummerer argumentet til godkendelse. Disse er ikke papirarbejde for papirarbejdets skyld; de er måden, sikkerhedsræsonnering gøres eksplicit, gennemgåelig og varig.

Fareanalyse: identificering, analyse, evaluering, kontrol. Kerneløkken er: fareidentificering (systematisk at forestille sig, hvordan systemet kan bidrage til skade – gennem workshops, kliniske gennemgange, fejlmodeanalyse), risikoanalyse (at estimere alvoren af skaden og sandsynligheden for, at den indtræffer), risikoevaluering (at sammenligne den estimerede risiko med acceptkriterier) og risikokontrol (at indføre foranstaltninger – designændringer, alarmer, oplæring, procedurer – for at reducere uacceptabel risiko og derefter genevaluere restrisikoen). Risikoen reduceres så lavt som rimeligt praktisk muligt (ALARP): du bliver ved med at kontrollere, indtil yderligere reduktion ville være grovt uforholdsmæssig i forhold til den opnåede gevinst.

Regulering af medicinsk udstyr, MHRA og Software as a Medical Device (SaMD). Nogle digitale sundhedsteknologier er reguleret medicinsk udstyr. Software med et medicinsk formål – at diagnosticere, forebygge, overvåge, forudsige, behandle – kan selv være medicinsk udstyr: Software as a Medical Device (SaMD). I Storbritannien regulerer Medicines and Healthcare products Regulatory Agency (MHRA) medicinsk udstyr, herunder SaMD, og livscyklusstandarden for software IEC 62304 regulerer, hvordan sådan software skal udvikles. At afgøre, om din teknologi er reguleret udstyr, er et tærskelspørgsmål med store konsekvenser, og det er adskilt fra – selv om det står ved siden af – klinisk risikostyring efter DCB0129/0160.

Digital Technology Assessment Criteria (DTAC). DTAC er den nationale baseline, NHS- og socialplejeorganisationer bruger til at vurdere digitale produkter før indkøb, og den dækker klinisk sikkerhed (evidens for overholdelse af DCB0129), databeskyttelse, teknisk sikkerhed, interoperabilitet og brugbarhed. Den erstatter ikke klinisk risikostyring; den tjekker, at en leverandør har gjort det.

Human factors og sikkerhedskultur. Human factors (ergonomi) er det videnskabelige studie af, hvordan mennesker interagerer med systemer under virkelige forhold – træthed, afbrydelser, kognitiv belastning, alarmtræthed. De fleste digitale skader opstår ikke af kode, der er "forkert", men af designs, der gør den sikre handling svær og den usikre handling let. Sikkerhedskultur er den organisatoriske forpligtelse til at bringe risiko frem, rapportere den og lære af den uden at give skyld – forskellen på et team, der skjuler næsten-hændelser, og et, der udvinder forbedringer af dem.

Hændelsesrapportering og læring. I England er Learn from Patient Safety Events (LFPSE) den nationale tjeneste til registrering af patientsikkerhedshændelser, og Patient Safety Incident Response Framework (PSIRF) fastlægger, hvordan NHS-organisationer reagerer på og lærer af hændelser – med vægt på forholdsmæssig, systembaseret rodårsagsanalyse frem for skyld. Systemer i drift genererer nye farer, så klinisk sikkerhed fortsætter efter idriftsættelsen gennem hændelsesfeedback ind i farelogen.

Bedste praksis#

1. Udpeg en kompetent klinisk sikkerhedsansvarlig, og giv vedkommende reel beføjelse. Navngiv en registreret, praktiserende kliniker med anerkendt oplæring i klinisk sikkerhed som CSO for hvert system inden for rækkevidde, og sørg for, at vedkommendes godkendelse er en ægte port, ikke et gummistempel dagen før lanceringen. CSO’en skal kunne sige "ikke endnu" og blive hørt – hvilket betyder at beskytte vedkommendes tid, uafhængighed og position over for programbestyrelsen. En CSO, der tilsidesættes af leveringspres, er en styringsfiktion.

2. Foretag fareidentificering tidligt, med klinikere i rummet. Start farer-workshops i afdækning og design, ikke før idriftsættelsen, fordi de billigste og mest effektive kontroller er designændringer foretaget, før noget er bygget (se emne 3.5 — Leveranceforløb). Tag klinikere fra frontlinjen med, ikke kun analytikere, fordi de ved, hvordan arbejdet virkelig foregår – afbrydelserne, omgåelserne, måden en skærm læses på klokken tre om natten. Gennemgå realistiske kliniske scenarier og spørg ubønhørligt: "hvordan kan dette system bidrage til, at en patient kommer til skade?"

3. Før en levende farelog, ikke et dokument til lanceringsdagen. Behandl farelogen som et vedvarende register, der åbner i afdækningen og aldrig lukker, mens systemet er i drift. Hver fare registrerer sine årsager, potentielle skade, indledende risikovurdering, de anvendte kontroller og restrisikoen efter kontroller. Når en hændelse, en ændring eller en næsten-hændelse afslører en ny fare, kommer den ind i loggen og gennemgår den samme løkke – loggen er hukommelsen om din sikkerhedsræsonnering.

4. Lad den udrullende organisation eje DCB0160, selv med en overholdende leverandør. En leverandørs DCB0129-sikkerhedscase dækker produktet som bygget; den kan ikke dække, hvordan du konfigurerer det, hvilke arbejdsgange du bygger omkring det, eller hvilke af dine populationer der bruger det. Gennemfør din egen DCB0160-vurdering af lokale farer – integration med dine andre systemer, din datakvalitet, dine kliniske forløb – og før din egen farelog. At antage, at leverandørens assurance dækker din kontekst, er en almindelig og farlig genvej.

5. Gør risikokontrol forholdsmæssig, og foretræk design frem for advarsler. Rangér kontroller efter styrke: at designe faren ud (begrænsninger, standardindstillinger, tvangsfunktioner) slår en alarm på skærmen, som slår en linje i en oplæringsmanual. Forbehold den tungeste assurance til de farer med højest konsekvens, og anvend lettere, hurtigere proces til reelt lavrisikoændringer – forholdsmæssighed er det, der lader sikkerhed holde trit med leverancen. Reducér risikoen til ALARP, og registrér, hvorfor restrisikoen er acceptabel.

6. Design til human factors, og respektér alarmtræthed. Antag, at brugere er travle, afbrudte og mønstergenkendende, og design, så den sikre handling er den nemme, standardmæssige handling. Vær på vagt over for alarmoverbelastning: en alarm, der udløses for ofte, ignoreres, så hver yderligere advarsel skal fortjene sin plads, ellers forringer den dem, der betyder noget. Brugbarhedstest under realistiske forhold er en klinisk sikkerhedsaktivitet, ikke blot en designfinesse.

7. Fastlæg bevidst din regulatoriske status. Spørg tidligt, om din software opfylder definitionen på medicinsk udstyr eller SaMD, og hvis ja, tag MHRA-kravene og IEC 62304 i brug fra starten frem for at opdage forpligtelsen sent. Forkert klassifikation er dyr i begge retninger – et uregistreret udstyr er en juridisk og sikkerhedsmæssig fiasko, mens overklassificering af et simpelt værktøj spilder knap assurancekapacitet. Er du i tvivl, så søg regulatorisk rådgivning og dokumentér begrundelsen.

8. Brug DTAC som et gulv, ikke en målstreg. Behandl Digital Technology Assessment Criteria som den mindste adgangskontrol for ethvert indkøbt digitalt produkt og bekræft, at klinisk sikkerhed, databeskyttelse, sikkerhed, interoperabilitet og brugbarhed er adresseret. At bestå DTAC betyder, at en leverandør har gjort arbejdet; det betyder ikke, at produktet er sikkert i din kontekst, så par det med din egen DCB0160-vurdering og levende overvågning.

9. Luk løkken fra hændelser i drift ind i farelogen. Før din hændelsesrapportering – LFPSE-indberetninger, PSIRF-undersøgelser, lokale rapporter om næsten-hændelser – tilbage i klinisk risikostyring, så reel skade og næsten-hændelser opdaterer dine farer og kontroller. En sikkerhedscase, der aldrig genbesøges efter idriftsættelsen, rådner, fordi systemer i drift, integrationer og klinisk praksis alle driver (se emne 3.8 — Servicestyring og drift). Læring er systembaseret og skyldbevidst, ikke en søgen efter nogen at straffe.

10. Opbyg en retfærdig, rapporterende sikkerhedskultur. Gør det trygt og forventet at rapportere næsten-hændelser og at udfordre en lancering af sikkerhedsmæssige grunde, for farer, du aldrig hører om, er farer, du ikke kan kontrollere. Ledere sætter tonen ved at reagere på dårlige nyheder med nysgerrighed og forbedring frem for skyld og ved at behandle CSO’ens forsigtighed som værdifuld frem for obstruktiv. Kultur er det substrat, enhver anden praksis her afhænger af.

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

1. Hvor i vores nuværende portefølje stoler vi på en leverandørs sikkerhedsassurance til at dække risici, der faktisk er vores at eje? Dette spørgsmål undersøger delingen mellem DCB0129 og DCB0160, som teams rutinemæssigt udvisker. En leverandørs DCB0129-sikkerhedscase adresserer produktet som fremstillet, men i det øjeblik, du konfigurerer det, forbinder det med dine andre systemer, bygger lokale arbejdsgange omkring det og peger det mod din specifikke patientpopulation, introducerer du farer, leverandøren aldrig vurderede og ikke kunne have vurderet. Den ærlige spænding er, at det koster knap klinisk og analytisk tid at gennemføre din egen DCB0160-vurdering, og det er fristende at behandle en leverandørs rene assurance og en bestået DTAC som tilstrækkeligt. Gennemgå en udrulning i drift eller forestående og spørg konkret: hvem er vores navngivne CSO for den, har vi vores egen farelog, og hvilke farer opstår udelukkende af vores lokale kontekst frem for selve produktet? Et godt svar nævner specifikke systemer, hvor lokal vurdering er tynd, adskiller produktfarer fra udrulningsfarer og forpligter sig til at eje de sidstnævnte frem for at antage, at de er dækket.

2. Hvor forholdsmæssig er vores kliniske sikkerhedsproces – begraver vi lavrisikoændringer i papirarbejde, mens højkonsekvensændringer glider igennem på momentum? Emnet argumenterer for, at assurance bør skalere med klinisk risiko: tungeste granskning for farer med højest konsekvens, lettere og hurtigere proces, hvor risikoen reelt er lav. Dette spørgsmål afprøver, om jeres organisation faktisk kalibrerer eller anvender én sløv indstilling. Begge fejlretninger er reelle og dyre – en ensartet tung proces oplærer teams til at se klinisk sikkerhed som en bureaukratisk skat og omgå den, mens en ensartet let proces lader en ændring af en medicindoseringsberegner passere med samme indsats som en ændring af en hjælpeside. Den mere subtile fare er, at momentum, ikke risiko, afgør granskningen: et flagskibsprogram med direktionens opmærksomhed kan få en aura af uundgåelighed, der afskrækker CSO’en fra at sige "ikke endnu". Gennemgå to eller tre nylige ændringer med tydeligt forskellig risiko og spørg, om den anvendte indsats svarede til potentialet for skade, og om nogen følte sig i stand til at bremse den højprofilerede. Et ærligt svar indrømmer, hvor processen er fejlkalibreret i begge retninger, og behandler forholdsmæssighed som et forsvarligt, eksplicit skøn frem for en refleks.

3. Da noget næsten gik galt med et af vores digitale systemer, hvad skete der så faktisk bagefter – og ville en kliniker fra frontlinjen sige, at det var trygt at rejse det? Dette spørgsmål undersøger sikkerhedskultur og hændelseslæringsløkken, som er der, hvor erklærede forpligtelser møder virkeligheden. Klinisk sikkerhed afhænger af at høre om næsten-hændelser, men folk rapporterer kun, når det føles trygt og meningsfuldt, og når de ser, at det fører til forandring frem for skyld. Spændingen er, at instinktet under lever- og omdømmepres er at forklare en næsten-hændelse væk, lukke den hurtigt og komme videre – især hvis en fuldstændig fremlæggelse ville forsinke en lancering eller genere en senior sponsor. PSIRF’s systembaserede, skyldbevidste tilgang findes netop, fordi det at lede efter en enkeltperson at bebrejde undertrykker den rapportering, du har brug for, og overser de reelle, systemiske årsager. Forankr drøftelsen i en specifik nylig næsten-hændelse eller hændelse: blev den logført, nåede den farelogen, blev der foretaget en forholdsmæssig undersøgelse, og ændrede noget sig faktisk? Et godt svar er åbent om, hvorvidt rapportering føltes sikker, adskiller reel læring fra papirlukning og nævner konkret adfærd, ledere vil tilegne sig, så den næste, der opdager en fare, siger fra.

4. Har vi ærligt afgjort, hvilke af vores produkter der er regulerede medicinske udstyr – og hvem er ansvarlig for den beslutning? Regulatorisk status er et tærskelspørgsmål med uforholdsmæssigt store konsekvenser, og det er let at lade det stå ubesvaret, fordi svaret kan være ubelejligt. Software, der diagnosticerer, forudsiger, overvåger eller behandler, kan selv være Software as a Medical Device og trække MHRA-forpligtelser og livscyklusstandarden IEC 62304 ind – adskilt fra og i tillæg til klinisk risikostyring efter DCB0129/0160. Spændingen går begge veje: underklassificering efterlader dig med at levere et uregistreret udstyr, en juridisk og sikkerhedsmæssig fiasko, der kan vise sig katastrofalt i stor skala, mens overklassificering af et simpelt administrativt værktøj brænder knap assurancekapacitet af, du havde brug for andre steder. Faren er, at klassifikationen falder mellem roller – klinikere antager, at udviklerne har afgjort det, udviklerne antager, at det regulatoriske eller kommercielle team har, og ingen har faktisk skrevet begrundelsen ned. Se konkret på de produkter i jeres portefølje, der ligger tættest på grænsen – alt med en triageregel, en risikoscore, en alarmalgoritme – og spørg, hvem der traf udstyrsafgørelsen, på hvilket grundlag, og om den er dokumenteret og genbesøgt, efterhånden som funktioner ændrer sig. Et ærligt svar nævner grænseprodukterne, peger på en registreret og forsvarlig begrundelse for hver og er åbent, hvor beslutningen aldrig reelt blev truffet.

5. Designer vi farer ud, eller samler vi stille og roligt alarmer og advarsler, som vores klinikere allerede har lært at ignorere? Emnet rangerer kontroller efter styrke – at designe faren ud slår en alarm på skærmen, som slår en linje i en oplæringsmanual – men alarmer er den lette vej, fordi det er hurtigt at tilføje en advarsel og føles ansvarligt, mens det er langsomt og omstridt at redesigne en arbejdsgang. Med tiden samler denne bias sig til alarmtræthed: så mange advarsler udløses, at klinikere mønstergenkender forbi dem alle, inklusive den, der betyder noget, så hver ny alarm faktisk kan reducere sikkerheden. Den reelle spænding er, at hver unødvendig alarm har en sponsor, der tilføjede den i god tro efter en eller anden hændelse, hvilket gør advarsler politisk svære at fjerne, selv når de forringer systemet. Human factors er disciplinen her – at designe, så den sikre handling er den nemme, standardmæssige handling for en travl, afbrudt bruger, der læser en skærm klokken tre om natten – og brugbarhedstest under realistiske forhold er en klinisk sikkerhedsaktivitet, ikke en designfinesse. Gennemgå et system, jeres teams faktisk bruger, og spørg, hvor mange alarme en kliniker møder i en typisk opgave, hvilke af dem der reelt ændrer adfærd, og hvor en tvangsfunktion eller en bedre standardindstilling kunne have erstattet en advarsel helt. Et godt svar modstår refleksen til at tilføje endnu en alarm, behandler alarmbelastning som en målbar fare i sig selv og er villigt til at fjerne advarsler, der ikke længere fortjener deres plads.

6. Efterhånden som vores systemer i drift, integrationer og kliniske forløb driver over tid, hvordan ved vi så, at vores sikkerhedscase stadig holder? Klinisk sikkerhed slutter ikke ved idriftsættelsen; systemer i drift genererer nye farer, og verden omkring et system bevæger sig hele tiden – en opstrøms integration ændrer sine data, et klinisk forløb redesignes, en leverandør udgiver en opdatering, en ny patientkohorte begynder at bruge værktøjet. Et sikkerhedscase godkendt for to år siden beskriver et system og en kontekst, der måske ikke længere findes, så spørgsmålet er, om jeres farelog er et levende register eller et dokument, der blev underskrevet én gang og overladt til at rådne (se emne 3.8 — Servicestyring og drift). Spændingen er, at vedligeholdelse af sikkerhedsræsonnering efter lancering konkurrerer med ny leverance om den samme knappe CSO- og kliniske tid, og drift er gradvis og usynlig på en måde, der sjældent kræver opmærksomhed, før noget svigter. Konkrete vinkler omfatter ændringsstyring, der genudløser farevurdering, når konfiguration eller integrationer ændrer sig, periodisk gennemgang af farer med højest konsekvens og overvågning, der faktisk ville opdage en kontrol, der lydløst forringes. Vælg et system, der har været i drift i et år eller mere, og spørg, hvornår dets farer sidst blev gennemgået, hvad der er ændret under det siden godkendelsen, og hvem der ville bemærke, hvis en nøglekontrol holdt op med at virke. Et ærligt svar adskiller systemer med reel løbende sikkerhedsstyring fra dem, der kører på et forældet sikkerhedscase, og forpligter sig til en forholdsmæssig gennemgangsrytme knyttet til reel forandring frem for kalenderen alene.

I praksis: et eksempel fra sundhed og pleje#

Et integreret plejesystem (ICS) udruller et fælles e-henvisningsværktøj, der lader praktiserende læger henvise patienter direkte til kommunale tjenester, med et indbygget triageregelsæt, der router akutte tilfælde til en hurtigere kø. En leveringsdrevet tilgang ville tage leverandørens DCB0129-sikkerhedscase, bestå DTAC og gå i luften for at ramme en dato, bestyrelsen har lovet.

I stedet udpeger programmet en praktiserende læge med oplæring i klinisk sikkerhed som klinisk sikkerhedsansvarlig og åbner en klinisk risikostyringsfil og en farelog ved starten af designet. Tidlige farer-workshops med praktiserende læger, kommunale sygeplejersker og administratorer afdækker flere farer, leverandørens produktniveau-case aldrig berørte – alle opstået af lokal udrulning. Den værste: triagereglerne var konfigureret mod ICS’ets egne servicedefinitioner, og en mappingfejl kunne route en akut henvisning for hudkræft ind i en rutinemæssig dermatologikø med flere ugers ventetid. Den fare vurderes som høj alvor, plausibel sandsynlighed.

I arbejdet med risikokontrolløkken foretrækker teamet design frem for advarsler. De tilføjer en tvangsfunktion, så et akut klinisk flag ikke lydløst kan tilsidesættes af routinglogikken, en afstemningsrapport som en kliniker gennemgår dagligt og – lavest i hierarkiet – en oplæringsnote. Restrisikoen revurderes og vurderes acceptabel og ALARP; CSO’en registrerer hvorfor. Fordi værktøjet kun router og ikke selv diagnosticerer, vurderer teamet, at det ikke opfylder SaMD-tærsklen, dokumenterer den begrundelse og arkiverer den. Human factors-test fanger et separat problem: en overivrig "dobbelt henvisning"-alarm udløses så ofte, at praktiserende læger allerede ignorerer den, så den redesignes til kun at udløses ved reelle dubletter.

Ved idriftsættelsen godkendes DCB0160-sikkerhedscasen af CSO’en, ikke af programdirektøren. Tre uger inde afslører en LFPSE-rapport og en næsten-hændelse markeret af en receptionist en ny fare – et fritekstfelt, der bruges til at smugle akut information ind, som routingen aldrig ser. Under PSIRF kører en forholdsmæssig, systembaseret gennemgang, faren kommer ind i loggen, en designændring planlægges, og en midlertidig kontrol briefes samme uge. Sikkerhedscasen er et levende argument, og registreringen viser præcis, hvordan hver fare blev ræsonneret om – hvilket er det, en inspektør, en retsmediciner eller en ny CSO om to år vil have brug for.

Sektorperspektiver#

Alle skylder den samme pligt til at kontrollere klinisk risiko, men maskineriet, incitamenterne og presset varierer kraftigt efter organisation.

Startup#

En digital sundheds-startup møder ofte klinisk sikkerhed som en indkøbsport: en NHS-køber beder om DTAC og et DCB0129-sikkerhedscase, og der opstår hastværk. Det vindende træk er at bygge klinisk risikostyring ind fra første sprint – en farelog ved siden af backloggen, en tilgængelig klinisk sikkerhedsansvarlig (ofte kontraheret frem for ansat, men reelt kompetent og bemyndiget) – fordi det at eftermontere et sikkerhedscase på et færdigt produkt er langsomt, dyrt og uoverbevisende. Grundlæggere må også konfrontere SaMD-spørgsmålet ærligt og tidligt, da det at opdage midt i skaleringen, at produktet er et uregistreret medicinsk udstyr, er en eksistentiel juridisk og sikkerhedsmæssig risiko. Gjort godt bliver modne kliniske sikkerhedsartefakter et kommercielt aktiv, der forkorter NHS-salgscyklusser.

Lille virksomhed#

En etableret lille udbyder – en lægepraksis, et lokalt apotek, et plejehjem, et hjemmeplejefirma, en enkelt klinik eller en lille sundhedsteknologileverandør forbi fasen uden omsætning – bærer den samme DCB0160-pligt som et stort hospital, når den udruller og konfigurerer digitale systemer, men uden nogen ledig kapacitet til at udføre den. Der er sjældent en dedikeret CSO eller sikkerhedsanalytiker på lønningslisten, så den praktiske vej er at købe en kompetent, praktiserende kliniker ind på kontraktbasis og føre en slank, men ægte farelog frem for at foregive, at pligten ikke gælder. De skarpeste lokale farer er normalt konfigurations- og arbejdsgangsfarer – hvordan den fælles journal sættes op, hvordan akutte flag håndteres, hvordan en deltidsadministrators omgåelse bliver en routingrisiko – netop de farer, en leverandørs DCB0129-case aldrig dækker. Forholdsmæssighed er den lille udbyders ven her: koncentrér den ringe assurancetid, I har, om farerne med højest konsekvens, brug DTAC og leverandørens sikkerhedscase som et gulv ved valg af produkter, og læn jer op ad fælles ressourcer som ICS’ets kliniske sikkerhedsstøtte frem for at forsøge at bygge hele apparatet alene.

Stor virksomhed#

Et NHS-hospital eller ICS bærer dobbelt ansvar: det udruller andres systemer under DCB0160 og bygger eller konfigurerer ofte tungt sine egne under DCB0129. Det karakteristiske fejlmønster er institutionelt – et flagskibsprogram for elektronisk patientjournal, hvis idriftsættelsesdato har politisk vægt, så CSO’ens forsigtighed stille og roligt behandles som en hindring. Modgiften er strukturel: giv CSO’en uafhængighed og et reelt veto, før en levende farelog på tværs af landskabet frem for en hylde af lanceringsdagsdokumenter, og før LFPSE- og PSIRF-læring tilbage i klinisk risikostyring som en stående proces. I stor skala er de største farer integrations- og konfigurationsfarer, som ingen leverandørassurance dækker, så lokalt ejerskab er ikke til forhandling.

Myndighed#

Et nationalt organ – NHS England, MHRA, DHSC, NICE – fastsætter de standarder, andre skal opfylde, så dets arbejdsmåder former hele systemet: DCB0129/0160, DTAC og SaMD-regulering er instrumenter for sikkerhed i befolkningsskala. Beslutninger her tiltrækker tilsyns-, parlamentarisk og offentlig granskning, og et nationalt påbudt system, der bærer en latent fare, fordeler den skade over millioner, før nogen ser mønstret. Forpligtelserne er forholdsmæssighed gjort eksplicit i offentliggjorte standarder, gennemsigtighed om restrisiko og at holde det regulatoriske rammeværk aktuelt, efterhånden som teknologi – især AI – løber fra det (se emne 8.4 — Styring af AI og ny teknologi). Den særlige risiko på denne skala er systemisk: at pålægge en teknologi i hele landskabet på tynd sikkerhedsevidens cementerer en fare overalt på én gang.

Typiske fejlmønstre#

• Sikkerhed boltet på til sidst. At producere et sikkerhedscase ugen før idriftsættelsen for at tilfredsstille en port. Modgift: åbn farelogen i afdækningen; design de største farer ud.
• Leverandørassurance forvekslet med lokal sikkerhed. At behandle et DCB0129-case og en bestået DTAC som dækkende for din udrulning. Modgift: eje din egen DCB0160-vurdering og lokale farelog.
• CSO som gummistempel. En klinisk sikkerhedsansvarlig uden tid, uafhængighed eller beføjelse til at sige "ikke endnu". Modgift: beskyt rollen og gør godkendelse til en ægte port.
• Død farelog. Et dokument skrevet én gang og aldrig genbesøgt efter lanceringen. Modgift: hold det levende; før hændelser og ændringer ind i det.
• Alarmoverbelastning. Så mange advarsler, at klinikere ignorerer dem alle, inklusive de vitale. Modgift: human factors-design; hver alarm skal fortjene sin plads.
• Skyldkultur. At straffe enkeltpersoner for næsten-hændelser, så rapporteringen tørrer ud. Modgift: en retfærdig, systembaseret kultur på linje med PSIRF.
• Overset regulatorisk tærskel. At levere SaMD uden at genkende det som reguleret udstyr. Modgift: vurdér og dokumentér status som medicinsk udstyr tidligt.

Modenhedsmodel#

Tjekliste#

• En kompetent, praktiserende, uddannet klinisk sikkerhedsansvarlig er navngivet for hvert system, med tid og beføjelse til at sige "ikke endnu".
• En klinisk risikostyringsfil, en levende farelog og et klinisk sikkerhedscase findes for hvert system inden for rækkevidde.
• Fareidentificering begyndte i afdækningen med klinikere fra frontlinjen i rummet.
• Den udrullende organisation har gennemført sin egen DCB0160-vurdering, ikke blot accepteret leverandørens DCB0129-case.
• Risikokontroller foretrækker design-ud frem for alarmer frem for oplæring, med restrisiko reduceret til ALARP og begrundet.
• Status som medicinsk udstyr / SaMD er vurderet og dokumenteret, og MHRA- / IEC 62304-forpligtelser er taget i brug, hvor det er relevant.
• DTAC er gennemført som et gulv, parret med lokal klinisk risikostyring.
• Human factors- og brugbarhedstest under realistiske forhold er udført; alarmbelastning er kontrolleret.
• Hændelser i drift (LFPSE) og PSIRF-læring føres tilbage i farelogen som en stående proces.
• Det er synligt trygt og forventet at rapportere næsten-hændelser og udfordre en lancering af sikkerhedsmæssige grunde.

Centrale kilder#

• NHS England — DCB0129: Clinical Risk Management: its Application in the Manufacture of Health IT Systems.
• NHS England — DCB0160: Clinical Risk Management: its Application in the Deployment and Use of Health IT Systems.
• NHS England — Clinical Safety Officer training og vejledning om klinisk risikostyring.
• NHS England — Digital Technology Assessment Criteria (DTAC).
• MHRA — vejledning om Software and Artificial Intelligence (AI) as a Medical Device.
• IEC — IEC 62304: Medical device software — software life cycle processes.
• ISO — ISO 14971: Application of risk management to medical devices.
• NHS England — tjenesten Learn from Patient Safety Events (LFPSE).
• NHS England — Patient Safety Incident Response Framework (PSIRF).
• World Health Organization — Global Patient Safety Action Plan 2021–2030.

Referencer#

1. Patient safety — Wikipedia — https://en.wikipedia.org/wiki/Patient_safety
2. Risk management — Wikipedia — https://en.wikipedia.org/wiki/Risk_management
3. Hazard analysis — Wikipedia — https://en.wikipedia.org/wiki/Hazard_analysis
4. Safety case — Wikipedia — https://en.wikipedia.org/wiki/Safety_case
5. Medical device — Wikipedia — https://en.wikipedia.org/wiki/Medical_device
6. Medicines and Healthcare products Regulatory Agency — Wikipedia — https://en.wikipedia.org/wiki/Medicines_and_Healthcare_products_Regulatory_Agency
7. Ergonomics (human factors) — Wikipedia — https://en.wikipedia.org/wiki/Ergonomics
8. Safety culture — Wikipedia — https://en.wikipedia.org/wiki/Safety_culture
9. As low as reasonably practicable (ALARP) — Wikipedia — https://en.wikipedia.org/wiki/As_low_as_reasonably_practicable
10. Root-cause analysis — Wikipedia — https://en.wikipedia.org/wiki/Root-cause_analysis
11. IEC 62304 — Wikipedia — https://en.wikipedia.org/wiki/IEC_62304
12. DCB0129: Clinical Risk Management in the Manufacture of Health IT Systems — NHS England — https://digital.nhs.uk/services/clinical-safety/clinical-risk-management-standards
13. DCB0160: Clinical Risk Management in the Deployment and Use of Health IT Systems — NHS England — https://digital.nhs.uk/services/clinical-safety/clinical-risk-management-standards
14. Digital Technology Assessment Criteria (DTAC) — NHS England — https://www.nhs.uk/digital-technology-assessment-criteria-dtac/
15. Software and Artificial Intelligence (AI) as a Medical Device — MHRA, GOV.UK — https://www.gov.uk/government/publications/software-and-artificial-intelligence-ai-as-a-medical-device
16. IEC 62304: Medical device software — software life cycle processes — International Electrotechnical Commission — https://www.iso.org/standard/38421.html
17. ISO 14971: Application of risk management to medical devices — International Organization for Standardization — https://www.iso.org/standard/72704.html
18. Learn from Patient Safety Events (LFPSE) service — NHS England — https://www.england.nhs.uk/patient-safety/patient-safety-insight/learning-from-patient-safety-events/
19. Patient Safety Incident Response Framework (PSIRF) — NHS England — https://www.england.nhs.uk/patient-safety/patient-safety-insight/incident-response-framework/
20. Global Patient Safety Action Plan 2021–2030 — World Health Organization — https://www.who.int/teams/integrated-health-services/patient-safety/policy/global-patient-safety-action-plan