Month: April 2012

How can Angry Birds and Facebook change e-health?

sarikanLeave a comment

Well, not through clinical versions of these applications of course. That would be an interesting approach though, especially the social networking idea may have many applications in health IT, but I’d like to talk about something else that is happening in front of our eyes.

Facebook, Twitter, Angry Birds and other big names of the mobile application market are doing something for us that would normally take a lot of effort, and would not probably be as effective, these applications are training clinicians for mobile device usage.

We were having a conversation with Professor Ingram (Professor David Ingram of UCL) last week, and he was talking about some mobile applications he has seen, which aim to provide information to clinicians on the iPhone.

This led me think about the success of iPhone and iPad, which id pretty much obvious, at least based on Apple’s company value and sales numbers. That success has led to a new computing platform that has a user base from all ages. Now this is quite interesting, because if you introduce a computing platform with a completely different user experience (touch vs mouse & keyboard) and a completely different operating system, that would normally be a huge challenge for your sales and marketing. People usually do not switch that easy, because learning to use new devices takes time.

Even on the same hardware and software platform, introducing a new application into healthcare is a tough task. When I was working for HIS vendors back in Turkey, everytime we used to introduce one of our products into a hospital or to a pharmacy we had to deal with the training of users. If you had an application that you were replacing things would get even harder, because users would ask for pretty much the same features to walk around the learning curve. “But we used to to use ctrl + F7 to switch to patient search!, This new program does not do it, it does not work!”

What has been harder, is to get clinicians use computers. Even if when they don’t have to type anything, getting a heavy weight professor to use a computer to check out computer records for a patient is not an easy task. They would almost loathe the use of computers, and if you ask them, some would say they are too busy to learn new stuff when they’ve got so much work to do (read: they’re too old to learn new stuff).

What is interesting is, the same professor would be checking his e-mails on his iPhone between patients, and he may even be checking the pictures of the grandsons and granddaugthers on Facebook. The grandson, at the age of 6, probably already has a Facebook account, opened by the parents (yes, there are parents who do that)

Medical students? Oh yes, they all have Facebook accounts, they tweet, they play angry birds, and they would probably skip courses about using computers for clinical practice.

Through various applications, an incredible amount of people are using mobile devices, and they’re getting good at using them. I don’t remember such a large number of people getting so good at using computers (which all smartphones and tablets are) so fast at any time in the last 28 years or so (I was seven when I started using computers, and I’ve been in front of them ever since)

So if I were to introduce a mobile app, whether on iPhone or on a tablet, chances are that other applications will already have trained the users for using the device. Desktop computers never caused such interest from end users. People used them because they had to, MS Office, Internet browsing and maybe gaming made people use them, but I don’t think it has ever been like what we’ve been seeing for the mobile platforms.

So there is a platform that is in the pockets and bags/backpacks of many clinicians, all the way from students to professors, and if you manage to put something there, it will probably be quite accessable to them. This is a big opportunity for people who are trying to introduce computing as a tool into the clinical practice. Sure, we can’t move everything to these platforms easily, they’re mostly information consumption devices, due to their design, but if it makes it easier to reach clinicians to provide them information, then it is still an advantage over the problems we have to deal with desktop platforms today.

So let them play Angry birds, and check Facebook. The better they get in using those devices, the less friction your next application is going to face. What we need to do , is to find out how to develop interactions that maximize the capabilities and common patterns of these platforms, because they’re different than what we’re used to. If we can do that, we can improve at least some aspects of health IT, simply because we’re able to reach a larger user base.

Why reference models matter in healthcare IT?

sarikan1 Comment

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!