Wednesday, December 26, 2012

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. This is great for planned transitions in care. It is the basic delivery of information from one provider to another. It can be as basic as sending results from a test or study back to the physician who ordered it. It can be a more advanced communication for a care transition between providers such as a hospital transfer or discharge.
 
This is the basic replacement of the fax machine that most HIEs start with. This is the HIE the verb it is accomplished by either peer to peer or centralized HIE services.

More advanced versions of this support active monitoring of the patient. For example, I defined and had my team implement a "Subscribe with Consent" functionality that is the cornerstone of our offerings for care managers. It is essentially, publish/subscribe that complies with the NYS consent policy. This allows the care manager to subscribe to the patient events and get a PUSH notification or document to trigger care coordination. For example, we can send discharge summaries to care managers for the patients from whom they have collected affirmative consent. That monitoring is a value of HIE the noun over pure peer to peer (P2P) solutions.
 

Review Patient Clinical History

This is the primary purpose of the HIE PULL functionality. The PULL has mistakenly been described by some as the naked and unconscious in the ED use case. However, that is not the case. This functionality covers any unplanned or uncoordinated transition in care. Showing up at the emergency department is one of these, but naked and unconscious has nothing to do with it. In fact, if that were the case, I don't think it would work if the treating team could not identify you. It is more likely that the patient is dressed and conscious and has granted consent to access their records. This is also valuable for other ambulatory visits to review recent activity with other providers that your family physician or specialist may have been unaware of otherwise. It saves time and money tracking down records with other providers.

This is the slightly more advanced HIE query/response that replaces phone calls and fax machines and does in seconds what would have taken hours and probably not even been attempted. This is what more advanced clinical HIEs do today. This is HIE the noun as most people see it.
 

Schedule Patient Visits

The clinical HIE is the ideal place to exchange (both PULL and PUSH) schedule data. It gives the provider a view of upcoming appointments and missed appointments. Being able to request appointments and get one scheduled via HIE enables collaboration between the patient, care coordinator (if not the patient), and the care team (all providers).
 

HIE must Support Care Manager Use Cases

Manage Care Transitions

  • Notify Care manager when patient meets criteria for transition assurance.
    • This is the use of functionality such as the "Subscribe with Consent" mentioned above.
  • Track patients enrolled in various management programs
    • This is basically an additional demographic of the patient. What programs are they enrolled in?
  • Schedule Appointments with Practices. 
 

Manage Patient Adherence to Quality Standards and Physician Orders

  • Support direct contact with patient for Follow-up scheduling. The HIE should be able to connect the consumers system (a PHR or similar) for communicating with their care team.
  • Notify Care Manager when patient falls out of adherence or is about to. This can be adherence for quality measures, attending appointments, or filling orders for medications, lab work, image studies, or other referrals.
 

HIE must Support ACO Program Development and Evaluation Use Cases

 
The product of the ACO is lower cost, higher quality care through evidence based management of the patient care lifecycle. Analytics/Reporting against the HIE activities is a mean to close the loop in that lifecycle for continuous quality improvement (CQI).
 

Analyze Current Operation

The HIE needs to support reporting on clinical and financial outcomes with ability to segment and aggregate based on patient care lifecycle (how the patient flowed from point a to point b with or without intervention along the way)
 

Develop New Programs

The HIE needs to support an ability to define a program and enroll patients into that program. This is covered above in program enrollments as well.
 

Implement Change

The HIE needs to support an ability to assign patients to care managers. The care managers are the implementation of the care management program.

This is all about getting the right data sent to the right person. For example, "subscribe with consent for whom?" The answer is for care manager X and ACO Y or for the PCP, etc.
 

Measure effectiveness

The HIE needs to support the reporting need as “Analyze Current Operation” but with ability to compare with and without ACO program and cost savings versus the cost of the ACO program itself (Value of the ACO program).

This closes the loop on the question: "Did the program work as we expected it to?"
 

HIE must Support ACO Revenue Cycle Use Cases

 

Track patients enrolled in various management programs

This is simply reporting against the HIE by patient demographics (program registrations are essentially just a slowly changing dimension of the patient demographics).
 

Report Quality for Pay for Performance (P4P) measures.

Ease reporting submission to CMS’s Physician Quality Reporting System as it moves to accepting QRDA XML submissions.
 
Theoretically, quality will be how ACOs and other may be paid in the near future. The HIE is a great vehicle not just to submit these documents but to find exceptions in them and to share them with other providers.
 
By finding exceptions in the quality reports, providers can benefit from increased compensation. The HIE can find where the patient is actually in compliance with a measure and send the information back to the ACO or PCP to recalculate their measures.
 
By sharing the quality reports as sections of the on-demand CDA document produced by the HIE for consumption by providers (The CCD or portal view that providers look at), they can get a quick view of patient non-compliance and have an opportunity to bring them into compliance. This opportunity can occur anywhere in the community, not just at the PCP office. The patient will then get the same message on compliance everywhere they go. They can be bought into compliance during an urgent care visit as well as at their PCP so long as compensation models support/reward it.

 

Summary

 
I think the evolution beyond displacing the fax machine above is what will make HIE a game changer for healthcare. We won't be supporting just a better mousetrap for moving information. We will support better management from better information.
 
 

Sunday, December 23, 2012

The Audacity of Tenacity


A Lesson in Strategic Management of HIE

Recently I was awarded "The Game Changer" award by the HIXNY collaborative RHIO, where I am the current COO. It was a very nice presentation including a letter of recognition from Senator Charles Schumer.

In reflection though, I didn't "change the game". What I did was I continued to play the game long after the other regions around the state abandoned the statewide strategy for other pursuits. As a result, HIXNY is the only real implementation of the SHIN-NY standards.

Strategic Management

Many years ago, in a class on strategic management, we studied the varied aspects of strategy. Most of it was fairly basic common sense, but a couple of the more unusual aspects of strategic management that stuck with me were serendipity and sticktoitiveness. Thus, I try to never miss an opportunity that falls in my lap, and I try to be tenacious and never give up too soon.

Managing Stakeholders and Expectations

If I had given up on the SOA/ESB model of exchange, HIXNY would not be where it is today as perhaps the most robust multi-stakeholder exchange in the country. During the process, it was like opening a restaurant with Gordon Ramsey, I had to keep the patrons (healthcare providers) in the restaurant, the cooks (my staff) in the kitchen, and the waiters (HIT vendors) getting the orders right and in line with what we could deliver and when.

The patrons wanted to eat and instead of waiting for their dinner, they wanted to eat some appetizers. Unfortunately, this would take away the stove from the main entree so we had to limit the appetizers to just a few. Those appetizers took the form of minor demonstration projects that were built on fragile infrastructure and would later have to be migrated to the more robust SOA infrastructure we were building. While this slowed overall achievement, it was necessary. Unlike when you cook dinner for someone, they can't see a half-baked HIE and get an estimate of when they will eat. It doesn't do anything the stakeholders will recognize until it is done. Those of us in IT knew when we were 90% of the way there, but the stakeholders couldn't tell 10% from 90%. To them is was all 0% or 100%. So they needed the distraction of minor demonstrations to prove that we knew what we were doing.

The cooks were mainly just afraid that the patrons would storm the kitchen. As long as I just made it clear that we were staying on our path come hell or high water, and they didn't see any fear in my eyes, we were fine.

The waiters were another issue all together. Basically, I had to play them against each other. Who would get an extra reward for being first to take an order and deliver it? Vendor X is going live next week, with all the work you put in don't you, Vendor Y, want to go first? The truth was nobody was going live. They all wanted to test more. The problem was, test data was never going to present all of the variation as production. Somebody was going to have to serve the first meal and hear that the meat is undercooked. Eventually, I got one to move through this competitive positioning and another to follow. The rest would then follow out of competition as well.

Taking Risks and Drawing on Experience


Even one of my key vendors didn't want to support our move to go live with repository exchange for the same reasons. Their exact response was "no don't do it, it’s not ready". I simply told them that they better put on more support staff and expect that we were going to open support tickets. The meals were going out to the patrons, ready or not. We were going to learn and fix at the speed of live production. If I didn't do it, who would? My problem was, I didn't spend two years of my life just to show a test implementation to NYS to get final payment from a grant. I did this to do it for real. So we were going live. We were between CEOs at that moment so I didn't need to ask anybody. It was my responsibility to make the call and my accountability to live with the consequences.

I had the prior experience taking ERP systems live across the globe. I knew that nobody was ever happy enough to take those live either, but we always made it through and had a more successful company at the end. So, I figured we would have some complaints but those would happen no matter when we did it and how much more testing we did. It was go time.

Sticktoitiveness is NOT Following the Herd

I could have followed the herd. The herd was just getting signoff on grants and never putting repository based HIE into production. The herd was so concerned with their customer having a perfect experience that there was no such thing as a "good enough" first effort that could be improved upon. To add to that, some parts of the herd were already moving onto the next thing, like Direct.
We didn't follow the herd and after one year in production with the standards everyone agreed to, we have delivered on the promise. The customers see the value developing. There is still more to do to make this easier and more valuable but we are on the right track. By taking the risk, we eliminated the chance that HIXNY would give up and follow the herd of non-compliance with the state model.

Deliver with Integrity because the game never ends

In the HIXNY case, we have a payoff for now. This is a changing market however. Thus, those who did not stick, may still wind up on top. I suggest anyone building an HIE stick to what they say they are going to do and achieve something besides pulling down grant funds. Even if others pocket more money and perhaps win over you in superficial ways, at least you can have self-respect and there are always other opportunities for those who deliver on what they say they will deliver. The game may change. You may win a round or loose a round. But the game never ends.