Twilighted Homegrown Systems: The Experience of Six Traditional Electronic Health Record Developers in the Post–Meaningful Use Era

Abstract

Objectives  This study aimed to understand if and how homegrown electronic health record (EHR) systems are used in the post–Meaningful Use (MU) era according to the experience of six traditional EHR developers.

Methods  We invited informatics leaders from a convenience sample of six health care organizations that have recently replaced their long used homegrown systems with commercial EHRs. Participants were asked to complete a written questionnaire with open-ended questions designed to explore if and how their homegrown system(s) is being used and maintained after adoption of a commercial EHR. We used snowball sampling to identify other potential respondents and institutions.

Results  Participants from all six organizations included in our initial sample completed the questionnaire and provided referrals to four other organizations; from these, two did not respond to our invitations and two had not yet replaced their system and were excluded. Two organizations (Columbia University and University of Alabama at Birmingham) still use their homegrown system for direct patient care and as a downtime system. Four organizations (Intermountain Healthcare, Partners Healthcare, Regenstrief Institute, and Vanderbilt University) kept their systems primarily to access historical data. All organizations reported the need to continue to develop or maintain local applications despite having adopted a commercial EHR. The most common applications developed include display and visualization tools and clinical decision support systems.

Conclusion  Homegrown EHR systems continue to be used for different purposes according to the experience of six traditional homegrown EHR developers. The annual cost to maintain these systems varies from $21,000 to over 1 million. The collective experience of these organizations indicates that commercial EHRs have not been able to provide all functionality needed for patient care and local applications are often developed for multiple purposes, which presents opportunities for future research and EHR development.

Background and Significance

The origins of electronic health records (EHRs) in the United States result from pioneering initiatives dating back to the mid-1950s when a selected group of universities and hospitals started to implement computer laboratories to support biomedical research. 1 2 Among those was the University of Utah, 3 where Homer R. Warner led the development of what is likely the first clinical decision support (CDS) system used at the point of care. 4 The system developed by Warner et al used Bayes' theorem to suggest the diagnosis of patients referred to the cardiovascular laboratory of the LDS (former Latter-Day Saints) Hospital in Salt Lake City, Utah. When compared with the diagnosis suggested by the referring physicians, the system outperformed all but one of the participants. With the addition of other capabilities, the system evolved into the Health Evaluation through Logical Processing (HELP) EHR used for over four decades at Intermountain Healthcare. 5 In the late 1960s and early 1970s similar initiatives emerged resulting in other prominent homegrown systems. 6 7 8 In the 1990s, evidence of problems related to paper-based records led the Institute of Medicine to advocate a shift from a paper-based to an electronic medical record 9 ; however, most EHRs used at that time were still based on proprietary systems developed locally and national adoption rates were still low. 10 Wider adoption would take several years and would reach fruition only with financial incentives provided by the Meaningful Use (MU) program. 11

Although accurate estimates of the proportion of organizations that have developed their own EHR are not available; previous systematic reviews of EHR adoption estimate that as least 20 to 25% of the studies published between 1995 and 2007 were from organizations that developed their own system. 12 13 A subsequent review found that studies from these early adopters showed predominantly positive results, 14 which likely contributed to the establishment of MU and attests to the key role played by homegrown systems on advancing EHR research and adoption. 15

MU started to be implemented in 2011 and its criteria had a constrained time frame, which added a significant burden to some of the traditional EHR developers, 16 as a result, today, 9 in 10 hospitals use a government-certified EHR, 17 and the vast majority are vended products. 18 However, the fact that homegrown systems have been replaced does not imply that they are now irrelevant. For example, our own institution, the University of Alabama at Birmingham (UAB), has a long history of homegrown EHR development and despite having installed a commercial EHR recently, its homegrown system still adds value to the UAB health system with functionality used for routine care and as secondary downtime solution. Inspired by our own experience with the need to maintain our homegrown system in the post-MU era, we decided to investigate the destiny of some of the most well-known homegrown EHRs recently replaced with commercial systems.

Objectives

The objective of this study was to understand if and how homegrown EHRs are used in the post-MU era according to the experience of health care organizations widely known for pioneering contributions to EHR development. We specifically explored the experience of health care organizations that have developed homegrown EHRs and have recently replaced them with commercial systems.

Methods

Study Questions

We sought to answer the following four questions:

1. What was the rationale for replacing the homegrown system(s) with a commercial EHR?

2. If the homegrown system was maintained, what was the rationale for doing so?

3. What are the costs and technical challenges to maintain the system and to migrate other infrastructure such as terminology and knowledge management solutions?

4. Do local applications continue to be developed?

Study Design and Participants

We conducted a descriptive study that includes a questionnaire with open-ended questions. To avoid recall bias, we specifically focused on eliciting the experience of organizations that have replaced their homegrown system(s) during or following the implementation of MU, which we considered to be the period between 2009 (when MU was established) and 2015 (when MU's stage 2 was implemented). We invited chief medical informatics officers (CMIOs) or other professionals with equivalent positions from an initial convenience sample of six organizations: Columbia University, Intermountain Healthcare, Partners Healthcare, Regenstrief Institute, UAB, and Vanderbilt University. The organizations were chosen based on authors' experience and collaborations with researchers from these early EHR developers.

Procedure and Data Analysis

We developed a questionnaire that is divided into the following three parts:

• Part I: descriptive data.

• Part II: open-ended questions to explore the experience of the care delivery organizations.

• Part III: snowball sampling questions for referrals within the organization or to other organizations.

To create the questionnaire, the two authors iteratively formulated an initial list of questions that, according to our own experience from multiple EHR adoptions, are more likely to elicit relevant information to address the study questions. We piloted an initial version of the questionnaire with our own CMIO, and based on his responses to and feedback about our questions, we modified questions that needed further clarifications or corrections and defined the final version of the questionnaire. Table 1 lists the questions included in the final version of the questionnaire.

Table 1. Questions sent to the survey participants.

Study question	Questionnaire questions
	Part I: descriptive data
–	What is the ownership of your health system? (for profit, not for profit, public)
–	Number of inpatient beds?
–	Number of outpatient visits?
–	Years developing homegrown systems?
–	To what commercial EHR did you transition?
–	In what year did inpatient settings transition to the commercial EHR?
–	In what year did outpatient settings transition to the commercial EHR?
–	Part II: open-ended questions
–	1. Please briefly describe the history of the development of the homegrown EHR system(s) used prior to the commercial EHR adoption. In what type of setting was/were it used (inpatient versus outpatient) and what were the most important functions provided by the system(s)?
Study question 1	2. Please briefly explain the rational for replacing the homegrown system(s) with a commercial EHR. Was there something missing in the legacy system(s)? Did the MU program play a role in the decision? If so, what was MU's role?
Study question 1	3. Did your organization maintain the homegrown system(s) for a given period after completing the transition to the commercial EHR?
–	If yes (to question 3):
Study question 2	a. What was the rationale for maintaining the system(s)? Was there any reluctance to stop using it or did the system continue to add value to your organization?
Study question 2	b. For how long the system(s) was/were maintained? Were all new data generated in the commercial EHR added to the homegrown system(s), only some data, or was/were the homegrown system(s) used only for historical purposes?
Study question 2	c. How is(are) the system(s) used today or how was it used while being maintained? Was it fully operational or was it on a read-only mode? Please can you provide a few examples of how the system is/was used while it was maintained?
Study question 2	d. Is there a formal process/procedure for EHR downtime (i.e., EHR not available/accessible) at your organization? If yes, please can you briefly describe what is/are the procedure(s)?
Study question 3	e. Can you estimate the monthly/annual cost of maintaining the homegrown system(s) at your organization? Can you estimate the % of IT or informatics personnel allocated to maintain the system(s)?
Study question 3	f. Did your organization have a terminology or knowledge management database prior to the commercial EHR adoption? If so, how did the transition to a commercial EHR impact the management of such databases? Are they still in use today? For what purposes?
–	If no (question 3):
Study question 2	g. Is there a formal process/procedure for EHR downtime (i.e., EHR not available/accessible) at your organization? If yes, please can you briefly describe what is/are the procedure(s)?
Study question 4	4. Does your organization continue to develop local applications to be connected to the commercial EHR? If so, what is the rational for developing such applications locally and not through customizations of the commercial EHR? Do local applications use data exchange standards to interface with the vended EHR such as HL7 FHIR or use vendor's proprietary APIs?
	Part III: snowball sampling questions
–	1. Do you know any other employee from informatics or clinical departments at your institution who is/were directly affected by the homegrown systems here discussed and would recommend for this survey?
–	2. Do you recommend any other healthcare system with a known history of homegrown systems' development to be included in this study?

Abbreviations: APIs, application programming interfaces; FHIR, fast healthcare interoperability resources; EHR, electronic health record; HL7, health level 7; IT, information technology; MU, Meaningful Use.

Participants received the questionnaire in a Microsoft Word document and were asked to provide a written response to each question without any restriction on the level of detail allowed. After having received all responses, one of the authors (T.K.C.) contacted the participants for clarifications as needed.

The first question in part II refers to the historical evolution of homegrown systems. Although most of the information needed to answer this question can potentially be found in the literature, we wanted to give respondents the opportunity to contribute with additional facts that might not be publicly available. The participants were instructed to send the questionnaire to other colleagues or to collaboratively fill out a single questionnaire file. When multiple responses from the same organization were received, they were merged into a single file containing complementary points of each respondent.

We sent the questionnaire to other potential participating organizations following suggestions of the snowball sampling questions.

Results

Participants from all six organizations included in our initial sample completed the questionnaire and provided multiple referrals. Most referrals were to the organizations already included in our initial sample, and four referrals were to other organizations: University of Michigan Health System, Marshfield Clinic, One Medical Group, and Beth Israel Deaconess Medical Center. We sent up to three requests to each of these organizations. Two organizations (University of Michigan and One Medical Group) did not return our request. The respondent from Marshfield Clinic indicated that their organization plans to migrate to a commercial EHR but has not selected a vendor. The respondent from Beth Israel indicated that they do not have plans to abandon their homegrown system. All four were therefore excluded from further analysis. We attempted to contact the respondent from Beth Israel to obtain more information on their decision to maintain their homegrown system, but we did not receive a response.

Most organizations sent multiple questionnaire files and/or a single file with input from multiple employees; therefore, we were unable to identify the exact number of respondents from each organization. Table 2 lists the participating organizations' characteristics. The subsequent sections describe a brief history of homegrown system development at each organization and their experience with homegrown system replacement and maintenance. Table 3 lists the summary of findings.

Table 2. Participating setting's characteristics.

	Columbia university	Intermountain healthcare	Partners healthcare	Regenstrief institute	UAB	Vanderbilt university
Inpatient beds	2,600	2,700	3,000	360	1,200	1,019
Outpatient visits (annual)	>2,000,000	>2,000,000	>2,000,000	>1,000,000	>1,000,000	>2,000,000
Years developing EHR	>30	>40	>40	>40	>20	>20
Commercial EHR adopted	Allscripts	Cerner	Epic	Epic	Cerner	Epic
Year adopted	2009	2015	2015	2016	2012	2017

Abbreviations: EHR, electronic health record; UAB, University of Alabama, Birmingham.

Table 3. Summary of findings for each participating organization.

	Motivation to replace HS	Motivation to keep HS	Annual cost to maintain HS	Apps developed/maintained locally	Reason for developing/maintaining local apps
Columbia university	Merger of two health systems	Continues to add value, Downtime system	Server cost: $120,000	• Results display • CDS applications to augment vendor's solutions	Vendor solution considered inadequate or unavailable
Intermountain healthcare	Failed partnerships, Consolidate multiple systems, Cost to comply with MU	Historical data (read only)	Server cost: 1.6 M Personnel: 4 FTEs	• Patient portal • Behavioral health application • CDS applications, examples include:  □ Clinical protocol for Pulmonary Embolism  □ Alerts for readmission risk  □ Alerts for sepsis risk  □ Alerts for low tidal volume ventilation	Vendor solution considered inadequate or unavailable
Partners healthcare	Consolidate multiple systems, Cost to comply with MU	Historical data (read only)	Not available	• Patient safety dashboards • Patient safety reporting tools • Ordering tools • CDS applications to augment vendor's solutions • Messaging tools • Summarization/visualization tools	Vendor solution considered inadequate or unavailable Intend to share with others
Regenstrief institute	Consolidate multiple systems, Cost to comply with MU	Historical data (read only), HIE	Not available	• Risk score app for social determinants of health	Vendor solution considered inadequate or unavailable
UAB	Cost to comply with MU	Continues to add value, Downtime system	Server cost: $21,000 Personnel: 3 FTEs	• Results display • Workflow management applications • Immunization history • Decision support calculators • Insurer health record viewer • Mobile applications	Vendor solution considered inadequate or unavailable
Vanderbilt university	Inpatient system being sunset, Adopt widely used system, Cost to comply with MU	Historical data (read only), Platform for local apps	Server cost: 1 M	• FHIR-based CDS applications to augment vendor's solutions • Voice-driven clinical Information retrieval system • Mobile applications	Vendor solution considered inadequate or unavailable Intend to share with others

Abbreviations: API, application programming interface; app(s), application(s); FHIR, fast healthcare interoperability recourses; EHR, electronic health record; HIE, health information exchange; HS, homegrown system; M, million; MU, meaningful use.

Columbia University

Homegrown systems development at Columbia started in 1987 under the leadership of Paul Clayton. The EHR was initially developed using a hierarchical database that evolved into one of the first clinical relational databases. 19 The system used a formal knowledge-based terminology with interfaces driven by the knowledge base and included several CDS and natural language processing capabilities. 20

The replacement of the homegrown system with a commercial EHR (Allscripts, Chicago, Illinois, United States) was primarily motivated by the merger of the Presbyterian Hospital (a Columbia University affiliate) and New York Hospital (a Cornell University affiliate). The homegrown Columbia system has been maintained and it is used as an integrated patient view aggregating data from multiple inpatient and outpatient settings, which contributes to its high volume of monthly accesses, over 500,000. The system provides functionality preferred by the clinicians (e.g., better results display) or not available in the commercial EHR (e.g., advanced CDSs). A data feed from the commercial EHR keeps the homegrown system up-to-date, which allows it to function as a secondary solution for downtime.

Annual cost to main the system is estimated as $120,000 in software infrastructure and four full-time equivalents (FTEs). The Medical Entities Dictionary developed in the 1990s 21 is still used as the institutional terminology server. Local applications continue to be developed to accommodate functionality not available or considered inadequate using Fast Healthcare Interoperability Recourses (FHIR) and the vendor's Application Programming Interfaces (APIs).

Intermountain Healthcare

Homegrown systems development at Intermountain Healthcare was initiated by informatics pioneer Homer R. Warner, which led the development of the HELP system in the late 1960s. HELP included several CDS capabilities 22 and multiple inpatient functions. 23 An outpatient longitudinal version called HELP-2 was latter developed to support outpatient services. 24 HELP-2 was the result of a direct partnership with 3M to develop a commercial product. It was used for clinical documentation, results display and CDS across all outpatient clinics. Several landmark studies on CDS systems have been published by Intermountain researchers over the years, examples include a patient advice system to direct respiratory therapy in intensive care units 25 and significant improvements observed on several safety outcomes as a result of a computer-assisted management program for antibiotic orders. 26

HELP and HELP-2 were certified in 2012 with an estimated cost of $12 million for customizations, 16 and despite the investment, Intermountain decided to replace them with a commercial EHR (Millennium, Cerner Corporation, Kansas City, Missouri, United States). According to the respondents, several factors contributed to this decision as follows: (1) failed partnerships to develop the next generation EHR, (2) desire to consolidate multiple systems into one, and (3) cost to maintain a development staff.

The homegrown systems were maintained after the commercial EHR adoption to provide a read-only access to historical data. The systems do not receive a data feed from the commercial EHR and so cannot function as downtime systems. Downtime procedures rely primarily on vendor solutions that include a read-only version of Cerner's EHR (network/power available) and local computers with printers (network/power unavailable).

Annual server cost to main the legacy systems is estimated to be $1.6 million annually and three FTEs for HELP and one FTE for HELP-2.

Intermountain's own terminology server and knowledge repository were maintained and are still in use.

Some local applications have been maintained or continue to be developed when key functionality is not available in the commercial system or is considered inadequate. Respondents informed that they have used the vendor's proprietary API and FHIR-based APIs but consider Cerner's support to FHIR-based APIs to be limited.

Partners Healthcare

Partners Healthcare is one of the earliest EHR developers with the development of the computer-stored ambulatory record (COSTAR) system dating back to 1968. 6 The Massachusetts General Hospital (incorporated into Partners in 1994) developed the Massachusetts General Hospital Utility Multiprogramming System (MUMPS), the first programming language for clinical systems. 27 Another large hospital of the network, the Brigham and Women's Hospital (also incorporated into Partners in 1994), has a long history of EHR development with the incorporation of the Center for Clinical Computing (CCC) system in 1984, 28 which later evolved into the longitudinal Brigham Integrated Computing System (BICS). 29 Partners was an early adopter of computerized provider order entry (CPOE), bar-coded medication administration, and laboratory computing. 30 Partners' researchers have also made several contributions to advance CDS, examples include team interventions using CPOE to prevent serious medication errors 31 and a notification system to alert clinicians about inpatients' serious conditions. 32

After several years of developing multiple homegrown systems, an initiative called “Common Clinicals” was created to integrate these systems into one. The rationale for replacing the homegrown systems with a commercial EHR (Epic Care, Epic Systems, Verona, Wisconsin, United States) was based on the increasingly expensive cost to maintain the systems internally, especially after MU.

The homegrown systems were maintained after the commercial EHR adoption to provide a read-only access to historical data and do not function as downtime systems. Downtime procedures rely primarily on vendor solutions that include a read-only version of Epic's EHR (network/power available) and local computers with printers (network/power unavailable). Before the commercial EHR, Partners used a combination of local and third-party solutions for terminology and knowledge management, which have now been replaced with Epic's and one third-party terminology management solution. FHIR-based applications continue to be developed when functionality is not available in Epic and considered inadequate or when Partners intends to share it with other institutions. Respondents were unable to estimate the cost to maintain the homegrown systems.

Regenstrief Institute

The Regenstrief Institute has made many pioneering contributions to EHR development. Under the leadership of Clement McDonald, the Regenstrief medical record system (RMRS) was implemented at Wishard Health Services in 1972. 8 The Institute introduced randomized clinical trials 33 and controlled crossover studies of EHRs 34 and implemented one of the first computer-assisted order entry workstations. 35 In 1984, a standard structure for exchanging clinical data was developed and became the core of the observation message in Health Level 7 (HL7). 36 In the 1990s, RMRS was gradually expanded from the outpatient clinics to the inpatient setting where it provided CPOE, clinical documentation, CDS, problem list, and nursing documentation. In 1993, the Institute formulated the first health information exchange (HIE), which became a model for HIEs across the country. 37

The rationale for replacing the homegrown system with a commercial EHR (Epic Systems) was primarily based on the desire to integrate multiple applications into one and the increasing cost to comply with MU's requirements. The homegrown system was maintained after migrating to the commercial EHR to provide a read-only access to historical data, comply with legal requirements, and support the HIE infrastructure. Downtime procedures rely primarily on vendor solutions like other Epic clients. At the time of this study, one application has been developed using the vendor's APIs. A terminology server developed locally was mapped to Epic during the migration and was then replaced without any major challenges.

Respondents were unable to estimate the cost to maintain the homegrown system.

University of Alabama at Birmingham

Homegrown systems development at UAB began in 1995 with the development of a results display. Over the years, medication list, problem list, radiology image viewer, and an order entry system were developed into an integrated patient view called Horizon. Horizon has served as a convenient clinical summary for UAB clinicians for over two decades. Despite having certified Horizon for MU in 2012, UAB decided to replace it with a commercial EHR (Cerner Corporation). The primary motivator was the cost to maintain a development staff to comply with MU's criteria.

UAB has kept Horizon operational after migrating to Cerner's EHR and it now receives a data feed for all information needed to populate its integrated patient view. The patient view is available within the commercial EHR as an additional module and has on average 30,000 accesses per month. In addition to the value added for patient care, Horizon is also available as a secondary downtime system. When the commercial EHR is unavailable but the network is available, Horizon can provide most recent patient data needed to support care decisions.

The annual cost to maintain Horizon is estimated as $21,000 in server costs and three FTEs. Before migrating to a commercial EHR, UAB had no proprietary terminology server, and it now uses Cerner's products for terminology and knowledge management.

Respondents reported that despite having a commercial EHR available, UAB continues to develop local applications using Cerner's APIs when key functionality is not available in the commercial system or is considered inadequate. According to the respondents, Cerner's support of data exchange standards is limited as it includes a fee per FHIR transaction (after a certain number of transactions), which hampers its seamless use.

Vanderbilt University

In the late 1990s, Vanderbilt University Medical Center launched a paperless strategy for its outpatient clinics inspired by successful applications developed for inpatient services, such as the WizOrder, 38 which was one of the first CPOE systems to incorporate the Unified Medical Language System (UMLS) as a dictionary to encode free-text entries. 39 The outpatient system included an integrated web-based platform called StarPanel, which provided an integrated view of patient panels, clinical documentation, results display, and electronic messaging. 40 Vanderbilt's researchers have also developed a comprehensive data visualization tool to improve medication safety. 41

In parallel to the MU implementation, an inpatient commercial EHR that partially covered hospital-based services was being discontinued. At that time, Vanderbilt's leadership decided that the adoption of a widely used commercial product would benefit the organization and both the commercial and homegrown system were replaced with a single commercial product (Epic Systems). MU's regulations played a secondary role as they increased the cost of the development staff.

The homegrown system was maintained to provide access to historical data not migrated to the commercial EHR and serves as a platform for local applications. Local applications continue to be developed as needed and interface with the commercial EHR using HL7 V2 and FHIR APIs. The estimated annual cost to maintain the system is $1 million in server cost.

A third-party solution for terminology management was maintained after the implementation of the commercial EHR and another third-party solution was acquired for knowledge management. According to one of the respondents the transition to a commercial EHR was an opportunity for the institution to adopt a knowledge management solution that already interfaces with Epic.

Discussion

We have conducted a survey of six traditional homegrown EHR developers and report the current use of their systems. Our analysis is not intended to be exhaustive regarding the experience with homegrown systems nationally, but the collective experience of these pioneers provides some insights regarding the decreased, but persistent presence of homegrown EHRs in commercially based digital health systems. We found that in cases where homegrown systems continue to add direct value to patient care (Columbia and UAB), or in the case of the other organizations that use them primarily to access historical data, these systems continue to have some sort of application in the post-MU era by filling gaps left by vended products.

MU was heavily based on studies that reported predominantly positive results associated with EHR adoption, 42 including many studies evaluating homegrown systems such as those discussed here. 12 However, as consistently reported by our survey participants, MU's requirements and constrained time frame seem to have played an important role on their decision to adopt a commercial system, since vendors can amortize the cost to adapt their products to such regulations in a way that health care organizations cannot. As a result, homegrown systems that frequently produced positive clinical outcomes 22 30 38 were replaced with commercial systems adopted without a much needed redesign 43 to fix widely known problems such as suboptimal interfaces, 44 45 bloated notes, 46 47 and overzealous alerts. 48 It is true that achieving nationwide adoption by relying primarily on homegrown systems would likely be unattainable, as the infrastructure needed to share functionality developed locally is still under development. 49 50 However, it is also true that the expected benefits of a digital health system 51 have not yet materialized through commercial EHR adoption 52 53 54 55 56 ; 4 years after becoming a commercially based digital health system, the U.S. health system continues to be the most expensive and lags behind other developed countries in some quality outcomes. 56

The collective experience of the surveyed organizations indicates that while the migration to a commercial system may facilitate implementation or maintenance of terminology and knowledge management solutions, it also introduces important gaps. Two organizations decided to adapt their homegrown system to function as a secondary downtime solution to mitigate the risk of having data inaccessible when vendor's downtime solutions do not function properly. Four organizations use their legacy systems primarily to access historical data that could not be migrated to the commercial system, including the three organizations with longer experience with EHR development, which did not migrate large amounts of historical data to their commercial product due to technical and cost barriers. All organizations considered the cost to comply with MU's requirements as a contributing factor to replace their legacy systems, except for Columbia, which may not have faced a significant cost burden because they adopted a commercial system before MU's stage 1 started to be implemented. Lastly, all organizations continue to have business needs, for which vendor's solutions are considered either unavailable or inadequate, and so several local applications continue to be developed to fill multiple gaps, with the most common being on data visualization/display functions and decision support systems of sundry sorts. It is unknown whether these gaps will be filled by EHR vendors; therefore, they represent an opportunity for future research and new business models implemented through initiatives such as Substitutable Medical Applications, Reusable Technologies (SMART) on FHIR, and CDS Hooks. 49 50

Local applications depend on seamless interface with commercial EHRs, and the ease of use of standards, such as FHIR, varies across vendors. Cerner clients reported that Cerner's support for FHIR APIs is not satisfactory as Cerner imposes a fee per FHIR transaction, which prevents the expansion of FHIR-based applications. When questioned about this particular point, Epic clients did not report such a barrier.

Both Columbia and UAB respondents reported that their homegrown systems have been used multiple times as a downtime system including in situations when the vendor's downtime solution was not working properly, as stated by UAB's CMIO “ Horizon has saved us many times… .” Because these organizations had only short-planned downtimes recently, respondents were unable to estimate the exact number of accesses during downtime. However, unplanned downtimes are not rare and there are reports of commercial EHR downtimes directly affecting patient care. 57 A recent study found that in the event of an unplanned downtime triggered by a ransomware attack, laboratory testing results were delayed by an average of 20 minutes (62% increase compared with normal operation). 58 Given an increased incidence of such attacks 59 and the need to maintain homegrown systems, either for historical/legal purposes or for actual patient care, these systems seem to be effective tools for planned or unplanned downtime and can add an additional security layer for care continuity. In addition to serving as a platform for local applications, the development of the data feed needed to leverage homegrown systems to provide a minimum dataset during commercial EHR downtime can likely be accommodated within the FTEs allocated to maintain these systems. The cost of such an approach will surely be paid back many times over in critical moments, potentially preventing quality and safety hazards.

On balance, the collective experience of six traditional EHR developers provides useful insights for other organizations undergoing similar replacements or planning to do so in the future. First, technology champions and other key stakeholders should be involved as early as possible in the evaluation of a commercial system to be implemented, to identify unavailable or inadequate critical functionality. Such functionality may need to be developed locally as the uptake of the standards needed to make EHR functions shareable has been slow, and some EHR vendors may impose legal or financial restrictions on the use of such standards. Second, large organizations, such as the Veterans Health Administration, will likely need to develop strategies to make legacy data accessible in the commercial EHR, as the migration of vast amounts of historical data to commercial systems seems to be impractical. Lastly, vendor's downtime solutions may not be enough to guarantee continuity of care. This risk can be mitigated with minor adaptations to legacy systems, which should be assessed when their abandonment is being considered.

Limitations

We selected a group of specific organizations widely known for EHR development. Other organizations that have developed EHRs internally may have different perspectives. However, given the prominence of these pioneers, we believe that their collective experience is informative. We did not conduct a systematic analysis of cost to maintain the homegrown systems, a larger, more generalizable survey would likely be needed to address this limitation; however, we believe that the approximate estimates provided by the respondents could be useful to other health systems. Although we limited the scope to commercial EHR adoption that happened during the MU implementation, most of the events reported happened 5 or more years ago and are subject to recall bias.

Conclusion

Despite the nationwide adoption of commercial EHRs, some traditional homegrown EHR systems continue to be used for different purposes. In most cases, homegrown EHRs are used to provide access to historical data, but in some cases, they continue to be used for direct patient care or as secondary downtime solutions. The annual cost to maintain these systems varies from $21,000 to over 1 million. The experience of six traditional EHR developers indicates that commercial EHRs have not been able to provide all functionality relevant for patient care and local applications continue to be developed, which presents opportunities for future research and EHR development.

Clinical Relevance Statement

Although most homegrown EHR systems have been recently replaced with commercial EHRs, these systems continue to have some sort of application in the post-MU era by filling gaps left by vended products. In addition, with an increasing incidence of ransomware attacks resulting in unplanned commercial EHR downtimes, homegrown systems can be leveraged to provide a minimum dataset needed for continuity of care, potentially preventing quality and safety hazards.

Multiple Choice Questions

1. According to the experience of traditional homegrown EHR developers, what was an important contributing factor for the replacement of homegrown systems with a commercial EHR in their organizations?

   1. Lack of support from organizational leadership.

   2. The higher quality of commercial EHRs.

   3. Clinicians' preference for commercial EHRs.

   4. Regulations and their cost constraints.

   Correct Answer: The correct answer is option d. According to most traditional EHR developers included in this study, the Meaningful Use program was mentioned as an important factor on their decision to adopt a commercial system, followed by the need to consolidate multiple systems into one.

2. What are the most common uses for homegrown systems in the post-Meaningful Use era?

   1. They have no use.

   2. They have the same uses as before the Meaningful Use.

   3. They are primarily used to access historical data, but in some cases, they are also used for direct patient care and as a downtime system.

   4. They are maintained only for legal purposes.

   Correct Answer: The correct answer is option c. According to most traditional EHR developers included in this study, homegrown systems continue to be used to access historical data not migrated to commercial systems, and, in some cases, they continue to add value to patient care and can function as secondary downtime systems.

Funding Statement

Funding This study was supported by research funds from the Informatics Institute of the University of Alabama at Birmingham.