Sunday, March 19, 2006

Healthcare IT -- the "Consumer Effect"

I'm a sometime patient slash healthcare-services-consumer. Which of the following technologies can I use when my healthcare services are delivered?
  • Multifunction cell phones
  • Home broadband access
  • PDAs
  • Personal or local search
  • Digital video
  • MP3 players
  • Programmable Web
  • GPS navigation
  • Social software or networks
  • Podcasts
  • Mobile video phones

Answer:

Why, all of them, right?

It depends. You'll get different responses from consumers, providers, and payers.

The title of this post and the options above come from an intriguing article in InformationWeek, "The Consumer Effect," by Andy Dornan. You guessed it -- IT shops are facing a nightmare trying to control what will soon (and have already) become obvious benefits for a connected society. Who are the innovators in healthcare IT in the vanguard?

And that's just the technology. Consider too the business processes. Are consumers part of providers' workflow? Do consumers - or rather, the technologies they use - affect revenue cycle management? Do consumers have a stake in better-faster-cheaper when it comes to their health?

In a lot of areas, my life was just plain poor before the advent of those splendid technologies. Now it's better. Can I say the same for my health care?

Points to ponder.

Monday, March 13, 2006

Service Oriented Healthcare Systems

Here's an interesting post on Service Oriented Architecture:


Book: the business of SOA is… business by ZDNet's Joe McKendrick -- Now, an SOA book for the rest of the business.

As a long-time enterprise architect, I really appreciated this quote:

I'm not quite sure what "doom" awaits by not service orienting, other than remaining mired in archiac, calcified and siloed processes — which a lot of businesses do anyway, and still manage to stay afloat. But that's the topic for another posting.

Why does that remind me of healthcare IT applications? Or, more to the point, what is the risk to healthcare service delivery of having critical business processes just "manage to stay afloat?"

Now, a good architect is taught never to confuse meaning with metaphor. However, let's look at the usefulness of mapping IT processes (web services) to healthcare business processes (delivery services) when you develop healthcare IT systems. Here's are three basic tenets of service-oriented architecture development that healthcare business processes share:

  • Services are loosely coupled
  • Focus is on the public results of the processes - the information they produce - instead of the private methods the processes employ
  • Individual processes can be re-applied for multiple purposes

If you're a clinician, think of services such as "lab services for reporting blood work." If you're a techie, think of services such as "web services for reporting lab results in a networked environment." In either case, think of recasting healthcare business processes in a different light to come up with best methods for effective healthcare service delivery with multiple partners, providers, and consumers thrown into the mix.

That's the art and science of Business Process Management, and establishing a Service Oriented Architecture for the supporting IT systems is an important strategy to consider when you apply that craft.

Tuesday, March 07, 2006

EHR - Standards for Interoperability

I am pleased to read the latest version of the EHRVA Interoperability Roadmap from the HIMSS Electronic Health Record Vendors Association. --

From Healthcare IT News:

EHR vendor group develops interoperability roadmap
The HIMSS EHRVA has provided an EHRVA Interoperability Roadmap Version 2.0 that details what is required to reach the goals for a nationwide health information network. The roadmap was developed originally in response to the Office of the National Coordinator for Health Information Technology's request for information for architectures to support a nationwide health information network.
March 7, 2006


The draft has the tone and flavor of standards that deal not with mechanics but rather with the process of establishing standards itself. Two key areas to note:

  • Framework for interoperability
    (Business, Communication Service, Integration Profile, and Base Standards Levels)
  • Categories of information services
    (Security and Identity, Persistent Information Management, Dynamic Information Access, and Workflow and Quality)

Clearly, as in architecture development for distributed enterprise systems of all kinds, "one size fits all" does not apply. It is unlikely that a single EHR product would span local HIT systems, RHIO's, and integrative models for a NHIN. This roadmap, however, can help guarantee that healthcare IT designers will achieve the levels of system interoperability -- based on business process management -- that are so keenly desired by all stakeholders.

Visit the EHRVA site and forward your comments on the roadmap.