Vård IT i Realiteten

Inte för att jag vill vara elak… jo, det vill jag. Det är ju så härligt tacksamt att vara elak mot landstingspolitiker och annat folk som styr över vården och vård IT. Har dom inte hittat på ett fullkomligt skrattretande diagram som förutsätts illustrera vårdprocesser även om det bara är i deras egen överförenklade fantasi, så har dom nog köpt baldakiner för att skydda el-allergiska patienter. Verkligheten är ju mer fantastisk än dikten.

Förutom att man tydligen förutsätter att el fälten kommer uppifrån, så har man inte heller räknat särskilt rätt vad gäller våglängden, om det nu är vågor man vill förhindra. Är det fält så har man nog inte heller hajat hur det funkar. Det här är ju alltså samma folk som bestämmer vilka journalsystem vi ska ha och det förklarar ju en hel del. T.ex. hur dom gör leveranstester av journalsystem. Med korstecken och spågummor?

Det förklarar i synnerhet varför det är så hopplöst att argumentera med det här folket. Det enda åtminstone en del av dom verkar tro på är vidskeplighet. Är det inte hög tid att vi avkräver våra landstingsbeslutsfattare en kompetensexamen för området dom avses styra över? Bristen på både teknisk och medicinsk kompetens är ju skrämmande. Om jag nu visste vilket parti det var som bestämde det här med baldakinerna, så visste jag vem man inte skulle rösta på. Fast dom andra är nog inte mycket bättre, förstås.

Vilket leder mig till följande upprop: vem ni än tänker rösta på i valet, försök ta reda på om dom är kompetenta i vård, teknologi och andra områden som du värnar om. Själv har jag upptäckt en djupt hål av okunskap hos dom jag talat med. Det är hög tid att vi kräver och belönar kompetens i våra politiker, inte bara retorik. Kompetens verkar ha gått helt ur modet i landsstyret. Det spelar inte så mycket roll vilket parti du röstar på om du bara inte röstar på klantskallar.

Kolla in SKLs flödesmodell för patientens väg genom vården. Ett lovvärdigt initiativ i klassiskt disponentanda. Med lite läsande blir det tydligt att man vill abstrahera vårdens flöden till en enkel modell som är lättare mätbar än den beklagansvärda verklighet man tvingas umgås med. Kan man rationalisera och förenkla biljettförsäljning på tunnelbanan och lagerhantering för bilkonstruktion, så ska det väl inte vara något problem med vården, tänker disponenten, och ritar ett enkelt diagram:

I frågor och svar lugnar man ner potentiellt upprörda och överarbetade vårdarbetare med sakliga argument och med det allt övergripande behovet att kunna mäta. Allt detta låter ju behjärtansvärdigt, så jag tänkte att jag skulle förbättra diagrammet lite här och där, eftersom man missat en del saker som händer i verkligheten. Det blir lite jobbigt att tydligt referera till delar i grafiken eftersom den varken är riktig graf, state diagram eller flowchart, men jag gör vad jag kan:

a. I punkt 2 kan man bedöma vårdbegäran och se att den är ofullständig, så den skickas tillbaka.
b. När man planerar en aktivitet kan man upptäcka att en annan aktivitet borde ha planerats först.
c. Under genomförandet av en aktivitet kan man misslyckas och behöva planera om den.
d. Under genomförandet kan man märka att det är fel aktivitet.
e. Under genomförandet kan man också märka behov av en ny vårdbegäran för ett orelaterat problem.
f. När man utvärderar aktiviteter kan man märka att en saknas och planera den direkt.
g. Efter avslutat vårdåtagande kan patienten återkomma och visa att problemet inte var löst, men kvarstår så att mer behandling behövs.
h. Man kan avsluta ett vårdåtagande och ändå ha en planerad behandling som patienten själv kan påbörja om det visar sig att problemet ändå inte var löst.
i. Efter avslut kanske man istället bedömer behovet av aktiviteter på nytt om problemet i efterhand inte visar sig löst.
j. Vid bedömning av ett vårdåtagande kan man naturligtvis fastställa att det inte finns något att åtgärda.
k. Medan man planerar aktiviteter kan man fastställa att man behöver hänvisa vårdåtagandet.
l. Medan man bedömer en vårdbegäran där redan aktiviteter gjorts, går man direkt till bedömning och utvärdering av dessa aktiviteter.

Så min version av diagrammet kommer att se ut så här:

Med dessa små tillägg borde modellen fungera som förenkling av ett typiskt vårdförlopp. Nej, SKL, ni behöver verkligen inte tacka mig, det var en rent nöje att hjälpa er med analysen.

Apropå nästan ingenting har jag blivit scrum skeptiker. Om du inte vet vad scrum är och är nyfiken, kan du börja på beskrivningen på Wikipedia först, sen fortsätt och läs. Om du inte är intresserad så kommer jag inte känna mig stött om du struntar i resten av det här inlägget. Eller snarare, även om jag är stött kommer jag inte erkänna det.

Agil utveckling har många bra sidor, men även en del dåliga sidor och jag tror dom sämsta sidorna drivs till sin spets i scrum. Scrum metoden är helt inriktad på att mätbart och omedelbart ta sig framåt genom en “backlog”, dvs en lista med saker som ska göras. Det låter ju som musik i öronen på en sliten utvecklingschef. Dag för dag trillar utförda programmeringsjobb ner som poletter och man formligen hör det klirra. Allt går framåt, ingenting blir stående eller går baklänges. Och där finns ett gigantiskt problem.

I agil utveckling i allmänhet (och nu talar jag inte om scrum) så sägs det att koden är varje utvecklares egendom. Om han/hon ser att kod som underligger nuvarande uppdraget inte är som den ska, då kan utvecklaren fixa det på direkten i stället för att bygga vidare på dålig kod eller begära en ny work item bara för det. Och det låter ju vettigt, åtminstone om problemen är begränsade. I scrum säger man samma sak, men egentligen finns inget utrymme för det. Man har ju kalibrerat utvecklingshastigheten på vad som kan beskrivas som nedförsbacke och vind i ryggen. Med en eller annan liten grop i vägbanan.

Verkligheten stämmer inte med det här. Det är inte så, inte i något projekt jag någonsin sett eller hört talas om, att man faktiskt har en jämn eller lätt guppig väg framåt. Tvärtom. När man gör en första design som ser vettig ut och börjar koda, upptäcker man snabbt att den haltar. Om man är klok så kastar man bort den designen och börjar om. Andra designen blir mycket bättre, men börjar halta lite längre fram på vägen. Är man smart kastar man bort den också och börjar om.

Så här kan det fortgå ett tag. Själv har jag alltid av något egendomligt skäl byggt vidare på design nummer 6 eller 7 som visat sig solid (om ni ser någon av mina alster i drift och undrar varför det finns så många filer som slutar på 7 så vet ni nu varför). Det här låter ju vidrigt slösaktigt för någon som tänker i termer av att bygga en väg. Man börjar väl för f… inte om 6 gånger! Men ska vi säga så här istället: tänk dig att du bygger ett hus. Du börjar med källaren och bottenvåningen. När du då ska lägga på en våning till och märker att bottenvåningen inte håller, börjar du om eller stöttar du huset med stag på utsidan? Nästa våning: mer stag? Trappor som går inne i huset eller över fasaden? Om du aldrig får tillstånd att börja om med det där huset, kommer det snabbt att se ut som lustiga huset på Gröna Lund och vara lika roligt att bo i.

Är då min metod slösaktig och långsam? Ja, första veckorna är den det, men eftersom min design kommer att bli rätt, eller så rätt jag kan få den till, så kör jag om dom piskade scrumkillarna i tredje kurvan. Efter det ser dom inte röken av mig längre.

Min slutsats är att hur bra scrum än ter sig för utvecklingschefen och hur mycket jobb man faktiskt får gjort, så får man fel jobb gjort. Produkten blir sämre för varje sprint. Utvecklarna belönas för varje stagning och stöttning och varje fuskjobb, medan en arkitekturell omarbetning när den behövs formligen förbjuds. Produkter som byggs på det här sättet kommer snabbt ut på marknaden, men håller inte i längden. Dom blir nog svårare att underhålla än förra generationens system, misstänker jag.

Agil utveckling i sig är nog bra, men har ett problem just med detta. Scrum i synnerhet gör problemet värre. Det tråkiga är att jag inte har någon bättre lösning. Jo, kanske att man inte tillämpar scrum i början av projekt och att man är beredd att lägga scrummandet på is när tydliga arkitekturella problem uppstår. Men den softwaredisponent som kan avstå från att trycka utvecklarnäsorna i slipstenen är svårfunnen, verkar det som.

Dom av er som har en bakgrund i datavetenskap har fått lära er att Alan Turing var en av vetenskapens stora förfäder. Hans huvudsakliga bidrag var att beskriva den minsta allmänna programmerbara beräkningsmaskinen, vad vi nu kallar en “Turing machine”. Med denna teoretiska maskin och ett superenkelt programmerspråk som innehöll bara fyra regler kan man i princip göra vilket program som helst.

Nu har någon faktiskt gjord en riktig Turing maskin, bara för att visa hur det skulle se ut och det är värt att se. När man ser den i “full fart” inser man ju att vi kommit en bra bit på väg att göra våra maskiner mer effektiva än det här. Men i grund och botten är det samma princip, matematiskt talat, som moderna maskiner, trots att botten är väldigt långt nere.

En iPad har visserligen inte två rullar tape och en penna med sudd djupt inne i elektroniken, men ändå härstammar den logiskt talat från Turings maskin. Och därmed gör även iotaMed det. Djup bugning i Turings riktning (sydväst?).

Under tiden hackar jag vidare på iPad delen. Inte är den vacker än, men det går framåt. Vill ni se lite ful kod och ha roligt på min bekostnad, se projektet på github, där jag ibland laddar upp koden. Det tar emot att visa kod innan man är bra på en plattform, men ödmjukhet skadar nog inte (fast jag har aldrig försökt med ödmjukhet förr, så vi får väl se). Jag har en demo planerad i slutet av oktober och även om det inte är en hel produkt så måste den ju åtminstone ge en bild av vad meningen är då. Lite stress brukar vara bra för produktiviteten.

Om någon vill diskutera koden, gör det gärna i kommentar här eller på Vård IT Forum. Försök vara konstruktiv, jag vet redan att koden inte är vacker.

I’m just copying a post here I just did to a closed forum for CISSPs.

A couple of days ago, I had to create a death certificate in Cosmic, the EHR system produced by Cambio Healthcare Systems and used in many provinces of Sweden and increasingly abroad.

So, I opened up the records for the patient, created a new death certificate form and filled it in. Printed it out, since it needs to go the paper route to the IRS (in Sweden, they handle the population registry). Then, just to make sure my data matched the EHR entry I made a few days before, I opened up the form again and discovered four different entry fields had changed after I saved. Two adress fields were blanked, my “place of employment” was changed to “Summer house” (part of another field I had filled in) and finally, my telephone number I had added was blanked out. I corrected the fields and resaved, same thing happened again. Did it three times, same thing. I never signed the document, of course, instead having a secretary scan in my paper form, which was correct, and have that put in the EHR. The erroneous form remains there, but unsigned.

I pointed out this severe bug to the IT department, and the reply I just got went into some depth explaining to me what the different fields were supposed to contain, but they didn’t touch at all on the hairraising fact of changing the documents behind my back. That’s apparantly entirely ok for them.

In this scenario, I never signed, but if I had done that, nothing would have played out differently. The scary thing is that the normal workflow is to fill in a form, any form, print it out (optionally), then sign it, which flags it as signed and saves it in one operation. You never see what actually gets saved with your “signature” on it. We’ve had a number of bugs before, where dates were changed in sick leave forms, a number of crucial fields erased and so on, so this is just the last in a long series of such bugs.

This system, the largest on the Scandinavian market, uses Acrobat Reader (yes, you read that right, *Reader*) to fill in forms. So they prepare the form data in the background, launch the Reader, lock it down modally since they can’t handle the interactions right, then let you edit and save. The “save” and “signature”, even “delete” buttons are implemented *inside* the document form since they run modally. Just to give you an idea of the “leading edge technology” we’re talking about here.

The forms as such are designed by the end-user organisation, so the problem is in two parts: Cambio enables a sloppy workflow and does not respect the immutability of signed data in their application. The end-user organisation does not test new forms for problems.

So, my issues with all this are:

1. This product has passed CE approval. So where is the systems test? These problems are trivial to find before rollout. Not to mention that I, and others, have pointed these form problems out in public since at least two years. What’s the point of the CE, anyway?

2. If Cosmic is able to change the content of forms behind my back, why isn’t this recorded in a log? There is no way I can show after the fact that the form contains stuff I never wrote, even if I would be able to remember what I wrote and this has caused much consternation before with the sick leave forms. Why isn’t audit trailing of this a requirement from the user organisation or from the CE protocol?

3. Why does the system not warn me or show me the changed information during or after signature? It bloody well warns me for everything else I don’t need warnings for. A typical Windows app, if you get my drift.

4. Why doesn’t the “signature” mean anything? It’s simply a flag set in the system with no functional binding to the information. They’re in the process of rolling out smart cards now; I have one. You stick them into a slot on the keyboard to sign in, at least that’s the idea (doesn’t work, they don’t have the trusted root installed…). But that’s for Windows login. The “signature” in the EHR remains a dumb flag AFAIK.

Meanwhile, the law and regulations governing medical practice make a huge deal out of these signatures. We *have* to sign stuff in a timely fashion and can be sanctioned if we don’t. And if we do sign, we’re held to what we sign, legally, morally, ethically. Our careers can be held hostage by a stupid flag in a stupid database record, designed by an irresponsible designer, and implemented by an agile and equally uninformed coder.

My question is this: is this shitty state of affairs, this total ignorance of what the law and regulations say, this total lack of interest in quality and consistency in application design and implementation, something common to EHR systems everywhere? Is this laissez-faire attitude something you actively try to combat as security professionals if you work in the medical field, and if not, why not?

Or, provocatively, I’ve repeatedly heard on this list (it’s a while since last time) that doctors don’t respect security in EHR systems, but now my question is this: does anyone else? It seems not.

And finally, WTF is the point of the CE approval…? I’ve seen all the cynical answers, now I want a real answer somehow.

Jag jobbar egentligen inte inom primärvården för närvarande, så det är bara sällan jag är på en vårdcentral. Men varje gång jag är där, träffar jag på någon hårresande bugg i Cosmic, verkar det som. Idag var jag tvungen att dra dit igen och skriva om ett dödsbevis som försvann någonstans på vägen till Skatteverket.

Jag öppnar Cosmic, läser mina notat och skriver ett nytt dödsbevis i Cosmic “blanketter”. Normalt klickar jag “Signera” i formuläret, vilket signerar blanketten och sparar den i ett enda moment. Men den här gången gjorde jag inte det, utan skrev ut först, klickade “Spara” för att sen dubbelkolla mina data i journalnotatet. (Som ni säkert inte kommer ihåg, så kan man inte läsa journalen i Cosmic medan ett formulär är öppet. Förr i tiden när vi skrev för hand hade vi inte det problemet. Leve tekniken!)

Man kan signera dokument utan att öppna dom, men det gjorde jag inte. Jag öppnade dödsbeviset igen och såg att Cosmic ändrat i fälten! Tredje och fjärde raden i dödsplatsen tog den bort. Mitt tjänsteställe ändrade den till att bli samma som första raden i fyndplatsen (i det här fallet “sommarstuga”), och till sist tog den bort mitt telefonnummer. Jag korrigerade och kontrollerade det här tre gånger, och varje gång gjorde Cosmic samma sak.

Så grejen är här att om du signerar ett sånt dokument har du alltså signerat något helt annat än det du skrev. Utan att kunna bevisa i efterhand vad du egentligen skrivit. Enda lösningen är att fylla i formuläret i Cosmic, skriva ut det, inte signera det, sen låta papperskopian skannas in i journalen. Det var vad jag till slut gjorde.

Det är hårresande vilken låg kvalitet det här systemet har och hur extremt nonchalant Cambio (och landstingen!) hanterar patientsäkerhet. Om det är CE märkt, vilket jag utgår från att det är, är nog Cosmic vårt starkaste bevis hittills att CE märkning inte garanterar något över huvud taget.

PS: Nej, semestern är inte över. Tyckte inte jag kunde vänta med det här en månad till, helt enkelt.

Jag tar sommarlovspaus i bloggandet och börjar igen någon vecka in på augusti. Ha en bra semester, allihopa! Under tiden kan ni ju registrera er på Vård IT forumet, där finns väl alltid någon t.o.m. mitt i sommaren. Jag, antagligen, i synnerhet om det regnar.

My previous post got a few reactions from the IT people, all of them sounding as virgins having their panties pulled down. To say they didn’t like it is the understatement of the day. Which leads me to conclude I wasn’t clear enough. It also points to something being seriously wrong with their idea of their role, so let’s clarify that, too. I understand what brought us to this, namely “democracy in the workplace”, but if this is the price we have to pay for it, it’s too expensive by far. Nothing is worth this degree of dereliction of duty.

Healthcare in Sweden, as everywhere else, has one well-defined and unassailable goal and that is to make and keep the population as healty as possible, or some other variation of the Hippocratic oath. That’s what it’s for, nothing more, nothing less. The providers of this service are doctors, nurses, and other paramedicals. To support them in their work, we have IT staff, administrative staff, housekeeping, etc. There is no ambiguity in the roles or lines of authority here. Doctors at the top, nursing and paramedicals under them, except in certain areas of care where nursing and paramedicals work independently under their own authority. Nowhere is IT to be seen in this diagram, since IT staff have no authority of any kind in healthcare. They should have absolutely no say in how healthcare is provided or even with what means it is provided. Theirs is to do what we tell them to do as well as they can. But it seems they’ve lost track of this along the way.

In Sweden, the IT staff in many places has taken it upon themselves to decide what equipment and software doctors and nurses should use. It’s no wonder it has turned into a total disaster. These people have no idea what this stuff is supposed to be used for, they don’t have the training for it, and naturally, I pointed this out with my usual tact and finesse, resulting in the virginal yelps of affront. Amidst the whining, the best offer I got was that they’re willing to sit down on neutral territory for open discussions about what can be done. You must be kidding me!

Now get this, IT support people: you are support people. That means, you’re not to question how healthcare is to be done. You are not to question what we need in the form of IT to do our job. You have one task, and one task only, and that is to provide the medical staff with the best IT support you possibly can. If you’re not willing or able to do that, you shouldn’t be in this business.

Now get this, medical managers: you should never have let IT people misunderstand their role this badly. It’s up to you to clearly state the goals of the organizations and see to it that everyone in the organization understands and supports that goal and keep their noses pointed in the right direction. You’ve failed in that and now you have to fix it!

As things are now, the healthcare IT people behave as if they’re Santa Claus in disguise. If you get a working machine from them, they expect a big smile and a big thanks. And if you’re naughty, you’ll have to wait another year for your gift.

We doctors are also to blame. In our efforts to be nice to people, we have let them believe it’s ok to have to beg them for machines, and by implication, that they can reward us if we’re nice to them. These machines aren’t toys, they are the means we must have to perform our primary task, and that is, as you conveniently seem to have forgotten, taking care of patients. This situation could only arise due to a failure of leadership, and lack of a firm directives given to IT support departments. We’ve let them stray from their task, because we didn’t pay attention when we should have.

IT people, listen up now: your behaviour and your attitude, as I and most of my collegues have encountered it, is inexcusable. Don’t come to us telling us what we can or cannot do. Come to us only to ask what you can do to help improve healthcare, nothing else. And I’d strongly advise all healthcare staff to adopt the same attitude. We have a serious and dangerous attitude problem here, and it’s time IT support got a grip on reality and started supporting us instead of playing “Animal Farm” and keep sabotaging healthcare.

I’m sure there are well-meaning and capable people in healthcare IT support in our provinces, and I love you all. But please, make yourself heard and noticed, will you?

If you’ve followed along, you’ll have seen what I regard as the major problems and what I think are the major solutions for the electronic health-care record in general. But if we want to get anything done, there are major hurdles that are different from one country to the other, mainly due to political system differences. In some countries, you can sell technology on its merits, while in others you sell it on entirely different criteria, and Sweden belongs in that latter category.

The merits in our case would be how effective an EHR system is at helping doctors diagnose and successfully treat patients both directly and indirectly. It would do it directly by making it easier to understand what has historically happened to a patient and how to proceed along a scientifically sound path both in diagnosis and treatment. It would do it indirectly by collecting data for prospective studies and providing epidemiological warnings.

But in Sweden, this is not the major criterion for development and purchasing of systems, largely due to a politicized organization where the decisionmakers are highly motivated by concerns that have nothing to do with the direct application of medical care, and where the top decision-makers are laymen as far as medical care goes. It’s not an environment that is conducive to either good economy, good efficiency, or good healthcare IT.

In Sweden, this results in a lot of projects that have very little benefit for the actual medical care of the patient, but do have all the characteristics of political posturing, such as patient’s access to electronic health care records, massive standardization efforts without declared goals, integration of EHR systems over large areas, investment in cross-border electronic prescriptions, you name it. If it’s large, international, expensive, and photogenic, it’s on.

On the other hand, projects that would, according to the medical profession, seriously increase the direct medical benefit to the patient, such as revamping the EHR to be guideline oriented, better user interfaces for all the different parts of the EHR system, and improved referral systems, are largely ignored. Swedish healthcare IT is, in short, run by a self-serving bunch of laymen bureaucrats who score political hit points by publicly demeaning the needs expressed by doctors and nurses, and that is no way to run something as important as this.

As doctors and as basically well-meaning developers, what can we do to be allowed to improve healthcare, as we know we can? Can we get rid of the bureaucrats? No, it’s the oldest profession in the world, and it will not go away any time soon (you can argue if it’s older than the other oldest profession, or basically the same, no matter to me), so we have to work around it.

When we can, we have to make a case that they cannot resist, pretending to be on their side (it’s a fair assumption they don’t read this, they’ve ignored us so far), or we have to do without them in the form of skunk-works or as scientific projects, which are largely run by other people. We also have to find a way to either eliminate, or go around, or work together with the major vendors that are now the sole beneficiaries of the bureaucrat’s decisions. I’m sure they, in their heart of hearts (it’s a leap of faith to assume they have one, but I think they do), would really like to do a good job, but they aren’t really prepared to risk the goldmine they’ve found, so it will take some tact and planning.

The next couple of posts, I’ll try to suggest a few tactics we can use. If you have other ideas and you don’t want to make them public yourself, send me an email and I’ll pretend I thought of it.

You should also, of course, register on the Vård-IT Forum, where things tend to happen every now and then.

Vad jag tycker det är träligt att alltid gnälla på Cosmic. Det var kul ett tag, men inte nu längre. Jag funderade ett bra tag om jag bara skulle låta bli den här gången, men å andra sidan är det nog min plikt att försöka varna andra. Det kanske t.o.m. är min plikt att Lex Maria anmäla det, men jag är inte säker.

För någon dag sedan gjorde jag en beredskapsjour i primärvården och när jag senare begav mig till en vårdcentral för att uppdatera journalen med de ärenden jag avhandlat, möttes jag nästan omedelbart av samma bugg som jag redan skrev om 18 november 2009. Det är alltså en display bugg som gör att en del av notatet inte syns om man inte tar till ganska ovanliga åtgärder. Jag skulle gärna återge skärmdumpar här, men då skulle jag nog hamna i finkan pga brott mot sekretessbestämmelser, så det skippar vi. Men IT supporten och därmed Cambio har fått dom.

Grejen är alltså att vissa notat av en viss längd och sammanställning gör att Cosmic skrollar förbi sista delen av notatet utan att visa det. När 6e sista raden syns undertill skärmen och man klickar på skrollpilen ner, eller rullar ner med mushjulet, hoppar displayen direkt till nästa notat. I mitt fall visades aldrig dom sista 5 raderna. Det här kunde jag upprepa hur många gånger som helst. Det fanns bara ett sätt att se alla rader och det var att greppa “thumbtracker” i scrollbaren (konstig svenska det här) och långsamt och försiktigt dra den nedåt. Det är ju inte en manöver man gör frivilligt och det är ju inget sätt att läsa en journal.

Om man just skrivit notatet i fråga så vet man ju att det saknas rader. Om sista raden tydligt slutar mitt i en mening kan man också förmoda det. Men om dom sista osynliga raderna är en självständig mening eller paragraf är det kört. Dom blir helt osynliga.

Är det här allvarligt? Det kan du ge dig attan på att det är! Det är formligen livsfarligt. Det är ju ofta just slutet av ett notat innehåller en slutkläm som är väsentlig för läsaren. Det egendomliga är att jag tydligen ser det här relativt ofta, trots att jag bara jobbar deltid i primärvården, medan ingen annan verkar rapportera det. Har andra inte min misstänksamhet? Rapporterar andra inte lika lätt som jag? Jag vet faktiskt inte vad förklaringen är.

När jag rapporterade det förra gången så blev jag bedyrad av Cambio att man skulle ta det väldigt allvarligt och dessutom hålla mig informerad om vad man hittade eller inte hittade. Inte ett knyst har jag hört. Men buggen är där fortfarande och lika farlig som alltid.

Now we’ve arrived at the last of the solutions in my list, namely “Opening the market for smaller entrepreneurs”. There are a number of reasons we have to do this, and I’ve touched on most of them before in other contexts.

The advantages of having a large all-in-one vendor to deliver a single system doing everything for your electronic health-care record needs are:

• You don’t have to worry about interconnections, there aren’t any
• You don’t have to figure out who to call when things go wrong, there’s only one vendor to call
• You can reduce your support staff, at least you may think so initially
• You can avoid all arguments about requirements from the users, there is nothing you can change anyway
• It looks like good leadership to the uninitiated, just like Napoleon probably looked pretty good at Waterloo, at least to start with

The disadvantages are:

• Since you have no escape once the decision is made, the costs are usually much higher than planned or promised
• There is only one support organization, and they are usually pretty unpleasant to deal with, and almost always powerless to do anything
• Any extra functionality you need must come from the same vendor, and will cost a fortune, and will always be late, bug-ridden, and wrong
• The system will be worst-of-breed in every individual area of functionality; its only characteristic being that it is all-encompassing (like mustard gas over Ieper)
• The system will never be based on a simple architecture or interface standards; there is no need for it, the vendor usually doesn’t have the expertise for it, and the designers have no incentives to do a quality job
• Since quality is best measured as the simplicity and orthogonality of interfaces and public specs, and large vendors don’t deliver either of these, there is no objective measure of quality, hence there is no quality (there’s a law in there somewhere about “that which is not measurable does not exist”; was it Newton who said that?)
• Due to poor architecture, the system will almost certainly be developed as too few and too large blocks of functionality, making them harder than necessary to maintain (yes, the vendor maintains it for you, but you pay and suffer the poor quality)

Everybody knows the proverb about power: it corrupts. Don’t give that kind of power to a single vendor, he is going to misuse it to his own advantage. It’s not a question of how nice and well-meaning the CEO is, it is his duty to screw you to the hilt. That’s what he’s being paid to do and if he doesn’t, he’ll lose his job.

But if we want the customers to choose best-of-breed solutions from smaller vendors, we have to be able to offer them these best-of-breed solutions in a way that makes it technically, economically, and politically feasible to purchase and install such solutions. Today, that is far from the case. Smaller vendors behave just like the big vendors, but with considerably less success, using most of their energy bickering about details and suing each other and the major vendors, when things don’t go as they please (which they never do). If all that energy went into making better products instead, we’d have amazingly great software by now.

The major problem is that even the smallest vendor would rather go bust trying to build a complete all-in-one system for electronic health-care records, than concede even a part of the whole to a competitor, however much better that competitor is when it comes to that part. And while the small vendors fight their little wars, the big ones run off with the prize. This has got to stop.

One way would be for the government to step in and mandate interfaces, modularity, and interconnection standards. And they do, except this approach doesn’t work. When government does this, they select projects on the advice of people whose livelihood depends on the creation of long-lived committees where they can sit forever producing documents of all kinds. So all you get is high cost, eternal committees, and no joy. Since no small vendor ever could afford to keep an influential presence on these committees, the work will never result in anything that is useful to the smaller vendors, while the large vendors don’t need any standards or rules of any kind anyway, since they only connect to themselves and love to blame the lack of useful standards for not being able to accomodate any other vendor’s systems. This way, standards consultants standardize, large vendors don’t care about the standards and keep selling, and everyone is happy except for the small vendors and, of course, the users who keep paying through the nose for very little in return.

There’s no way out of this for the small vendors and the users if you need standards to interoperate, but lucky for us, standards are largely useless and unnecessary even in the best of cases. All it takes is for one or two small vendors to publish de facto standards, simple and practical enough for most other vendors to pick up and use. I’ve personally seen this happen in Belgium in the 80′s and 90′s where a multitude of smaller EHR systems used each other’s lab and referral document standards, instead of waiting for official CEN standards, which didn’t work at all once published (see my previous blog post). In the US, standards are generally not invented by standards bodies, but selected from de facto standards in use, and then approved, which explains why US standards usually do work, while European standards don’t.

Where does all this leave us? I see only one way of getting out of this mess and that is for smaller vendors to start sharing de facto standards with each other. Which leads directly to my conclusion: everything I do with iotaMed will be open for use by others. I will define how issue templates will look and how issue worksheets and observations will be structured, but those definitions are free to use by any vendor, small or large. At the start, I reserve the right to control which documents structures and interfaces can be called “iota” and “iotaMed”, but as soon as other players take active and constructive part in all this, I fully intend to share that control. But an important reason not to let it go from the start is that I am truly afraid of a large “committee” springing up whose only interest will be to make it cost more, increase the page count, and take forever to produce results. And that, I will fight tooth and nail.

On the other hand, I’ll develop the iotaMed interface for the iPad and I intend to publish the source for that, but keep the right to sell licenses for commercial use, while non-profit use will be free. Exactly how to draw that limit needs to be defined later, but it would be a really good thing if several vendors agreed on a common set of principles, since that would make it easier for our customers to handle. A mixed license model with GPL and a regular commercial license seems to be the way to go. But in the beginning, we have to share as much as possible, so we can create a market where we all can add products and knowledge. Without boostrapping that market, there will be no products or services to sell later.

Around 1996 I was part of the CEN TC251 crowd for a while, not as a member but as an observer. CEN is the European standards organization, and TC251 is “Technical Committee 251″, which is the committee that does all the medical IT standardization. The reason I was involved is that I was then working as a consultant for the University of Ghent in Belgium and I had as task to create a Belgian “profile” of the “Summary of Episode of Care” standard for the Belgian market. So I participated in a number of meetings of the TC251 working groups.

For those that are in the know, I must stress that this was the “original” standards effort, all based on Edifact like structures and before the arrival of XML on the stage. I’ve heard from people that the standards that were remade in XML form are considerably more useful than the stuff we had to work with.

I remember this period in my life as a period of meeting a lot of interesting people, having a lot of fun, but at the same time being excruciatingly frustrated by overly complex and utterly useless standards. The standards I had to work with simply didn’t compute. For months I went totally bananas trying to make sense of what was so extensively documented, but never succeeded. After a serious talk with one of the chairpersons, a very honest Brit, I finally realized that nobody had ever tried out this stuff in reality and that most, maybe even all, of my complaints about inconsistencies and impossibilities were indeed real and recognized, but that it was politically impossible to publicly admit to that. Oboy…

I finally got my “profile” done by simply chucking out the whole lot and starting over again, writing the entire thing as I would have done if I’d never even heard of the standards. That version was immediately accepted and I was recently told it still is used with hardly any changes as the Belgian Prorec standard, or at least a part of it.

The major lesson I learned from the entire CEN debacle (it was a debacle for me) is that the first rule in standardization of anything is to avoid it. Don’t ever start a project that requires a pre-existing standard to survive. It won’t survive. The second rule is: if it requires a standard, it should be small and functional, not semantic. The third is: if it is a semantic standard, it should comprise a maximum of a few tens of terms. Anything beyond a hundred is useless.

It’s easy to see that these rules hold in reality. HTML is a hugely successful standard since it’s small and has just a few semantic terms, such as GET, PUT, etc. XML: the same thing holds. Snomed CT: a few hundred thousand terms… you don’t want to hear what I think of that, you’d have to wash your ears with soap afterwards.

From all my years of developing software, I’ve never ever encountered a problem that needed a standard like Snomed CT, that couldn’t just as well be solved without it. During all those years, I’ve never ever seen a project requiring such a massive standards effort as Snomed CT, actually succeed. Never. I can’t say it couldn’t happen, I’m only saying I’ve never seen it happen.

The right way to design software, in my world, is to construct everything according to your own minimal coding needs, but always keep in mind that all your software activities could be imported and exported using a standard differing from what you do internally. That is, you should make your data simple enough and flexible enough to allow the addition of a standard later. If it is ever needed. In short: given the choice between simple or standard, always choose simple.

Exactly how to do this is complex, but not complex in the way standards are, only complex in the way you need to think about it. In other words, it requires that rarest of substances, brain sweat. Let me take a few examples.

If you need to get data from external systems, and you do that in your application in the form of synchronous calls only, waiting for a reply before proceeding, you severely limit the ability of others to change the way you interact with these systems. If you instead create as many of your interactions as possible as asynchronous calls, you open up a world of easy interfacing for others.

If you use data from other systems, try to use them as opaque blocks. That is, if you need to get patient data, don’t assume you can actually read that data, but let external systems interpret them for you as much as possible. That allows other players to provide patient data you never expected, but as long as they also provide the engine to use that data, it doesn’t matter.

Every non-trivial and distinct functionality in your application should be a separate module, or even better, a separate application. That way it can be easily replaced or changed when needed. As I mentioned before, the interfaces and the module itself, will almost automatically be of better quality as well.

The most useful rule of thumb I can give you is this: if anyone proposes a project that includes the need for a standard containing more than 50 terms or so, say no. Or if you’re the kind of person who is actually making a living producing nothing but “deliverables” (as they call these stacks of unreadable documents), definitely say yes, but realize that your existence is a heavy load on humanity, and we’d all probably be better off without your efforts.

The quality of our IT systems for health-care is pretty darn poor, and I think most people agree on that. There have been calls for oversight and certification of applications to lessen the risk of failures and errors. In Europe there is a drive to have health-care IT solutions go through a CE process, which more or less contains a lot of documentation requirements and change control. So by doing this, the CE process certifies a part of the actual process to produce the applications. But I dare claim this isn’t very useful.

If you want to get vendors to produce better code with less bugs, there is only one thing you can do to achieve that: inspect the code directly or indirectly. Everything else is too complicated and ineffective. The only thing the CE process will achieve is more bureaucracy, more paper, slower and more laborious updates, fewer timely fixes, and higher costs. What it also will achieve, and this may be very intentional, is that only large vendors with massive overhead staff can satisfy the CE requirements, killing all smaller vendors in the process.

But back to the problem we wanted to solve, namely code quality. What should be done, at least theoretically, is actual approval of the code in the applications. The problem here is that very few people are actually qualified to judge code quality correctly, and it’s very hard to define on paper what good code should look like. So as things stand today, we are not in a position where we can mandate a certain level of code quality directly, leaving us no other choice than doing it indirectly.

I think most experienced software developers agree that the public specifications and public APIs of a product very accurately reflect the inner quality of the code. There is no reason in theory why this needs to be the case, but in practice it always is. I’ve never seen an exception to this rule. Even stronger, I can assert that a product that has no public specifications or no public API is also guaranteed to be of poor quality. Again, I’ve never seen an exception to this rule.

So instead of checking paperbased processes as CE does, let’s approve the specifications and APIs. Let the vendors subject these to approval by a public board of experts. If the specs make sense and the APIs are clean and orthogonal and seem to serve the purpose the specs describe, then it’s an easy thing to test if the product adheres to the specs and the APIs. If it does, it’s approved, and we don’t need to see the original source code at all.

There is no guarantee that you’ll catch all bad code this way, but it’s much more likely than if you use CE to do it. It also has the nice side effect of forcing all players to actually open up specs and APIs, else there’s no approval.

One thing I can tell you off the bat: the Swedish NPÖ (National Patient Summary) system would flunk such an inspection so hard. That API is the horror of horrors. Or to put it another way: if any approval process would be able to let the NPÖ pass, it’s a worthless approval process. Hmmm…. maybe we can use NPÖ as an approval process approval test? No approval process should be accepted for general use unless it totally flunked NPÖ. Sounds fine to me.

Glöm inte att registrera på Vård IT Forum, det är där det händer.

Forcing a large application into small independent parts that have to communicate with each other using minimal interfaces is always a good thing. Large monolithic applications go “fat and lazy” when there is no requirement to keep them split up. Also, the effort to expand and maintain the applications go through the roof. We know all that since ages, but both our IT purchasers and our vendors act as if it’s raining and it’s all business as usual. Of course, monolithic means all the business goes to one vendor, making him fat and happy, and very little requirement for thinking and effort by the purchasing organizations and the IT support. Now, if IT support considered their actual task, which is not work avoidance but the implementation and support of an effective IT organization enabling the health care staff to do a better job, things would look different.

The thing is, we do absolutely need modularity. The IT applications should mimic and support medicine as it is actually practiced, and not the other way around. Medical practice should not need to adapt itself to poorly conceived IT solutions. (You recognize this tendency by the constant cries for “more training”. It’s all just so much nonsense. My advice: ignore them.)

Different specialities have different needs for note taking and guidelines. On the other hand, needs for handling of pharmaceutical prescriptions differ according to type of department. Internal medicine on a ward or outpatient differs from internal medicine as practices on an intensive care unit. Different needs also arise for appointments according to the ownership of the practice, regardless of speciality. And so on.

These differences aren’t gratuitous; they are necessary and are an inherent part of how medicine works. The attempts to eliminate these differences by large, universal systems, and their large, universal ways of working, don’t work, since they force a suboptimal way of operating on the medical profession.

Now, the defenders of the great unified systems, let’s call them “unicorn followers”, argue that medicine should adapt itself to how IT works, else the IT systems will be too expensive and complex. To the unicorn followers, we should say: yes, the IT systems will be more expensive, but the savings in medical practice will outpace them by orders of magnitude. Don’t suboptimize and try to save just on IT, that is not your job! Your job is to enable medicine to save lives and money through better healthcare, not through junk IT software and equipment.

Oh, and while we’re at it: modular systems are actually cheaper to produce and work much better, but that is something most software engineering texts explain and provide the proofs for. And you out there who purchase, or sell, or build these systems, you have read those texts, haven’t you?

In short, even the unicorn followers, once they’ve picked up a bit of the computer science of the last half century and started to worry about what their real task in the medical context actually is or should be, will undoubtedly see the light and start to specify new systems as modular in every possible aspect. The unicorn, just like the “one medical records system” is a mythical beast and will never be seen in real life. Even if it wasn’t mythical, it would get stuck everywhere with that unwieldy horn and die of hunger. Good riddance.

Ah, finally we arrive at solutions. The first in the series is the elephant in the room: issues.

Why do I say “elephant in the room”? Because when a doctor examines and treats a patient, he thinks in “issues”, and the result of that thinking manifests itself in planning, tests, therapies, and follow-up. When he records the encounter, he records only planning, tests, therapies, and follow-up, but not the main entity, the “issue” since there is no place for it. The next doctor that sees the patient needs to read about the planning, tests, therapies, and follow-up and then mentally reverse-engineer the process to arrive at which issue is ongoing. Again, he manages the patient according to that issue, then records everything but the issue itself.

Other actors such as national registers, extraction of epidemiological data, and all the others, all go through the same process. They all have their own methods of churning through planning, tests, therapies, and follow-up, to reverse-engineer the data in order to arrive at what the issue is, only to discard it again.

This is what I mean by the “elephant in the room”. The problem is so pervasive, so obvious, so large, that it is incomprehensible to me how this situation ever came about and why it is so difficult to convince our IT providers about the need for this entity in our systems, and the huge range of problems that its introduction would solve. Doctors in general don’t see it either, but at least they are almost to a man (and woman) extremely easy to convince. And once they see the problem and the solution, it’s as obvious to them as it is to me. This is how it looks today with all different actors trying to make sense of a highly deficient EHR (the images are taken from a presentation, and I think you may get an idea of the meaning even without my sweet voice explaining what you see):

So, after that harangue, this is my message: we need the “issue” concept in our medical systems. If the issue concept is present in the EHR, there is no need for every doctor and every actor to keep reconstructing it from derived and deficient data. It’s very easy to adapt the issue templates to cover all the needs of the different actors, simply because it turns out they are all after more or less the same thing. This only becomes obvious once you see it from the perspective of “issues”.

If we look at what exactly an “issue” consists of, we see that it is an ICD-10 code, or an ICD-10 code range, that defines the symptom or disease as such. Further, it contains a clinical guidline on how to diagnose and treat the disease, or how to further investigate it and refine the diagnosis, including differential diagnoses. It would entirely replace the usual medical records in daily use and it would best be presented on a touch operated slate device such as the iPad, simply because following links, making choices, and looking up information will be much more important than entering text. The text entry part will still be possible, but will be more of an exception than a rule.

Naturally, even though you will work with “issues” instead of regular medical records, the medical records are still produced in the background, and preexisting records are both viewable and linkable through the same interface. If you look at the bottom of my little mock-up, you’ll see tabs that bring you to the old medication list, chronological records (old style EHR), referrals, lab, etc. But in general, you’ll be working in the “issue worksheet” for most of the time, only occasionally looking up information through the other tabs.

To emphasize the radical difference between this way of working and the old EHR way of working, I made a simple mockup of the entry screen for a patient record. All you see is the patient’s name and a list of issues, some of which are subissues, or differential diagnoses that haven’t been resolved yet. For an entry screen, that is actually all we need.

You may notice that “Eric the Seafarer” had breast cancer according to this screen, which is very unusual in men. But vikings were a strange and wonderful people, so I would not jump to conclusions about that.

Oh, better late than never: click on any image for a larger resolution.