Skip to main content
Journal of the American Medical Informatics Association: JAMIA logoLink to Journal of the American Medical Informatics Association: JAMIA
. 2014 Oct 23;22(2):465–471. doi: 10.1136/amiajnl-2014-003023

Implications of an emerging EHR monoculture for hospitals and healthcare systems

Ross Koppel 1,, Christoph U Lehmann 2
PMCID: PMC11749203  PMID: 25342181

Abstract

In many hospitals and health systems, a ‘new’ electronic health record means a shift to one vendor: Epic, a vendor that dominates in large and medium hospital markets and continues its success with smaller institutions and ambulatory practices. Our paper examines the implications of this emerging monoculture: its advantages and disadvantages for physicians and hospitals and its role in innovation, professional autonomy, implementation difficulties, workflow, flexibility, cost, data standards, interoperability, and interactions with other information technology (IT) systems.

Keywords: Epic, Implementation, Cost, Markets, Data Standards, Innovation


Many healthcare systems and practices are shifting to Epic's electronic health record (EHR).1 Based on software (MUMPS) developed at Massachusetts General Hospital in 1968, ‘EpicCare Inpatient Clinical Systems’2,3 now capture more than 50% of new large hospital contracts in the USA,4 and, as of 2013, reportedly included at least partial health information for 51% of the US population.5 Epic is replacing other EHR vendors in the market and is beginning to establish a single-vendor landscape, a monoculture.

As early as 2012, Shaywitz predicted establishment of a ‘Pax Epic’, with the vendor becoming ‘health IT's Roman Empire: Establishing the laws and the language for [the] ‘known world’, as well as the underlying infrastructure …  shaping information flows, IT architecture and—potentially—the eventual configuration of provider systems.’1

Several Chief Executive Officers (CEOs) describe Epic as the default EHR choice—not because of its outstanding performance but because other systems were considered inferior.6,7 One Chief Information Officer (CIO)8 wrote that Epic's success is due to its single-product/sign-in solution, improved physician buy-in, standardization of governance and processes, reduced demand on IT staff for customization or best-of-breed solutions, compliance with Meaningful Use (MU), reduced-risk vendor choice, and built-in integration across institutions.

Evidence: While Epic has both committed devotees and critics,9 a literature search did not identify any evidence of its superiority or inferiority compared with other health IT (HIT) systems. Conducting a randomized controlled trial (RCT) incorporating implementation of more than one system is not feasible: an Epic hospital system costs from US$250 million to US$1.1 billion, where implementation accounts for two-thirds to three-fifths of the total cost.10 A blinded RCT is inconceivable and would endanger patient safety. Despite the fact that several organizations implemented Epic after successful use of another EHR product, to our knowledge no studies have been conducted that show a before/after effect or compare the effectiveness of products within the same organization.

Evidence or not, a central question remains: what are the advantages, disadvantages, and implications of one vendor's market pre-eminence and an impending Epic monoculture?

In boxes 1–3 we consider the advantages, disadvantages, and complex realities of these emerging phenomena.

Box 1: Advantages.

Data standards

Without full sharing of electronic health record patient data, advantages of a one-vendor culture include

  • de facto establishment of data standards

  • similar formats

  • similar user interfaces

  • potential internal ad hoc interoperability

  • benefits from reduced development and maintenance efforts

  • improved standardization of care across facilities

Interface standards

Semi-monopolies (eg, Microsoft's operating system) often

  • reduce training needs

  • create de facto interface standards
    • – similar interfaces facilitate clinician occupational and geographic mobility

Box 2: Mixed advantages and disadvantages.

New application programming interfaces (APIs)

Until recently, Epic restricted access to real-time data across patient populations. Access was limited to relational databases that were:

  • separate

  • time-delayed

  • incomplete (ie, they contained only selected data)

Recently, however, it created interfaces (APIs) allowing greater access to real-time data.5

Dependence on the vendor for modifications: benefits of limits

Via careful control over software customization, limited modifications are possible, but they are often overwritten with the next software update. One CIO wrote ‘with Epic, demand is more easily managed by noting that desired features and functions depend on the vendor's release schedule. It's not under IT control.’13

Limited best-of-breed

Although also listed under ‘disadvantages’ (see below), restrictions on best-of-breed products generate several advantages by

  • reducing number of systems deployed in an organization

  • thwarting product interoperability difficulties

  • forcing specialized referral hospitals to work with the same tools as local organizations

Increased pressure for industry consolidation

One-vendor market dominance will result in other vendors seeking to attenuate the impact through

  • mergers and acquisitions

  • lowering of sales prices

  • creation of data crosswalks

The existing vendor products, however, differ so much in their basic structure that efficient software integration will take many years. Pressure for competing data standards may also be enhanced by consolidation, which may invigorate each opposing camp.

Box 3: Disadvantages.

Cost

Epic costs are significantly higher than comparable competitor products, and, in at least one study, did not produce savings for payers.14 Billings found a 10-fold price difference between an Epic implementation and a similar non-Epic installation.15 Known spending on Epic implementations (ie, including software, training, integration, customization, etc) by major health systems include

  • Harvard-Partners system: US$1.6 billion

  • Duke: US$700 million

  • Sutter's East Bay hospitals: US$1 billion

Contract costs are only a fraction of the total. As with any electronic health record (EHR), institutions incur substantial and continuing costs for

  • maintenance

  • development

  • customizations

  • linkages

  • consultancies

  • training

  • work interruptions

Upgrade costs (as a percentage of system's initial cost) are high

  • Epic: 40–49%

  • Cerner: 30–35%

  • Allscripts: 20–22%16

Additional implementation issues are

  • lower initial patient volume (while physicians acquire skills to use the system)

  • opportunity losses from unconverted historical data

  • other revenue-reducing effects

Higher lock-in costs

As with any EHR, vendor lock-in extends for a decade or more.

  • Epic's increased purchase and implementation cost magnify lock-in penalties

  • Opportunity loss and internalized cost add to lock-in penalties

  • Cost of full system implementation can exceed billions of dollars and will outspend an institution's Meaningful Use subsidies 10–20-fold

Familiar but not identical

Each EHR installation both offers and limits transferability of skills—often in unknown ways

  • Similar interfaces can produce very different results generating user errors with patient safety implications. A CMIO who used two Epic systems implemented at neighboring hospitals noted that the systems were related (like speaking ‘Spanish and Italian’), but data and interfaces differed enough that assumptions of similarities could be treacherous.17

Modification motivation

All vendors’ decisions about new features are primarily based on market forces rather than on patients’ or clinicians’ needs. Without vendors’ willingness to build new functions, providers must

  • devise workarounds, or

  • perform activities outside the EHR

Epic, among all vendors, has an extensive record of excluding third parties18 and homegrown software,19 in part due to intellectual property concerns resulting in20

  • no usability comparisons

  • no publication of screenshots

This reduces opportunities for patient safety interventions. Without transparency, users, implementers, potential buyers, and regulators cannot ascertain needs for improvements, needs for accommodations, predictable and non-predictable hazards.

Limited best-of-breed

  • Requirement of an integrated system without product heterogeneity

  • Prevention of best-of-breed systems that use already installed software of proven value while integrating new software that incorporates desired features

  • Challenge to specialties, which often require domain-specific solutions

Conclusion

Epic is creating an emerging monopoly in the USA, with a small but growing presence in Europe and Asia. Its product is tailored to Centers for Medicare & Medicaid Services (CMS)’s documentation guidelines, and its savvy marketing plus total package approach, aided by federal incentive (and penalty) programs, all contribute to its achievements. It is not feasible, sensible, or morally acceptable to interrupt the firm's impressive (and often laudable) success. Prudence suggests, however, that increasing domination of both covered providers and patients necessitates scrutiny to ensure that its growth does not endanger patient safety by outsized influence on clinician judgment, data fluidity, usability, or the development of data standards and interoperability. We recommend that users, hospitals, clinicians, and the government encourage all vendors to adhere to the following principles.

  1. Speedy implementation of new consensus data standards allowing independently assessed exchange of data with other EHR systems

  2. Creation of tools and databases that promote innovation by local developers and allow real-time Clinical Decision Support (CDS) and secondary data use

  3. Requirement of unrestricted usability assessments, allowing transparent comparisons of vendors

  4. Permission for customers to share safety-related data, known hazards, and screen images by prohibiting non-disclosure clauses in vendor contracts

  5. Development of model contracts that
    • A. outline realistic costs of implementation, training, linkages, reprogramming of existing IT, etc
    • B. contain realistic estimates of time required for implementation and for time to reach previous levels of efficiency
  6. Provision of objective information to assist Chief Medical Informatics Officers (CMIOs), CIOs, and Chief Technology Officers (CTOs) and practice office managers in purchasing and negotiations

  7. Recognition that model contracts are guides for future actions. Intervention is required now to enable patient safety-related reporting as soon as is practicable

  8. Consideration of the role of future MU regulations on vendor market control and provider capabilities

  9. Enhancement of collaborative relationships with academia to foster innovation for future products

Single-vendor ascendency offers remarkable opportunities as well as challenges. Providers and others should examine the advantages and disadvantages, and then act to ensure patient safety, interoperability, clinical efficiency, regulatory prudence, cost reductions, and the long-term health of the HIT marketplace. All stakeholders are obliged to analyze the tradeoffs of an emerging HIT monoculture.

Acknowledgments

We thank the many dedicated individuals who encouraged us to write this article and helped us by sharing information, stories, examples, and experiences of vendor help and hindrance. We also thank the contributors to the AMIA implementation listserv and the ACMI listserv for their extraordinary insights, wisdom, and knowledge about healthcare IT and so many other issues. Last, we also wish to thank the anonymous reviewers and the editors of JAMIA for their thoughtful comments, balanced criticism, and passionate advocacy of patient safety.

Contributors

Both authors contributed equally to this article. Both authors participated in conceptualizing, writing, conducting additional research, and rewriting the document.

Funding

Neither author received any funding for this research.

Competing interests

RK is the recipient of grants from the FDA, ONC, and NSA. None of that work was involved in the writing of this paper. (Partial support for this work was received from grant # NSF CNS-1035715.) He consults with the Prescription Advisory Service Technology (Princeton, NJ). He has received payments for lectures by Duke University and royalties from Cornell University Press for a book on patient safety. He holds stock options from Wearable Intelligence Inc. He has never been involved in the selection of any EHR.

CUL's potential conflicts of interests include board membership on the board of the International Medical Informatics Associations. He is a recipient of grants from AHRQ. He is the editor-in-chief of Applied Clinical Informatics and edited the textbook Pediatric informatics. He serves as the director for the Child Health Informatics Center at the American Academy of Pediatrics. He is a member of an ACGME advisory board and serves on the Health IT Policy Committee. He was involved in the selection of an EHR at Johns Hopkins University in an advisory capacity.

Provenance and peer review

Not commissioned; externally peer reviewed

REFERENCES


Articles from Journal of the American Medical Informatics Association : JAMIA are provided here courtesy of Oxford University Press

RESOURCES