All posts by martin

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.


iotaMed is intended as an organizing overlay to existing information. It adds the guideline layer, including knowledge transfer and checklist functionality, to the classic electronic health care record. The information needed cannot be stored in the existing EHR systems, simply because they lack the necessary concepts. In other words, we do need our own database to contain the iotaMed information, even though we may leave all the “old” information where it already resides in the legacy EHR. Even the new information added through iotaMed will result in new information to be added to legacy EHR systems, even though that information, by necessity, is as poor as the information currently stored there. There simply is no way to turn this particular toad (the legacy EHR) into a prince.

So, what do we choose for an iotaMed database, that is for the iotaDB? It’s painfully obvious to most that a relational database is very unsuited to this purpose and has always been. Using relational databases for medical information has never been a good idea due to the unstructured or semi-structured nature of medical data. Every EHR I’ve seen that uses relational databases has been a Frankenstein’s monster of inefficiency and inflexibility. It the wrong choice, pure and simple.

Lately, graph databases are becoming popular, and seem to be a much better fit for this purpose. Entities used in medical databases are practically always of variable structure, with a huge number of possible value types, but with only a small number of value types used in each instance. If implemented in a relational database, this results in sparse tables, or more often in blatant misuse of the database where one column is used to define the value type of another column, so that just about anything can be dumped into a single table. It’s horrible.

The “issue”, “issue worksheet”, “clinical guideline”, “item”, and “observation” objects clearly form a graph that would be difficult to squeeze into a relational DB, but would fit nicely into a graph database.

Currently, I’m looking at Neo4j, since it seems to be one of the more evolved open source graph databases.There’s a nice intro to Neo4j here. Neo4j does not seem to have a language binding for Objective-C yet, and it needs Java to run, but since I’m planning on deploying iPads logically tethered to an OSX machine, the Neo4j can run there. The interface between Objective-C and Java would then effectively be a server side proxy app. If somebody already did this, I’d appreciate hearing from you, though.

A medication change

In the previous post I did a simple medication domain model. After a brief exchange of comments on my Swedish blog, I was quickly made to realize it was far too simple, so let’s see how it looks today:

In this diagram, I’ve replaced the “prescription” object with a “prescription worksheet” that works very similarly to an issue worksheet. It’s all very logical; each pharmacological therapy or product comes with a set of guidelines that include when it’s to be used, what steps to take before using it, what values to check, etc. All of this is very similar to a clinical guideline but centered around a prescription. So it makes a lot of sense to treat it almost exactly the same way as issues, except it isn’t kept at the same position in the object dependency tree. We don’t want the prescriptions up there commingling with diseases, but rather somewhere lower in the tree.

However, the items and the values of those items (“observation”) can overlap with those used in issues. For instance, the item “creatinine concentration in serum” can be used both in an issue and a prescription worksheet, if the prescription guideline says that the product should not be used, or used differently, in renal failure. So some items will be used in prescriptions, some in issues, and some in both.

Medication Domain Model

In conventional EHR systems, medications are usually just a list found under the patient. The problem here is that there is no direct relationship between the medication and the reason it is administered, simply because there is no concept that could function as “reason”. Lucky us, with iotaMed we do have “issues” so that’s what we’ll use.

A “prescription” is an order for a particular drug, for example “Aspirin, twice daily”, while a “refill” is the order to the pharmacy, for example “Aspirin, box of 100”. (Highly simplified.)

Since a “prescription” is for a particular issue, that is a particular symptom or disease, it should be a child of the issue in some way. Since it will typically appear in a clinical guideline under the section “Treatment”, it will appear as a line item.

Encapsulated lifetime

If you look carefully, you’ll see that each “prescription” can relate to more than one “issue worksheet”, which allows it to relate to more than one “issue”, since a different “issue worksheet” belongs to another “issue”. This is necessary since a prescription could serve a purpose for more than one disease. For instance, an ACE inhibitor is beneficial both in heart failure and to prevent diabetic kidney problems. And it is also used to treat hypertension.

Making “prescriptions” dependent on “issues” makes it much easier to stop medications when they’re no longer necessary. What we often see in practice today, with the crippled EHR systems we have, is that medications are continued indefinitely since it is often unclear exactly why it was started in the first place. Most systems allow a comment to be printed on the medication label describing the intent in a language the patient is meant to understand, but this is just a bad workaround. Often it is not filled in and if it is, it is sometimes incomplete. It is, after all, just a text field.

In iotaMed, however, it is abundantly clear exactly why a medication is prescribed and this allows the system to prompt for continuation or interruption of the prescription as the issue itself is activated or deactivated. Using an object term, we can say that the “lifetime of the prescription is encapsulated in the issue lifetime”, as it should be.


Current EHR systems usually issue warnings for interactions between prescribed products. This isn’t as great as it is made out to be. Generally, these systems stink. They throw up meaningless and frankly ridiculous warnings so often that nobody pays attention anymore. I can’t count the number of times our system has warned me that eardrops can cause unwanted pregnancies. I kid you not.

Also, interactions aren’t the main problem we have with medications. The main problem is contraindications, but since EHR systems can’t handle that, we’re supposed to believe that interactions are more important. Don’t fall for it, they’re not.

All medications have a list of contraindications, that is, conditions that if present makes their use dangerous. Some drugs for urinary problems, for instance, may not be given if the patient has glaucoma. A number of products should not be given if the patient has prostate problems, or heart problems, or asthma, or any number of other conditions. But if the EHR system has no idea what diseases and conditions the patient has, it can’t detect contraindications and there you are.

iotaMed, however, is built on the presence of issues, which are exactly those conditions we need. If we try to prescribe a medication for one condition that is contraindicated in the presence of another condition which the same patient has (as an issue), then the system can easily point out the conflict and stop you from doing something really stupid.


Jag skrev ett svar på ett inlägg på Vård IT Forum om grundkraven på nya journalsystem och beskrev vad jag håller på med i ett antal punkter. Jag beundrade mitt eget svar så till den grad att jag helt enkelt tar över det från mig själv och publicerar det idag.

Just nu jobbar jag heltid med att göra en prototyp av det journalsystem jag tycker vi behöver. Grundprinciperna är:

  • Öppen utveckling: design och resultat ska vara publikt tillgänglig
  • Användning av open source när det är görligt
  • Användning av ny teknik på klientsidan, i synnerhet vad gäller UI, vilket i dagsläget betyder iPad och OSX
  • Hel nystart vad gäller journalen, fullständig byggd runt “issues”, vilket är symptom eller sjukdomar, inte kontakter
  • Sekretess runt “issues”, inte avdelningar
  • Direktkoppling av medicinering till “issues”, vilket tillåter varning på kontraindikationer isf enbart på interaktioner
  • Total integration av vårdprogram i “issues” (se nedan)

Integrationen av vårdprogram i “issues” innebär:

  • Omedelbart kunskapsstöd till läkaren vid patientkontakten
  • Omedelbar uppdatering av kunskap enligt senaste rön
  • Direktkoppling till kvalitetsregister via vårdprogrammet i “issue”
  • Extrem förenkling av beställningsförfaranden som labb, med både beställnings och tolkningsstöd direkt i journalen
  • Extrem förenkling av remissförfarande, eftersom motivation, anamnes och status nu sker automatiskt från “issue”

Just nu håller jag alltså på med prototyputveckling av UI för iPad. Jag har ingen avsikt att behålla det här för mig själv och är mycket intresserad av att andra vill hjälpa till. Varje form av samarbete är tänkbar och förslag mottages gärna. Jag tänker också publicera screenshots vartefter, åtminstone om jag inte behöver skämmas för dom alltför mycket.

Vård IT Forum är stället där vi kan diskutera detta, men jag är även mottaglig via email, naturligtvis.

“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.

Effektivitet (II)

Det här är fortsättningen på Effektivitet (I) från förra veckan.

Den uppmärksamma läsaren (dvs allihopa) har väl tänkt att den måste kosta mer tid än vanligt att göra så här. Dvs varje patient borde ta längre tid. Och visst, det gör det nog, men om vi räknar med administrationstiden som man normalt måste spendera efter varje konsultation, oavsett om man gör det mellan patienterna eller på reserverad arbetstid, så är den totala tidskostnaden utan tvivel betydligt mindre. Det roliga är ju att trots att jag alltså spenderar mindre total tid per patientmöte, är patienten inne hos mig en väsentligt längre del av den tiden. Om du går tillbaka till föregående inlägg och ser hur jag spenderar konsultationstiden, så ser du att patienten är närvarande så gott som hela den tiden.

Dom flesta vårdcentraler (kanske t.o.m. alla?) har reserverade tider för “administration” på schemat. Med min metod behöver man betydligt mindre sådan administrationstid, så man kan ta fler patienter istället.

LoH (läkarutlåtande om hälsotillstånd) gör jag oftast med patienten närvarande på bokad tid 30-45 minuter eller också bokar jag in en tid för det på en viss dag, så patienten vet precis när jag kommer att göra det. På så vis kan ju en sekreterare också svara på när det kommer att göras utan att avbryta mig.

Vad gäller små ingrepp, typ naevi, gör jag dom oftast direkt. Om jag fått en 30-minuters tid för “bedömning naevus” och jag tycker det ska tas bort, så gör jag det på stubinen. Med all sannolikhet går det alldeles utmärkt inom 30-minuters gränsen och även om det glider över med 5 eller 10 minuter är det värt det. Eventuellt tar jag nästa patient medan jag väntar på att operationsrummet görs klart. Patienten blir (oftast) glad, vilket gör alla andra gladare också. Patienten sparar tid, pengar och behöver inte be arbetsgivaren om lov en gång till.

När jag får in remissvar och labbsvar, meddelar jag alltid patienten direkt, oberoende av om resultatet är normalt eller inte. Helst via brev, eftersom det passar mitt arbetsflöde bättre, men om jag vet att patienten är nervös, typ “har jag kancer, hur är mitt PSA?“, så ringer jag dom direkt. Man kan inte låta folk gå omkring och vänta på den sortens svar i dagar. Att alltid skicka brev så fort som möjligt betyder ju också betydligt färre begäran om telefontid. Nästan inga, faktiskt. Jag skriver naturligtvis breven själv, stoppar i kuvert, på med frimärke och i lådan.

Enligt min uppfattning är oerhört mycket av tidsförlust och stress förorsakat av att man måste sätta sig in i en patienthistoria alltför många gånger. Sättet jag jobbar på betyder att man försöker få så mycket som möjligt gjort varje gång man satt in sig i en journal, så att man inte behöver göra om det så ofta. Om du fått ett remissvar och du förväntar dig att patienten ska ringa för att få det förklarat, tvingas du ju till att sätta dig in i svaret två gånger; först när du får svaret och sen en gång till när du ska förklara det för patienten. Om du i stället ringer eller skriver till patienten redan första gången har du sparat en hel del tid och energi.

Det finns många mer detaljer i min “metod”, men alla går ut på att göra allt man kan så tidigt som möjligt och i ett enda sammanhang, vilket resulterar i ett tomt skrivbord och tom signeringslista. Det resulterar också i ett lugnt samvete, eftersom jag inte behöver gå omkring och oroa mig för att jag missat något resultat som ligger begravt nånstans på mitt skrivbord eller i en signeringslista i journalprogrammet. Jag är övertygad om att en sån oro för missar är en stor orsak till att så många läkare “går in i väggen”.

Jag vågar påstå att jag klarar av flera patienter per dag med den här metoden än jag skulle göra om jag jobbade som alla andra. Jag vågar också påstå att patientens väntetid på vård är signifikant kortare, med allt vad det innebär av minskade kostnader för patienten, vården och samhället. Jag vågar påstå att patienterna har betydligt mer insyn i processen och mer kontroll än annars. Jag vågar också med säkerhet fastslå att jag verkligen gillar att jobba på det här viset och jag är mycket mindre stressad än jag var innan jag organiserade mig så här.

Men var kommer IT in i den här historien? Den frågan har flera svar. För det första skulle det knappast vara möjligt att tillämpa min metod om IT inte fanns på scenen. Hm… det är nog inte rätt, eftersom jag gjorde så här redan för 25 år sedan och då hade jag inga journaler i datorn, bara en del bokföring. Men, ok, vi kan ju låtsas om att det inte skulle funka utan IT, varför skulle ni därute annars vilja läsa om det?

För det andra bör IT verktygen vara anpassade för det här sättet att jobba. Nästan alla större verktyg typ journalsystem är designade utifrån läkare-dikterar-sekreterare-skriver och det märker man på att det är lätt att läsa i journal, det är lätt att skriva, men det är jobbigt att läsa och skriva samtidigt. Inte omöjligt på långa vägar, men alldeles onödigt struligt.

Därtill är det väl inte för mycket begärt i dessa tider att gå ifrån 19 tum LCD monitorer i 1024 * 768 (vintage 90-tal) och skaffa dubbla 20 tummare i minst 1280, helst högre, upplösning. Vi har ju som läkare ganska så mycket information som vi behöver se i ett uppslag. Att jobba med en liten skärm där alla fönster ligger staplade på varandra är som att ha ett kontor med en pall som skrivbord. En rent skandalös snålhet från landstingens sida och helt oprofessionellt. Min sjuåriga dotter har mycket bättre material än så.

Men idag är det läkarnas arbetssätt jag pratar om, så min slutkläm blir som följer:

Jag tycker det finns ett klart behov av en utbildning i effektivitet för läkare, både i primärvård och sjukhusvård. Personligen tror jag att det kunde göra mycket mera skillnad i både kostnad och resultat i vården än dom flesta stora och dyra IT projekt, och det skulle väl inte kosta mycket att åtminstone provköra en sån utbildning någonstans och sedan evaluera resultatet? Om någon är intresserad, låt mig veta det. Jag skulle väldigt gärna vara med och hjälpa till.

Effektivitet (I)

(Det här är, för ovanlighetens skull, ett inlägg i två delar. Del II publiceras nästa onsdag om inget annat kommer emellan.)

Att läkare underproducerar är välkänt. Samtidigt är det lika välkänt att dom jobbar ihjäl sig, så nåt problem måste det ju vara i det här. För mig själv har jag utarbetat en rutin som funkar rätt bra. Den är baserad på “tomt skrivbord, ingen övertid” och ärligt talat funkar det. Samtidigt som jag får jobbet gjort, brukar patienterna tycka att dom får mer tid med mig än dom är vana vid, vilket ju också är ett plus. När patienten lämnar mitt kontor är allt gjort och jag kan koncentrera mig helt på nästa patient. När patienten lämnar kontoren tar jag in nästa patient på en gång. Jag gör alltså aldrig något mellan patienterna som har med dom patienterna direkt att göra.

Dom viktigaste punkterna i den här metoden (om man nu ens kan kalla det för en “metod”) är:

Skriv allt själv. Som läkare måste du helt enkelt lära dig hantera tangentbordet och journalprogrammet. Det finns inget skäl i världen varför du inte skulle kunna det. Öva, gå på kurs, gör vad som helst, men se till att du kan skriva med alla fingrar i full fart och blint, så att du kan titta patienten i ögonen medan du noterar. I detta är jag kompromisslös, du måste helt enkelt. Du ska inte ha en fungerande diktafon på ditt kontor alls. Den är ett djävulens påfund och leder dig i frestelse. (På senaste åren har jag dikterat en enda gång, och det gjorde jag för att testa hur det funkar med elektronisk diktering. Jo, det funkar, tack och adjö.)

Försök ligga före på schemat. Ta in patienter helst några minuter före avtalad tid, vilket gör dom glatt överraskade, håller väntrummet ganska tomt och gör dig själv betydligt mer avstressad. Du har ju marginal nu för lite extra problem om det behövs. Om en patient dyker upp just före kafferasten, ta patienten först, sen en lugn och avslappnad kafferast.

Just innan du hämtar in patienten, ge journalen en snabb blick så du har ett hum om varför dom är där. För det första undviker du klavertramp som “Jaså, du kommer för näsan?”, “Näää, är det nåt fel på min näsa?” (Det har faktiskt hänt mig för så många år sedan att det är preskriberat.) Dessutom vet du antagligen på förhand om du ska lotsa patienten till ditt kontor, till ditt undersökningsrum, eller till en annan lokal typ gyn eller op. Så vi sparar ett antal steg och nån minut.

När patienten väl kommit in på kontoret (dit tar jag dom så gott som alltid i första hand), låt dom berätta på en gång. Skriv vartefter dom berättar i journalsystemet (det har du under tiden lärt dig göra), medan du håller ögonkontakt. Om dom pratar för fort, be dom vänta lite. Jag har aldrig hittills mött en patient som blir irriterad av att jag skriver medan dom pratar, snarare tvärtom. Dom verkar känna att vad dom säger noteras (bokstavligen) och hamnar i journalen. Ett tips här: börja inte med “kontaktorsak“, men med “aktuellt problem” e.dyl., eftersom själva kontaktorsaken oftast bara blir tydlig efter att dom berättat en stund.

Sen är det ju också så att du tvingas att grundligt förstå vad patienten säger och vad han syftar på i detalj eftersom du måste formulera en begripbar text på samma gång. Du tvingas helt enkelt be om förtydliganden när dom behövs. Om du bara noterar stolpar på papper medan patienten berättar är det oerhört lätt att missa detaljer och poänger, som du sen får försöka fuska dig runt när patienten har gått och du sitter i din ensamhet och dikterar.

Om ingen större undersökning visar sig behövas, går jag aldrig med patienten till ett undersökningsrum, utan auskulterar jag och tar blodtryck på kontoret. För det ändamålet har jag alltid med mig mitt eget stetoskop och blodtrycksmätare. Om du, som jag, använder en elektronisk blodtrycksmätare sparar du ytterligare någon minuts tid eftersom du kan fortsätta att läsa, skriva och prata medan mätaren är igång. Å andra sidan, eftersom du mäter sittande och utan föregående vila, notera det i journalen. Om blodtrycket är marginellt på något vis, drar vi i alla fall till undersökningsrum och tar om det efter vila.

Av samma skäl har jag alltid med mig mitt eget otoskop, så jag slipper dra till ett undersökningsrum för öronundersökning eller hals (otoskopet är ju en utmärkt ficklampa också).

I dom enklaste fallen behövs nu enbart recept och dom skriver väl dom flesta direkt på papper eller elektroniskt. Och kanske konsultationen tog slut nu, men i många fall behöver ju mer saker hända. Kanske behöver patienten ett sjukintyg? I så fall, skriv det nu, medan patienten är närvarande. Finns det frågor så sitter han ju där och kan svara.

Behövs en remiss? Skriv den nu! Om du inte vet hur den ska adresseras, fråga en sekreterare, men gör den själv. Om du behöver råd om den, ring specialisten medan patienten sitter där. Fördelen är att han kan hjälpa dig med att svara på frågor samt att patienten övertydligt är med på vad som händer och vet vad du gör och att du kan låta patienten bestämma med i processen. Skriv klar remissen, stoppa den i ett kuvert och ta med den ut till sekreteraren samtidigt som patienten går hem. Om remissen går elektroniskt, ge gärna patienten ett kvitto på att den gått iväg och tala om för honom att ringa sjukhuset om någon vecka eller två om dom inte hört nåt.

På så sätt behöver du inte ta hand om den här remissen efter sista patienten när du helst skulle gå hem, och långt efter att du glömt dom flesta detaljerna. Om du sen dikterar den och sen får tillbaka för signatur, så har det tagit ett par dagar, eller t.o.m. någon vecka innan den skickas. Under tiden väntar patienten, betalar försäkringskassan sjukpenning och börjar du få påminnelser och gnäll från alla håll och kanter som bara sänker din “glädje” över att jobba i vården och kostar ännu mera tid.

Och hur tafflig du än är medan du skriver remissen och patienten tittar på, och hur lång tid det än tar, är det mycket mindre tid än den sammanlagda tid du annars kommer att spendera på att läsa journalen igen, diktera, signera, svara på frågor och gnäll, m.m.

Som sagt, del II kommer nästa onsdag. Stay tuned.