SMER (Statens Medicin-Etiska Råd) gav i 2020 ut en kort skrift man kallar “Kort om Artificell Intelligens i hälso- och sjukvården” som en kollega skickade mig ett utdrag av. Jag läste utdraget, dvs inte hela rapporten, och så här tänker jag om det.
Continue reading AI i vårdenCategory Archives: Journalsystem
AI…
Det skrivs och hoppas på att AI ska fixa vården. Typexempel är väl Anders Ekholms obegränsade entusiasm.
Men det är viktigt att veta är när AI baserad på learning sets är tillämpligt, och det är inte tillämpligt på det sättet inom medicin. Förklaringen till det är ganska lång, men i korthet kan man beskriva det som följer.
Continue reading AI…Nu blev det allvar
Jag har länge uttryckt i många sammanhang att journalsystem är osäkra, att man inte tar tester av säkerhet på allvar, och att konsekvenserna kan bli extremt allvarliga om data läcker. I synnerhet det sistnämnda verkar man inte riktigt inse. Typ, vad kan vara så värdefullt med min medicinska journal?
Här har ni en bra illustration av vad som kan hända. I Finland blev ett journalsystem för psykoterapi komprometterat. Vad jag hört från kollegas i Finland så vägrade psykoterapigruppen att betala lösensumman, trots att man hotade publicera journaldata.
Tänk på de som berättat om elaka chefer, sina förhållanden, sina drogproblem, m.m. Hur mycket skulle du själv betala för att inte sånt skulle komma ut? Kan kosta dig jobbet, äktenskapet, familjen, körkortet, pilotlicensen… läkarlegitimationen…?1
Och i förlängningen, hur många kommer att våga dela sina känsliga hemligheter med en psykoterapeut i framtiden?
Standardisering
Jag tror inte på gemensamma dataformat. Finns flera skäl, men det viktigaste är nog min personliga erfarenhet över åren. Jag har utvecklat en hel del system och ofta haft att göra med sammankoppling och data transformationer. Jag har också en tid (1 år ungefär) setat med i Europakommissionens standardiseringskommitte för medicinska data (Technical Committee 251). Ett antal olika punkter är för mig tydliga efter dessa erfarenheter:
Att skapa ett gränssnitt för transformation av en bestämd informationsmängd från ett system till ett annat specifikt system är sällan en stor eller krånglig uppgift, utan att använda en standard. Att göra det med en standard är så gott som alltid betydligt svårare.
Att skapa en beskrivning av en transformation mellan system med en i princip okänd och vagt begränsad informationsmängd är “orders of magnitude” mer komplicerat och omfångsrikt. Mängden buggar och missar är också mångfaldigt större. Genom att förbereda sig på näranog “alla eventualiteter”, vilket man måste om det ska vara standard, så har man introducerat en stor mängd felkällor och onödiga begränsningar.
I en framtida förändring så är chansen stor, nästan 100%, att även en bred och omfattande standard inte täcker det man just upptäcker att man behöver, vilket gör att en stor och otymplig standard nu måste ändras och expanderas, med följden att alla parter som använder den också behöver anpassa sig. Detta trots att kanske bara 2 eller 3 av alla parter behöver ändringen. Allt arbete blir alltså mångfaldigt större pga detta, alternativt förhindras.
Eftersom det är så svårt att anpassa en standard till senare utvecklingar, försöker man förutse framtiden när man gör standarder, vilket nästan till 100% blir fel och begränsar innovation isf att befrämja den. Varje feature är ju också en begränsning.
Om man jobbar utan standard däremot, så kan man utveckla precis det gränssnitt man behöver, inget mer, och är man fri att adaptera det när man vill om bara de två parter som är inblandade är med på tåget. “Orders of magnitude” lättare.
Skulle det vara så att man hade en situation där flera system utväxlar en mycket enkel informationsstruktur och det finns ett mycket stort antal kommunikationsparter, medan informationsstrukturen är relativt statisk, ja då är en standard bra. Tänk HTTP, XML. Enkla, t.o.m. mycket enkla, specifikationer med många miljoner användare.
Men i medicin är det inte så. Informationsmängden ändras hela tiden, ingen vet hur den bör se ut i framtiden, och den är extremt komplex och omfattande. Kommunikationspartner är mycket få till antalet; ett större journalsystem samtalar med enstaka, kanske ett dussin, partner och dessutom är dessa olika på varje annan installation. Det finns alltså extremt få fördelar med standardisering men gigantiska nackdelar.
Mitt år på standardiseringskommitten lärde mig, förutom en hög grad av cynicism, att arbetet med sammankoppling av medicinska system bör ledas av att man i första hand strävar efter att eliminera behovet av standarder. (Notera “behovet av”). Kan man utveckla system som kan passa i en helhet utan att man behöver en standard, så blir livet bra mycket enklare och trevligare och systemen bättre.
Jag tror att strävan efter standarder, jäms med drivet mot “stora gemensamma system”, är vår största fiende i kampen för bättre system inom vården.
I modern programmering talar man mycket om principen YAGNI (“You Ain’t Gonna Need It”). Dvs, designa inte features i software för teoretiska framtida behov. Dessa features blir nästan aldrig använda och sitter bara ivägen. Europeiska standarder inom vård-IT är ett prima exempel på detta.
Å andra sidan, om man nu har en mängd system som redan har kopplat ihop sig och gjort det på ett fåtal bra sätt, då kan man i efterhand rekommendera ett av dessa sätt över de andra. Dvs utnämna en bevisat bra metod till standard i efterhand. Men där är vi inte på långa vägar. Nyckelprincipen här är att man endast ska standardisera det som är i bruk och bevisat funktionellt, aldrig på förhand. (Det är förresten så som ANSI, IEEE och ISO funkar. I Europakommissionen går man den meningslösa teoretiska vägen istället, det jag beskrev ovan.)
Moralen av detta: en standard ska aldrig föregå och leda en utveckling. En standard ska alltid och enbart vara ett val mellan flera olika konkurrerande och redan realiserade lösningar. Mao, utveckla först, installera, använd. Sen möjligen välja som standard. Gäller att inte göra det bakvänt.
Stora eller små system?
Det största tankefelet man gör inom vårdens IT, både från teknikerhåll, tjänstemän och från användarna är att man blandar ihop tillgänglighet av data med storleken på systemen. Det är två helt skilda saker.
Man tror att bara alla använder samma system så kommer data att vara tillgängliga överallt och vice versa, att om man inte har samma gigantiska system överallt så kan man inte dela data. Det här var lite grann sant på 80 och 90-talet när man enbart hade tillgång till data inom varje tillverkares system, men då berodde det inte så mycket på tekniska svårigheter, men på oviljan av leverantörer att på något vis göra livet lättare för konkurrenter. Man diktade upp en hel del skäl till varför alla kunder borde köpa deras produkt för att göra utbytet möjligt. Och kunderna gick på det i mycket stor utsträckning. Det lever kvar.
Om man ser på jämförelsen mellan ett gäng små och olika system som utbyter data när det behövs å ena sidan, samt stora regionsomspännande system med gemensam databas å andra sidan, så finns både fördelar och nackdelar.
Fördelar med stora system
- regionernas IT avdelningar kan alltid hänvisa till en och samma leverantör oavsett problem. CYA. Samt “Ingen förlorar jobbet för att de köpt Cosmic eller TakeCare”.
Nackdelar med stora system
- utvecklingen är svindyr. Komplexiteten och antal fel i systemet växer exponentiellt, dvs ett dubbelt så stort system har kanske 3-4 ggr så mycket kod och buggar och tar 3-4 ggr längre tid att utveckla.
- anpassningen för individuella behov får lida. Mao får användarna anpassa sig till systemet isf tvärtom.
- datakoppling till andra system behöver fortfarande lösas om man inte lyckas med konststycket att sälja Cosmic till hela galaxen. (Fast det kanske motiverar namnet…)
Fördelar med små och diversa system
- varje specialitet kan i princip hitta ett system som funkar bäst för dem.
- utvecklingen är mycket billigare, även alla olika system sammantaget. Se ovan ang exponentiell komplexitet.
- mer “resilient” vid tekniska problem. Inte hela regioner som går ned vid problem.
Nackdelar med små och diversa system
- man behöver fler integrationsarbeten mellan system. Men detta är betydligt mindre svårt och kostsamt än man gärna låter påskina. För priset av en enda integration mellan regionsystem kan man få bra många mindre integrationer.
I allt detta, glöm inte att de som håller i narrativet är just de stora leverantörerna och regionernas tjänstemän. Dessa två grupper har intresse av stora gemensamma system av skäl jag redan givit ovan. De har inget intresse av en balanserad bedömning av problemet. Och som jag sagt tidigare har dessa grupper ett mycket begränsat intresse av att göra vårdpersonalens jobb lättare. De ser det inte som deras uppgift.
Det blir ju inte bättre av att tekniskt rätt oinformerade läkare på alla kanter regelbundet kommer ut och “kräver” nya, stora, gemensamma system för att “äntligen” fixa problemen med tillgänglighet av data. Men, ja, eftersom makthavarnas önskan sammanfaller med detta, trots att incentiven är perversa, så får de inget mothugg. Och vi fortsätter att ersätta dåliga system med än sämre och dyrare.
Cosmic nere och därmed ett helt landsting
Cosmic ligger nere idag. Det är i och för sig inte så upprörande eftersom system av den här komplexiteten alltid kommer att ha sina mörka moment och sluta att fungera. Det vet vi.
Vad som är upprörande är däremot att det har sådana konsekvenser. Alla dessa system här i landet är byggda på samma sköra sätt, nämligen som monolitiska kolosser och det är helt enkelt en dålig systemarkitektur. Det är ogenomtänkt av producenten att bygga systemen så här trots att jag misstänker att det är beställarna som insisterar på centrala, gigantiska system. Sannolikt eftersom man tror det är lättare att hantera.
Hade man byggt, eller snarare rullat ut, Cosmic (och Take Care och resten av gänget) som mindre och asynkront sammankopplade system, ja då hade ett systems problem begränsats till den avdelning, klinik eller vårdcentral den betjänar i stället för att dra ner ett helt landsting på en gång.
Det är ingen rocket science att bygga så och det är inte heller något nytt. Kostar inte ens mer och är dessutom mer skalbart än de gigantiska och i särklass sårbara system man nu har.
Men det verkar som man bara driver det här än längre. Man vill ju bara ha större och större centraliserade system. Man tror att man kan undvika systemfel, medan man egentligen borde planera för problem; vi vet ju att det alltid händer.
Q.E.D. – recept
Receptförskrivning1 är lite annorlunda och lite mer komplicerat. Vissa element vill vi att systemet lär sig i kontexten “kontaktorsak” eller “bedömning”. Andra element vill vi ta från en mer grundläggande källa. Jag tar elementen en för en.
Q.E.D. – sökord
Låt oss återvända till notatmallar som jag redan tidigare nämnt, men nu med fokus på hur man matar in information i varje sökord. Där finns mycket att hämta i hjälp och effektivitetsvinster. Om man kan göra införandet av klinisk information via journalmallens sökord snabbare och enklare än att diktera journalen, så har man gjort en rejäl vinst.
Q.E.D. – kontakt och bedömning
Vi har sett “kontaktorsak” (eller “problem”, samma sak1) ett bra tag nu. Kontaktorsaken är själva grunden för Q.E.D. eftersom alla förslag systemet ger är baserade på just kontaktorsaken/problemet. Det är lätt att inse, som läkare, att kontaktorsaken definierar vad vi kliniskt undersöker och hur vi planerar en utredning. Till exempel ser vi att vid en kontaktorsak “diabetes typ 2 årskontroll” så ligger det för handen vilka sökord vi vill se i journalnotatsmallen. De mest sannolika remisserna kan man också härleda till funduskopi, fotvård, samt dietist2.
Q.E.D. – sjukintyg
Att fylla i sjukintyg för Försäkringskassan är nog bland det jobbigaste administrativa jobbet vi har som läkare. Det är rätt mycket att skriva och det är svårt att formulera sig snabbt och precist. Det är dessutom svårt att tolka in vad man ska skriva som “aktivitetsbegränsning”, vilket är det FK baserar sig på mest. Har man en snygg formulering för en typ av fall så vill man gärna återanvända den, i synnerhet som funktionsnedsättning och aktivitetsbegränsning inte varierar så mycket mellan olika patienter med samma problem.