Category Archives: IT Politik

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.

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.

Watson igen?

(Jag skrev det här som ett inlägg på SFAM forumet, så det är lite i svarsstil.)

Jag tror det är ett misstag att bedöma IT i vårdsituationer utifrån Watson. Watson fyller en viss speciell funktion (om det funkade) som inte konkurrerar med vad vi gör dagligdags. Min bild av hur “medicin” ser ut, sett ur ett kunskapsprocess perspektiv är att det handlar om tre nivåer:

1. Ren kunskap om biologin och patologin, typ EBM, epidemiologi, m.m. I princip inte individuellt patientorienterat.

2. Tillämpning och anpassning (implementering) av ren kunskap i det individuella patientfallet.

3. Kännedom om patientens egenskaper, mätvärden, tidigare tillämpade diagnostiska medel och behandlingar.

Continue reading Watson igen?

Lecture på KI

Till min stora glädje blev jag inbjuden att ge en lecture på Engelska för “International Masters Programme Health Informatics” på Karolinska Institutet och jag gav den förra måndagen. Vi spelade in hela föreläsningen, 3.5 timmar, på video och nu har jag hållit på en vecka för att konvertera, dela in, lägga till slides, fixa ljudet, m.m. Föreläsningen omfattar 12 sektioner, men resulterade i 20 videos eftersom YouTube begränsar till max 15 minuter per video.

Alla 20 finns i en playlist på YouTube:

http://www.youtube.com/user/mitmab#p/c/0F725A1175F25924

Lecture notes finns också:

https://iota.pro/images/8/89/Ln20101206.pdf

Föreläsningen omfattar allt möjligt som jag har tankar om i Vård IT, och som bekant är det väldigt mycket. Sista sektionen, nr 12, handlar om iotaMed och innehåller även de nya vyerna, dvs kvalitetsregister och kronologisk journal. Den delen är dryga 50 minuter i sig.