Ända sedan 1980-talets slut har utvecklingen av IT-system för sjukvården pågått. Utan detaljkännedom om landstingens olika budgetar under de gångna 20 åren, anar man att det satsats miljarder på programvaruutveckling i vården. Under fyra år kring millennieskiftet deltog jag aktivt i några av dessa projekt och fick en liten inblick i denna verksamhet.
Nyligen togs frågan om ­datorstöd i vården upp i medierna [1], eftersom man nu – trots 20 års utvecklingsarbete – finner att en femtedel av alla lex Maria-fall är IT-­relaterade. Man sitter med redan föråldrade inkompa­tibla system som till exempel inte kan hantera röntgenbilder och elektroniska recept samtidigt, eller där olika delar av patientens journal finns i olika programvaror, på olika datorer. Exemplen kan göras oändliga.
Varför lyckades bankerna och inte sjukvården?

Sedan slutet av 1990-talet har jag skött alla banktransaktioner via Internet. Hur kommer det sig att bankerna lyckats konstruera så säkra system att de kan tillåta kunderna (patienterna) hantera sina egna konton med enkla knapptryckningar och inloggningssystem? Beror detta på att hanteringen av pengar är mindre komplicerad och kräver mindre säkerhet än sjukvården? Tillåt mig att besvara frågan med ett provocerande enkelt »Nej«.

Vilken är då skillnaden? Min uppfattning är att det föreligger ett fundamentalt glapp mellan sjukvården och IT-branschen. Sjukvården är en offentligt finansierad verksamhet som bedrivs av människor som är utbildade till att vårda sjuka i en icke vinstgivande miljö. IT-branschen är en sektor inom industri/handel, en verksamhet som är direkt intäktsfinansierad och konkurrensutsatt.
Det fundamentala glappet uppstår när kompetenta personer inom vården ska ställa krav på en kompetent IT-­leverantör. Inom vården saknas enligt min uppfattning den detaljkunskap om teknik, handel och affärer som krävs för att förhandla fram realistiska avtal med en industripartner inom IT-sektorn.
Resultatet har blivit att sjukvården under 20 år mjölkats på miljarder, utan att de förväntade välfungerande systemen levererats.
Vad händer med IT-sektorn inom sjukvårdsområdet den dag då vi är nöjda och allt fungerar? Principen är att upprätthålla vårdens behov av vidareutveckling och handpåläggning, som kan faktureras fortlöpande. De miljarder som investerats med »dålig avkastning« är skattemedel som skulle kunnat förkorta köer och lagts på kärnverksamheten i stället.

Hur kan problemet lösas? Under mina år inom IT-området ritade jag ofta och berättade om några idéer kring utvecklingen av programvara för sjukvården. När jag nu ser resultatet av det som pågått under 20 år känns det än mer angeläget att få ventilera några principer som skulle kunna underlätta arbetet för alla parter.
Vid beställning av datasy­stem till vården har man försökt precisera önskemål om funktioner i en detaljerad kravspecifikation som ofta utarbetats under lång tid. Man har presenterat en slags telefonkatalog över funktioner som ska finnas, som dock under resans gång hunnit bli föråldrade när specifikationen väl lagts och avtalet med leverantören tecknats.
Ofta vet leverantören att kravspecifikationen aldrig kommer att kunna uppfyllas i detalj och att funktioner och krav kommer att förändras under utvecklingstiden, men avtalet gör att man knyter upp sig mot en kund som kan faktureras.

Tillåt oss att för en stund reflektera och göra en grov jämförelse med byggsektorn. I tidernas begynnelse konstruerades våra bostäder av det byggnadsmaterial som fanns tillgängligt. Olika icke kompatibla material som trä, sten och lera blandades. Med tiden utvecklades byggnadskonsten, och som ett resultat finns nu Svensk byggnorm. Denna möjliggör leveranser av olika komponenter till ett husbygge från olika leverantörer som specialiserat sig på till exempel fönster eller dörrar, rörkonstruktioner eller eldetaljer. Man kan till och med köpa rördelar som lekman hos olika leverantörer och veta redan i butiken att delarna kommer att passa ihop.
Att bygga ett enda övergripande IT-stöd för sjukvården, till exempel ett digitalt journalsystem, som täcker samtliga behov från invärtesmedicin, IVA, röntgen, labb, psykiatri, klinisk fysiologi, kirurgi är tekniskt omöjligt. Det borde var och en som deltagit i detta arbete insett för 20 år sedan – jag också.
I stället borde man koncentrerat sig på att skapa en svensk IT-norm för konstruktion av moduler som kan kopplas ihop till ett helt »hus«. På detta sätt skulle de olika verksamheterna kunna välja sina moduler och koppla samman dessa till en fungerande enhet. Detta skulle även diversifiera marknaden och tillåta fler IT-företag att leverera delar till olika kunder inom vården.
Ansträngningar görs för att skapa europeiska standarder på området, men så länge vi inte har välfungerande sy­stem på det nationella planet ter sig detta som »överkurs« och något överambitiöst – ­såvida inte utbytet av medicinsk information över gränserna i Europa ska prioriteras före utbytet mellan våra inhemska vårdinstanser som kommun, primärvård och sjukhus?

Hur ska då problemet med kravspecifikationen kunna lösas? IT-system är i ständig förändring, de kommer aldrig att bli färdiga och levererade som en klar produkt. Utvecklingen pågår ständigt, antingen vi vill det eller inte. Hur ska vi då kunna skapa ett håll­­bart utvecklingskoncept? Låt oss en stund studera IT-gubben och det »venösa« och »arteriella« flödet i hans kropp (Figur 1).
Nya idéer om IT-lösningar och funktioner skapas ständigt inom verksamheten. Dessa idéer borde utgöra fundamentet i de system vi bygger, eftersom de speglar våra reella behov. Idéerna behöver dock sorteras och filtreras i ett första steg (Arbetsgrupp 1) med hänsyn till till exempel lagstiftning och andra faktorer.
När en idé godkänts vid den första granskningen, bör den sändas vidare för prissättning och prioritering (Arbetsgrupp 2). En liten förändring kan vara komplicerad att bygga, och kosta mycket pengar, medan en stor ändring kan vara enkel att göra och därmed billigare. Förändringarnas angelägenhetsgrad kan ju också variera. När prissättning och prioritering genomförts kan beställningen göras hos IT-leverantören.
Efter leverans kan Arbetsgrupp 2 utföra det första funktionstestet och antingen återremittera ärendet för modifikationer eller acceptera leveransen. Samtidigt som Arbetsgrupp 2 får tillbaka ärendet i form av en leverans, informeras idégivaren om hur förslaget omhändertagits. Väljer man att inte gå vidare med förslaget ska idégivaren informeras även om detta.
När leveransen skett, kan arbetet faktureras. Detta genererar mindre fakturor med kortare intervall, vilket borde underlätta även för IT-leverantören.

Problemet med stora beställningar och omöjliga avtal måste enligt min bedömning angripas på ett annorlunda sätt. Eftersom en stor övergripande och färdig produkt inte kan levereras, kan den inte heller offereras eller beställas som en vara. I stället måste utvecklingen ses som en slags ständigt pågående »snurra« (Figur 2). När en idé tagits om hand enligt »Gubb-modellen«, och levererats ut till verksamheten, kan den faktureras.
Redan när leveranser sker, kommer de sannolikt att generera nya idéer om modifikationer när de testats i praktiken. Dessa idéer bör i sin tur tas om hand på nytt enligt »Gubb-­modellen« och åter­remitteras för vidareutveckling (om så anses befogat i Arbetsgrupp 1). Snurran kan således illustreras med pilarna som leder framåt i en ständigt snurrande spiral.
Scenariot innebär att det inte går att upprätta ett köpeavtal. I stället skulle kunden kunna betala ett slags abonnemang över tid, där man abonnerar på möjligheten att vara med och utveckla programmet. Inget säger att arbetsgrupperna måste bestå av medarbetare från bara ett landsting eller en region – ju mer övergripande överenskommelser som kan göras, dess bättre.

Under min tid inom IT-området diskuterades ofta frågan om patientsekretess som den mest centrala, liksom olika lösningar för att göra journalinformationen begränsad, till och med mellan enskilda kliniker inom ett och samma sjukhus. Då verkade behovet av informationsutbyte mellan till exempel primärvård och specialistvård vara av helt underordnad betydelse jämfört med sekretessen.
I dag, 10 år senare, verkar man ha insett att begreppet patientsäkerhet väger betydligt tyngre och att tillgången till information är grundläggande för en professionell sjukvård.

Sekretessfrågan är naturligtvis viktig, men man kan reflektera över om det inte är viktigare att nödvändig information finns till hands exempelvis i en akut vårdsituation? Vi är ett resande folk som till och med kan bli sjuka utanför vårt eget landstings gränser!
*
Potentiella bindningar eller jävsförhållanden: Inga uppgivna.


Figur 1. IT-gubben är ett förslag på hur nya idéer om IT-funktioner kan hanteras.



Figur 2. IT-utveckling bör ses som en slags ständigt ­pågående »snurra«.