Tuesday, September 30, 2008

Service Oriented Architecture for Healthcare

As chair of HITSP, I am a non-voting facilitator who supports all stakeholders equally - large/small, open source/commercial, payers/providers. It's rare for me to personally champion an idea, but today's HITSP Board meeting has given me a cause to celebrate.

We reviewed a proposal, to be widely circulated among all stakeholders, which envisions a future for HITSP as the champion of "service oriented architecture (SOA)" for healthcare.

Before you declare that SOA is just another fad at the peak of the Gartner hype curve, realize that SOA is not about a specific technique such as web services, but about a way of connecting organizations using a set of principles that adapts easily to changes in technology.

The joy of a service oriented architecture is that it is loosely coupled - each participant does not need to understand the internal applications of trading partners. SOA exchanges typically do not require complex technical rules for interactions between senders and receivers.

Highlights of SOA include:

* Service "contract" - Services adhere to a communications agreement, as defined collectively by one or more service description documents
* Service abstraction - Beyond what is described in the service contract, services hide logic from the outside world
* Service reusability - Logic is divided into services with the intention of promoting reuse
* Service composability - Collections of services can be coordinated and assembled to form composite services
* Service autonomy � Services have control over the logic they encapsulate
* Service discoverability � Services are designed to be outwardly descriptive so that they can be found and assessed via available discovery mechanisms

To date, HITSP interoperability specifications have focused on the contents of the medical record and vocabularies, not the transaction rules among participating systems needing to exchange data. Although HITSP has developed specifications for transmission of data, it has not specified a common "envelope" for routing and delivery of healthcare information, leaving that to individual implementers.

The HITSP Board voted to establish a working group which will deliver a plan within 90 days to wrap all HITSP work so that it will plug and play with a service oriented architecture. The advantages of doing this
is that it provides strategic position for HITSP within national initiatives as the coordinator and harmonizer of SOA for healthcare. It also helps all the other national healthcare IT stakeholders by:

* Incorporating the lessons learned from the recent Nationwide Health Information Network demonstration
* Providing CCHIT with the necessary standards and framework for certifying Health Information Exchange
* Aligning HITSP work with industry trends including the Federal Health Architecture and IHE efforts
* Rationalizing the reuse and repurposing of HITSP interoperability specifications and their components

You'll hear much more about this effort over the next several months.

When a healthcare stakeholder asks questions such as "I need to exchange medication lists, discharge summaries, personal health records, glucometer data and quality data" the answer will be - HITSP has a well defined service component for that!
Load disqus comments