Implementing and Upgrading an Information System

The American Recovery and Reinvestment Act (ARRA), enacted in 2009, spawned the Health Information Technology for Economic and Clinical Health (HITECH) Act. One of its primary goals was that each person in the United States would have a certified digital medical record by 2014, including the electronic exchange of health information across healthcare institutions, to improve quality of healthcare. As discussed in detail in Chapter 29, the HITECH Act created a $27 billion federally funded incentive program that provided Medicare and Medicaid payments over 5 to 10 years to three groups: (1) eligible providers (EPs), (2) eligible hospitals (EHs), and (3) critical access hospitals (CAHs). CAH were defined as rural hospitals certified to receive cost-based reimbursement from Medicare. Within the HITECH Act, two EHR incentive programs were developed, specifically the Medicare EHR Incentive Program administered by the Centers for Medicare and Medicaid Services (CMS) and the Medicaid EHR Incentive Program, which was governed by individual states and territories. It is important to note that these government incentive programs were not established to cover the total cost of implementing an EHR system but rather to encourage or “incentivize” healthcare organizations and healthcare providers to use an EHR in a meaningful way—called Meaningful Use (MU) (this term is now referred to as “promoting interoperability”)—and to foster faster rates of adoption across the nation (One Hundred Eleventh Congress of the United States of America, 2009). Other terms often used for this incentive program were “stimulus funds,” “stimulus package,” or simply “ARRA funds” (Healthcare Information Technology Standards Panel [HITSP], n.d.).

CMS established the criteria for MU or promoting interoperability, including minimal thresholds for select objectives. There were three stages in the EHR Incentive Program. Stage 1 began in 2011 and emphasized capturing patient data that was expected to be shared with other healthcare professionals and the patient. Stage 2 began in 2014 and focused on advanced clinical practices and providing patient portals where patients could access their medical records. Stage 3 began in 2017 and accentuated data interoperability and patient outcomes while increasing the thresholds for the objectives and clinical measures (Centers for Medicare & Medicare Services [CMS], 2015). Additional requirements included the submission of detailed and timely reports demonstrating interoperability adoption to CMS and the appropriate state offices.

CMS requirements for promoting interoperability mandate that the EHR be a “certified complete EHR” or have individual modules that are “certified EHR modules.” This means that they are certified by the Office of the National Coordinator for Health Information Technology (ONC). Complete EHR certification means that the system was required to prove it was functional with the appropriate data elements and logic to support all facility departments. EHR module certification means that the ancillary application met one or more requirements. Most hospitals and physician offices purchased commercial systems that incorporated all essential capabilities. A list of certified products can be found at CHPL (https://chpl.healthit.gov/#/search).

The Certification Commission for Health Information Technology (CCHIT) began testing and certifying new software applications in 2006. In 2014, it ceased testing and certifying EHRs for financial reasons and changed its role to advising healthcare providers on how to comply with the government’s regulations and providing guidance to health IT developers on how to meet the government’s requirements for a certified EHR. The CCHIT worked with the Health Information and Management Systems Society (HIMSS) to advance programs and policies that strongly promote interoperability and to advocate using IT between patients and providers as another tool to transform healthcare (Terry, 2014). CCHIT ceased all operations in 2014.

The ONC now manages the EHR certification program—which first began in 2010—using the process shown in Fig. 20.1. The ONC has increased the use of this program to other CMS and non-CMS programs. There are multiple editions of the program, each more robust than the last, to improve interoperability standards, increase transparency, and moderate costs for the programs and systems it supports. Modifications to this system have been instituted and documented in the Final Rule by the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program.

However, the MU criteria did not require purchasing a commercial, certified product. A few hospitals and EPs had developed their own “homegrown” EHRs that may or may not have included commercial components. CMS welcomed organizations to certify their systems using the EHR Alternative Certification for Healthcare Providers (EACH) program. The EACH program was a three-step program to certify homegrown systems or existing EHR technology not already covered by a vendor certification. The program provided a mechanism to obtain certification by demonstrating that the system met the U.S. Department of Health & Human Services (HHS) MU requirements (US DHHS Office of the National Coordinator [ONC], 2015). For example, the Regenstrief Medical Record System (RMRS) in Indiana is an EMR system that began in 1972 and expanded to several additional major hospitals (Duke, et al. 2014). Other medical centers that successfully opted for this alternative include Geisinger Health System, Marshfield Clinic Health System, Landmark Hospitals (Chartpad), and Brigham and Women’s Hospital (Braunstein, 2015; Mace, 2016).

U.S. hospitals, while initially slow to adopt an EHR system, found that the HITECH could be clearly implemented. A 2011 survey conducted by the American Hospital Association found that EHR use doubled from 16% to 35% between 2009 and 2011. By 2014 the ONC reported that 76% of hospitals implemented at least a basic EHR system, and almost 97% of those implemented a certified EHR technology (Charles et al., 2015). The American Hospital Association in a 2019 report noted that 9 of 10 hospitals used the EHR to inform their practice (https://www.aha.org/news/headline/2019-04-17-onc-nearly-all-hospitals-use-ehr-data-inform-clinical-practice).

On December 13, 2016, the 21st Century Cures Act (“Cures Act” for short) was signed into law with the goal of improving electronic access, exchange, and utilization of health information for patients and providers (ONC Cures Act). Specifically, the ONC enacted the Cures Act Final Rule to implement the interoperability and health information transparency terms of the Cures Act. The ultimate goal of the Final Rule was to facilitate patient control and engagement of their own health information. In addition to providing patients and their healthcare providers with access to health information, the Final Rule also aimed to increase incentives towards developing a health application ecosystem, such as a call to use more standardized application programming interfaces (APIs) to access structured healthcare data on smartphone applications. Furthermore, the rule required that patients have the ability to securely access their electronic health information (EHI) at no cost to them and in a timely fashion. Section 4004 of the Cures Act identified the role of information blocking and eight activities (Table 20.1) that do not qualify as information blocking according to this piece of legislation. Information blocking is a practice conducted usually by a health IT developer of certified health IT, health information network or exchange, or healthcare provider that is likely to interfere with the access, exchange, or use of EHI.

Federal rules implemented under the bipartisan Cures Act also specified eight types of clinical notes (as outlined in the United States Core Data for Interoperability) required to be available to patients free of charge. The eight note types included (1) consultation notes, (2) discharge summary notes, (3) history and physical, (4) imaging narratives, (5) lab reports, (6) pathology reports, (7) procedure notes, and (8) progress notes. Additional note type exceptions apply to protect patient confidentiality and sensitive matters (i.e. psychotherapy notes, those notes used in court proceedings).

The Cures 2.0 Act draft was released as follow-up legislation in June 2021. The Act aimed to galvanize medical product innovation, institute appropriate regulations for safety and quality, and modernize FDA and CMS processes. Additional aspects of the Act included bolstering future pandemic preparedness, supporting digital health technologies, and streamlining Medicare coverage processes (Locke et al., 2021).

With each new release, information systems become more complex and robust, enabling them to incorporate evidence-based content (called evidence-based practice [EBP]) and to use clinical decision support (CDS) features in the system. Detailed information on EBP and CDS is included in Chapters 11 and 12, respectively; however, one of the most frequently quoted definitions for EBP is one proposed by Sackett et al.—EBP is “the conscientious, explicit, and judicious use of current best evidence in making decisions about the care of individual patients. The practice of evidence-based medicine means integrating individual clinical expertise with the best available external clinical evidence from systematic research” (Sackett et al., 1996). EBP involves making decisions for clinical care based on the most current recommended treatments for specific diagnoses. These recommendations are derived from an ongoing review and analysis of high-caliber, peer-reviewed scientific studies in the literature. While entering orders from an EBP order set, the practitioner may override any of the recommended diagnostic or treatment options based on the individual needs of the patient. Some healthcare providers strongly object to a preconfigured EBP order set, referring to it as “cookbook medicine,” and resist incorporating it into practice. Berner offers an analogy of CDS, including EBP similar to the nursing process of the traditional “five rights” for medication administration: “The clinical delivery system should provide the Right information to the Right person in the Right format through the Right channel at the Right time” (Berner, 2009).

A major challenge to EBP is remaining current due to the continuous discovery of new knowledge and the resulting changes to recommended best practices guidelines that are embedded in EHRs. Commercial products can assist organizations in updating protocols by providing current EBP clinical solutions, such as order sets and care plans. Most major EHRs have been upgraded with common CDS features that help meet some of the specific MU mandates, such as alerts for critical lab results or a history of methicillin-resistant Staphylococcus aureus (MRSA) on new admissions, pregnancy warnings on select medications and diagnostic tests, drug allergies, drug–drug interactions, drug–diagnosis warnings, dosage range limits, the capture of specific data such as smoking status and advance directives, and immunization reminders.

The advantages of using a system that incorporates evidence-based content and CDS include the following: Defines standardized, appropriate care and reduces variability of care for common diagnoses.

EHRs help decrease medication errors, especially if closed-loop bedside barcoding medication administration is an integral piece of the system (Poon et al., 2010). Quality of care and outcomes improve when decision-support mechanisms, standardized order sets, and care plans based on best practices are incorporated in the EHR. Besides being aware of all the positive functionalities and advantages of the EHR, staff also need to be well informed on what the EHR cannot do.

Major implementations can elicit strong pushbacks from hospital staff for a variety of reasons. A primary reason is that a major implementation often involves changes in well-established workflows and processes, resulting in a temporary decrease in productivity, particularly in the early stages when clinicians are still learning the system. In addition, while the new system may offer significant advantages to the institution (e.g., a decrease in medication errors, reduced time between order entry and delivery of services, or a dramatic decrease in telephone calls from nursing and pharmacy to physicians about illegible or questionable orders), individual practitioners may focus on the disadvantages that personally affect them, such as an increase in time to enter admission orders or immediate post-op orders.

In a previously paper-based-records world, some healthcare providers created their own personal order sets for their practice and titled them using their name, such as Dr. Smith’s Routine Admission Orders for Surgery. Once records became electronic, personalized order sets were discouraged or even less likely to be made available in production. Each specialty benefits from creating a standardized order set for each of its common procedures, diagnoses, surgeries, and admissions, incorporating EBP. This approach minimizes wide variances in care and avoids an IT maintenance challenge to keep individual physicians’ order sets up to date. One of the most important success factors in the implementation of an electronic health system is to involve as many users as possible in the design and planning of that system and discuss the inevitable changes to workflows, processes, policies, and procedures (Menachemi & Collum, 2011).

Using the EHR to perform a task for which it is not designed or using a poorly designed system may produce poor results or outcomes. Published studies report a variety of unintended consequences for EHRs. Ash et al. identified nine types of unintended consequences and corresponding interventions to minimize each of these risks (Ash et al., 2009). A few of the unintended consequences are associated with human error, such as selecting the wrong patient or the wrong medication from a list. They refer to this type of error as a juxtaposition error. Recommended strategies to decrease unintended consequences are very similar to the best practices for a successful implementation discussed later in this chapter (Ash et al., 2003). Weiner et al. coined a new term, e-iatrogenesis, to describe the most critical of the new type of errors seen in EHRs (Weiner et al., 2007). Other types of errors include users who fail to validate or read the list of all orders entered during a session before final acceptance or who accept the defaults for select orders without review.

The EHR may use Tall Man lettering (i.e., the use of mixed-case lettering) for look-alike names of medications recommended by the Institute for Safe Medication Practices (ISMP). Studies indicate that using mixed-case lettering in similar drug names helps decrease medication errors during order entry, medication dispensing, and medication administration by highlighting the differences in the drug names. A few examples of medication names using Tall Man lettering are NiFEDipine versus niCARdipine, DOBUTamine versus DOPamine, and CISplatin versus CARBOplatin (Institute for Safe Medication Practices [ISMP], 2011).

Another safety benefit associated with the implementation of an EHR is that it can enforce the use of CMS-approved abbreviations. In addition, EHRs can incorporate real-time updates or revisions to the order item master (a master list of orderable items) and electronic order sets. For example, Darvon and Darvocet were recalled in 2010 because of serious cardiac arrhythmias. Institutions with EHRs were able to quickly remove these medications from the pharmacy formulary, automatically inactivating Darvon and Darvon equivalents on all electronic order sets.

HIPAA legislation that was originally drafted in 1996 mandated unique national patient identifiers (NPIs) to ensure patient safety and promote interoperability. However, privacy advocates voiced strong opposition, and Congress passed laws preventing the development of unique NPIs. HIMSS has recently reintroduced a strong argument for an NPI and patient matching strategy using demographic attributes that are considered relatively stable and unlikely to change. Many proponents believe that we cannot achieve true interoperability until it is in place (Ritz 2013). Examples of attributes include first name, middle name, last name, maiden name, date of birth, gender, driver's license number, street address, city, state, ZIP Code, and phone number (Terry, 2015). Both proponents and opponents can cite scenarios in which data attributes may prove unstable, and the algorithms that are used do not address enough data elements. An ONC report found that patient matching accuracy oftentimes depended on whether it was matching patients internally or externally across organizations. The error rate varied widely from 10% in IT sophisticated organizations to an alarming 40% to 50% rate when matching across enterprises (Office of the National Coordinator for Health Information Technology, 2014).

Advances in EHR infrastructure have impacted the patient’s experience with the healthcare system. The development of EMR-tethered patient portals for viewing lab results, messages from healthcare providers, and other notes has been associated with several reports of positive patient experiences, lower no-show rates, and self-reported decreases in healthcare system use (Graham et al., 2020). With the advent of the COVID-19 pandemic, telemedicine also came to the forefront as a necessary tool to continue providing healthcare to the masses. Systematic reviews and meta-analyses prior to the pandemic also identified that patients participating in telehealth visits described improved healthcare outcomes, increased ease of use, lower costs, and improved communication with healthcare providers (Kruse et al., 2017). E-visits have also been implemented in certain settings where patients can receive detailed diagnostic or treatment recommendations in an asynchronous messaging format with their healthcare provider team. Literature is pending on the effects of these visit types on long-term cost effectiveness and utility.

Table 20.4 details many different types of testing and what the role each type of test plays. Regardless of the system being implemented (custom versus COTS), some testing will be common to both scenarios. Internal testing techniques are commonly done before release to the customer including unit testing, function testing, and regression testing. A COTS developer will do this in isolation, but similar testing is done when the organization is planning for the implementation.

Prior to implementation or go-live, having a testing plan or phase ensures that the project will perform to the predetermined specifications for the project to be a success. Test plans will also commonly have phases and checks to ensure timely delivery of a functional system. As the project continues through the timeline, it is important to perform integration testing throughout system development to ensure that necessary interfaces between software systems are functioning appropriately. This can apply to both unit integration and system integration.

One of the major components to the testing plan before go-live is user acceptance testing (UAT). This is the final stage of testing prior to go-live where the software manufacturer slash vendor and health care organization can further debug the software to ensure final functionality of the system. It is the closest testing to the end-user to identify any remaining problems. UAT is not one particular test, but it is considered the last step of tests before the general roll-out. Three important features in UAT are the strategy, scenarios, and scripts (Healthcare Information and Management Systems Society, 2015). The strategy is the details of who will be involved, what equipment or software is needed, which procedures will be followed, and what support is necessary for a successful test. The scenarios should be a representative number of events to simulate the requirements of the software. The test scripts are the step-by-step instructions that will be used for each test and the associated expected results.

Education of all end-users is a mini project and is best assigned to an education department to coordinate and oversee all components. A training plan must address the development of teaching plans, training manuals, and any training materials, like tip sheets, to provide instructions on common tasks to be used during training and on the job. Training falls into three major categories:

Training should be a requirement for any staff using the system, and policy and procedures should be developed for dealing with those who do not complete and/or pass the training. Considerations in planning training and education should include time for training, methodology of training, content, training rooms, and hardware needs (Table 20.5).

Maintenance is an ongoing process that involves a variety of tasks such as code updates, patches for identified defects, and a continuous revision of the system in response to users’ requests, as well as new regulatory requirements and initiatives. The maintenance phase is an iterative process and will be ongoing. As a retrospective study reviewing changes made over a 6-year period of the Kaiser Permanente Institution points out, significant resources, expertise, and interdisciplinary collaboration are key. Over this time frame the number of changes tracked was significant and affected many users within the organization (Liu, 2019).