A question: What is the opposite of health IT return on investment?
The answer: Unintended financial consequences, or UFCs, for short.
The scenario: A sophisticated medical center health system begins to roll out an expensive proprietary EHR and shortly thereafter sustains an operating loss, leaving no choice but to put the implementation on hold. The operating loss is attributed to “unintended financial consequences” directly related to buying a very expensive EHR system.
This is exactly the situation at MaineHealth, who selected Epic. As recently reported, a little while ago Maine Medical Center President and CEO Richard Peterson sent a memo to all employees saying the hospital …
… has suffered an operating loss of $13.4 million in the first half of its fiscal year. The rollout of MaineHealth’s estimated $160 million electronic health record system, which has resulted in charge capture issues that are being fixed, was among several reasons Maine Med’s CEO cited for the shortfall.
“Through March (six months of our fiscal year), Maine Medical Center experienced a negative financial position that it has not witnessed in recent memory,” Richard Peterson, president and CEO of the medical center, wrote in the memo to employees.
Peterson’s memo outlines the specific UFCs that explain, in part, MaineHealth’s operating loss:
- Declines in patient volume because of efforts to reduce re-admissions and infections
- Problems associated with being unable to accurately charge for services provided due to the EHR roll out
- An increase in free care and bad debt cases
- Continued declining reimbursement from Medicare and MaineCare, the state’s Medicaid program
These challenges are common to just about any medical system in the country, making MaineHealth potentially a harbinger of things to come for those hospitals and health systems that pay multi-millions of dollars for a health IT system.
The State of Maine is rightfully concerned about the developing financial scenario at Maine Medical Center and within MaineHealth. In a May 1 letter to the editor of the Boothbay (Maine) Register, local Selectman Stuart Smith questioned the EHR buying decision and associated operational costs that led Lincoln County Heathcare, a MaineHealth member, to close the local healthcare facility, St. Andrews Hospital.
I do question the $150 million figure. I think it is extremely high and Portland has had a real failure in its implementation. So much so that it looks like [Lincoln County Heathcare] will not have a real integrated EMR until 2015 and financial software problems exemplify a major failure of [MaineHealth] to create any real benefit to the state.
It becomes important to understand what MaineHealth and arguably many other health systems face financially with regard to total cost of ownership (TCO), return on investment (ROI) and those dreaded, apparently unpredictable, UFCs.
Based on some widely accepted industry conventions, we can sketch out what might be MaineHealth’s costs:
- From the Peterson memo, upfront rollout costs for their system are pegged at around $160 million, which usually includes software licenses, interfaces, implementation and training. Often, these costs are paid by a health system’s nonprofit foundation.
- Annual maintenance and support costs are customarily 18 – 20 percent of rollout costs, which would be $28.8 million, in this instance, or $144 million over five years.
But to fully understand MaineHealth’s total costs, we have to also include the cost of staffing to support the system. Former CIO Barry Blumenfeld described their team in a November 2012 interview with Healthcare IT News.
We have 125 people in a command center, so there are teams of people for each of the Epic applications literally sitting and waiting to correct anything that goes wrong.
To make it simple, and being somewhat conservative, let’s say the average salary for each MaineHealth staff member is $100,000. Let’s also assume that if this many staff are needed to implement Maine Medical Center, at least as many will be needed to roll out and support the system for another eight MaineHealth hospitals and clinics over five years. In this equation, total staffing would be $12.5 million per year or $62.5 million over five years. With a bit more math we can estimate MaineHealth’s TCO—all costs directly related to the EHR project annually and over 5 years.
| TCO | Annual | 5 Years |
| System Rollout | Upfront | $160,000,000 |
| Annual Maintenance & Support | $28,800,000 | $144,000,000 |
| MaineHealth Team | $12,500,000 | $62,500,000 |
| Total Annual Operating Costs | $41,300,000 | NA |
| Total Cost of Ownership | NA | $366,500,000 |
In our back-of-the-napkin analysis, total annual operating expenses would be in the neighborhood of $41.3 million, meaning MaineHealth would have to create a combination of increased revenue and decreased expenses totaling $41.3 million annually for a positive operating gain. If we factor in the initial upfront costs under the assumption MaineHealth is financing that expenditure, positive ROI must be greater than the TCO of $366.5 million over five years, which requires increases in revenue and /or decreased costs averaging $73.3 million per year.
Keep in mind, these costs are not unintended; these are the intended financial consequences of buying and owning the system. In our calculations, we haven’t even included dollar values for declines in patient volume, fewer patient readmissions, inability to accurately charge for services, increases in free care and bad debt, and declining federal reimbursement.
And, according to former CIO Blumenfeld, MaineHealth expects to receive about $60 million in total for Meaningful Use, which might cover one year of the potential ROI gap, depending on how upfront costs are being covered.
What are the chances, then, when both the intended and unintended financial consequences associated with choosing an expensive proprietary EHR system total an estimated $73.3 million annually, that MaineHealth can ever actually achieve a positive ROI? In the long run, will completely eliminating some sites of care contribute positively or negatively to ROI? How will it impact patient care for citizens of Maine?
The employees and patients of St. Andrews Hospital deserve an answer to these questions.
So, in light of the revealing MaineHealth situation, what questions should be asked by healthcare organizations that have not chosen an EHR?
- Can we justify hundreds of millions for an EHR that contributes greatly to a negative financial position?
- Shouldn’t a mature EHR that’s been rolled out to over a hundred organizations help control costs and lower financial risk?
- Shouldn’t the vendor help manage risk and adapt the EHR to our particular environment?
- Can we support these levels of EHR operating expenses in light of increasing constraints on reimbursement?
Perhaps this EHR was designed in less financially constrained times. Maybe it was created for organizations that have the financial resources to navigate UFC costs and complexity hiccups. But those are not the circumstances health IT faces now. Health care IT is at a tipping point where it must provide a clear path to positive ROI, support positive operating gains and help avoid UFC’s, not contribute to them.
In a Portland Press Herald article on the MaineHealth implementation from December of last year, Blumenfeld provides some insight into the mindset of organization leadership in making the EHR decision.
Blumenfeld said MaineHealth bought “the Cadillac” of electronic medical records systems, which has been adopted by several other leading national health care organizations, including the Cleveland Clinic, the Mayo Clinic and Geisinger Health System.
If this Cadillac is not too expensive to buy, it is certainly too expensive to own.
Stay tuned: There is a Better Way.
Edmund Billings, MD, is chief medical officer of Medsphere Systems Corporation, the developer of the OpenVista electronic health record.
Categories: Uncategorized
Re: “Health care IT is at a tipping point where it must provide a clear path to positive ROI, support positive operating gains and help avoid UFC’s, not contribute to them.”
This will never happen while hospitals are hiring the cheapest and least-skilled personnel possible (e.g., lacking formal clinical and/or Medical Informatics education and expertise) for health IT project management roles. HHS recommendations are at http://hcrenewal.blogspot.com/2009/12/onc-defines-taxonomy-of-health-it.html but rarely paid attention to.
Kyle,
Its a open source service subscription which is step farther than just SaaS. When I say service subscription and it is all-in, that means implementation, training, support, maintenance, all VistA updates. It includes all professional services to support these items.
it is designed to be be an operational expense for any hospital rather than a capital expense. it is priced on net patient revenue to scale to the business and to be affordable by another hospital. You don’t license the software, you subscribe for services to implement, maintain and upgrade the system on an ongoing basis.
It can be a SaaS model for hosted services or delivered behind the firewall. SaaS obviously will lower the local technical support. As you rightfully note, this is relatively less of the cost than the professional services required to build, change manage, implement and maintain the system and its use overtime.
The number of staff required both for the vendor and for the organization for a single source proprietary EHR is a level of magnitude higher than what is affordable by the mainstream.
RESTful APIs to the rescue!
I agree healthcare’s incentives and business models are broken. I agree many healthcare problems are caused by broken incentives. I don’t agree that EHR and HIT are failing (solely) due to broken incentives.
One of the advantages of process-aware business process management-style health information systems and EHRs, is they can be quickly adapted to changing incentives and regulations. If we could change healthcare’s incentives and business models tomorrow, current EHR and HIT systems could not easily adapt into newly optimized configurations and workflows. We are cementing into place frozen workflows that will resist systematic improvement for years to come.
Even after we improve healthcare’s business models, even after we connect applications so they can speak to each other, we won’t have good ways to tell them what, when, and how. We’ve no ways to represent (and edit and improve) healthcare workflow so it can be designed and executed without need for programmers who don’t understand it. Today, ‘workflow’ is spread throughout the implementation code of every EHR and HIT application involved in this workflow. EHR and HIT-mediated interactions, inside hospitals and clinics and outside with patients and payers, are fragile, prone to ambiguity, don’t cross organizational boundaries well, and scale badly. The more we automate healthcare workflow with current non-process-aware technology and the more participants who join the fray, the more static healthcare workflow becomes and the harder it is to propagate change and new players into these workflows.
Dr Webster
I agree about your general technical wisdom, but don’t think technicals are enough. I’m not the first person to say it, but the problem is the billing system itself. As someone that’s lead the design of a clinical EHR system, i’ve learned far more about billing than i ever wanted to. the system is tied to the billing rules. until we change the billing system, hospitals won’t start running like real businesses that try to cut costs, no matter how open, closed,or just plan awesome the IT systems are.
Opening real, RESTful APIs that developer can into would help. My company is developing apps for doctors on google glass, so i live and die by EHR APIs. We can help save some costs, but we aren’t going to affect the bottom line at an organization of any significance. Perhaps 30 3rd party app developers tied into a single system could collectively drive a 1-2% total change in costs (im talking current applications, not Watson super computers that make most doctors go away)
Dr Billings
Great responses. The SaaS model is nice, but does that include all professional services? I’ve read through a few Epic contracts myself (very lucky to have gotten my eyes on those; i most certainly wasn’t supposed to!), and the split i’ve seen is about 65% professional services, 35% software, which is pretty in line with enterprise apps across industry verticals.
The SaaS model for software may help spread some costs, but SaaS doesn’t account for flying people around the country, hotels, cars, training, consultants, and organizational incompetence. Based on track records, I’d actually go so far to say that Epic has probably figured that side of the business – the people side – better than anyone else. Their project management expertise is breathtaking. UNLESS, Medsphere takes on the risk of the project running over and eating the professional services costs themselves, I think SaaS only solves part of the problem. It’s definently better than legacy client-server stuff pricing models, but it’s not global in scope.
I would love to continue these conversations offline if you’re interested. There’s a lot to be learned. kylesamani@gmail.com
To address Kyle’s questions.
The key is that the leading single source proprietary vendors developed their solutions with the early adopters beginning nearly a decade ago. In a classic case of “crossing the chasm’, these solutions were developed by resource rich organizations and with early adopter visionary users pushing for all of the features imaginable. Leading academic institutions have the capital resources in their foundations and endowments. Kaiser Permanente an early adopter spent billions out of the non-profit foundation. They spent this much because they could and have to re-invest their “profits”.
The result is that these product are rich in cost and complexity. When these rich early adopter solutions are sold to the the less rich, they often do not “cross the chasm” to mainstream market scalability. MaineHealth is the example du jour.
OpenVista is offered under an all-in subscription model with a predictable and affordable quarterly payment for all services. The software is less complex and more straight forward requiring a level of magnitude less time and people to implement and support. The software was paid for by the US taxpayer and does not have to recouped. The money and time saved by the organizations can then be invested in configuration and innovation on the open platform.
Medsphere also partners and goes at risk with its clients to attain results like meaningful use and clinical business improvement…. gets paid only when financial goals are met.
Yes, same system can get completely different results based on how people implement it. In this case we are talking about an organization hitting a financial wall when the costs take their operational margin negative.
Expensive single source proprietary vendors may be right for the ‘have alots” in the market. But the “haves” and the “have nots” beware of the costs, complexity and risk.
A subscription service and partnering model may be better for these organizations. Software is soft and results are hard.
(To elaborate on Kyle’s comments…)
Inability of current EHRs to reduce healthcare cost is due more to lack of open, transparent, and systematically improvable workflow, than proprietary software. Ironically, a proprietary workflow management system has more open and transparent workflow than a traditional open source EHR.
Ideally, I’d love for everyone to have their cake and eat it too: open source workflows on open source systems. So, in the long run, open source workflow vs. open source EHR is a false choice. But in the short run, not so much.
One way to think about open source workflow running on proprietary BPM (business process management) systems is by analogy to open vs. closed (proprietary) operating systems and applications. Open source application software (such as PHP) can run on proprietary operating systems software (such as Windows). Closed source application software (such as Oracle) can run on open source operating systems software (such as Linux). The same is true of application software. Open sourced workflow definitions can run on either proprietary BPM systems or open source BPM systems (which do exist).
To make EHR and health IT workflow more open, transparent and systematically improvable, we must move beyond current structured document-based management systems (open source or proprietary) to less workflow-oblivious alternatives.
I have a few questions to get the Monday juices flowing?
1. How much money has Kaiser Permanente spent on EPIC to date? I’ve heard $6+ Billion plus the ongoing expenses of “temporary” contractors who support EPIC on Kaiser’s dime. Is this sustainable?
2. Why does EPIC have a non-disparage clause in their contract? Last time I checked, we still live in the U.S. Right?
3. What happens when all of the ARRA “stimulus” goes away? Who continues to build Judy Faulkner’s fortune? We do. Taxpayers.
Hope I get your attention……a lil.
Aside from the obvious question of whether EHRs offer any benefit to institutions that adopt them, the question here seems to be: “How did such a collosal effup occur?”
Epic = “Epic FAIL”
Have you been drinking?
howdy Dr Billings
I’m curious how MedSphere can actually deliver materical cost savaings relative to Epic. VISTa has many architectural similarities to Epic, including a MUMPS foundation
As best I can tell, Medsphere’s fundamental technical strategy and deployment strategy isn’t radically different from any of the other major vendors. Medsphere may perhaps have a small R&D budget because its just a contributor to VISTA, but from the outside, I don’t see any fundamental differences in business model, cost structure, or deployment methodologies.
What does medsphere do so differently?
Given that most of the major research centers in teh country run Epic, and that they haven’t gone bankrupt, doesn’t that speak to the fact that the failure’s at MaineHealth were probably due in large part to failures by MainHealth? Installations fail not because of software, but because of the people involved. This is common knowledge in the EHR industry