Erik Sundvall var vänlig nog att påpeka vikten av att diskutera archetyper och openEHR projektet i samband med mina anmärkningar om monolitiska system och exponentiella skalfaktorer. Hans kommentar innehåller länkar som jag också återger på slutet av detta inlägg.
Själv var jag med som observatör i CEN TC251 1995-96 och då blev jag mycket frustrerad över den omfattande byråkratin, och som jag upplevde det, den stora bristen på användbara resultat. Mycket lite av de standarder som producerades på den tiden användes i verkligheten vare sig före eller efter standardiseringen. För en “hands-on real developer” som jag var då och fortfarande är, föreföll hela processen som totalt verklighetsfrämmande, det var helt orealistiskt torrsim från början till slut. Själv hade jag ett uppdrag från Belgiska staten och var jag ansvarig för en “profil” av “Episode of Care Summary” för Belgien, vilket var skälet till att jag hamnade i TC251. Jag kämpade heroiskt för att kunna använda CEN standarden, men fick till slut lämna det föreskrivna spåret och hitta på egna lösningar för att ens tillnärmelsevis få det att gå ihop. Om min profil någonsin blev antagen som Belgisk standard har jag ingen aning om, men jag hoppas för Belgiens skull att dom lät bli. Jag måste medge att min skepsis mot dylika Europeiska standardiseringsprocesser uppstod under den perioden.

Nåväl, så nu läser jag de openEHR dokument som Erik tipsade om och jag märker att jag missat något stort, nämligen att man börjat tänka i mycket mer användbara banor efter att jag gett upp (typiskt… suck…). Jag känner igen riktiga utvecklartankar från folk som antagligen själv byggt system och vet vad som är meningsfyllt och vad som inte är det. Det här var riktigt uppfriskande. Tackar, Erik!

Det är mig inte helt klart och tydligt var openEHR kommer ifrån, men det verkar som om det är ett initiativ från en grupp människor som har utgjort, eller kanske fortfarande utgör, en del av CEN TC251, men det verkar inte vara ett CEN initiativ. Antingen blir det tydligt för mig senare, eller också kommer Erik eller någon annan läsare göra klart för mig hur gruppen situeras egentligen. Hur som helst, jag är mer intresserad av vad dom säger än vem dom är (vilket förklarar till en del varför jag aldrig kommer att komma långt i politik).

Redan tidigt i arkitekturen [2, p 17] delar man upp arkitekturen i två modell-lager, nämligen den underliggande “Reference Model” som implementeras i software, medan allt vad som är kliniskt innehåll hamnar i ett annat lager (“Archetype Model“) som inte är hårdkodat. Det här är en klassisk “add another level of indirection” som ju brukar lösa de flesta problem inom software development. Man kan nog se det som om “reference model” egentligen är en speciell platform för vård-it, en sorts virtuell maskin, men det är bara en illustration av idén. Om man ser det så, så har man egentligen skapat ett programmeringsspråk som är lätt att använda för icke-programmerare, och det är alltså det andra lagret, det lager som domänexperterna ska hantera.

Det sättet att resonera gör ju att man blir av med “nej, först gör vi det här” syndromet. Så t.ex. den totala paralys av utveckling som kan ske om man får för sig att man först måste komma överens om en data struktur eller en gemensam termkatalog. Vad openEHR gör, som många av oss försökt göra många gånger men inte fått gehör för, är att delegera ner ansvaret för semantik till det domänspecifika lagret. Annorlunda formulerat: “fundera ut termkatalogen medan vi skriver systemet. Ni kan ändra hur mycket ni vill i efterhand.” Mycket av dessa standarder och överenskommelser behövs inte alls innan man bygger systemen, om systemen bara byggs rätt. Man skulle kunna kalla det en Politik-Tolerant-Arkitektur (PTA). Smutt.

Meddelandestrukturer lämnas utanför denna arkitektur. Så länge meddelandestandarden inte försöker gå utanför sitt eget revir och avtvinga en viss dokumentstruktur i journalsystemens egen databas, finns det egentligen inget beroende mellan dessa.

Archetyper är en bra idé och verkar utförbart. Det skulle tillåta minimala journalsystem, men lämnar user interface (UI) och processer i journalsystemet, och där tycker jag man missat en stor chans till modularitet. Användargränssnittet hör hemma i journalsystemet, men det finns inget skäl varför processer inte kan undergå en liknande separation som man gjort med datastrukturerna. Ett sätt vore att använda Arden syntax moduler, men jag tror inte det är nödvändigt att vara så restriktiv. Om man definierar en arkitektur baserat på ett “blackboard pattern” [3] tillåter man en i princip obegränsad mängd processer att bearbeta gemensamma datastrukturer parallellt och/eller seriellt. Dessa processer kan var och en för sig vara implementerad på helt olika sätt och på olika plattformar. Det är inte heller nödvändigt att det bara finns en enda “blackboard”; varje system kan ha sitt eget, med sin egen grupp av processer.

I realiteten skulle det betyda att ett journalsystem å ena sidan läser och lagrar data enligt den tvålagers arkitektur som Thomas Beale beskriver, och å andra sidan endast lagrar signaler för processer i ett gemensamt blackboard som antagligen är implementerad som archetyper också. Om användaren klickar på en knapp som bär texten “e-recept” så utför journalprogrammet inget annat än att sätta en flagga i databasen som säger att användaren klickat på knappen. På det ögonblicket kommer databasen själv (om det är en s.k. “aktiv databas” [4]), alternativt en extern process, att trigga en eller flera processer som effektivt utför e-recept processen. Dessa processer har ingen annan bindning till journalsystemet än genom databasen.

Denna sorts lösningar har jag själv byggt många gånger och erfarit hur mycket enklare de är att bygga och hur mycket mer skalbara och driftssäkra de är. Flexibiliteten, redundansen, samt anpassningen till multithreading kommer liksom på köpet. Helt naturligt följer också att varje process blir ett litet system, och som vi vet betyder det låga utvecklingskostnader och billigt underhåll.

Nästa stora steg som måste tas i arkitekturen av journalsystem är att börja utnyttja dessa välkända patterns till att bygga effektiva system bestående av många samverkande små program och bli av med de dinosaurier som fortfarande byggs på löpande band.

[1] Archetypes: Contraint-based Domain Models for Future-proof Information Systems, Thomas Beale, 2002.

[2] openEHR Architecture 1.0.1, overview.

[3] Blackboard Pattern

[4] Active database systems, ACM Computing Surveys (CSUR), vol 31, March 1999
Denna länk innehåller en lång lista på referenser.

Inlägget har 2 kommentarer:

Arketyper är lockande och sympatiska för att de så att säga ger mer makt till vården. Och Tomas Beale är sympatisk att lyssna på. Själv kan jag dock inte skaka av mig känslan av att man kraftigt underskattar komplexiteten i att utföra det jobb som måste göras av vården. När jag tänker på hur stora diskussioner om enstaka GUI-aspekter vi kan ha mellan enstaka personer på Profdoc så blir jag mörkrädd av tanken på att samma typ av diskussioner skall försiggå inom ett helt landsting. Jag skulle tro att jobbet som måste göras inom Arketyp-lagret kan vara 80% eller mer av helheten. Nån gång har vi kanske kommit så långt att vi kan jobba på det sättet som OpenEHR föreskriver, men jag tror att det är rätt långt dit (fast det vore kul att vara med då!) Av Torbjorn…, 070702 00:01

Torbjörn, visst så är det. Byggandet av archetyper är utan tvekan ett programmeringsjobb det också, men det är åtminstone ett oberoende programmeringsjobb. Man kan kalla det en “vertikal modularisering”. Det i sig själv tillåter losskoppling av olika faser i utvecklingen och lättare anpassningar till lokala krav. Och framför allt ett motmedel mot “gigantismen” i nya IT initiativ och isolation av politiska manövrar till ett visst lager i arkitekturen. Och visst kan jag också hitta många tveksamheter eller ofullständigheter just i den här idén, men varje initiativ som leder till bättre modularisering, horisontalt eller vertikalt, bejublar jag nästan per default. Man kan säga att idén är ofullständig, men däri ligger en djupare filosofi, nämligen att även arkitektoniska lösningar ska vara modulära. Sätter dom beskriver det på gör att idén kan tillfogas i en större arkitektur. Delvis begick jag samma misstag som många andra i mitt inlägg när jag tyckte dom missat att ta med processer. Dom behöver inte externalisera processerna i beskrivningen av arketyper, det kan någon annan göra i en beskrivning av processhantering. Dvs, beskrivningen av arketyper står för sig själv och hindrar inte andra former av vertikal modularisering av andra delar av arkitekturen. Av mwehlou, 070702 10:38