Category Archives: Standardisering

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.

Lecture notes

Every year for the past couple of years, I’ve been giving a lecture to the “International Masters Program in Health Informatics” at the Karolinska Institute in Stockholm. Tomorrow I’ll give another one. The notes for that lecture are fairly complete and can be read on their own as a text which concisely outlines my major ideas and problems about electronic medical records. Suddenly it struck me that I should publish those notes here, and not just hand them out to the students as I usually do. So here they are.

Handout 20131216

SQL is dead, long live RDF

…um, at least as far as medical records go. SQL remains useful for a lot of other things, of course. But as far as electronic medical records are concerned, SQL is a really bad fit and should be taken out back and shot.

Medical records, in real life, consist of a pretty unpredictable stack of document types, so some form of graph database is very obviously the best fit for storage. Anything with rows and columns and predeclared types, is a very poor fit, except maybe for the patient demographics and lab data. Or maybe not even that.

The problem so far was the lack of viable implementations so instead of doing the right thing and creating the right database mechanism, most of us (me included) forced our data into some relational database, often sprinkling loose documents around the server for all those things that wouldn’t fit even if hit with a sledgehammer. All this caused mayhem with the data, concurrency, integrity, and not least, security.

I have to add here that I never personally committed the crime of writing files outside of the SQL, but squeezed them into the database however much effort it cost, but from the horrors I’ve encountered in the field, it seems not many were as driven as I was. I have, though, used Mickeysoft’s “structured storage” files for that, a bizarre experience at best.

You have to admit this is ridiculous. It leads to crazy bad databases, bad performance, horrible upgrading scenarios, and, adding insult to injury, high costs. Object-relational frameworks don’t help much and without going into specifics, I can claim they’re all junk, one way or the other, simply because the idea itself sucks.

From now on, though, there’s no excuse for cramming and mutilating medical records data into SQL databases anymore. Check out RDF first, to get a feel for what it can do. It’s part of the “semantic web” thing, so there’s a buzzword for you already.

A very good place to start is the rdf:about site, and right in the first section, there’s a paragraph that a lot of people involved in the development of medical records really should pause and contemplate, so let me quote:

What is meant by “semantic” in the Semantic Web is not that computers are going to understand the meaning of anything, but that the logical pieces of meaning can be mechanically manipulated by a machine to useful ends.

Once you really grok this, you realize that any attempts to make the computer understand the actual contents of the semantic web is meaningless. Not only is it far too difficult to ever achieve, but there is actually nothing to be gained. There’s nothing useful a computer can do with the information except present it to a human reader in the right form at the right time. What is important, however, is to let the computer understand just enough of the document types and links to be able to sort and arrange documents and data in such a way that the human user can benefit from accurate, complete, and manageable information displays.

It is almost trivial to see that this applies just as well to medical records. In other words, standardizing the terms of the actual contents of medical documents is a fool’s errand. It’s a pure waste of energy and time.

If a minimal effort would be expended to standardize link types and terms instead, we could fairly easily create semantic medical records, allowing human operators to utilize the available information effectively. All it would take for the medical community to realize this would be to raise their gaze and check out what the computer science community is doing with the web and then copy that. At least, that’s what we are aiming to do with the iotaMed project and I hope we won’t remain alone. What is being done using RDF on the web makes a trainload of sense, and we’re going to exploit that.

In practice, this means that you need to express medical data as RDF triples and graphs. This turns out to be nearly trivial, just as it is very easy to do for the semantic web. It’s a lot harder, and largely useless, for typical accounting data, flight booking systems, and others of that kind, but those systems should really keep using SQL as their main storage technique.

We also need a graph database implementation and we’re currently looking into Neo4j, an excellent little mixed license product that seems to fill most, if not all, requirements. But if it turns out it doesn’t, there are others out there, too. After all the years I’ve spent swearing at SQL Server and inventing workarounds for the bad fit, Neo4j and RDF is a breath of fresh air. The future is upon us, and it’s time to leave the computing middle ages behind us as far as electronic medical records are concerned.

“Issues” och konfidentialitet

På min ursecta blogg beskriver jag idag hur man kopplar sekretess till “issues” isf läkare, avdelningar, eller notat. Det löser en mängd problem och kan t.o.m. lösa problemet där sjukdomar som är viktiga i andra sammanhang förblir okända i nuvarande system.

Just idag fick vi vår 100:e medlem på Vård IT Forum! Stort grattis till mig själv! Tackar, tackar! Medlemslistan börjar bli ett litet Who’s Who av personer och företag inom vård IT i Sverige. Vi har mer än 350 inlägg i 80 olika ämnen för ögonblicket.

Kejsarens nya termkatalog

Det sägs att bristen på enhetlighet i hanterandet av medicinska termer hos läkare och i  journalprogram utgör ett stort hinder för vidare automatisering och sammankoppling av olika system. Det låter ju logiskt på något vis, men det är inte sant. Inte nog med att en gemensam termkatalog för journaler är näranog omöjligt att åstadkomma, den är utan nytta även om det gick att göra och att hela idén är byggd på fel premisser.

Continue reading Kejsarens nya termkatalog

Lagen om alltings naturliga dj… motsträvighet

Gång på gång misslyckas stora projekt, typ storslagna standarder, gemensamma databaser, enhetliga gränssnitt, “en patient/en journal”. Små projekt, däremot, fortsätter att lyckas i förfärande omfattning, trots den uppenbara amatörismen i många fall, medan dom stora projekten ofta leds av folk som borde veta bättre (dubbelmeningen var avsiktlig). Man behöver inte vara ett under av perceptivitet för att inse att det faktiskt är så, men det är uppenbarligen svårt att greppa att det inte är en tillfällighet utan faktiskt en lag som ligger bakom detta, och det är inte lagen om alltings naturliga, hum, motsträvighet.

Continue reading Lagen om alltings naturliga dj… motsträvighet