Skip to main content

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.


Popular posts from this blog

eRegister and Get Rid of the Clipboard

The Real Use Case for Personal Health Records (PHR) I have been at this, HIE game, for a few years or so now. And when I go out and meet new people, I get the typical, "so, what do you do" question. Once I tell them and give a little explanation of what it means, about half of them have a follow-up question. There is only ever one follow-up question and it is always the same question "so, are you going to get rid of that clipboard of paperwork that I have to do over and over again every time I go to see a doctor". The fact that I only get one question from general consumers and it is always the same question tells me one thing. This is what matters to them. This is how they see their information making it from them to their provider today. This is what they want to eliminate by using HIE or a PHR. In essence, I see the HIE and PHR as one in the same. The HIE, in a fixed repository model, is a collection of "views" of the patient. We have a primary

Game Changing Healthcare Information Exchange

Evolving HIE Beyond just replacing the fax machine   HIE can be more of a game changer for healthcare than just being a replacement for the fax machine. The route to being a game changer is to be an enabler of care management. That care management can come from a health plan (managed care organization), an Accountable Care Organization (ACO) like a Patient Centered Medical Home or Medicaid Health Home, or from the patient/consumer as care manager for themselves or as the caretaker of another.   To do this, I think the HIE needs to serve the following customers and their use cases. These are the healthcare providers for care coordination, the care manager in the role of managing care, the care management at a program management or quality improvement level, and the care management at a financial management level.     HIE must Support Provider-Patient Coordination Use Cases   Send patient data between providers This is the primary purpose of the HIE PUSH functionality

Why Direct makes sense for Data Delivery to an EHR Hub

Who precisely are you sending that message to? There is a little recognized problem in using legacy HL7 over VPNs to deliver data (lab results, image studies, reports, etc). The orderer is in the message regardless of whether you are trying to send to them or not. The CC list is in the message regardless as well. The attending, the primary, etc. all there but maybe not who you are routing to. Who are you routing it to? How is this a problem? In today's modern world of Software as a Service (SaaS), many of the EHRs get data delivery through a common gateway for many practices. If you route a message to a single practice with a locally installed EHR, then when the data source (e.g. hospital or an HIE as its proxy) sends a message to the practice, the practice endpoint and the EHR endpoint are one in the same. There is no confusion about who the message is for. When the EHR serves multiple practices is where we get the confusion. The endpoint of the practice is a spoke off of