True Healthcare Reform

I will trust that true healthcare reform has arrived, when doctors stop wearing stethoscopes like a policeman wears a pistol... At the ready, all the time, just in case a violent heartbeat breaks out or a congested lung tries to hold up a 7-11.

That was a friendly jab at my physician friends...like they jab me for wearing a pocket protector.

;-)

If Google Wants to Help Healthcare

They would develop an open source, freely available tool for probabilistically matching patient identities and managing patient record duplicates. If Plaxo can do it with my contact lists, why can’t Google do something incredible with patient identity? I’m pretty sure a patient is a person and sometimes vice versa, so the concepts for identity should cross over, right?

I appreciate Google’s recent involvement with PHRs, especially anything to enhance their portability. Like our dear and respected colleagues at the Cleveland Clinic, we also use Epic’s MyChart product. It’s very impressive-- extremely functional—and our patients love it. But, it’s not truly a personal health record because our patients can’t personally port their personal data between personal care settings, not even to other Epic sites without a great deal of trouble. I sincerely extend my compliments to Google and the Cleveland Clinic for addressing the portability of data between PHRs. I hope that, within the scope of their project, they also focus on the portability of those past medical history forms, family history forms, current medications, etc.—i.e., the redundant and repetitive manual collection of which plagues all of our patients in every care setting.

But… If Google really wants to help healthcare, and can do so with only a minor investment and extension of their existing computing skills, they would build an open source software service for patient identity matching and duplicate management that could be downloaded for local use or be used in an ASP, “software as a service” model.

Encounter-based healthcare, where we’ve been stuck for hundreds of years, starts when a patient and a provider come together. Patient identity management doesn’t matter much because we tend to focus on the health issues right here, right now. On the other hand, longitudinal lifetime-based preventive medicine and healthcare, which is where we need to go as an industry, fundamentally requires the consistent and reliable identification of a patient throughout their lifetime. I’m preaching to the choir, right? But, if I’m preaching to the choir, why do we still struggle with this issue as an industry, which is one of the most fundamental building blocks to effective healthcare?

At their request, I facilitated a meeting with a large hospital system a few years ago who was also struggling in various ways because they lacked a master patient identifier. They were trying to cost-justify their investment in an enterprise master patient index. In the meeting, we calculated the average costs per incorrect patient identification. We calculated their lost revenue from billing, delayed A/R, etc., but kept that in a separate section of the spreadsheet, purposely, because we were really trying to appeal to the physician leadership of the company, not the CFO, by emphasizing patient quality of care and safety. At the end of the reasonably sane process for estimating the benefits to their system, ignoring the billing benefits, we then extrapolated the costs to the entire healthcare industry in the U.S. -- $24 billion annually and that was in 2002. BTW, the hospital system justified their investment in a master patient index.

So, Google, do the country a favor— apply those incredible brains and capabilities and build a free, open source tool that we can be used locally or as a secure ASP to more effectively manage patient identities. Design it so that it can also extend to a national, voluntary patient identification system, across all EHRs and PHRs.

Services Oriented Architectures

While I’m thrilled to see SOA momentum, my cynicism tells me that many of the headline grabbing initiatives in health care are poorly conceived, based upon what I’ve read and heard from those involved. I see a gold rush to SOA in health care, but many people still don’t “get it” when it comes to fully grasping SOA concepts. Ironically, we are over complicating the basic software engineering issues and overlooking the simple lessons-learned from previous similar frameworks and building blocks like JCL, DCE, RPC, OOP, CORBA, and COM. More than any other point, I emphasize that SOA concepts are not new, nor revolutionary. They are very much evolutionary, and the more we in the health care industry understand about the history of events, methodologies, and technologies which preceded the current attention on SOA, the more likely we are to be successful and avoid the mistakes of the past. Kevin Chamberlain in Harvard Business Review On-Line wrote: “Leaders often fail to consider history because they have an unhealthy sense of their own uniqueness, and they have a sense that the events around them are 'peculiar' to their time and therefore history is of little value.” I see young and inexperienced software engineers and marketing representatives from vendors who tout the heroics of their capabilities in SOA, yet can't answer basic questions like:

• What led to CORBA's poor adoption rate?
• Which companies have grasped the essence of SOA and are leveraging it best and how?
• How do you balance fine and coarse granularity of services in an overall design strategy?
• What principles of granularity have you developed for your software engineers?
• What's the value of UDDI in a smaller organization with no intent to publish?
• How does an entire industry manage UDDI without the content imploding over time?

One of the most important and first SOA steps in health care is simply the development of a semantic list of services and the basic API's for services associated with our industry. This exercise is equivalent to defining the message types in HL7, but at the software services layer, not the messaging layer. To use another metaphor, think of data modeling at the software services layer. I believe HL7 is the best governance organization for this new "SOA Standard" to reside, but I'm not encouraged by HL7's embrace of or progress on the topic so far. I'll keep my fingers crossed.

I was a chronic agonist to my friends and colleagues at Intermountain Health in the late 1990s about this topic. Arguably, the failure of our relationship with 3M and the Care Innovation Suite can be traced to a poorly designed services layer. In 1998 or 1999, we finally held a retreat at the local Marriott and documented the list of core software services, and their behaviors, which would define a future path for our development efforts. I'm not sure what happened to that list-- I would love to have a copy-- but the 3M relationship was eventually replaced by GE, and the development of the 3M services fizzled. I hope the current development agreement between GE and Intermountain has somehow resurrected those core services, at least conceptually. Developing the list of services does not represent a "rocket science" endeavor. It's a day-long affair with a handful of bright people who understand software engineering and healthcare processes. Iterative improvements on the list will go on forever, but getting started is not that complicated.

Anyway, the bottom line is: We are transitioning from a "buy and maintain" to a "buy and develop" culture at Northwestern and we plan on making tangible progress with our SOA in 2008, but we likely won’t be looking to any of the early headline leaders in health care for positive role models unless I see a greater appreciation for the history that got us here.