In the Boston marketplace, Partners Healthcare is is replacing 30 years of self developed software with Epic. Boston Medical Center is replacing Eclipsys (Allscripts) with Epic. Lahey Clinic is replacing Meditech/Allscripts with Epic. Cambridge Health Alliance and Atrius already run Epic. Rumors abound that others are in Eastern Massachusetts are considering Epic. Why has Epic gained such momentum over the past few years? Watching the implementations around me, here are a few observations
1. Epic sells software, but more importantly it has perfected a methodology to gain clinician buy in to adopt a single configuration of a single product. Although there are a few clinician CIOs, most IT senior management teams have difficulty motivating clinicians to standardize work. Epic's project methodology establishes the governance, the processes, and the staffing to accomplish what many administrations cannot do on their own.
2. Epic eases the burden of demand management. Every day, clinicians ask me for innovations because they know our self-built, cloud hosted, mobile friendly core clinical systems are limited only by our imagination. Further, they know that we integrate department specific niche applications very well, so best of breed or best of suite is still a possibility. Demand for automation is infinite but supply is always limited. My governance committees balance requests with scope, time, and resources. It takes a great deal of effort and political capital. With Epic, demand is more easily managed by noting that desired features and functions depend on Epic's release schedule. It's not under IT control.
3. It's a safe bet for Meaningful Use Stage 2. Epic has a strong track record of providing products and the change management required to help hospital and professionals achieve meaningful use. There's no meaningful use certification or meaningful use related product functionality risk.
4. No one got fired by buying Epic. At the moment, buying Epic is the popular thing to do. Just as the axiom of purchasing agents made IBM a safe selection, the brand awareness of Epic has made it a safe choice for hospital senior management. It does rely on 1990's era client server technology delivered via terminal services that require significant staffing to support, but purchasers overlook this fact because Epic is seen in some markets as a competitive advantage to attract and retain doctors.
5. Most significantly, the industry pendulum has swung from best of breed/deep clinical functionality to the need for integration. Certainly Epic has many features and overall is a good product. It has few competitors, although Meditech and Cerner may provide a lower total cost of ownership which can be a deciding factor for some customers. There are niche products that provide superior features for a department or specific workflow. However, many hospital senior managers see that Accountable Care/global capitated risk depends upon maintaining continuous wellness not treating episodic illness, so a fully integrated record for all aspects of a patient care at all sites seems desirable. In my experience, hospitals are now willing to give up functionality so that they can achieve the integration they believe is needed for care management and population health.
Beth Israel Deaconess builds and buys systems. I continue to believe that clinicians building core components of EHRs for clinicians using a cloud-hosted, thin client, mobile friendly, highly interoperable approach offers lower cost, faster innovation, and strategic advantage to BIDMC. We may be the last shop in healthcare building our own software and it's one of those unique aspects of our culture that makes BIDMC so appealing.
The next few years will be interesting to watch. Will a competitor to Epic emerge with agile, cloud hosted, thin client features such as Athenahealth? Will Epic's total cost of ownership become an issue for struggling hospitals? Will the fact that Epic uses Visual Basic and has been slow to adopt mobile and web-based approaches provide to be a liability?
Or alternatively, will BIDMC and Children's hospital be the last academic medical centers in Eastern Massachusetts that have not replaced their entire application suite with Epic? There's a famous scene at the end of the classic film Invasion of the Body Snatchers, which depicts the last holdout from the alien invasion becoming a pod person himself. At times, in the era of Epic, I feel that screams to join the Epic bandwagon are directed at me.
22 comments:
John,
I've always viewed Epic as a consulting firm that leaves behind software. It is not a platform that encourages innovation. Until we see a vendor with a Salesforce type business model, or Open Source like Apache, you are doing the right thing.
To use different media analogies - I tend to see being assimilated by the Borg to be the only way to have the experience of hacking your way from the inside out and mastering something (ala The Matrix). Building your own solution has the benefit of innovation and control, of course. Integrating with someone else's solution has the fun challenge of learning how to work around their quirks and legacy technology.
Nice article and looks at all sides for sure. MUMPS of course is the original no SQL data base and I guess why the staying factor is so strong as you have the others using it as well. Somewhere along the line you do have to give CEO Judy some credit here too as her background in writing the beginning software is key, like Bill Gates with Microsoft, it has value.
When the founders move on though, things do take on a little different appearance and we see that every where really when the guts and drive of the founders are gone who "have" the initial hands on knowledge and experience. CEO Judy is a smart woman. At Cedars in LA years ago we saw a failed implementation as well as the home grown that Kaiser produced so you have those two big ones out there with Epic saving the day, of course with a lost of cost.
I think it's not as simple with today's platforms and models as it used to be for sure and thus so migrating servers, etc. with all the aggregation is a bit of a fear versus the old client/server days and for good reason. Who wants to migrate servers today (grin). When there are issues..well we know that story.
It will be interesting to see what direction things go and all efforts contribute to knowledge though, one way to view methodologies I think:)
I have been around long enough to remember the IBM adage. I also remember what we used to say about dressing up old technology and calling it new- putting lipstick on the pig! I am pretty sure BID is headed in the right direction. john
http://www.forbes.com/sites/zinamoukheiber/2013/07/11/who-says-you-cant-lose-your-job-over-epic/
Great writeup. How easily a system integrates is key. Writing your own ensures that. I wonder if there is a comparison anywhere of EMR systems and their architecture, platform, database and overall "robusticity".
http://histalk2.com/2013/05/01/readers-write-are-hospital-ehr-vendors-primarily-software-or-services-companies/
This is a post I wrote a few months ago for HIStalk. EHR vendors are services companies that sell software to lock in services
Good read.....great insight. I always enjoy your thoughts and I couldn't agree with you more here.
The bandwagon affect is in full swing here. It will be interesting to watch as this unfolds over the coming years.
Hi John,
I follow your blog and this post really got my attention! I work at a private hospital in Sydney, Australia. We decided to develop our own EMR instead of implementing one from a box whilst the public health system around us are going with Cerner. Like BIDMC, we use best of breed in specialize areas such as MetaVision from IMDsoft in our ICU/CCU. Integration with it has been a challenge.
We use thin clients and our home grown system is so customised to the work flow and wishes of our staff. Sometimes I wonder if we made the right decision but the comments of others have been encouraging. Some of our users don't appreciate and realize how fortunate we are to be creative and innovative in building our own EMR. We are considering if we should build a medication system or purchase one. The jury is still out on that.
Thank you for sharing what you have done and are doing as it is encouraging to know that there is a Med Ctr out there travelling a similar journey!
Nice article John!
As an engineer, I believe there is a clash of cultures that inhibits innovation in this space. I would say that the use of VB (or MUMPS) is almost a symptom of the culture of medicine... Let me explain :)
At this point in history, most providers already have some kind of EHR. When clinicians engage engineering (whether internally, or with the vendor) to request features/functionality they do not want anything to change, they only want the new features bolted on. The clinicians have spent years learning the system and working around issues. If faced with the prospect of an entirely new system, the clinicians will just retract their request and fulfill their needs elsewhere.
Conversely, when engineering have spent years hacking on a system and keeping it together with hay wire and fielding requests from clinicians they devise a system/architecture that will make their job easier and more efficient. When a plan as this is presented to the clinicians they push back - hard - because this includes a fundamental change of the EHR system.
Clearly, the experience at BIDMC is very different because of your (John) experience with developing software so you can direct the evolution of the EHR much better. I would say, almost as a general rule, CIO's don't have a strong engineering or a clinical background - whereas you have both. I think the choice of Epic is a result of two things: A standard system that more clinicians have experience with and, frankly, the best choice a provider has to get out of the build culture. We talk about Epic installation failures, but what about adding up all the internal build failures??
If a system comes along that is a better choice, it will have to be developed in a very disruptive manner outside of the current establishment. Personally, I go back and forth on the idea that the medical informatics field is equipped to solve this problem. I almost think a pure software engineer and a physician make a better 'informaticist' than a trained 'medical informaticist'. On the other hand, I think a lot of the fundamental problems informaticists grapple with are just engineering problems, and innovations in other fields will contribute greatly to the creation of a better EHR.
John, as you know Vanderbilt integrates and creates software based on sound design principles and produces some important results. But, as you state, the number of institutions using their own softwas is shrinking. So it would be valuable to turn it around. What is the case for those who build to continue to do so?
Another interesting and stimulating post; I enjoy following along as you share both your professional thoughts and personal adventures on 'the farm' - not sure how you find the time :)
I like the approach you have taken - have you or would you ever consider creating an open source solution based on the platforms that you have built? I am sure other CIO's around the country was be interested in exploring the feasibility of such a solution. I would love to see an open source EHR, similar concept to Linux - the McKesson, Cerners and Epics would become the Red Hats, and Ubuntu's of the world - adding value and consulting services and through iterative innovation would add value back to the core 'kernel' .
We've developed a vaccine that should help bolster BIDMC's immune response to Epic, should it be exposed. BIDMC is our only hope...
Epic had an idea/suggestion button, but nothing seemed to ever come of the feedback I left for them. Then they took the button away. I wonder how we should interpret that?
Epic wasted minutes of my day, everyday. For several of my partners it was likely an hour due to Epic's inflexibility and lack of ability/willingness to support clinician skills/workflows.
John, you are absolutely right. Epic's lack of flexibility and minimal responsiveness to clinician's suggestions for innovation will lead it to be by-passed by the more agile, cloud-based systems you describe -- and have built with the help of the great innovators at the BIDMC Division of Clinical Informatics. Stay the course: the Emperor has no clothes.
Developing your EHR is a challenge, but less expensive than the cost of EPIC. What I really want to know is why is EPIC winning against all the other companies? EPIC has old technology, poor UI, and less robust features. I have not heard one physician speak well of the product. I have heard that CIOs like the "no interfaces required pitch." The #4 point really applies to any of the major players. So why EPIC over the competition?
Although it has been some time since I've been working in a HIT environment for a hospital system, I can point to many similarities that outpatient clinics have regarding challenges of EHR implementation. In the Portland, Oregon area, there is, like you've pointed out, a great deal of "peer pressure" as one or more hospital systems are adopting Epic. Unfortunately, I've heard from various physicians, nurses, and hospital staff the challenges of Epic adoption and integration with exisiting IT infrastructures which negatively affect workflow and productivity. Even interoperability (which was implicitly promised if every other system is on Epic) is not guaranteed.
In the outpatient world, this is even more magnfied and the pressured to get on Epic is starting to creep in as organizations (especially the larger, multi-specialty ones) are touting that to attract new graduate doctors, you need to have Epic because it is a system that medical students/residents have familiarity with.
Like you, I've adopted a cloud-based, thin client approach to my own practice and out of frustration with the lack of suitable, agile EMRs, I made my own (although it is geared more towards outpatient clinics, than hospitals). As an open source EHR, I have the advantage of quickly innovating and improving my product and I feel that there is a real and viable future for these types of implementations in both hospital and outpatient realms. In the end, I believe the less monolithic and reliance on legacy technlogy the better. I suppose we'll see. My blog is at http://noshemr.wordpress.com
I've always thought another major reason for the Epic craze, that makes Epic a safe choice, is their implementation methodology. They're there to help you (if not carry out for you) all the project management you're supposed to do (build or buy). And thus the likelihood of a "successful" implementation (where successful minimally means no meltdown) is high. I think sound project management skills are also underappreciated and in short supply.
The hospital I work for is in the middle of an Epic implementation (going from Allscripts to Epic). I have to disagree with your statement that Epic "has perfected a methodology to gain clinician buy in to adopt a single configuration of a single product." Epic doesn't have clinician buy in, they have a rigid and limited system that doesn't allow for a lot of customization. We have a LOT of custom CDS in our Allscripts system that Epic simply can't provide. How will that be reconciled? How do you communicate to providers that we are able to prevent this common error/provide this specific dosing guidance/make sure that the right person is notified for this order today, but all those safeguards will disappear when we turn Epic on? On another note, why is Epic implementation causing financial problems for so many institutions? My hospital is having issues in that arena as well. The prediction is that we won't be back to our pre-Epic patient volume in our ambulatory care areas for another TWO years! A temporary dip in patient volume is common and expected, but a three year dip? I think the approach taken by BID and Children's is the best approach for patients and providers alike. They are also the first places I'll look for a job after we sunset our current system next June. We need innovation and flexibility in the healthcare IT space right now, and Epic simply doesn't allow that. (I also LOVE your farm! I live in Holliston - right next door.)
Hi John,
Thanks for the post. As always, great insights and reasoning! Now that I have joined one of the other outposts still developing software (in our case, focused on CPOE with G3, the Medical Gopher's successor), the considerations you discuss have become mine, also. In dentistry, I have lived in both worlds: developing quite a bit of custom software (sometimes way before similar systems appeared in the market), as well as implementing commercial systems.
One of my standard refrains is that "HIT is still in the Stone Age." People always look at me funny since they wonder how, of all people, an informatician could say that. But, when I look at where HIT is today and where it could be, I despair at the chasm (or delight in the opportunities). And, if you add to that where medicine is going and how fast, you know that that gap is likely to grow, not shrink.
I wonder what role BIDMC, Vanderbilt, Regenstrief, and others in the US and around the globe could (and should) play with regard to this. I would love to see us become stronger engines of innovation in HIT. But, for a number of reasons, we are not well positioned to translate our advances easily and smoothly into generalizable benefits. For the most part, the biggest bang is where our software is deployed - locally. But, I think that forgoes much of the benefit we could provide.
The more established HIT companies (as is the case in pretty much any industry) become, the more difficult it is for them to innovate. In healthcare, the most exciting and far-reaching innovations are typically produced by small, entrepreneurial companies. As they grow, they become subject to what I call the "installed base problem": As more customers are added, more and more resources are required for support and maintenance.
The largest software company in dentistry, Dentrix, faced that problem a few years ago. What did they do? They opened up their platform to outside app development, so others could innovate on top of it (see http://www.dentrix.com/Connected/resources/MarketPlace%20Brochure.pdf). If you knew the company and the players, you would have thought they would never do this. But when I asked the CEO, Kevin Bunker, about why he said: "It's simple. We knew we could not produce all the innovations that our customers wanted, so we needed to broaden our strategy. Plus, it sells more copies of our software." I think the next few years will prove both his statements true. I wonder when an EHR vendor will see things the same way.
Anyway, thanks again for the post!
Titus Schleyer, DMD, PhD
Clem McDonald Professor of Biomedical Informatics, Regenstrief Institute (schleyer at regenstrief dot org)
PS: The ACMI panel "Informaticians, CxIOs and Industry: Strengthening the Fabric of HealthIT" at the coming AMIA Fall Symposium should provide some interesting discussion on the subject above (see http://www.amia.org/amia2013/panels).
I heard a CIO tell a funny joke. EPIC has similarities to the old roach motel commericals. Data goes in but never comes out. it will take until some insitutions go bankrupt for things to change. In no other industry would we spend this much per unit for IT on the part of the business that is shrinking the fatest and holds little growth. There are superior systems for the ambulatory market.
Acetech is a Web Designer expert, providing Software Development Services Delhi, Cheap SEO Services, Web Development Services and lot more
Post a Comment