Thursday, August 30, 2012

"Version the Verb" is more efficient with "HIE the Noun"

What happens when you version the standards for P2P exchange?

One of the key value propositions of "HIE the noun", for example an Enterprise Service Bus (ESB) based regional patient-centric exchange, is that it abstracts between data providers and data consumers. Thus, if a new standard comes along, some can implement it and some can hold off. The HIE provides the abstraction between the two. There is no tight-coupling between trading partners. In the "we will all do the same thing peer to peer" model, doesn't it break when something new comes along? Otherwise, every P2P end-point needs to support every standard that emerges as they emerge and until everyone has it implemented, the world is frozen.
That sounds an awful lot like where HIT is with ICD10 right now. Most systems seem to have tightly coupled to the ICD9 codes rather than having an abstraction in their system between internal coding and the outward facing standard codes, now they have trouble upgrading, and nobody can move until everybody moves or the trading partners need to build the abstraction that they missed so that they can do both without losing granularity in the coding. Why repeat the ICD10 mess, build on abstraction!
Part of the argument for a P2P strategy is that current HIE is too expensive if you can even do it. I say ESB based HIE is less expensive than the support of P2P because of reuse and we do it every single day.

Essentially, I only see 3 possible ways to support electronic HIE:
  1. You build on a single standard and never change it so that P2P is inexpensive but is not adaptive to change or extensible for new solutions.
  2. You allow change but still want P2P so everyone runs an ESB and everyone supports every version of every standard and they need to tightly-couple to their trading partners by knowing what standard they support and transforming to that standard.
  3. You have a community service bus, an "HIE the noun", and thus you benefit from reuse. Everyone has one integration with the ESB rather than with each other. And you benefit from abstraction. You don't need to know how your trading partners can send or receive data, the HIE takes care of the transformation.
If option one were a reasonable model, we would all be running Version 1 of just about everything. So logically, that is not going to happen. Option two is what option one leads to once you realize standards version and get replaced. Option three is the cost saving alternative to two where you centralize the abstraction as a service. That abstraction service is called HIE and it is generally provided by RHIOs in the parts of the country that have successfully matured this service. So what is the argument for P2P being less expensive again if it results in every system having to be an ESB and everyone having to know how what their trading partners can support?

Friday, August 10, 2012

Is our HIE Effective?

In "Ryba's 16 rules of effective HIE" published in Government Health IT, I recently wrote about what I believe to be the rules that can be used to define an HIE that is reusable across all use cases. I don't get into what technical implementation it supports or even what type of healthcare information is being exchanged. However, if your HIE complies with these rules, I believe you have a "fully effective" HIE. That said, if it does not, it may or may not be adequately effective for where the world is today. The point is, these rules are what I think exchanges, public or private, should comply with, or at least should be able to comply with, from a functional perspective. How soon you will need to meet all of them will probably be determined by market forces or government mandates in your area.

While I left technology out of the rules, if you follow any of my previous writings, you know I of course believe that a services oriented architecture and enterprise service bus best applies to the rules primarily due to its inherent focus on resuability and abstraction. So, if you are building your HIE using an ESB, I think you are probably heading in the right direction.

If you haven't yet met all the rules, you probably are not alone. The rules are what I think we aspire to. They are based on mostly where we are but to a greater degree where we are going.

To answer my title question, our HIE is effective and is mostly compliant to the rules, but like all HIEs, we still have work to do. Abstraction is an area that seems to always need continual maturity for both syntactical interoperability to transform between transports and schemas and semantic interoperability to translate terminology between different vocabularies. Syntactical interoperability allows one to know what the other is saying; semantic interoperability allows them to understand what you mean. This is never-ending work since new standards emerge or version on a regular basis. The abstraction rule is where myself and my staff spend a lot of our time. We see it as a big part of the technical solution value of HIE the noun.

Friday, August 3, 2012

Weaving the "Fabric of Care"

There have been a lot of varied models of care management for many years now that are described by terms like Health Homes, Patient Centric Medical Homes, Primary Care, Managed Care, Accountable Care, etc. One thing I have noticed is that the industry seems to skim over the fact that this cannot be a patchwork quilt of care. It needs to be a woven fabric of care that can be cut and sewn into varied models through mass customization. We cannot expect that a provider is going to function differently if the patient in front of them is enrolled in a particular program or not. That certainly isn't going to create administrative efficiencies; quite the opposite. If they have to capture different information, provide different information, or provide different treatment based on how care is paid for; they will certainly be less efficient due to administrative burdens. Therefore, the customization needs to happen in the background as part of the ACO business processes.
 

Business process management (BPM) is the loom

 
As I mentioned in an earlier post, the well-architected HIE is based on a Service Oriented Architecture (SOA) and implements an Enterprise Service Bus (ESB). The HIE's ESB is essentially a "Healthcare Process Manager" and provides the ability for organizations to define business processes, otherwise known as "orchestrations", to automate care coordination activities based on events. HIEs provide the event notifications. The orchestrations, usually developed in Business Process Execution Language (BPEL), apply business rules to an event to decide to trigger additional events that drive action or care intervention. For instance, a patient is discharged from a hospital; this can trigger an event for follow-up appointment scheduling. It also may reset the clock on one or more quality measures. Based on either the immediate event (visit) or subsequent time based events (falling out of quality compliance if no more visits) intervention can be driven.
 

Business activity monitoring (BAM) cuts the fabric

 
While BPM allows the implementation of new business processes to manage care, without impeding on those providing care to perform varied activities based on compensation models, BAM lets you grade the effectiveness of those processes and business rules. With BAM we can answer questions like; How many patients are compliant now versus before a change?; How many patients have been readmitted with avoidable conditions based on our business rules?; and How have these changes over time as we change our business processes? This "Healthcare Activity Monitoring" provides the platform for answering all of these questions and driving action to change processes based on results.
 

Dashboards for care managers sew together a finished product

 
The above are implementations of existing abstract technologies for Business Process Management (BPM) and Business Activity Monitoring (BAM). The HIE differentiator comes from using its real-time data feeds to provide services like real-time quality reporting based on standard business rules for healthcare such as NQF quality measures. Additionally, BPM and BAM can provide the flexibility for power-users to define custom business rules and dashboards. Hence, the HIE portal platform can be extended as an application for triggering care coordination through event alerts and quality reporting dashboard mash-ups that meet individual needs.

Why the finished product is better than the patchwork


What we enable using the SOA/ESB based HIE (BPM, BAM, and mashups as needed) to abstract between program management and care delivery is an environment where care is delivered in a uniform manner.

  • With our finished product the management (definition, monitoring, and change) of the programs is on the program managers and not the care delivery. Mass customization using BPEL and mashups allows for many programs to be defined and manages without creating undue burdens. The patchwork alternative puts custom systems in place for every program and undue burdens on care delivery.
  • With  our finished product the patient gets a uniform message from care delivery based on information sharing, including patient history, quality measure compliance, and treatment plans. Thus, the patient can be guided towards the same quality care at any and every point in care.
I suggest that as new ACO and Healthplan programs are launched, they should look first to how they will use a SOA/ESB based central HIE to enable the program rather than put in another silo solution intended to support one programs need.