Dagens Industri arrangerade ett webinarium “Från stetoskop till datadriven vård”. Det var beklämmande. Men inte på något sätt oväntat. När man varit med i “IT i Vården” svängen ett tag, så känner man igen mönstret från vartenda seminarium och symposium de senaste 20-30 åren. För en läkare som inte är van vid det ger det alltid en overklighetskänsla att höra hur så många annars rätt intelligenta människor så komplett kan ha missförstått det område de ju byggt en karriär på att supportera och förbättra.
Continue reading DI/MS webinariumCategory Archives: Utveckling
AI i vården
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årdenAI…
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…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.
Teknikoptimism och patientmakt
En deprimerande och väldigt tidstypisk artikel i Veckans Affärer.
Den här artikeln är fylld med teknikglädje och allt vad digitalisering kan göra för vården. Skriven ur synvinkeln av systemdesigners och beskriver till 99% meningslösa lösningar på problem som antingen inte existerar eller som ska lösas på helt andra sätt.
Argumenteringen är utifrån önskningar om hur vården ska bete sig efter patientens och teknikers önskan (märk väl, inte behov) med en total frånvaro av argument baserade på vetenskap. Snarast tvärtom, nämligen att “individuell” medicin är bättre än det vi gör nu, evidence based på gruppnivå (fast debattören inte ens nämner det).
I slutklämmen, som vanligt, kommer lösningen nämligen att vården ska förstå tekniken bättre. Inte en antydan att tekniken ska förstå vården bättre. Själv har jag en fot i vardera lägret och det är för mig smärtsamt tydligt att huvudproblemet är kunskapsbristen hos systemutvecklarna om vården och inte tvärt om.
Men så här blir det om vi överlåter till våra dear leaders att sköta hur vården förses med hjälpmedel. Våra dear leaders kan väldigt lite om vården och medicinsk vetenskap och behöver därför av ren självkänsla tona ner vikten av det. Och vi låter det ske.
Sånt här nonsens dominerar debatten och kommer att fortsätta att göra det tills läkare organiserar sig och handgripligen ändrar på styrningen av vårdteknik. Tråkigt nog verkar man inom läkarkåren i Sverige inte vilja anstränga sig utan stannar hellre på sidolinjen och klagar. Det är onekligen bekvämare.
Artikeln tillåter förresten inte kommentarer. Vilken överraskning.
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.