Skip to main content

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.

Comments

Post a Comment

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
7 comments
Read more

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
3 comments
Read more

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
1 comment
Read more