Utvecklingsfilosofi

Jag håller med, men jag kan inte låta bli att undra hur man skall göra om man behöver mycket eller komplicerad funktionalitet. Det ideala borde förstås vara om man kan bilda många sådana små team. Men hur skall de i såna fall samverka för att inte slöa ner varandra? Vad händer när man då och då oundvikligen måste bygga in beroenden mellan delar från olika team?

Denna motsägelse har jag inte sett någon ge ett tillfredsställande svar på. Har du?

Det mumlas mer och mer om att XML kanske inte alltid är ett bra sätt att strukturera information. Här och här är några inlägg. Jag tycker att det ligger en hel del i det som sägs.

Häromdagen blev jag retad av min fru för att jag stod och tittade på myror som på myrors vis stretade fram och tillbaka över vägen. Jag fick svårt att att föklara att jag alltid har misstänkt att det finns mycket att lära av myrorna.

En intressant sak med myror är t.ex. att de väldigt ofta gör fel. Om en myra t.ex. hittar ett bra ställe med smarrig näring så lägger hon upp ett tydligt doftspår mellan maten och stacken och vips uppstår en myrstig med ett otal myror som hämtar in förfriskningarna. På avstånd ser det imponerande välordnat ut, men om du följer en enstaka myra ser du att hon sällan följer spåret raka vägen. Istället vinglar hon fram, nästan berusat, och kan plötsligt sticka iväg helt åt skogen (nåja, hon är ju i skogen hela tiden, men du förstår poängen).

Det är naturligtvis uttänkt. Om alla följde den utstakade vägen skulle ingen nånsin hitta nästa ställe med godbitar.

Det är viktigt att göra fel ibland, annars uppstår ingen utveckling. Det är därför utopier är så fruktlösa – om någon påstår sig kunna leverera alla svaren, den ultimata lösningen, så finns det inget utrymme för fel. Och det är därför de där flotta ppt-bilderna och de kloka herrarna med alla svar och inga frågor är så missledande.

Så nästa gång du hör någon lägga fram den ultimata lösningen för informationsförsörjningen i vården: luta dig tryggt tillbaka i förvissningen om att du som mest bara är förvirrad förmodligen är betydligt närmare målet.

Det finns forskning som visar att skillnaden i produktivitet mellan olika utvecklare med samma erfarenhet är stor, ofta i storleksordningen ett till tio eller mer.

Man slås av en del frågor:

• Varför är då skillnaden mellan olika slutprodukter inte ett till tio?
• När jag rekryterar utvecklare, varför letar jag inte med ljus och lykta efter de enstaka hyperproduktiva individerna och betalar dem fem-tio gånger så mycket?
• Varför kan jag inte gå till min chef med mina stora, välskrivna, buggfria kodmassor och säger: kolla vad bra jag är, du måste tiodubbla min lön?

Förgäves har jag bett om mothugg och kritik till mina inlägg. Nåväl, i väntan på andra debattsugna personer får jag väl plocka upp handsken själv...

Jag har tidigare varit kritisk till att det mäts så mycket i vården. Efter att ha träffat Anna-Karin Nesheim på Enalog har jag bytt uppfattning. Hon berättade hur hon som verksamhetsansvarig på Axessakuten med hjälp av nya IT-system hade mätt väntetider och patientflöden i olika delar av verksamheten. Efter en noggrann analys kunde de organisera om sig och minska bemanningen, ta emot fler patienter och reducera personalens stress. Mycket intressant.

Mätningen byggde på integrationer mellan Journal III från Profdoc (där jag jobbar), kösystem från NemoQ och anpassningar byggda av Elicit. Nu har NemoQ, Elicit och personer med bakgrund på Axessakuten startat bolaget Enalog för att föra idéen vidare. De erbjuder en spännande mix av webbaserad tidbokning, köhantering, online-betalning och uppföljning/statistik. Lycka till!

Och förresten: jag har tidigare skrivit att små korta projekt har större chans att lyckas. Elicit verkar, enligt vad de påstår på sin webb, ha drivit detta till sin spets. När de beskriver sitt projektupplägg SMILE tycker de att ett IT-projekt bör ta 6 veckor (och dessutom levereras till fast pris). Att döma av resultatet från Axessakuten lyckas de dessutom göra detta med bibehållen kvalite. Keep up the good work, Stuart and the rest of you!

Inte precis någon nyhet men det tål en påminnelse: för systemutveckling gäller ”small is beautiful”.

Redan 1998 kom Standish fram till att den effektivaste storleken för IT-projekt är 6 personer som jobbar i 6 månader. Detta efter att ha utvärderad ett antal tiotusen projekt. Två år senare rapporterade man att fyra personer var ännu effektivare – så små projekt var nämligen inte inräknade i den tidigare undersökning.

Alltså: gör vad du kan för att dela upp dina projekt i små, självständiga delar. Om du räknar med att utvecklingen drar över 6 – kalendermånader eller människor – så försök att dela upp eller ändra kraven. Dina chanser att levererar en lyckat lösning ökar rejält.

När vänner och bekanta får höra vad jag jobbar med ställer dom ofta den uppenbara frågan: varför har personalen idag inte tillgång till journalen som skrevs där jag var förra veckan? De har ju datorer på båda ställena?

Jag känner mig alltid lika ställd inför den frågan och ger mig ut i långa träiga utläggningar, och den som frågade tappar snabbt intresset. Men varför är det så svårt att svara? Man kan ju tycka att det skulle gå att dra till med en fin generell formulering; ett enkelt svärdshugg genom den gordiska VårdIt-knuten.

P-O Kaiser*, som framgångsrik drev projektet för Gemensam Läkemedelslista i SLL förra året, resonerar i den här artikeln bland annat kring informationskvalité i de befintliga systemen. Han hävdar att informationskvalitén är för låg och att de därför måste bytas ut mot en specialbyggd applikation. Jag hävdar att det inte är riktigt så enkelt och att det finns en del att tänka på.

(* Rättelse: Sedan detta skrevs har P-O Kaiser påpekat för mig att det inte var han utan projektledaren för GVD som uttalade sig om informationskvalité. Mitt misstag.)

Min blogg skall inte vara ett reklamblad för Profdoc. Men jag kan ju inte vara så idiotobjektiv att jag helt låter bli att berätta om vad vi själva håller på med.

I höstas startade jag upp ett nytt verksamhetsområde. Det gäller system för realtidsintegrationer och går under samlingsnamnet CPS - Common Patient Services (irriterande nog ännu en trebokstavsförkortnting…).

Vi vill tassa in på marker där ingen egentligen varit förut – att integrera system och funktioner på ett nytt sätt, samlat i lättbegripliga, packeterbara tjänster och produkter för spridning i stora volymer.

Du kan följa utvecklingen på vår CPS-webb. Just nu håller vi på med patienttjänster, t.ex. webbtidbokning. Tidigare har vi gjort klart vår patientöversikt, en slags NPÖ med regionalt fokus (RPÖ?).

Douglas Adams skriver i Liftarens Guide till Galaxen om universums mest framgångsrika företag. Deras produkter, från brödrostar till rymdkryssare, är genomgående usla, men de säljer som smör eftersom de konsekvent byggs enligt principen ”dölj alla grundläggande konstruktionsfel med brister i designen”.

Vi utvecklare på Profdoc brukar skratta gott åt den principen. Jag menar, så gör man ju inte i verkligheten.

Eller?

Användarna på den här vårdcentralen känner att systemet inte är riktigt färdiganpassat för dem. Men när företaget bakom konsekvent misslyckas med att leverera system (se hur illa det går i Värmland), är det verkligen bara ytlig design? Eller har brister i designen lyckats dölja mer grundläggande konstruktionsfel?

Vi hör IT-strateger som bokat upp sig på Soarian från Siemens säga saker i stil med att ”anpassning för primärvården är inte riktigt klar än”. Men när företaget år efter år inte är riktigt klart är det kanske ett tecken på något mer basalt problem än en anpassning? T.ex. att system avsedda för USA-marknaden där vården har helt andra organisatoriska förutsättningar är grundläggande fel för Sverige?

Eftersom jag inte lyckades igår skall jag nu försöka förklara varför lösningarna på de olika hörnen bör vara olika.

Verksamhetsstöd. På vår whiteboard stod journalsystem, jag vill även inkludera andra verksamhetsnära system som röntgensystem, labsystem, operationsplanering etc. Dessa används intensivt och kräver en hög grad av interaktivitet. Fokus är att få jobbet gjort, det måste gå snabbt att hämta och skriva.

Nyckelord: interaktivitet, snabbhet

Patientöversikt. Här räcker det gott att titta – du behöver inte skriva. Patientöversikten används mer sällan i det dagliga värvet, alltså är prestandakraven lägre. Däremot finns det andra utmaningar, nämligen att samordna information från olika system så att det bli läsbart.

Nyckelord: läsbarhet, samordning

Kvailtet/statistik. Här krävs ingen realtidsdata. Prestandakraven har en helt annorlunda karaktär och därför är de system som är utmärkta för verksamhetsstöd dåliga för statistik. Däremot finns stora krav på standardisering (mycket större än i de andra hörnen) för att kunna göra relevanta jämförelser och avancerade bearbetningar.

Nyckelord: jämförbarhet, bearbetning

Informationen i de olika systemen är bitvis densamma. Men det vi skall göra med information är helt olika. Det är därför det ställs olika krav på systemen.

Det som saknades i bilden var ett verksamhetsövergripande processtöd. Detta skulle jag vilja rita in så här:

Såna här bilder innebär kanske en förenkling bortom gränsen till dumhet. Men det är ju så skönt att förenkla ibland. Vad sägs om det här som en bild av vårdens IT-behov?

Hittills har de flesta leverantörer, t.ex. alla vi som levererar journalsystem, i huvudsak sysslat med verksamhetsstöd. Ofta med fokus på att dokumentera sånt som redan är gjort.

Så var det också (enligt samma person) i bankvärlden för sisådär 10-15 år sedan. Sedan dess har man arbetat mycket mer med processtöd, dvs IT-system som spänner över fler verksamheter, med inbyggda möjligheter att även agera över organisationsgränser, alltså mellan banker.

• Ta inte bort det som är bra i dag (se denna blog om ett misslyckat införande). Alla, och jag menar ALLA, ansatser för processinriktning jag hitills sett har glömt det!

• Processtöd är mycket svårare än verksamhetsstöd, helt enkelt därför att det är så många fler parter inblandade. Finansiering av såna system kan vara knepigt.

Är det någon som vet hur man har löst det här dilemmat i andra branscher? Det kanske finns nåt vi kan stjäla, förlåt, jag menar lära oss av…

Separeringen förbättrar inte förståelsen – information sammanställs ändå i gränssnittet (eller borde göra det). Men den gör den enkla hämtningen från journalsystemet till en mardröm på grund av att systemen (ofta av goda skäl) lagrar de fyra fälten olika. Om man istället låtit varje system skicka en sammanställd textrad som i exemplet hade saken varit en barnlek.

Och det här är bara ett exempel i raden. Det finns många fler…

Det här gäller förstås enbart i situationer då information bara skall läsas (alltså de flesta situationer). Om information skall bearbetas statistiskt eller återanvändas på annnat sätt måste en bättre struktur användas.

Det finns tillräckligt många svåra saker i livet - låt det enkla förbli enkelt.

På sistone har jag träffat kollegor både hos leverantörer och beställare som är övertygade anhängare av att låta alla, eller åtminstone många, av kundens applikationer lagra sin patientinformation i samma databas.

Det låter ju praktiskt. En enda databas att drifta. Ett ställe att hämta statistik från. Osv.

Men hur blir det för användarna? När jag har byggt applikationer har lagring alltid gått hand i hand med användargränssnittet. Om det finns ett fält för diagnoskod på skärmen så finns ett fält för diagnoskod i databasen, och ett fält för diagnoskod i datasetet som flyttar datat genom mellanlagren. Eller som i Take Care från Profdoc Care: om det finns en skärm för att mata in en hel diagnos så finns ett objekt på servern som innehåller all data som utgör en enskild diagnos.

Varför är det så här? Varför gör vi inte en generell lagringsstruktur i databasen som kan lagra all typer av information i samma struktur? Så gott som jag förstår, är skälen prestanda och begriplighet. Hämtning av data blir effektiv. Och det är lätt att förstå sambandet mellan information som visas för användare och information som lagras, vilket förenklar utveckling.

Alltså vinner användarna. De får snabba applikationer som lätt kan byggas om efter deras behov.

Men vissa konkurrenter och kunder verkar alltså ha en annan syn, förmodligen grundad på andra aspekter av gemensam lagring, eller på aspekter som jag inte har förstått. Jag kommer säkert att återkomma till detta. Till dess ser jag fram emot kommentarer; helst avvikande – mothugg är ju så mycket mer spännande än medhåll.