Open Healthcare Framework

Tuesday, August 01, 2006

OHF as an API for Healthcare Interoperability

Among others, the Eclipse OHF project is being used in several events sponsored by Integrating the Health Enterprise (IHE) and Health Level 7 (HL7). The OHF IHE plugins build atop of other core OHF components (security, and HL7 stack for example). OHF members are active in the IHE committees, and share the goal of true interoperability in healthcare.

One could argue that the IHE specifications can be viewed as a distributed "operating system" for healthcare interoperability. Some of the reasons MS Windows™ became a popular "user experience" OS in the nineties is:
  • For developers, Windows provided tools to
    • Write pixels to the screen and use assembly if they really wanted to
    • Use standard components in C++ to make an application more conveniently with windows native UI.
    • Use Visual Basic to make it possible for the novice programmer to create a decent application.
  • For the users they provided a good plug and play experience. It wasn't perfect but the drivers mostly worked, and users where not expected to ever know about source code compilation.
Please don't flame about using Windows as an example. I use and love both Ubuntu and MacOS, just want to make a point of how to help users and ISVs use a system.

How can OHF help make the IHE model the dominant healthcare interoperability architecture? Obviously open standards and technical excellence are not enough. Here is the OHF analog to the list above:
  • For IHE developers, OHF provides tools to
    • Implement the IHE protocols, going down to the IHE "assembly"; i.e. implementing the ebXML, SOAP, HL7 stack and so forth. No need to use OHF for that, though one may use at least few of the OHF building blocks like the HL7 and security plugins.
    • Use the OHF Plugins (such as the provided actor APIs, data structures, and security features) as building blocks to construct IHE compliant applications.
    • Use the OHF Bridge web services interface by existing applications. The bridge exposes radically simplified API to make it possible for the novice IHE user to easily create healthcare interoperability workflows.
  • As we found in the last IHE Connectathon, protocols and specs are great but in real life, implementations seem to create "dialects" of the protocol. OHF users will enjoy a plug and play experience. It won't be perfect but OHF will provide components well tested against vendor services as soon as those become available. Users are not expected to know about ebXML, namespacing problems, carriage return charecters in a SOAP attachment, or the HL7 versions.
So why open source? As the saying in the HIT for small & medium clinics goes "free is not cheap enough", license is only part of the TCO and it's not what open source is all about. The main reason for Open Source is it's collaboration model. Open source provides a great collaboration model between partners and rivals in the IT market. A good example is the Eclipse organization itself where you see a set of partners and rivals BEA, Borland, CA, IBM, Intel, Motorola and Nokia collaborating and sharing actual source code.


Post a Comment

Links to this post:

Create a Link

<< Home