Så har vi en produkt till i utveckling, nämligen iotaEd, en desktop editor för issues som tillåter allmänläkare och specialister att skapa egna issues. Det är ju därifrån vårdprogrammen kommer nu och det är ju därifrån “issues” också ska komma, eftersom de ju i grunden är vårdprogram.
En videopresentation finns naturligtvis för denna också.
Nu har jag två demo filmer till om iotaMed®. Betydligt mer data och mer operationer. Spoiler: kvalitetsregister är en baggis. Man kan bäst se dom i omvänd ordning, för jag gjorde dem i fel ordning, så blir det rätt.
iotaMed på iPad lever och frodas och kommer att visas på Vitalis nästa vecka (oh, sh… bara en vecka till…). Vi har kunnat jobba 100% med det här sen två månader pga det fantastiska stödet från SYSteam. iotaMed är alltså en open source produkt under BSD licens1 så vi kan ju inte sälja licenser. Affärsidén är att kunder och leverantörer inser att en delad open source produkt faktiskt är bättre för alla än en ren proprietär produkt. Det här är ganska tydligt i andra branscher och i andra länder, men i Svensk vård-IT verkar det vara ett riktigt främmande koncept. Förutom då för SYSteam som helhjärtat hoppat på det här och faktiskt financierar en viktig del av vår utveckling. Det finns andra leverantörer som nosar på idén, men bara SYSteam har anslutit sig helt. Så på Vitalis kommer vi att visa en iotaMed som är branded för SYSteam och kopplad till deras befintliga system i tillräcklig grad för att visa konceptet i funktion. Så det bästa stället att se och peta på iotaMed blir på SYSteams monter.
Vi kommer också att ge en presentation i auditorium A6 den 7e april 11:45-12:30. Där kommer vi att visa iotaMed med SYSteam kopplingen och ett koncept för iotaMed i handläggning av fotledstrauma på akuten.
Under den här veckan kommer jag att publicera mer om iotaMed, men jag kan ju i alla fall redan nu peta in några skärmbilder som aptitretare.
Förresten, mycket av diskussionerna som föregick designen av iotaMed finns på vårt forum. Andra utvecklare som vill hänga på bör nog registrera sig där. Det börjar ta fart nu. Det kanske finns andra företag än SYSteam där ute som vill investera i en ny generation av vårdsystem?
Hittade just min egen rapport till Landstinget Uppsala om Cosmic från 2006, om någon är intresserad. Skriver det här så jag inte tappar bort länken igen. Det är klart jag har rapporten själv, men eftersom jag skrev den i uppdrag av LUL är det väl korrektare att endast hänvisa till deras egen publicering av den. Om ni undrar, alltså. Här är den:
http://www.it.uu.se/edu/course/homepage/ITisam/ht06/links/CosmicStudie.pdf
Till min stora glädje blev jag inbjuden att ge en lecture på Engelska för “International Masters Programme Health Informatics” på Karolinska Institutet och jag gav den förra måndagen. Vi spelade in hela föreläsningen, 3.5 timmar, på video och nu har jag hållit på en vecka för att konvertera, dela in, lägga till slides, fixa ljudet, m.m. Föreläsningen omfattar 12 sektioner, men resulterade i 20 videos eftersom YouTube begränsar till max 15 minuter per video.
Alla 20 finns i en playlist på YouTube:
http://www.youtube.com/user/mitmab#p/c/0F725A1175F25924
Lecture notes finns också:
https://iota.pro/images/8/89/Ln20101206.pdf
Föreläsningen omfattar allt möjligt som jag har tankar om i Vård IT, och som bekant är det väldigt mycket. Sista sektionen, nr 12, handlar om iotaMed och innehåller även de nya vyerna, dvs kvalitetsregister och kronologisk journal. Den delen är dryga 50 minuter i sig.
Den här titeln gav sig själv, liksom, eftersom jag just läst boken “Jävla skitsystem!” av Jonas Söderström.
Boken täcker ett mycket brett spektrum av kniviga frågor, men trots det träffade jag inte på någonting alls, inte en enda punkt, som jag inte höll med om helt och hållet. Den är också skriven av någon med lång erfarenhet i branchen och i synnerhet med användbarhetsfrågor och därmed nästan oförvitlig trovärdighet.
Jag har påbörjat design documentationen för iotaMed och den kan ni hitta här:
…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.
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.
