This is a copy/paste of a few responses I sent to a discussion in the openEHR lists. I’m copying them here because images in my responses and responses themselves are not properly archived anywhere yet.
If you want more: I wrote a PhD thesis on this stuff, so if you want a deeper discussion of the topic here it is but I suggest you read the following first.
Here is the whole exchange from openEHR mail lists, with all responses, including mine:Read More »
Necessary clarification: Please note that the term implementation in the text below refers to development of a software platform based on openEHR. I realised that the term is overloaded in the health IT space, implying adoption of a standard sometimes. That is not what I mean by ‘implementation’.
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.Read More »
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.
