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.