Open Healthcare Framework

Wednesday, March 29, 2006

Report from EclipseCon: OHF FTF

On the last day of EclipseCon, we had a FTF meeting. The meeting was well attended, with the normal attendees, and some very welcome guests. I'd like to thank every one who took the time to attend the meeting.

I was encouraged by the attendance. Since the beginning of this project, two main issues have stood in our way, that hinder our acceptance by the healthcare industry. The first issue I dealt with in my previous post - the server issue. So, we have resolved that. The second issue is the focus of our years work. I've lost count of the number of people who've said to me that the OHF project is doomed to failure, like any other open source initiatives in healthcare, because of [insert reason here].

I understand why there are so many people who believe that we will not achieve anything. But I've always believed that just as Eclipse is an idea whose time as come (an elephant that can no longer be ignored by anyone), so the time has come for a open source base for healthcare applications. While I'm less of a believer in open source healthcare applications - there's just so much to finish off in a healthcare application - I do think that an application framework that provides the common 90% of stuff that vendors all have to do to have any healthcare application can be a major contribution to the industry, and a value proposition for vendors and providers alike.

So the thing we have to do to convince the skeptical people is to start producing value. This years plan focuses on producing value: to publish robust and reliable IHE actor implementations that will help healthcare venders get IHE certification. In addition, we will be focusing on getting CTS in place, figuring out what supporting healthcare services and SOA means, and developing cutting edge HL7 tools.

For OHF this year, the message is simple: Code talks louder than words.

And, for those who care, I am writing up the outcomes of the meeting to post to the OHF web site and finalising the edits to the plan for 2006, and these will be posted soon.

Monday, March 27, 2006

Pictures from the EclipseCon

Check out our Wiki for pictures from the f2f meeting at the EclipseCon.

Report From EclipseCon

I've just returned from EclipseCon held in Santa Clara. EclipseCon was an amazing experience, there was so many interesting and exciting people gathered in one place. Meeting so many people I had communicated with was a real pleasure.

The thing I enjoyed the most was that I went to EclipseCon with a list of people/projects to speak to. Each of these people or projects have work lists that overlap with potential OHF work lists, and it's possible that we could duplicate work or work on incompatible models. In every case, when I sat down with the developers, within a few minutes we had sorted who was going to do what, and we were talking about how to do what we plan to do. That positive collaborative attitude really underscored what Ward Cunningham said (in one of the key notes) about how Eclipse is all about collaboration.

Two other things that are really important to OHF came together at EclipseCon. One issue that has been a real concern for OHF is the scope of the project. We clearly need to implement domain functionality that runs on client or server as appropriate for the needs of the domain, but Eclipse didn't have this concept. Equinox, partly due to our encouragement, created the OSGi/Server project, and there's a real buzz around this project. That Eclipse, as a community, will adopt the OSGi/Server platform provides us with the confidence to go ahead and commit code knowing it will be available to whoever wants it.

The other issue that had been a real concern for me was Security in RCP. There really wasn't any, and healthcare applications depend on good solid security. So it was great to meet the IBM workplace team and find out that not only do they need a good solid RCP security framework, they have the skills and motivation to work on it. All they need now is the permission to release their work...

We also had an OHF FTF meeting. I will report on that and post an outcomes document in the next 24 hours.

Sunday, March 26, 2006

Open Source Software: A Primer for Health Care Leaders

This Forrester Research report was prepared for the California HealthCare Foundation at Match 2006 (i.e. this month).

Here is a summery of the report conclusions:
... While not heralding the end of commercial software vendors, the report concludes that conditions are ripe for open source solutions to take root in health care, and that it will likely become the standard for capturing, sharing, and managing patient information to support quality care...

You can get the report here. Interesting to read :-)

Tuesday, March 21, 2006

How can we help your product use healthcare standards and be IHE compliant?

The OHF on Server project goal is to help products utilize the standard based OHF healthcare plugins. OHF on the server will expose OHF plugins via web services to be used by any product (say LAMP,.NET, MUMPS or Java based). The code base of the plugins had already passed the IHE Connectathon 2006 tests with full success, and was used by few third party products (during the Connectathon!).

Resulting from Grahame’s comment on my last entry, we are looking for healthcare applications (PHR/HER/EMR or niche long tail healthcare software) to make a proof of concept for our plug-ins and to help us bring them to a level where they pass the next 2007 IHE Connectathon tests.

Common Terminology Services (CTS)

The Challenge

Accessing and utilizing terminology resources are a common and necessary function for many healthcare IT applications. Whether the application is grounded in decision support, charge capture or EHR integration, the ability to access terminology resources is a necessary function for enabling interoperability within and across disparate healthcare IT systems.

Common Terminology Services

The challenge of defining a predictable set of vocabulary APIs has been addressed by HL7s Common Terminology Services (CTS) standard. The CTS defines the minimum set of functions required for terminology interoperability within the scope of HL7’s messaging and vocabulary browsing requirements.

While the CTS has been implemented as the basis for several HL7 compliant vocabulary service constructs, how the CTS APIs are implemented is left up to the developer. Due to the variety of vocabulary models and vocabulary uses surrounding each separate vocabulary application, CTS APIs can be implemented in multiple ways, each making sense when considered within the context of each implementation domain. The most oft sighted example of is a charge capture application, requiring near real time access to a vocabulary resource, contrasted with a decision support application, requiring true real time access of the vocabulary resource.

The OHF goal of providing HL7 CTS standard APIs is laudable, but begs the question: What is the end goal? Since vocabulary models and vocabulary uses differ so dramatically, to what model or implementation should the CTS be implemented? How can OHF implement CTS in such a way that it be relevant to such a diverse audience?

Common Model

One possible answer is employing a common terminology model to which the CTS APIs can be written against. A common terminology model is a meta-model to which many terminology models can be mapped. The common model maintains the semantics of each individual terminology resource mapped into it, while providing a common denominator of understanding for all terminology users. The CTS is then implemented to ‘talk to’ the common model. This is in contrast to implementing CTS for each individual vocabulary application. Thus, the CTS APIs return the required vocabulary content by accessing the common model, providing the availability of multiple vocabularies by a consistent API call.

If all of your terminology content is stored in a common format, then tool writing becomes much easier as you no longer need to write different tools for each terminology. If you have standardized API's for accessing the content, then your applications that use the content no longer have to have custom code for each terminology.


One such model is the Lexical Grid model developed at the Mayo Clinic. LexGrid is an Open Source vocabulary model capable of maintaining the semantics of multiple vocabulary resources in one meta-model. The LexGrid Model is a proposal for standard storage format for terminologies and ontologies. The LexGrid Model defines how terminologies should be formatted and represented programmatically. It also defines several different server storage mechanisms and a XML format.

The LexGrid model has already been selected by HL7 as the vocabulary model in which the HL7 vocabulary will be represented.

Combining OHF, CTS and LexGrid

The OHF goal of providing HL7 CTS standard APIs can be achieved by using both HL7 CTS APIs and LexGrid. By providing HL7 CTS APIs that query against the LexGrid model, along with examples and instructions on how to semantically represent vocabularies within LexGrid, a common set of HL7 standard CTS APIs can be provided that will communicate with LexGrid, and thus the vocabulary resources represented within LexGrid. This allows a single set of APIs to be developed that can work with multiple vocabulary resources for multiple purposes. Developers will no longer need to develop custom terminology resource implementations for custom applications, but can map their required terminology to LexGrid, and make use of already implemented HL7 standard APIs to access the terminology content.

Moving Ahead

The OHF goal of providing HL7 CTS standard APIs is a necessary but not sufficient part of the OHF Framework Terminology solution. To help achieve terminology interoperability, a common terminology service must be developed. Implementing already standard terminology service APIs against a common terminology model will go a long way in providing standard terminology interoperability within the healthcare arena.

About the OHF Blog

This blog is actually for use by all the OHF committers. Regular contributers will be myself, Eishay Smith, and Russ Hamm. Very quick bio's:
  • Grahame Grieve - Jiva Medical (, co-chair HL7 Infrastructure & Messaging
  • Eishay Smith - IBM Almaden Research Center
  • Russ Hamm - Mayo Clinic, co-chair HL7 Templates

Thursday, March 16, 2006

Making the tail of healthcare software longer

A lot has been said about the obsolete Healthcare information technology (HIT) which still dominates most of the healthcare market (can paper folders be considered as IT ? ;-).

The Internet and Information technology explosion hyped the “long tail” and “long tail of software”. We are starting to see niche applications targets unique healthcare needs. The long tail of HIT seems to start to wake up.

What should happen in the healthcare IT world to set the engine of the long tail into full speed?
What is needed for the “long tail” applications to mesh up into a live network and link the islands of information we have now?
How environments like the Eclipse RCP, and OHF framework can fit into this play?

Tuesday, March 14, 2006


From it's beginning, OHF has been associated with the HL7 HSSP project, which is now the SOA SIG. (see The SOA sig is starting to make waves in the HL7 community - what does it mean to use HL7 content in an SOA context. And there's a number of possibly mutally contradictory answers, but that's HL7's problem.

What I want to know is what the relationship between Eclipse and SOA is. Ok, Eclipse has tools, some of which are useful when specifying and implementing SOA. But does it go beyond that?

The OHF charter says it does - we are going to implement the SOA specifications, and perhaps work with the OMG process to provide the implementation part of the OMG responses. This means more than tools for specifying and implementing SOA, it means actually implementing SOA parts.

Obviously OSGi/Server (or Rich Server Platform) is part of the answer. But I think we need to think it through a bit more, and possibly get a wider perspective from the Eclipse community - how does Eclipse - either the platform or the community - see itself sitting in this brand new fashionable SOA world?

Thursday, March 09, 2006

About This Blog


My name is Grahame Grieve. I am one of the lead architects for the Eclipse Open Healthcare Framework. I will use this blog to talk about OHF issues, which are likely to cover java coding, industry politics (including standards), and arhitectural design questions.