I recently read Paul Levy’s blog post comparing large hospitals’ current loyalty to Epic with Stockholm syndrome and I don’t think of Epic as out of line at all for doing what it does: requiring its clients to buy all of its stuff at once, requiring that they install the Epic way, requiring that they take all upgrades and on the Epic schedule, etc. I actually think those are the things I love the most about Epic and, if the government ever came down on them for having that kind of corporate and brand integrity, I would scream with rage.
But Levy buried a statement partway down that I think is necessary for health care executives to digest before chunking out that kind of money for software or making commitments to that many years of implementing anything. He quoted Kenneth Mandl and Zak Kohane:
We believe that EHR vendors propagate the myth that health IT is qualitatively different from industrial and consumer products in order to protect their prices and market share and block new entrants. In reality, diverse functionality needn't reside within single [electronic health record] systems, and there's a clear path toward better, safer, cheaper, and nimbler tools for managing health care's complex tasks.
The idea that a health system needs to buy one single system for every type of information it produces and install the systems all at once is both patently false and dangerous. That one misunderstanding, in my opinion, will put a meaningful percentage of hospitals out of business in the next few years.
First, Epic is NOT one system. It’s a series of apps that integrate beautifully. There is EpicCare, the EHR. Then there is Cadence, the scheduling system. Then a huge list of others that I’m pasting at the bottom of this blog so you don’t scroll too much and lose my flow. I don’t know how these systems are connected, but I know that we connect to such systems using HL7 messages, which works great. In fact, a large Catholic health care system that is on Epic actually does all of its physician revenue cycle and scheduling on athenaNet. It blows my mind that anyone who wakes up in our Internet-connected world can think that the only way to exchange information reliably is by having all of it on the same server. Seriously…BLOWS my mind.
Second, once a hospital is done putting all of the entities it controls onto one instance of Epic, they will need to come to grips with the fact that they still MOSTLY depend on information that comes from OUTSIDE of Epic. Few hospitals can afford the salaries they are currently paying their docs. Losses per doc have gone from around $70,000 per doc per year in 2007 to $200,000 per doc per year. They are spending way beyond their balance sheets and they aren’t close to covering all sources of key health information. They don’t cover non-employed docs (independent practices) on whom they still depend for 40% of their non-ambulance admissions. These docs refuse Epic because they don’t have salaries and Epic slows them down too much. Also, primary care is increasingly happening in professionally capitalized and managed ventures OUTSIDE the hospital. MinuteClinic, Target clinic, Walmart, RediClinic, etc.…NONE of these are on Epic and most are on athenaNet. Add to this the fact that HALF of hospital admissions come from ambulances that are increasingly on EHRs and NOT on Epic.
Further still, hospitals are increasingly making use of “focused factory”specialists in Hospitalist Care, Emergency Care and Radiology Care. Are these Epic hospitals (we call them “Biospheres”) really going to switch all of these huge corporations to their installation of isolated Epic software? Of course not. Are they going to just NOT connect and start over on everything when the patient arrives at their doors? I sure hope not! So what are they going to do? They are going to connect to them. Well, once they get used to the idea that they are going to connect to other systems, why would they buy a system that’s primary benefit is that it only connects to itself? Especially if you have to pay $200 million more than you have and you have to pay doctors more than they earn to use it? If you are Harvard, Stanford, and Yale, you do it because you have almost unlimited permission to lose money. If you are a community hospital, you better not do it.
I strongly believe that the Internet is here to stay. I know that seems trite, but it is only recently that the cloud and cloud-based services have been a secure enough, reliable enough, tested enough place to put information in a sector ruled by the Hippocratic oath. But I think the early adoption phase is over and it’s time to get real. We need to stop the billions being spent by hospitals on off-line, closed systems! There is a real line being drawn in health care today. There are those who play to win through keeping information closed and controlled and those who try to win by being the place to go when information is liquid and transparent.
I salute the latter…
- ADT (Inpatient and Outpatient Admission-Discharge-Transfer Application)
- Anesthesia (Anesthesia Information Management System (AIMS)
- ASAP (Emergency Department Application)
- Beacon (Oncology Application)
- Beaker (Clinical Laboratory Application)
- BedTime (Bed Management Application)
- Bridges (Interface Application)
- Cadence (Scheduling Application)
- Care Everywhere (Information Exchange Application)
- Cogito Ergo Sum (formerly Clarity) (RDBMS Management Application, exporting Cache Hierarchical database data to Relational database)
- Cupid (formerly Cardiant, Cardiology Application)
- Data Courier (Data Environment Propagation Utility)
- Diagnose Behandeling Combinatie (Dutch Billing Module)
- Eligibility (Real Time Verification of Access and Billing Information)
- EpicCare Ambulatory (Ambulatory Medical Record Application)
- EpicCare Home Health (Specialized Home Health Application for use in Patient Homes)
- EpicCare Hospice (Specialized Hospice Application)
- EpicCare Inpatient (Universal Hospital System)
- EpicCare Link (Web-based Application for Community Users)
- EpicWeb (Web-based Clinical Application)
- Haiku (Device Mobility Clinical Application)
- HIM (Chart Tracking, Chart Deficiency Tracking, Release of Information Application, Coding & Abstracting)
- Identity (Master Patient Index [MPI] Application)
- Kaleidoscope (Ophthalmology Application)
- MyChart (Patient Chart Access)
- OpTime (Surgical Application)
- Phoenix (Application designed for the Management and Tracking for Solid Organ Transplants)
- Prelude (Inpatient and Outpatient Registration Application)
- Radiant (Radiology Application)
- Reporting Workbench (Operational Reporting Application)
- Resolute (Billing Application)
- Stork (OB/GYN Application)
- Tapestry (Managed Care Application)
- Willow Ambulatory (Outpatient Pharmacy Application)
- Willow Inpatient (Hospital Pharmacy Application)