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.

Favorite Prose: Grapes of Wrath

One of the best novels ever written. I can't possibly do justice to the context of the story in this measly little blog, so if you don't know it, you need to read the book, but Tom Joad, the main character, is contemplating the unjust death of his friend Jim Casy, the preacher-turned-labor activist, whose initials, coincidentally, he shares with another religious social activist in his day, Jesus Christ.

“A fellow ain't got a soul of his own, just little piece of a big soul, the one big soul that belongs to everybody, then...then it don't matter. I'll be all around in the dark - I'll be everywhere. Wherever you can look - wherever there's a fight, so hungry people can eat, I'll be there. Wherever there's a cop beatin' up a guy, I'll be there. I'll be in the way guys yell when they're mad. I'll be in the way kids laugh when they're hungry and they know supper's ready, and when the people are eatin' the stuff they raise and livin' in the houses they build - I'll be there, too.”

New Year's Resolutions 2008

For the past three years, we have been completely remodeling everything in Information Services and Informatics here at Northwestern. Like a home remodeling job, it has been brutally stressful and inconvenient at times, but now the remodeling is almost done and we are emerging-- from "Rennovation to Innovation." (Sorry for the cliche buzz phrase, but it works!)

In addition to our specific 2008 goals, we decided that we also wanted to list our cultural and behavioral goals for 2008, much like New Year's Resolutions, to reflect the end of an era in which Information Services and Informatics were more reactive than proactive, more servants than consultants. Here are those resolutions:

•Conduct our work with a sense of humor, laughter, and mischief…pull a prank on someone once in awhile

•Replace Renovation with Innovation
–We’re nearly done with major Renovation… now the real fun begins
–Be leaders, not followers…Ask less for permission, and more for advice
–Set the new benchmark for excellence in healthcare in each– IDX, Epic, Data warehousing, Infrastructure, Integration
–Action, dependability, and trust are preferred over conservative precaution, asking for permission, and seeking complete consensus

•Evolve towards proactive IS consultants and business partners
–Versus reactive IS servants and technologists
–Take upon an independent, entrepreneurial business mentality, serving the IT needs of NMFF

•Do not emplace nor allow for boundaries between the various campus IS organizations
–Provide seamless customer service and hand-off

•Provide early, rapid prototyping of everything-- requirements, plans, designs, applications, et al –Manage expectations, but give people something to react to, as soon as possible

•Practice lean communications and project coordination
–Conduct lean, frequent, efficient meetings as a method to better communicate and coordinate
–Make every meeting a working meeting, that gets something done

•Seek opportunities for firsthand observation
–Get out of the IS cubicle and into the customer’s work area
–Interact with customers, whenever and however possible

•Squeeze waste and inefficiency
–Eliminate minor IT inconveniences which have major cumulative effects on customers
–Challenge workarounds and anything else that doesn’t make sense
–Implement opportunities for open source technology and outsourcing

•We are now capable of being data-driven in IS and NMFF
–We’ve arrived: Analytics and metrics-driven process improvement are possible, so make it happen

•Look for opportunities to conduct true software development
–Customer-appreciated innovation will come from custom, services based web applications written on the boundaries of our core systems such as IDX, Epic, and Great Plains
–Develop applications which enable customer self-service
–Move from a Message Oriented Architecture towards a Services Oriented Architecture

Information Technology Return On Investment (ROI)

For many years as a consultant, I was well-recognized as an expert in calculating IT projects and their ROI. Companies would pay me enormous sums of money to help justify-- or kill-- IT projects based upon their ROI. I took great pride in my tough, financially-driven mindset when it came to IT investments and prioritization... until one day I realized that it was all a bunch of crap, and I was equally full of the same for selling the concept. It was all snake oil.

Depending on who hired me-- either IT or Finance-- I would cook the calculations long enough to justify the answer that the customer wanted. IT usually wanted a positive ROI to fund an investment. Finance usually wanted a negative ROI to kill a project. The reality is, it's essentially impossible to accurately calculate the a priori ROI for IT projects, and if I see another article about the ROI of an Electronic Health Record project as the basis for either justifying or killing the investment, I'm going to jump out the window. Post facto ROI calculations are much easier to calculate accurately, but even they can be tricky and misleading. Also, it is enormously rare to use a post facto ROI on a project as the basis to uninstall an IT investment, so before you even entertain the idea of this type of ROI, and spend lots of time and money in doing so, you better ask yourself, "For what purpose will the post facto ROI serve? What will we do with the answer?"

It seems to me that the best we can do is recognize the inherently subjective nature of the "Return" and focus carefully on the judicious and incremental application of the "Investment"-- i.e., invest a little, look for tangible value, then invest a little bit more. And the most tangible indicator of value won't be found in a financial calculation-- it will come from the mouths of the customers and users, which is why it's so important to deploy IT projects in small, incremental chunks which show value to someone. If the IT is valuable, people will tell you and you won't be able to pry it from their hands.

Nucleus Research, http://nucleusresearch.com/, is a very good resource for expertise in this area. They understand the balancing act between reasonable business decision making and the inherent inaccuracies of IT ROI calculations. They have a very simple, back-of-the-envelope approach that, with 20% of the effort of a traditional ROI, which get you at least 80% of the value. Nucleus suggests the following criteria for calculating the potential Return on IT-- note that the criteria do not address the Investment.

•Breadth: How many users will benefit from the IT? The more the better for ROI.

•Repeatability: How many times per day will the IT be used? The more the better for ROI.

•Cost: How costly is the task that the IT investment addresses and supports? The more costly the task, the greater the benefit from automation or appropriate technology support. Note that this is NOT the cost of the IT project investment.

•Knowledge: How reusable is the data collected in the IT solution for knowledge work? The greater potential to re-use the information in the system, the greater the potential ROI.

•Collaboration: To what degree is communication between members of the enterprise ecosystem affected by the IT investment? Communication between employees is costly, so the greater the collaboration component, the greater the potential ROI.

Healthcare Data Warehousing

Denis Protti, a gift of lucky influence in my life, from the U of Victoria in British Columbia, prodded me to finally publish, with his wonderful participation, an article on the basics of data warehousing in healthcare. Here's the link to the paper-- look for the PDF file called datawareshousing-- http://drop.io/dsanders

It's the first in a three part series, the second of which is underway and will discuss the actual hands-on lessons learned, primarily while I was with Intermountain Healthcare in Salt Lake City, but also my observations at other healthcare organizations, too.