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!

8 comments:

  1. I think pretty much every one of the platitudes we repeat related to SOA are the exact same ones we echoed ever since the advent of distributed computing. Why are these deemed to be a magic bullet again today?

    We really have not changed any of the underlying complexity of building distributed systems. In the end there are complexities when you get beyond scratching the surface of the simplest transactions and the engineering principals that need to be applied are not new or wonderful.

    Any system of some maturity has some kind of legacy data model, built in business and domain assumptions that make end to end compatibility with various other applications much more difficult to realize that a casual observer would think.

    IMO oppinion the primary difference today in this "SOA" era has nothing to do with distributed computing platitudes. It is simply that it is now generally possible and generally accepted that software will run on an open worldwide network and allow for almost any system to communicate with another.

    That is the only real difference between 20 years ago and now with respect to "SOA" (aka distributed computing). The alphabet soup of over the wire protocols or RPC techniques over the years has not added significantly to our ability to interoperate at the application level which IMO is the most difficult level to get compatibility. The lower levels of the stack are the easiest ones to standardize on and every time we change those lower levels we celebrate and act as though a new magic level of application level integration is now possible.

    But in the end making the top level of the stack interoprate with other systems is just a hard job and nothing in SOA is articulating anything novel in that area beyond what we already knew about distributed systems. I think focusing on it as an area of specialty may assist us in furthering everyone's education on the topic so that is a good thing but I just don't appreciate our industry trying to ring in some new era when there just isn't anything new.

    We should all accept that we now have a global and ubiquitous network that allow for a renewed focus on distributed computing but lets not pretend that some new "ah ha" moment has now made it magic to connect applications together.

    ReplyDelete
  2. Regardless of one's views of the relative novelty of SOA principles, I believe this step by HITSP is great news. One missing dimension in our ability to create more interoperable information systems is consensus in how to practically implement standards. I've advocated for a few years that an industry architecture (i.e., shared agreement on how enterprise architectures can interoperate) across health and life sciences would enable us to more effectively design applications that can participate in loosely-coupled scenarios, especially those related to shared data domains such as drug safety. An SOA focus from HITSP would allow us to address and overcome at least some of these human-related barriers that can have a big impact on the time, effectiveness, extensibility, and corresponding costs of these implementations. Keep up the great work, John.

    Jason Burke
    http://blogs.sas.com/hls

    ReplyDelete
  3. How will SOA / web services be impacted by HIPAA? Will all patients have to give consent if data is moved outside of one organization? What if the web services are delivering decision support and only need anonymous patient data? Would this need discrete consent?

    ReplyDelete
  4. Interoperability is a key success of such enterprise. Standards must be shared and adopted by main players in the industry.

    Having to may standards does not achieve interoperability goals more then having no standard.

    How does HITPS compares includes or "interoperates" with ASTM Continuity of Care Records standard.

    ReplyDelete
  5. Thanks for the comments. I do not believe that technology alone fosters connectivity. However SOA does help us with process and governance issues too. SOA with appropriate data use agreements can wrap any content - X12, NCPDP, HL7, ASTM, so it really helps all the standards develop organizations exchange their data contents in a consistent way.

    ReplyDelete
  6. Nice infomation blog on HEALTH care
    www.medicoglobal.com Medical Tourism

    ReplyDelete
  7. I am involved in the development of a wireless data network for blood pressure monitoring. The additional network requirements will be in terabytes. Issues I see with the network will be the management of the prognostic information that maybe gleaned. The framingham studies have clearly shown the strength on studying such a data set. Are the physicians ready for such a datastream?

    ReplyDelete