Recently, I found myself in more than one discussion during which I was trying to explain what openEHR is to someone.
It is common to adopt a different explanation of key concepts based on the occupation of the audience. The modelling side of things matter most to clinicians and policy makers and we talk in different terms than a conversation between software developers, architects etc.

The openEHR mail lists also reflect this natural distinction; there is technical, modelling, implementers etc.. I think I’ve realised something though, we end up having technical conversations with clinicians and implementation discussions with software developers. There is nothing wrong with it of course but I think the openness of the standard (it is in the name after all) is causing some problems in its adoption. This post is meant to express my thoughts about this pattern and it may or may not help you when you’re trying to understand some aspects of openEHR.

Since openEHR web site provides access to specifications and there are free modeling tools available to everyone, the introduction to openEHR has no barriers. Great, exactly what is needed. You can also access the discussion lists where implementation and technical issues are discussed. The implicit idea is that people should access resources that would be helpful and relevant for them.

Since openEHR focuses very strongly on giving the clinician control of what clinical information is going to be represented and processed, most people initially focus on model development, core concepts such as archetypes, templates etc.. Thanks to freely available tools such as the archetype editor and template designer, along with the models in the public CKM instance it is possible to get a good understanding in an acceptable amount of time which depends on your familiarity with the core EHR and information system concepts.

It gets harder after that. The natural flow of learning is to start with the models, archetypes etc and then move on to using these models for actual software development. This is where people begin to cross a threshold that marks harder territory ahead. There is still nothing wrong with this of course, you’re free to work on anything you want.

However, even if you’re a software developer who is tasked with developing a piece of software that uses openEHR to some extend, you may still be trying to get your head around something that you may not necessarily need to deal with. The single most important fact you should acknowledge is the following:

openEHR implementation is a large piece of work, it is hard and it is complicated.

This does not mean that openEHR is hard and complicated. There is such an important difference between the first and the second statements, the latter being a blanket statement that covers everything related to openEHR.

The key difference between the two statements is implementation. If you’re implementing openEHR, you’re looking at a real challenge. It is the challenge that exists in every project that aims to make complicated things easy and accessible. openEHR is designed to deliver computable health by letting clinicians define concepts and the rest should happen in a streamlined fashion. It does not end there though, the software developer is also supposed to be able to build the software that is based on the concepts defined by clinician in the same manner; it should be easy. Making this happen is hard, really hard.

It is the reason there are openEHR vendors out there. The easier you want to make something complicated, the harder your job is. Someone has to build a conceptual vault of some sort that will lock the complexity in. As much as I hate Apple analogies, I can’t avoid them sometimes: it is just like the iPhone and iPad line of products. Swiping with your finger is simply amazing in terms of interaction with a computer. No mouse, no keyboard, the screen is all you need. So simple. That simplicity has enourmous research and technology behind it that has cost Apple a lot of money. Apple does not put out its design specs for its products online, they don’t even give you a user guide. The simplicity and design around it is so good, you’re just supposed to be able to use it and it works as intended. Very impressive.

You don’t find users speculating about the way Apple’s cpu in iPhone works, you don’t even see most developers of applications (apps as we call them now) speculate about inner details of the platform (some do but they’re a lot less than the group who simply uses the platform and tools as provided by Apple)

openEHR does not do the same. It lets everyone access all that is available. There is a distinction, an attempt to address different groups of people, clinicians, developers, implementers but no barriers. The result is, people end up confused. The answer to “how do I use this?” becomes unclear. Especially software developers begin to think about actual platform implementation and the inevitable conclusion arises: “openEHR is hard” It would indeed be hard if you try to do it all.

It would be hard to use SQL if you had to implement a relational database just to use SQL. The archetype query language (AQL) is easy to learn, implementing a server that supports it is hard. Easy to use technology requires other people doing complicated things. Complexity acts like energy sometimes, you can transform it but you can’t simply make it disappear.

This is what openEHR vendors do. This is what Ocean Informatics has spend millions of pounds/dollars/yens/liras for (choose your currency as you see fit). Vendors, openEHR implementers give clinicians and software developers tools to make things easy for them. Developing those tools, those platforms is hard work, it is complicated, it takes people with skills and a lot of effort.

If you’re finding openEHR hard, please ask yourself the following question: “what aspect of this really large ecosystem I’m finding hard?”. Is it something for which someone already has an offering? Are you really sure that the complicated task belongs to you?

When I make these points, I usually get the looks that I gave to people at times when they tell me that I should not worry about the inner workings of something and use what is available. I don’t always like it, I want to understand it completely and maybe build my own solution for the problem I’m trying to solve. This is OK, it is OK for you to think like me, but acknowledging that building something is hard does not always mean it is something you have to do to use it. With openEHR, you’re free to do it, but it will costs you.

You’re absolutely free to step outside of your organisational roles, we all have one of those. Go ahead and build a whole stack of software if you want to but don’t underestimate the task ahead. If it is hard, well, there is a reason for that as I’ve written above.

If you’re finding something hard and there is nothing there that makes it easy, no offering from anyone, that means we have something to discuss; a point which we can improve to make things better in an openEHR ecosystem.

So next time you find yourself resorting to blanket statements such as openEHR is hard, please consider the possibility that you may be reaching into somebody else’s speciality. You’re free to do so, but you’ll pay the same price that they’ve paid.

Recently, I heard a question targeted at my colleagues at Ocean, something in the lines of “what do you think is your greatest accomplishment ?”

Ocean’s software stack has a lot of impressive components, the template designer with its TDO support, the back end repository, Tom’s Eiffel work that is called the Archetype workbench, and clinical knowledge manager are all polished pieces of software with a lot of work behind them (and don’t forget the archetype designer)

However, my pick would not be one of these if I were to choose greatest thing out there. I’d choose the RM, the reference model of openEHR. Why? Well, it is because I have a past that has lots and lots of software development. The vendor that is trying to deliver a product to the clinician stands between the clinician an the technical infrastructure, code and hardware. If you work with all the common approaches and tools of recent times, that is, if you’re doing Object Oriented development with a mainstream language such as C# or Java, it is highly likely that you’ll go through the well known lifecycle of an application. Even if you use agile methods and good practices such as test driven development, there is one fundamental thing in this business you have to get right, if you want to succeed: requirements.

What helps with the requirements?

As scary as it may be, there is not a lot out there that may help with the requirements. In fact, I could argue that one of the reasons we have agile methodologies (and they are liked so much) is that we are expected to get the requirements wrong as software developers! Release early, release often, because most of the time you will release wrong stuff!

Tooling may help you get what you understand as requirements to code faster. A good UML tool that can generate code from models, or convention over configuration approach of frameworks such as Ruby on Rail will certainly help you deliver something fast, but none of these tools will help you understand the requirements better. They’ll just help you avoid mistakes during some key tasks you’re supposed to perform no matter what your software is supposed to do.

Sounds good, right? No matter what you’re supposed to do, these tools help you do it better. That is where the catch is: they won’t make it easier for you to figure out what you’re supposed to do. In order to that, you’d need tools that improve your communication with users and your understanding of the domain, tools that improve your communication with computers would not help here.

This is exactly what RM does, and this is why it is so important. If you’re a clinician, and you want to explain what you want, RM based modelling tools help you express your requirements, without knowing anything about computers, and if you’re a developer, RM based code and frameworks help you figure out how to represent those requirements in code. Someone else did all those rounds of asking the requirements, identifying patterns, and turning them into computable concepts. They’ve done the mistakes, paid the price, and shared what they’ve produced with you. That is one of the most valuable things you can get in this business.

For example, a software developer has a very different view of the concept of quantity, compared to a clinician. The developer has to figure out that quantities in clinical data come with units, magnitudes, reference ranges, and learning this takes time, and costs a lot of money for the software vendors. RM provides time tested components that can help clinicians, developers and computers communicate. Remember: doing it in the right way, and doing the right thing are different. You need better human to human communication for the latter, and if you have something like RM that is accessible to both developers and clinicians, that is your key to productivity.

When comparing RMs people usually forget that RM is not only about clinician to developer communication, once the developer gets his/her hands on the clinical model based on the RM, RM is supposed to improve communication to computers just as well as it has improved communication to clinicians. This is where most efforts fail. If you design your reference model with a very strong focus on human to human communication, diminishing the computability of RM to the point of computer readable (read: XML), you’re going to miss many advantages of an RM that can talk to computer languages better than yours. There are factors such as the granularity of data types, the level of abstractness of top level concepts, and the extend to which object oriented concepts are used. These factors determine how successful your RM will fit into programming language concepts, in other words, languages of computers, also spoken by developers.

openEHR RM has a good balance that lets it sit at a good point between developers (read: machine language speakers) and clinicians. You get too close to developers on that imaginary line, the clinicians lose their ability to express their requirements. You get too close to clinicians, the computers can’t understand what they’re being told. You have to have an RM that sits on the sweet spot.

Every other tool that sits on the RM can be written for other RMs, code generation, persistence, clinical modelling tools, you name it. The one that will succeed is the one that is build on the right RM. This, my friends, is why RM is the most precious asset of openEHR. It has been tested by lots of clinicians and developers, and it has been implemented in many computer languages. Most criticism comes from other methods that are either closer to developers, or to developers.

I am not saying that openEHR RM is the best it can be, because I am not qualified to make these kinds of big statements, but personally I have not seen any other alternative that performs as well. Please give this approach some thought, and think where your approach is putting you on the imaginary line I’ve defined. If you think you’re at a better position than what openRM provides, please let me know!

Ok, this is a paper that should provoke a huge discussion. This paper with two of its authors from Harvard says that the picture in hospitals with computers is quite different than the one we always thought we would see.

Obviously one should read the paper before discussing it, and I  did so. First of all, I have to say that the paper seems to give little thought into why software does not seem to decrease costs. There are three potential reasons mentioned in the conclusion part of the paper, but the final one is quite interesting. Quoting from the paper: “Finally, we believe that the computer’s potential to im-
prove efficiency is unrealized because the commercial marketplace does not favor optimal products. Coding and other eimbursement-driven documentation might take precedence over efficiency and the encouragement of clinical arsimony”

Yes! The marketplace does not let us push out better technologies easily. You’d think that once you have a better solution for a problem, the world would give you a warm hug and thank you for your work. The reality of the marketplace is cruel: there is huge politics and conspiracy around healthcare informatics, and working towards better solutions is not enough on its own. It is such a pitty that there is a huge amount of people trying to make things better, and the lack of desired outputs is not only related to capacity of the solutions we are building.

I’d like to see some honest discussion about this paper, and please let me know if you come accross any riplle effects regarding this paper.

Ok, slightly off topic, but if you are interested in my reading list for the last couple of months, here is a brief summary.

Atul Gawande, “Better “. Professor Ingram gave this book to me. If you want to see how doctors see certain things, and how hard it is to perform some tasks which they are expected to perform without any errors, read this book. Gawande discusses some interesting topics, including ethics, with quite unusual examples. Would you become a lawyer after years of being a medical doctor, and sue your own colleagues for malpractice cases? Could you use your medical knowledge to end someone’s life, for an execution? A great read.

Stephen King, “Cell”.  King is not the King I’ve admired for so long anymore. He has his style, he never loses it, you get the same feeling everytime you read his work, but Cell made me feel that I am reading a recycled version of his creativity in the past. You’ll find many common points with this book and his previous works. I do not want to believe that he is done with his universe, after finishing the Dark Tower, but I am failing to enjoy his recent works.

Vernor Vinge, “A fire upon the deep”.  My first encounter with Vinge, and  I think this is a good book. Vinge reminded me of Asimov in many ways, and he manages to build a different type of society which is real enough to keep you in the story. A couple of interesting ideas about the universe, including the slow zone, allows him to explore the outcomes of a partitioned universe. I have found some important parts of the book to refer to Gibson’s Neuromancer trilogy, but it is hard to avoid him when you’re writing about AI.

Neal Stephenson, “Snowcrash”.  This is the book that come closest to Gibson’s world in Neuromancer, among the others listed in this post. It almost gives that feeling I get when I read Gibson, but the main story did not create a powerful impact on me. Still, a good work of cyberpunk. I’d like to get my hands on this kind of books more, but I’d like to see a little bit darker material.

David Mitchell, “Cloud Atlas”.  A serious demonstration of talent. Can’t say the genre, because Mitchell shows that he can write four or five genres in the same book! Tom gave this one to me as a present, and it is one of the most interesting works of fiction I’ve read in the last couple of years. It made me realize that I need to go back to non-science fiction more often.

I am now reading  The Graveyard Book from Neil Gaiman, but I have to say that I want him to focus more on adults’ stories. His genious in Sandman and American Gods shows that he can be very impressive when he constructs complex stories, but all his other works I’ve read after American Gods are a little bit too simple (maybe flat is a better word here). Anansi boys was good, but I want something in the lines of American Gods. I’ll always follow him, but he seems to be a little bit too much into writing books for young people recently.

It used to happen to me in the past. After playing for about 4 or 5 hours, and slightly. After almost 10 years of not playing fps games, I bought myself a copy of Half Life 2, and it hit me like a truck!

I can’t believe the strength of the nausea I experience after only 10 minutes of play. I wonder if it is specific to Half Life 2, or to my XPS’s monitor etc. The problem is trying to figure this out is expensive both in money and health terms. I guess I am really getting older.  I have to lie down now, before I decorate the keyboard in a very unpleasant way!

The competition amont different information models in healthcare will never end. Yes, I know that there are many out there who think that a particular piece of work is so much better than the rest, and it is the feature of healthcare informatics. Sorry, I don’t agree. There are many other reasons, which I’d like to outline in another post, but in general, I can’t see this competition going away in the future.

What is interesting is, use of terminologies is common in many information model standards, whether it be HL7, EN 13606 or openEHR. There are many open source tools for many aspects of healthcare informatics, but when it comes to terminology management, the choices are surprisingly few! Other than NCI’s LexGrid initiative and Apelon, I can’t see any serious terminology server work in the open source domain. These two have their own pros and cons, but in general, this sub domain is surprisingly deserted. Please know that I’m not considering projects which were updated 3 years ago for the last time as candidates for my work in Opereffa.

There is huge work around the concepts which will eventually get linked to terminologies, but there is not much effort in the terminology server area. Yes there are many browsers out there, but whatever you do in the modelling phase, you’ll have to have access to a proper terminology server during use of that model (be it a Snomed CT subset or an HL7 message with Snomed CT codes in it). So why I can’t see an interest in this? Is it because people are so focused at well known problems, that they do not bother to think about what lies beyond them? Did open source healthcare attack the problem of informatin model based solutions first, omitting terminology based solutions? Terminology based approaches are old, and they are well established, so I can’t explain the lack of open source decent projects in this field. If you know one, drop me a line, and I’ll buy you a beer/wine/{insert your favorite drink here}.

Does not sound possible right? I’m afraid the news are not that good though; not only it is possible, but we are just about to do this. Yes it is not about healthcare informatics or development or anything like that, but some things just get to me. Check out this independent article for details.

I’ve personally witnessed death of a great piece of sea. Gemlik bay, where I spent all summers of my childhood turned from a virgin piece of heaven into a pit of industrial waste and the fish I used to catch is just a memory of the past, just like my childhood. Somehow, this worries me too much, I’d love to go back to that little house near the bay and go to fishing again, but the fish is simply not there anymore.

Imagine this for all of the world. Scary.