KI och avvikelshantering inom tandvård

När KI är involverad i en händelse blir "avvikelsen" ofta oklar: Var det ett tekniskt fel? Felaktig användning? En leverantörsförändring? Ett brott mot integritet? Eller en patientsäkerhetshändelse?

Ett praktiskt sätt att tänka på är detta:

KI-relaterade avvikelser är inte en avvikelsestyp. Det är en händelse där KI (eller användning av KI) är en del av orsakskedjan, och därför måste hanteras genom klinikens befintliga avvikelsessystem, men med några extra frågor och dokumentationskrav.

1) Vad är en KI-relaterad avvikelse?

En KI-relaterad avvikelse kan vara:

• Felaktig output (t.ex. fel markering på röntgen, fel risikoscore, fel textförslag som används oreflekterat)

• Felaktig användning (KI använd utanför avsett ändamål, eller utan mänsklig kontroll)

• Oauktoriserad användning ("shadow AI") (anställda använder verktyg utan godkännande)

• Leverantörs-/modelländring (uppdatering som ändrar beteende/prestanda)

• Datahantering som avviker (patientuppgifter delade i ej godkänd tjänst, eller loggning/lagring som inte är klargjord)

NIST AI RMF betonar att AI-risker måste hanteras kontinuerligt, inklusive att identifiera och följa upp "emergent risks" i drift, vilket betyder att risken kan förändras efter att lösningen har antagits. 

2) Tre "spår" du alltid bör överväga samtidigt

När något går fel med KI, utvärdera händelsen i tre spår (som ofta överlappar):

Spår A: Patientsäkerhet och professionell kvalitet

• Påverkade KI en klinisk bedömning eller behandlingsval?

• Gjorde man ett fel eller ett nästan fel ("nära händelse")?

• Var mänsklig kontroll tydlig och faktiskt använd?

Spår B: Integritet och informationssäkerhet

• Innehåller händelsen brott mot personuppgiftsäkerheten (t.ex. delning/läckage/åtkomst)?

• Om ja: överväg rapporteringsskyldighet. Integritetsmyndigheten beskriver att brott normalt ska rapporteras inom 72 timmar, och att man kan rapportera stegvis om inte allt är klart. 

• Hälso- och sjukvårdsdirektoratets "Normen" pekar på samma 72-timmarskrav när avvikelsen är ett brott mot personuppgiftsäkerheten. 

Spår C: Styrning, leverantör och verifierbarhet

• Var verktyget godkänt, dokumenterat och använt i enlighet med interna riktlinjer?

• Har leverantören ändrat något (modell, dataflöde, villkor) utan att kliniken har upptäckt det?

• Finns det tillräcklig logg/dokumentation för att förstå händelsen?

3) En praktisk process: "KI-avvikelse" i 6 steg

Detta kan köras som en enkel handlingsplan i kliniken.

Steg 1: Stoppa och säkra

• Stoppa vidare användning i den specifika situationen.

• Säkra nödvändig dokumentation: skärmbilder, tidpunkt, vilken funktion som användes, vilken data som matades in (utan att sprida mer patientdata).

Steg 2: Triage (hur allvarligt är detta?)

Snabbklassificera:

• Patientsäkerhet: skada / potentiell skada / nästan-händelse / "endast kvalitetsavvikelse"

• Integritet: innehåller detta ett säkerhetsbrott? (ja/nej/oklart)

• Omfattning: en patient, flera patienter, systematisk?

Steg 3: Begränsa och tillfälliga åtgärder

• Inaktivera funktion / ta bort åtkomst / stoppa integration vid behov.

• Informera intern roll (ansvarig för kvalitet/risk, IT/integritet) enligt fast rutin.

Steg 4: Utvärdera och varningsbehov

• Vid möjligt integritetsbrott: utvärdera 72-timmars regeln för rapportering och dokumentera utvärderingen. 

• Vid cyber-/IKT-händelser: NSM rekommenderar grundprinciper och strukturerad incidenthantering som del av verksamhetens säkerhetsstyrning. 

Steg 5: Orsaksanalys (vad var det egentligen som gick fel?)

För KI-händelser är det ofta användbart att skilja:

• Tekniskt fel (fel i systemet)

• Användnings-/processfel (saknade kontrollpunkter, oklara rutiner)

• Kompetensbrist (felaktig tolkning av output)

• Förändringsbrist (uppdatering utan kontroll)

• Styrningsbrist (oauktoriserat verktyg / saknade godkännandeprocesser)

NIST AI RMF Playbook är utformad just för att operationalisera styrning och åtgärder över "Govern–Map–Measure–Manage", vilket innebär från styrning till hantering i drift. 

Steg 6: Lärande och förebyggande (kontrollerad iteration)

• Uppdatera policy, utbildning eller verktyglista.

• Lägg till en kontrollpunkt i arbetsflödet (t.ex. "KI-output ska alltid bedömas mot X innan beslut").

• Logga förändringen i ändringslogg (datum, vad, varför, förväntad effekt, när utvärderas).

4) Vad bör dokumenteras i avvikelsen? (minimum)

För att en KI-avvikelse ska vara verifierbar räcker det sällan med "KI gjorde fel".

Minimumfält i avvikelseformulär:

• Vilket verktyg/funktion (namn, version om känt)

• Användningssyfte (vad var avsikten i situationen?)

• Indatatyp (röntgen/foto/text/journalutdrag – utan att kopiera in mer än nödvändigt)

• Output (vad visades/föreslogs?)

• Mänsklig kontroll: vad gjorde behandlare innan beslut?

• Konsekvens (patient, kvalitet, tid, felinformation)

• Dataflöde: delades patientuppgifter med extern tjänst?

• Tillfälliga åtgärder och vem som blev informerad

• Utvärdering av rapporteringsskyldighet (och motivering)

5) Typiska "mönster" som ger återkommande KI-avvikelser

• Otydliga riktlinjer för användning (folk gissar vad som är tillåtet)

• Ingen definierad tolkning av output ("score" utan klinisk användningskontext)

• Shadow AI som kringgår leverantörsbedömning och avtal

• Uppdateringar utan kontroll (prestanda förändras utan att någon följer med)

• För lite utbildning (särskilt om begränsningar och felkällor)

Avslutning

God KI-avvikelshantering handlar inte om att "straffa teknologi". Det handlar om att göra KI-händelser klassificerbara, dokumenterbara och lärbara – så att kliniken kan visa kontroll över patientsäkerhet, integritet och drift.