Why US will have better clinical decision support than the EU

For many, smarter healthcare through the use of computers is an exciting idea. This has been the case since the sixties, and I belong to the current generation of people who try to make this happen.

There are so many misunderstood things about making computers help clinicians. It would take a lot of space to discuss these things, a luxury neither the blogger nor the reader can afford, so let’s stick to a key component of making CDS happen: data.

One form of CDS that benefits from data is based on building mathematical models using the data, then using these models to assess clinical scenarios. The more data you have, the more robust and accurate your decision making models are. This is why the big data hype is acting similar to rents in London: there appears to be no limit to its rise. Big data is basically breaking very large amounts of data that would not possibly fit into a single computer to smaller chunks and process it using hundreds and if necessary thousands of computers. It is not conceptually new, but it became easier and cheaper in the last decade. With this improved approach to processing larger data, the possibility of better decision making models arise, and (some) clinicians, vendors and investors begin to think: “This is it! We’ll now be able to have sci-fi smart computers”. Not so easy.

In order to realise the potential of the big data, you need big data. Anybody who spends more than a few years in healthcare IT knows that healthcare indeed produces a lot of data, but it is all over the place. So it is incredibly important that you have a way of getting the pieces of data together. This is why fracking is such a game changer for the energy industry. It is not possible to set up an oil rig and turn all those little pockets of gas into a large supply.

There is more than one way to join those bits of clinical data. Using healthcare IT standards is one of them. The idea is that software vendors create and exchange data in forms compatible with standards, so when it is needed, data can be pooled with relatively little effort. In Europe, and especially in the UK, this is the most promising and pretty much the only way of making big data in healthcare happen (there is so much more that is needed, but this is a real precondition) Why? Because the second tier of health services, that is, the hospitals have hundreds of systems from different vendors running. There is no way other than the standards adoption for these vendors to connect to big data.

The EU and the UK is doing whatever it can to support adoption of standards, I won’t go into details of that now. The important thing about e-health standards in the EU is that it is shaped as a government led process. Everyone expects the government to set the direction and then vendors will follow, to the extent they can.

Things are very different in the US for both the standards and the market structure. First of all, US does not have the committees that has to deal with adoption of standards across a number of countries. it is the industry that makes the decisions. There is minimum government intervention in setting the standards. So when a standard gains traction, it happens fast, and vendors take it forward.

The real advantage of the US is its scale driven healthcare IT market when it comes to big (health) data. A small number of vendors provide very large scale solutions installed across hundreds of sites, providing capability for a lot of functionality. This is not the pattern you’d see in the EU. Why is this an advantage? Well, you have a much smaller number of systems that needs to negotiate, and even when they don’t bother negotiating, they still produce a lot of data in a form that is completely under a single implementer’s control.

The other unique advantage the US market possesses is the massive cloud infrastructure and legal framework that allows vendors to use that infrastructure. This definition can be summarized with two words: HIPAA and AWS (go google this) There is nothing like this in the EU. With the EU regulations and laws in place, if you magically replaced every existing health IT solution with its standards based twin from an alternative universe in the blink of an eye, you’d still not be able to join that data in a cloud infrastructure.

In the US, Epic, Cerner, Intermountain Healthcare, Allscripts etc will build their own big data installations. They have the AWS to give them cost efficient infrastructure if they choose to use it, and the government has taken care of the legal framework, so all is in place. They may or may not negotiate to build larger pools, but if they don’t want to, they don’t have to. So these large actors will be building a whole new form of intellectual capital: mathematical models based on large scale health data. Which will turn into products themselves. You can imagine how things will develop.

You don’t even have to be a large corporation to innovate in this manner, though they’ll have the clear advantage. You can start a company based on a big data solution or algorithm you trust and if you can convince your customers, both the cloud and the legal framework is there for you.

So the US has a market structure and a legal framework in place that allows vendors to move forward much faster than the vendors in the EU. This is why I expect the US healthcare to have better clinical decision support sooner.

Please don’t interpret any of the above as a claim of better healthcare delivery or outcomes in the US. That is an entirely different topic. There is also the issue of most big data people not having a clue about healthcare data and how it is produced, but there is only so much that can go into a blog post.

is openEHR hard?

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.

The semantic web that never was. Will it be the same for smart healthcare IT?

I attended another Data Science London meeting last week. As usual, it was a good one. Speakers talked about their experience with twitter feeds that includes foursquare check-ins and scraping data from web sites. Scraping is basically extracting information from the web pages, in a way simulating a human’s use of the web site to use the information provided by that web site.

Both talks were interesting, and both had something in common: the people who are trying to access data had no programmatic, well defined method of doing so, so they resorted to other methods. The case of Lyst was especially interesting. They’ve gone through a lot of trouble to set up a system that can collect data from lots and lots of online fashion retailers. They have an infrastructure that extracts information about tens (hundreds?) of thousands of products from lots of web sites, and as surprising as it may be, they are actually keeping things under control, and presenting a single site that allows people to access data as if it is presented by a single source.  A question that was asked by someone in the audience was: “do you have any programmatic access to these sites?”. As in, do they give you web services? The answer was something in the lines of very few. It is usually a crawler that extracts information from the web site that does the job (though they are working with the consent of the web sites they’re parsing). I think it was also someone from Lyst  (or maybe the audience, not so sure about it) who said it is pretty much the reality of the web we have today, despite all that hype about semantic web.

Let me be honest: I never thought semantic web would take over. Whenever I saw someone giving a talk about the future of the web, about how web sites would be talking to each other, about how RDF and OWL would let the web become a computable gigantic knowledge base, I thought: “sorry, you’ll never get there”. That is because I’ve spend a serious amount of time developing web applications. I started around 97, and did it seriously until 2004 or so. I got to learn the way things work, got to see the way trends are going, and after 2004 I still did a lot of development using web technologies though I did not really have to deliver anything that needed to be production quality. When you see the business and technology side of the web, you begin to develop a sense of what would take off in this domain and what would not.

I was sure semantic web would never get to where it was expected to go, because (drumroll) it simply offered no immediate, tangible business value to owners of web sites. It is the good old semantic interoperability problem we have in healthcare. Someone must justify the extra effort for making data computable by others, or that effort will not be funded. It is an investment into a scenario which would become reality if everybody committed into it.   In healthcare, the need to integrate different sources of data has always been significant, so we had HL7, DICOM, openEHR, 13606 etc. For the web, the need is not really there. In fact, if you’re not selling an actual product, but you’re making money off information, it is better that you do not let anyone else process your information programmatically. It is your clicks, your ad revenue people will take away from you, so why let them do it?

On top of the business model related issues, add the technology problems. The UI on the web is becoming more and more interactive, javascript is ruling everything. Relational DBs and other well established back end technologies and architectures are being phased out and you’re expecting people to catch up with all these and support OWL or some other semantic web technology on top of it. Not going to happen.

RSS and web services may help islands of information to connect to each other, but they are mostly standards for the wire, that is, they help communicate information, they don’t offer content models, or support semantic interoperability. Just look at all those companies building businesses on top of extracting information from twitter.

I have put enormous effort into building a framework for better decision support in healthcare, and looking at where we are today, I think there is a future for computable health, so no need (yet) for me to cry for my lost years. The practice of medicine needs this. As hard as it may be, as long as the need is there, there will be effort to deliver. We should not be too relaxed though, because if the reward is good enough, someone will always build solutions on the interim approach, and if it is perceived as good enough, better may actually kill best.

There is a massive amount of tools, technologies and people out there, making the web work smarter even if the components of the web are not necessarily helping. I think healthcare will do better than web in terms of becoming computable, but it will get there much faster if we can offer an economic benefit to the system developers/builders, a reason to build computable health systems.

Pulse evolves into SDC Cloud Connect, and becomes even cooler

I am a big admirer of Eclipse. It is an incredibly ambitious piece of work. It tackles the problem of creating a platform for software tooling, a platform that can generalize features of most IDEs, report tools, scientific software and even regular desktop applications.

Not everybody agrees with me of course, when it comes to calling Eclipse an impressive piece of work. I won’t waste pages trying to convince those who disagree. Due to is generic infrastructure, Eclipse may not feel like a tool specific to java development, python development etc. Even if you get over the slightly unintuitive feeling it gives you,  it is hard to ignore the effort required to make Eclipse your home.

Home in the sense that your particular Eclipse installation supports Java, XML, Python, R, EMF or whatever you’re interested in using (Haskell? Sure, why not?) You configure it, you find the links to update sites, add them to your Eclipse config. Change workbench settings based on your preferences. Then someone else wants to work on your code, or you make a jump to another computer. Or you find yourself instead of a computer that is not your, but you need to use for an hour or so to demonstrate something to someone.

Being able to manage your Eclipse installation using the cloud help you in these cases. Imagine being able to share your IDE  with your friends,  colleagues, or simply with people who want to use your code through the exact same Eclipse setup you have, which is known to work for sure. Pulse was a product that enabled this for free. Was, because even though it is still available for a few more weeks, it is now being replaced with SDC Cloud Connect from Genuitec.

Genuitec is a company that understands how people use Eclipse, what kind of problems they have, and more important than that, how those problems can be solved. Pulse was my favourite tool because of this. I have a new computer at UCL? No problem. I install Pulse, pull the installations I want from my profile, and get to work. SDC Cloud Connect removes Pulse and uses an Eclipse plugin coupled with a clever web based interface to do the same. It is still free up until you hit a certain limit, in terms of Eclipse instances you’re hosting on the cloud. If you pay for it and go private, you can have a lot more: a custom server behind your firewall that lets you deploy your company’s version of Eclipse, and other nice things that people who pay for software get.

For me, Cloud Connect is a way of pushing my well polished configurations to colleagues and friends who keep saying “I can’t spend ages configuring Eclipse”. Well, I’ve spend all the time required, and here is a link for you, go get my statistics benchmark installation.  In the future, we may seriously consider this mechanism for distributing openEHR based tools, certainly beats explaining the plugin mechanism etc to first time Eclipse users.

So if you’re curious about the experience, go visit http://www.genuitec.com/sdc/cloud/ and play with the technology.

Open source in healthcare IT: being realistic about it

Dear reader, as you can see, the title begs the question: “are not we realistic about it?”. The answer, in my humble opinion, is no and this is a major issue.

I just wanted to express a few things I’ve had for some time in my mind about open source software  in written form so that I can give the URL to this post next time I encounter the same situation.

The perception of open source by people with different positions in healthcare seems to swing from one extreme to the other. Unless we can build a healthy, realistic view of open source software, we won’t probably be able to introduce benefits into healthcare IT, at least not at the level we would like to do so.

There is a large group of people who are proponents of using open source software. In many contexts, I am a member of that group.  However, this group is mostly branded as a group of idealistic hackers and activists who are defending open source for the sake of principles. Even worse, the members of the same group is mostly branded as the stereotypical,  paranoid enemy of the big software vendor who hates corporations and believes that open source software is always better. This is wrong, and it is killing a lot of good that could come from open source.

First of all, I do not think that open source can exist in a free market economy without clearly expressing its commercial aspects. Neglecting to assess and communicate the cost of open source hurts its credibility (a lot). The critical point in any discussion about open source is when you hear something in the lines of “and it has zero licence cost!”. Whatever the context is, at that point, someone should underline the fact that not having any licence cost does not mean not having any cost at all. Yes, you would not pay licence fees, but it is quite likely that you’d need to pay some support fees or buy some consultancy and from a cost perspective, if you manage to keep those expenses lower than the proprietary software scenario, then you’ll have a better deal with open source.

When offering an open source solution, one should always draw the whole picture in perfect clarity. This is how much you can save from the license fees, and this is how much you’d have to pay for support, training and consultancy. Once you do that, you have a proper business proposition with pros and cons which is subject to measurement with the same metric that the value of the proprietary option is measured with: money.

Putting the open source to this perspective actually saves everyone from the risk of bitter disappointment. Otherwise, we end up with users, managers, policy makers, all misinformed, waiting for something wonderful to be delivered by the community effort of hard working developers. This is not a realistic expectation, not at all.  Here is a list of facts that everybody who is hearing about open source should know (the sooner, the better):

  • Software has to be developed by developers. Good software takes good developers, and good developers are rare and usually expensive.
  • Unless they have other means of making a living or they don’t have any financial concerns, no one can escape the realities of making a living. Some people will put more effort for less, but at the end of the day, successful projects do take long term commitments, and people can afford to commit up until a certain limit.
  • 1 hour of work from 24 developers every day does not end up as 1 day of work. Good software always have leaders who dedicate focus and time continuously. Contributions do help, but most, if not all successful projects have a core team. Many key open source projects have key people funded by government, vendors, academia etc.
  • Not all open source software is in the form of turnkey solutions. Sometimes you get a good starting point, but it will take effort and investment to create value out of it.
  • Not all open source plays nice with established business models. Some open source licenses require the party using the open source software to make their own software also open source.  A software vendor may not be able to use open source software even if they want to.
  • Having the source code is not an absolute guarantee for survival. Software gets complicated very quickly. Just because you can access the source code does not mean you have the capacity to change, improve or fix it. In fact, developers need to go through serious pain and apply a lot of discipline to make sure that they can read and fix their own code.
  • Maintenance is the single biggest cost item in the software life cycle. A group of five developers can develop a very impressive piece of software, but it does not mean they can support two thousand users in a hospital. Even if the savings from not having to pay fees is great, and even if you shift all of those savings to the team, they may simply not have necessary amount of people to run an operation beyond a certain scale.
  • The consumer/contributor ratio is incredibly high in open source.

Does it look negative? It should not, because it is only realistic. It probably does not fit the image you have in mind for open source, and that is exactly what we need to change. My own experience has thought me that it is absolutely vital to be objective about what you’re offering as open source, and explain and offer it based on the same principles that are applied to closed source alternatives. Everything else leads to disappointment.  Having spent 15 years in this domain, I am sure that there is a lot that can be done, but we have to be very realistic about how to do it.

I am going to release a key part of my PhD work as open source software pretty soon, and this time I’m determined to be very clear about what I’m releasing, and when and how it can be useful. Once the open source argument adopts this practice of presenting pros and cons with an equal balance, it will certainly make waves. Facebook, Google, Skype, Microsoft, Oracle, IBM, RedHat and many others are already creating huge value from the approach that was once considered their demise, and there is much that needs to be said about the business models of open source especially in a unique setting such as healthcare, but that would deserve another post.

openEHR for practical people (cleaned up)

Warning: this is a re-post of an old blog entry. Things have moved since I’ve written this, and mostly in a better direction. Just remember that you’re reading a 4 year old entry.

 

Introduction and outline

This document is a guide for the software developer who is interested, or forced to be interested in openEHR. Let’s be honest, you may not be interested in the idea of semantic interoperability for healthcare or better healthcare services for everyone (including you). It is OK, this guide would still be helpful. On the other hand, if you are excited about openEHR, and you want to figure out what it means for you, than hopefully this guide will give you an overall view of openEHR, and help you out in using the other documents.

openEHR is a big initiative. The word initiative is used intentionally here, since calling openEHR a “standard” is actually underrating the huge amount of work and people that exist in and around the cumulative work. openEHR is a standard, that is true, but thanks to efforts of many people who has been working on various aspects related to standard, like implementations, tools etc, there is much more than simple docs that is available to you.

However, a software developer is mostly interested in writing software, and from a software development perspective, openEHR can be described better using certain terms and concepts from the software development domain. The following is an overview of the content you will find in this document.

First, we are going to introduce some of the concepts which have become popular in recent years in software development. We are going to be talking about them, because software developers are much better at understanding concepts if the concepts are provided to them using previous similar concepts.

After taking a look at the problems in the software development and recent popular approaches to solving these problems, we are going to take a look at the openEHR standard. We are going to see some of the approaches provided by openEHR, and we will try to see similarities between these approaches and software engineering methods which will be outlined in the first part.

Considering that this guide is written for software developers, major components of the openEHR standard will be outlined, along with what is in the standard, and what is not. (and also why).

The final part of the guide will be giving clues for next steps for the curious developer, who would like to give the Java reference implementation a try.

This guide is expected to be expanded in the future, with new sections focusing on actual code examples and deeper technical discussion

The state of software development in healthcare

The healthcare IT market is growing fast. It is one of the most challenging fields in software development, and it is a very rewarding domain with a lot of demand for particular solutions. Some concepts like semantic interoperability and electronic health records have become the holy grail of the domain, and there is still an army of people chasing that holy grail including you and me. There is no complete solution yet for some of the most heavily demanded functionality, like securely shared medical information, but progress is there.

As software development adopts to requirements of the world, new tools, new methods and new approaches are introduced every day. These changes in software development can contribute to the progress, so that healthcare domain can have better solutions to its well known problems. So what kind of changes are we talking about?

First of all, software engineering is still struggling to decrease the amount of uncertainty in software development. Software development is trying to change itself from being a fuzzy black art to an engineering discipline with well defined rules and metrics. Like healthcare, putting rules and well defined methods into software development is not an easy task, and there is still a huge amount of software that is being developed in ad-hoc ways. Project managers still have to explain why the team did not deliver the project before deadline, and software developers still have to hunt bugs. Certain practices have been accepted quite well by developers however, and these practices along with the tools that helps developers follow these practices have become almost mainstream. As time goes by, some terms which used to be cutting edge in the past become parts of everyday language between developers, and tools and methods related to these terms become common tools and methods. Developers are now expected to be familiar with these terms. Remember a couple of years ago, AJAX used to be a buzzword, SOA and MDA , along with Aspect Oriented Programming too.

In time, software industry invested in to these buzzwords, tested them, and in the process these technologies began to mature. Some of them were accepted more than others, and became more mainstream, and some of them, though being potentially quite important, did not take off as expected. We’ll mention about some key approaches below, and later we’ll see the relationship between them and openEHR.

MDA (Model Driven Architecture) is an approach for developing software. It is (roughly) based on the idea of using well defined specifications and guidelines for software development. What is the difference between this approach and the usual analysis methods you’ve certainly come across?

MDA is one of the the results of people recognizing a very common problem: requirements not being represented correctly and efficiently. Not representing a requirement correctly is probably the worst thing you can do when you are developing software. The client asks for a particular functionality, something that exists in the domain.

Real life example: you are in an analysis meeting with a doctor, and he says : “I’d like to record my initial opinions about the patient”. You take your note, write it down to your notebook, or maybe you record it in the form of a formal(ish) method like a simple use case diagram. You assume that a text box on screen is enough for this. All the doctor has to do is to type his thoughts, and you’re done. So after that part of analysis is over, you go to the office and you turn that requirement into code. Based on your particular design approach, you may design classes and than design a database table, where a single column in a table is used to hold this information. Then you have to write some code that will take the information from use interface, put into your class instance, and save it to database when necessary. Or if you are following DB first approach, you may design a database table and then write classes that will read and write information to database, and at last design user interfaces that will present and gather data. You may think that some of the approaches like DB first design is way too old, and “nobody does that anymore”. Well, it is not. There are still millions of developers who use these methods, and all these developers would feel more or less the same way when the following occurs:

After spending hours for writing the code, designing the database and user interface, testing it etc. you arrange another meeting with your customers, and the doctor who gave you the original requirement for recording his opinions looks at the software you’ve developed and shakes his head: “that’s not the was it is supposed to be”. You, under the obligation of being polite, ask “sorry?”. The doctor explains that he’d rather have a list of items on the screen each representing an opinion, so that he can read them better, and even more, he wants to use a certain code system for selecting opinions, or to be more accurate his diagnoses. Since he did not mention any of these in the first meeting, you say that he just said he’d like to record his opinions, and you’ve done what he wanted. All he does is shrug. “This is what I meant, I though you’d understand”

And it is done. Your hours of work is gone. You know that there is not a single piece of work you can save from what you have done before. Since there are multiple items that you’ll need to show in a list, your db design is pretty much irrelevant now. You have to introduce a new table for purposes of db normalization, that will hold selected condition ids. Your class which used to have a String field now has to have a collection of strings. Wait, we did not talk about the coding requirements! The user wants to use some coding standard.

So you get back to work, and following the same approach before, do the whole thing. For coding, you put a button on the form, and when the user clicks the button, a new dialog is displayed where there is a tree control, that includes hierarchical codes for conditions. You use a previously defined database table,created by another programmer. You write a smart widget that accesses the db as tree nodes are expanded and child nodes are added dynamically. You test the application, add a couple of conditions and it works. You are ready for the next meeting this time. You call your show your work, you are done now, right?

You perform the demo to the client, and you ask him to test it. He opens the dialog for selecting the conditions, and starts navigating the tree. He starts looking for a condition, and his journey through the tree never seems to end! After expanding about a dozen nodes, he finds what he wants, and clicks it. Then comes the next one, which is no easier to reach. After three diagnoses he turns to you and says: “sorry, we can not use this”. You find your hand shaking a little bit, but still manage to ask “why?”.

He says it would be impossible to use this during work hours where patients are waiting in the queue, and he has almost no time. Moreover, he wants to know if he can add his own codes to the list. You ask him what kind of user interface would he like then? And he says “I don’t know, something easier to use”.

Any developer who has done more than a year of development in a similar field knows what I’m talking about. This is software development. In the first case, you misunderstood the requirement,and your work is gone, your companies money is gone also, since they paid for those hours where no usable output was produced. In the second case, you got the requirement right, but this time due to nature and structure of domain data (the codes), you faced a usability barrier, a non-functional requirement is not satisfied (the system should be easy to use).

There is no escaping from what happened here, it has happened in the past and it will happen in the future again. You can not eliminate it, but you can decrease the amount of losses by handling it better.

MDA can help. If you had a model of the requirement, expressed in a specific format, some parts of this continuous process could have been much easier, and you could use the time you save in other places. For example, if persistence of data regarding this requirement was handled in a smarter way, say with some library that knows how to save and load data that is kept in your model, you would not lose so much time. Again, if some other tool made sure that you don’t have to change db schemas and write db read/write code when your model changes, would not that help? All you would have to do is to express the requirements in some form that can be used by software tools that would automate some of the following tasks. Handling persistence, and even business logic related class code generation.

MDA is build on this idea. You have formally represented models of real life concepts. The way your models are represented is important, and formal representation is the key here. Formal representation does not only mean that there is well defined method like a file format, or an xml schema, but usually this representation has other capabilities too. For example if we use a machine processable representation form, we may be able to automatically detect inconsistencies in models. If there are conflicting statements about the same real life entity in different models, our processable representation form may help us catch this inconsistency at the design phase, so that we can avoid a lot of future trouble and cost.

Moreover, our formal representation forms can also be a domain specific language. If we encapsulate commonly used terms and concepts from our domain, then representation of real life concepts become even easier. There is now a common language that can be used within all people who are expressing real life concepts. So you can avoid cases where an analyst uses the word “problem” while another uses “diagnosis”. In a fairly large project these little differences would probably end up as quite similar classes with duplicated functionality.

So expressing models with well defined, machine processable domain specific languages can save us from some trouble. We now have a less error prone method of modeling real life concepts. This is good, but it is not enough. Remember all the work you’d have to do if you followed a less formal method? Writing code to express real life concepts in whatever technology you use, and designing databased schemas? Do you also remember changing them, throwing away hours of work when you make mistakes? Well, models created with the approach of MDA solves some of your problems, not all of them though.

You’d still have to write the code for processing and saving those models. MDA also introduces the idea of platform independent models which can be transformed automatically to platform specific entities. So when you have a model, you can generate various artifacts from them, regardless of your choice of technology. (of course your tool set should allow this, if you are using Oberon or Assembly to write code, do not blame me for giving you false hopes).

So we can automate a significant amount of work using the model driven approach. The models can be automatically transformed into meaningful entities in your favorite (or imposed by your boss) technology. A patient examination act can be represented with a model, which can be transformed into a PatientExam class for example in Java or C#. Moreover, same generative approach can be used to give you a framework where requirements like persistence, or even GUI generation is handled automatically. Once you start building on the idea of a well defined, controllable form of expressing domain concepts quite impressive opportunities begin to emerge.

The important thing to remember at this point is that you are still not immune to making mistakes!. Software development is inherently hard, and you’ll still get things wrong, you’ll still make mistakes. The approaches developed by software engineering discipline target to decrease the amount of your mistakes but there is no guarantee for you developing software without any mistake. Even if you do not make mistakes, your clients will request new features or changes to existing ones. Software is about change, and dealing with change. The change may be necessary due to an error, or a request from the client. It does not matter, what matters is, you have to respond to these scenarios as efficiently as possible. The more agile you are, the easier you respond to these situations. So we are talking about achieving the same results you’ve been achieving in a more efficient way.

You can see some of the ideas realized in other approaches too, for example Object Relational Mapping Tools like Hibernate aim to isolate you from the database layer by generating classes that represent database tables. You are also given an automatically generated set of classes which save, load and query database tables, so when a change occurs in database, you can get back to focusing on actual business logic related code instead of rewriting all your database layer. Actually, object relational mapping tools caused a return to database centric methods of modeling domains to a noticeable extend, since developers realized that once they were done with designing a database, the rest of the work could be pretty much automated. Whether or not this is a good outcome is subject to discussion, but let’s just try to see that when you introduce solutions to well known issues in software development, you can switch to a more efficient form of software development.

Another benefit of using a formally defined model as a beginning point in software development is achieving a common language and a common development approach within your team. If you have ever been involved in a project with more than two or three developers you’ll see that habits or different interpretations of the situation at hand lead to quite different chunks of code. In time, ownership of code begins to be distributed among developers, each of them usually working on their own code. In the middle run developers may start violating coding conventions but things are still not that bad. In the long run they start developing their own utility classes or libraries for their own part of the code. The worst case is probably when the developers express domain concepts based on their own methods and experience. Since developers do move from company to company, or get assigned to other projects or somehow decide that they should rather run an antique shop, people end up trying to use or fix other people’s code. The initial response in a problematic project is “oh that’s Jason’s part, I really do not know how it works, I’ll need to take a look”. If things go all right, the new developer in charge of that part of the code will understand what is going on, and take care of the problem. If things do not go all right (and they rarely do in software development), the new developer will partly hack the code, and an even uglier brain child of two developers will be born, making it even harder for the next developer to understand what is going on. At some point someone will give up and rewrite that part of code. So new bugs with new costs will be introduced, and hours of payed work will go down the drain. What happens in this case is demonstrated in the diagram below.

clip_image002

This diagram shows the process that begins with identification of domain concepts, and their transformation into code by developers. Each developer works in the same domain, sometimes on the same concepts in the domain. However, they will all process the concepts based on their own methods, and they will end up producing their own views of the concepts in code. These differences in interpretation will be reflected into various layers of the software too. Persistence, user interface and business logic aspects of the software will also specialize, at least to an extend. There are many process improvement approaches from coding standards to proper documentation, to minimize problems that occur as a result of this situation. Still they do not change the fact that each developer is responsible with creating some form of representation of the domain concept in code, and there is an inevitable amount of integration among the outputs of different developers in the team.

Now when you have a common set of rules embedded into your development process, you are much less likely to suffer from these problems. If models are the only way of introducing domain concepts into your code, then it is unlikely that you’ll end up writing duplicate code. You’d mostly be adding business logic to a set of code that is already automatically generated for you. Less variation in project code is less time lost, and better capability to help others or to get help, since your code is clustered around commonly accepted classes.

What I would like to say at this point is, MDA may be the main approach that we have used so far, but when you read the following sections on openEHR, and when you start working on it in the future, do not see openEHR only in terms of MDA. openEHR incorporates a lot of concepts from different software engineering methods. You will see that openEHR’s design benefits from many software engineering practices. MDA is chosen in this guide as an introductory common ground for a software developer, but a good developer should try to see the other important ideas embedded in the standard.

MDA and other ideas have been being introduced into software development for the purpose of simply better software development, and many tools and approaches have been integrating them to software development process. But why are we mentioning them now? What is the relationship between openEHR and software development?

OpenEHR for software developers.

As a software developer, the first impression you’d get from openEHR may not be that it is very much related to software development. It is a standard for electronic healthcare records. It should basically be a set of documents that tell you have to express information and save it, right? This basic assumption is correct, but there is so much more in openEHR that it would be a shame if you, as a developer did not know about.

As a developer, you should know that openEHR is not only about saving some medical information in a pre-determined format. Just because its name is about records does not mean that is focused on storage of information. openEHR has a huge amount of features around medical information, and these features can help you out a lot as a software developer. Let’s see the major features and components of the standard, and how they are related to your tasks.

Modeling

openEHR uses ADL (Archetype Definition Language) to express clinical concepts. Since it is a formal, well defined way of creating models that represent clinical concepts, ADL provides many of the options we’ve discussed when we talked about model driven approaches above. As a developer it is important that you understand what an archetype is in the openEHR world. For you, an archetype is a unit of information, it is an entity that encapsulates a part of the domain that you’ll be writing software for. Let’s assume you are tasked with writing a piece of software that will be used in the emergency department, and poisoning is a quite common case in this department. So doctors need to provide a set of information regarding the poisoning event to the information system. This information will be used by other doctors during treatment, it will be saved into the system so that it will be a part of the patient’s medical history in the future, and many other parties like researchers will try to use this information in the future. In openEHR world, as a developer, you will be given something called a poisoning archetype. This will most probably be a text file which will contain content in the form of ADL. This ADL file will tell you what kind of information is used to model a poisoning event. The question that may arise is: does openEHR define a set of archetypes for each and every concept in the medicine domain? Are there archetypes for car accidents, falls, cancer or alien attacks? The answer is NO.

openEHR is a standard that provides guidelines that tell how to model medical concepts. It does not give a list of actual medical concepts as part of the standard. This requirement of listing and classifying concepts from medical domain is handled by terminologies usually. openEHR has well defined mechanisms for making use of that kind of work, but the standard itself does not contain an actual list of things in the medical domain. To make this bit a little bit clearer, we can say that openEHR is about recording and using identified concepts. Ontologies of reality (like Snomed) gives us a list of identified concepts in medicine. openEHR refers to these ontologies to link saved or used information with real life concepts. So when a piece of information is expressed using openEHR, you should not be surprised to see references to terminologies which are used as identifiers of concepts expressed in openEHR.

We said that (actually I said that) openEHR standard tells you how you should express, or model domain concepts, and ADL is the formal way these models are expressed. So how does ADL work? What does it do? ADL is an interesting language, because it work by the method of constraints. In case you want to express a real life concept like body temperature in ADL, you do this by constraining that concept. You “describe” something by listing its boundaries. If you were to define things only by using constraints, then body temperature would be something between 0 or 42 degrees (for a dead or alive body) with degrees being the unit of measurement. The data type for expressing this concept would be a double, and it would belong to a patient of course. In fact, it is possible to create a method of defining things by describing constraints regarding their attributes, and ADL does this. You should know that ADL also allows you to define data structures too, but these data structures are mostly used for expressing non-medical data in an archetype. (like the creator of the archetype, its version etc)

Wait a minute, how did we go from ADL to an archetype? What is the relationship between them? ADL is the language that we use to create archetypes. Archetypes are the models in openEHR world, which encapsulate medical concepts. So from now on when we say an archetype, it corresponds to a model that describes a real life concept.

Back to constraining things: why ADL does that? What is the benefit for the software developer here? First of all whatever data an information system processes, data validation is an inevitable requirement. As a developer, you are responsible for that validation, you can not insert a string value to a numeric column in a database, and you would better not let people type “asdf” in a field on the screen which is for entering age. It is not only about type safety either, even if your software allows the user to put a number into the age field the number should not be 780 unless you are writing a medical application for vampires. This kind of dirty data will cause a lot of trouble in the future. There are certain fields in every software which should be mandatory etc. So why not include this kind of requirements from the beginning, where requirements are specified? ADL does that for you, and since this aspect is covered within the formal model, you can make use of it in future steps. (we’ll talk about benefits of this more in the future)

Another advantage of constraint based approach is that it gives you a set of different combination of attributes and values for expressing a concept. This way, the model has a controlled amount of variation, it is neither very strict nor very free. Both of these conditions would harm our goals, especially in the context of model driven architecture.

Back to the big picture: we have a model at hand that describes a medical concept, the poisoning event. But what is exactly constrained here? Where does the things which are constrained by the archetype come from? They come from the reference model, which is a part of openEHR. The reference model contains various fundamental data types and structures, and other necessary things that would be required to represent concepts. This is called two level modeling, where reference model is a level, and archetypes constitute another level by expressing constraints over them. Using this approach, you can use fundamental building blocks in one level, and their compositions in the second level to express domain concepts. The compositions are archetypes in our case, and even if we use the term composition, please remember the golden rule: archetypes work by constraining.

Ok, so who builds archetypes and how? Well, it may be you, but it would be better if a clinician actually built them. And even if you can theoretically write them down using a simple text editor, you’d better use one of the freely available tools that would make things much easier for you. There appears to be a resemblance between the approach of MDA and using archetypes, but do archetypes support all the things we’ve discussed? Actually they do.

Implementations of openEHR

openEHR reference model is platform independent, but it is designed in a way that the fundamental types and structures it contains can be mapped to many modern development languages. These mappings are called implementations of the standard. The reference model clearly describes the attributes of the types used in archetypes. Types like String, Numeric values, Date types etc are all described in the relevant parts of the standard, so an implementation in Java is responsible with either using types which satisfy these definitions or with introducing implementations using its own language mechanisms. What we mean here is, if the standard describes a Date type with various attributes and capabilities, and if the Date type in your favorite programming language does not cover all the attributes and capabilities, then it is your responsibility to create that Date type in your language.

When you have a complete set of entities in the information model implemented in your technology of choice (C#, Java etc), you have an important asset. Think about the previous problematic case we have identified, in which developers are producing outputs which requires integration. Using reference model entities, we can now decrease the amount of error prone integration and inter-team communication efforts. The new approach is shown in the diagram below.

clip_image004

In this approach, developers use reference model implementation for expressing and using domain concepts in code. The reference model implementation contains a set of models with pre-defined attributes and behavior. These models are well suited to representing domain concepts, and the reference model implementation takes quite a bit of burden from the individual developer’s shoulders. Now the output of the development team is in a way using a domain specific language. Moreover, since the basic types and structures used by developers is well defined, there are no surprises due to personal interpretation of developers, which means that it is possible to benefit from tooling and middleware that can perform common tasks on the output of developers. Persistence mechanisms can be built which will expect reference model implementation based inputs. So as long as you use reference model implementation, you can isolate yourself from many troubles of persistence, by using highly automated code. Same arguments hold for user interface, business logic, workflow, decision support etc.. The reference implementation is potentially a platform for cooperation among many tools. It is a way of eliminating many common errors and problems, and hence costs.

Representation of information model entities in your development environment is not all that you need. You’d also need an archetype parser that would parse the archetype and give you a representation of it, again in your favorite language.

What kind of output you get from the archetype parser is also defined within the openEHR standard. This is called the archetype object model, and archetype parsers are responsible with producing output that is compatible with this part of the standard. So you should have an implementation of everything in the information model, a parser and an implementation of parser outcomes to be able to use an archetype.

What exactly do we mean when we say when using an archetype? As a software developer, IF you have the implementations mentioned above, an archetype parser gives you an in memory representation of actual models (requirements in a way). This is a very nice mechanism that gives you an output that you can use in your code. Think about it: an analyst, or a doctor uses a tool (archetype designer) to express the concept. This expression (archetype) contains data types, valid values, structure of attributes, even used coding systems (we’ll discuss this further). All you have to do is to use the parser, and this work is in your development environment as an in memory graph structure. If requirements change, the archetype will be changed, and (there are mechanism like versioning in the standard by the way) the changed archetype is given to you by the parser.

But what do you do after you parse an archetype? You expect to make use of it of course, but how? This is probably the most confusing point for anyone who is trying to understand how an archetype based software development approach works. So lets get into a little bit more detail. After you parse an archetype, you have a tree structure at your hand. The nodes of this tree are implementations of the Archetype Object Model. This tree is an object oriented representation of the textual archetype that your parser parsed. You now have the constraints and other data expressed in the archetype in the memory. But what can you do with it? This is a critical point, where you need to remember that what you have is a tree that describes the constraints. This tree is not a container for actual values of constrained types.

If a node in this tree describes a numeric value between 5 and 10, it means that this node of the medical concept will be represented by an object with the given type and that object will have a value between 5 and 10.

It is very important that you understand the relationship between archetype object model instances and reference model instances. The archetype object model instances that you get from the parser give you a description of the reference model instances that you’ll create to hold actual values. (Please read the previous sentence a couple of times) . Archetypes are models, but due to two layer modeling, the models are actually made up of types in the reference model. So when you have the output of archetype parser, you do not have any values at all, you now know what kind of structure you need to build, and you have not build it yet. Let’s keep things as simple and usual as they can be, and assume that you are going to take values from a user interface. You can automatically build a user interface using an archetype. For every node in the archetype parser output, you know the type of the node. This can be a literal value, a numeric value, and a set of values with one of them selected as the actual value of the node. (like a set of potential poisoning reasons expressed in codes). You can simply create a visual component for each of the nodes, a text box for text fields, a drop down box (combo box) for multiple values with a single value to select etc. So it is possible to create a widget or form that can be used to ask for data that will fill the model expressed by the archetype. Assuming you have done this, you now have a form with fields on it, and the user enters requested information, and clicks a button, lets say to save the information.

Now what? Developers mostly focus on the tree structure that they have received from the archetype parser, but that structure is not meant to hold data. To hold and process data, we need a parallel structure made up of reference model instances. If you have an archetype object model node in memory, which has a RM_Type_Name property with a value of “DV_Quantity”, this means that the value the user will enter into text field in the GUI is meant to be encapsulated in an RM instance of type DV_Quantity. Archetype object model instances point to reference model instances. An archetype object model instance is responsible with describing the reference model instance that you’ll use, so you should not assign data related responsibilities to it.

So you use reference model instances to hold and process real data. Another common question is “why am I using reference model types, and their implementation to hold and to process data?”. After all, you can simply get a value from the user interface, save it to some database table, and later get it back. If you keep a link to the original archetype node that has generated this node, you are done!. Well, not always. First of all, a value like 64 is not information, it is data. If a piece of software uses an integer to save 64, and another uses a double, there is now a type mismatch between these two systems. This scenario can happen even in the same development team. Another example is about dates. If an information system (or a developer) uses a particular date format (dd-mm-yy) to save a date, and another one users another format (mm-dd-yyyy) what happens a single piece of code tries to list all events in the history of this patient three years later?

This is why the reference model has its own types with very clear descriptions of attributes and behavior of the types. If you do not use real life values you get from the users with reference model types, you’ll deviate from the standard, and communication between users of the standard will fail. As long as you use reference model implementation to represent and process data, your code will behave consistently. This also eliminates the utility type of code written around custom use cases. A fellow developer of yours will probably introduce some utility method like “toUSADate()” into his custom use of a date value, and the next person who will try to make use of his code will have to figure out these utility functions around the code. Remember the scenario where someone was trying to figure out Jason’s code? If everyone uses the same reference model implementation, a lot of boilerplate code will not be necessary, and more important than that the way the code behaves will be consistent. Both within a system and among different systems. This is another realization of a domain specific language. Using the reference model, your developer friends (and you) have a common language in the code. A date related to a medical event is always the same type and there is now way of interpreting it differently. It is not possible for a developer to use “DateTime” while another uses a “Date” type in the language they are using. Even though interoperability is the primary reason openEHR is born, this side benefit of providing a common ground to developers should not be underestimated in terms of the benefits it brings. These little differences sum up to great losses and costs in software development, and openEHR can provide a significant benefit when it is perceived as a development framework. As a developer, or a manager you can benefit from openEHR in a quite unexpected way, as a software development framework.

If you take a look at the common functionality that exists in medical applications, you’ll see that all the major aspects are covered in openEHR, and moreover, the standard has considered how these aspects will be implemented by information systems. Remember the scenario where the doctor was not happy about your solution for providing a selection dialog for terminology nodes? openEHR archetypes allow the designers to impose constraints on terminologies, so whoever designs the archetype can state that only a subset of a terminology is appropriate for a selection.

What about issues like persistence, and querying? You’ll find out (or know) that saving medical data and later querying it is no easy task, and changes in requirements become quite costly when they are reflected into db design. If db design is not isolated from the code that processes data a change in a requirement creates a ripple effect, just like we’ve mentioned in the beginning. openEHR has considered persistence and querying requirements of the data as a part of the standard, so you can leverage existing research to introduce conceptually the same benefits we’ve outlined in reference model implementation. It is possible to automate aspects like persistence and querying to a large extend. Especially by adopting a generic mechanism that saves and loads model (archetype) based data, it is possible to avoid a large amount of effort that would otherwise be necessary to cover these aspects. openEHR wiki has pointers to potential methods of implementation for generic solutions to these concerns.

Other relevant concerns and requirements

Archetypes are the building blocks, fundamental units of representation in openEHR standard. However, archetypes are built for representing domain concepts, and there are some common, inevitable requirements regarding their use. Most of these requirements are also covered by the standard. A mechanism of the mainstream object oriented languages, “inheritance” is available for archetypes. So what do we earn by using inheritance? Inheritance is a quite good short cut for reusing definitions and behaviors of concepts. Its overuse can lead to long term problems in programming languages, but for archetypes the implementation of inheritance is not as deep as it is for programming languages. So it is possible to inherit an archetype that models a specific laboratory result from a generic laboratory result archetype. Archetypes also have the ability to contain other archetypes via a mechanism called slots. So you (or whoever does the modeling) can use mechanisms like inheritance and composition. Since these mechanism are supported quite well by mainstream languages, the tools that connect archetypes to implementations of the standard help you benefit from these mechanisms in your chosen development technology.

openEHR focuses on archetypes for representing domain concepts, but the standard also includes some other constructs which will inevitably emerge during the use of archetypes. What kind or constructs are we talking about? Well, if archetypes have a composition mechanism, we can place an archetype into another one, but what about grouping them together? Grouping archetypes is almost inevitable. Think about a medical process. There are different bits and pieces of information that must be captured and processed, like demographic data regarding patient, medical data related to status of the patient, a set of actions like administration of a drug etc. So, a real life medical operation as a whole is represented using more than one archetype. A demographic archetype can be used to model patient demographics, and an examination archetype can be used to model medical data. In this case, including archetypes inside other archetypes is not a solution. You can not add slots for each and every other type of archetype in every archetype you design.

Grouping archetypes is not the only requirement that will emerge quite often. Based on certain conditions, parts of an archetype may not be used, or some fields in an archetype may be constrained further, again based on certain conditions. Did we mention GUI related requirements? What if the creator of an archetype wanted to make sure that a particular field is represented in a particular way? These concerns, along with things like grouping etc are not related to medical domain. They are related to archetypes themselves. It would not be smart to let archetype definitions to contain data related to these kind of things, because they are not domain modeling related, and archetypes are for modeling domain. On the other hand, it is obvious that these use cases will emerge during the use of archetypes, so openEHR covers these uses cases and issues too. Templates in openEHR introduces well defined methods to cover requirements like the ones we’ve listed above: things which are not related to domain modeling directly, but will emerge in many scenarios, and will be necessary. By introducing templates, openEHR provides standardization around frequently emerging concerns, and you can exploit this approach during your implementation. Templates are work in progress at the moment, but you’ll find out that some quite common problems are handled via templates.

How to get started?

Good news is, there is a Java based reference implementation of openEHR, which contains an archetype parser, an implementation of archetype object model, and an implementation of reference model. For practical purposes, this is a quite nice starting point. This implementation is capable of taking you to the point where you can parse an archetype, get an in memory representation of it, and make use of it using reference model instances. There are useful implementations of key concepts like a terminology server integration etc. in this reference implementation, and you should experience on it. For a developer, making use of the documentation is important, and openEHR has a quite large set of documents. As a developer you may be working in a particular aspect like archetype modeling. Then you should make sure that you have ADL documentation and Archetype object model specifications with you. There is a shortcut mechanism in ADL that lets archetype creators to express various data types using a different syntax then the overall ADL syntax. Try to understand the differences between sub-syntaxes of ADL (cADL and dADL) first. When you feel that you have an opinion about how ADL works, take a look at information model documents. Whatever is being used (constrained) in an archetype has its definition in the information model documents. Data types, data structures like lists or sets are defined in the information model documentation. So if you want to work on modeling related aspects, along with overview documentation, these should help you get started.

In case you are a developer who is more focused on processing archetypes, you’ll have different priorities. In the ideal case, someone will give you a set of archetypes, representing models, and your task will be to produce software that makes use of them. In this case, a quick look at ADL documentation is necessary, but you should have absolute control over archetype object model documentation, since that is what you’ll get from the parser. You should also know about information model types and structures, since you are going to need them for processing data.

For a developer, the best way to clarify things regarding openEHR is to write a very simple application that parses an archetype, creates some sort of data input form for it, and saves and loads data. The Java reference implementation contains everything that you’d need to perform this task, and you are recommended to make use of coding and documentation in a balanced way. Do not try to memorize the standard, and do not plan to get started on reference implementation after having complete control of the documentation. The standard is big, and it is concerned with a lot of things you’ll probably not face in the learning phase, so do not introduce a steep learning curve trying to “get it” fully.

What is in the standard and what is not?

From a software developer’s perspective, the standard ends up being the answer to most of the questions. You should not expect to find the answer to all of your questions in the standard though, since that answer was found elsewhere a long time ago and it is 42.

You will realize that many things related to making an openEHR implementation work are not in the standard. It is not unusual for a software developer to expect more concrete material for an electronic healthcare standard. For example, a database schema for saving electronic health records would be nice would it not? The problem is, the standard has to draw boundaries to what it can define, otherwise undesired outcomes can occur. The first case is that of a very detailed standard that covers even the most complex technical details, like persistence mechanisms, how to create GUIs, and how to process parsed archetypes etc. In this case, the standard may not be implemented in some technologies and languages simply because the capabilities dictated by the standard are not available in those technologies. Even if you are using a technology that has all the necessary features, you may not need to implement all of the details in the standard, and worse than that, you simply may not have the necessary resources to do so!

So openEHR defines a lot of things, but some things are left to implementers for a good cause. openEHR has a very active and helpful community, so if you can not find the answer to your questions, be sure to ask them to the mail list(s) of openEHR.

Let’s take a look at a “left to implementor” type of thing with an example. A common question for a developer is “how do I get a GUI from an archetype?” Archetypes are usually not very large data structures, and one can easily be tempted to map them to user interfaces directly. Well, if that is what you want to do, there is nothing in the standard stopping you! (I’d still suggest that you take a look at draft templates specification) So, as a developer using openEHR, you decided that you want to build a solution where an archetype ends up as a user interface which can be used to collect information. How can you do this? Well, it is up to you! To take some of the burden from your shoulders, let me list three approaches with different pros and cons.

Option 1 is to generate a GUI automatically from an archetype. It is tempting, since as a software developer you’ll be able to write the generic code once, and you’re done. You’d have a pipeline that would take an archetype from one end, and spit out a GUI during runtime from the other hand. You’ll write an engine, that will execute during the runtime of a software and render an archetype in the GUI. Isn’t it great? You’ve even avoided designing, coding and managing user interfaces for each archetype? If you extend the functionality of your code to include templates, you can do even better. Basically we are talking about something like this:

clip_image006 This is a practical approach, but you’ll quite soon find out that with this shortcut, you are sacrificing quite a lot of flexibility. Once you push an archetype (or template) down the pipe, you have no method for intervention. In the runtime you’ll have an automatically generated user interface, and even if it can have things like validation etc, this approach does not let you inject GUI related logic easily. What if the users want to have a red flashing light at the bottom of the screen if the patient says that he/she was exposed to nuclear material? There is a piece of conditional execution, but there is no mechanism to express this logic in archetypes or templates. Clearly this is your responsibility, but you’ve automated the process maybe a little bit too much, so that you have no step in the process where you can write the code that does what we have just explained!

So maybe we can follow a more flexible approach, where we can benefit from model driven architecture, using archetypes and templates for automatically generating certain artifacts, but instead of generating them in the runtime, let’s assume that we’ll generate an intermediate form, something like an xml file, or source code. Since it is now possible to modify what is generated by our tools, we can inject the previous logic into this automatically generated output, and later use it within our software. This is a more flexible approach that is still supported by MDA. You’ll probably have to do more work for intermediate artifact generation and its use later, but you have more power now. Our solution would like something like this conceptually:

clip_image008

There is also the possibility that you are a real code master, a developer who does not like automating things, does his/her refactoring without any help from the development environment, turns of automatic code assist in his development environment, or even better use VI or Emacs to write code (and kill others who does not use VI or Emacs). With that state of mind, you decide that no automatically generated code is worthy of your compiler. You’ll write everything by hand, read ADL and design a GUI by hand (drag and drop GUI design is for little girls, just like ponies right?). So if someone wants a customization, you’ll have no problem because you know every line of your code by hearth. Your approach is basically a fully manual implementation, with minimum if not zero code generation and tool support.

clip_image010 The diagram is pretty much what you’d produce. So after taking a look at all of these approaches to developing a piece of software using openEHR, let’s ask the question: which one is right? What does the standard say?

Who knows? openEHR standard does not cover things like this. It can not, you have to implement these aspects based on things like technology at hand, the scope of your requirements etc. A good rule of thumb is to take help from the community, but the important thing that you should always remember is many implementation related decisions are up to you.

The second article in this series will hopefully walk you through the construction of the simple application mentioned above, but please do not use this information as an excuse to wait for that one.

As a conclusion: welcome to the world of openEHR, and I hope you’ll enjoy it.

Why the Microsoft tablet is a game changer?

With the announcement of a tablet from Microsoft, I found myself really excited about the possibilities.

I have not felt this way since MS decided to go into healthcare, and unfortunately that adventure did not exactly go in the direction that I’d like it to go. This one however, may work.

The reason I have high hopes for this one is that when it comes to creating a software market, there is simply no company that can match Microsoft. You may claim that Apple has done a better job via the iPhone and iPad, but as impressive as mobile market may be, it is still MS that is providing the OS that runs on 95% or more of world’s desktops.

Visual basic and .NET have created a huge market, because even though it is a monopoly (which by the way does not always mean something bad contrary to what you may have heard), MS has always been very encouraging when it comes to software development. Visual Basic 6, has recently got itself an extended support for Windows 8, a lifetime available to very few other languages. MS always wanted people to develop for its platforms, with as much limitations as possible, which in my opinion is the exact opposite of Apple.

Apple’s walled garden has walls a bit too high for my taste, and for the masses who have easy access to a Windows PC, developing for Apple platforms is still tricky at best.

Android was supposed to let the PC developers make a jump to mobile space, but due to fact that it was meant to run on lots of hardware, it ended up offering a sluggish experience on many devices.

Now we hear that MS is introducing its own tablet with its own OS (Windows obviously), and this is a direct challenging of Apple, unlike Google’s indirect attempt to give the OS to hardware manufacturers.

MS has done this before, to enter console market with XBox, and it has managed to steal almost half of the market, if not more of it, from Sony, which used to enjoy its PlayStation profits.

MS does not do hardware and software at the same time, but when they do, they are a company to watch for. They can provide links to world’s largest OS installation base, with killer software development tools, and with millions of developers out there, Apple may suddenly see competition getting tougher.

If MS does this right, and gives developers what they need, the freedom to enter the market with cheaper means of production (Visual Studio express and a PC), things will be quite interesting.

I for one welcome this challenge to tablet market, since I’ve considered Android to be an insufficient attempt so far. Android simply did not have a centre of weight, but this device may have that.

Check out the details here