HIM 301 Introduction to Health Informatics- WK3-D2
chantaxrews
HIM30117IntroductiontoHealthInformatics17-Chapter17.docxChapter 17 Implementing and Upgrading an Information System Solution
Christine D. Meyer
No matter whether the electronic health record (EHR) is new or an upgrade, the ultimate goal in implementations is to provide the highest level of care at the lowest cost with the least risk.
Objectives
At the completion of this chapter the reader will be prepared to:
1.Discuss the regulatory and nonregulatory reasons for implementing or upgrading an electronic information system
2.Compare the advantages and disadvantages of the “best of breed” and integrated system approaches in selecting healthcare information system architecture
3.Explain each step in developing an implementation plan for a healthcare information system
4.Develop strategies for the successful management of each step in the implementation of a healthcare information system
5.Analyze the benefits of an electronic information system with an integrated clinical decision support system
6.Explain the implications of unintended consequences or e-iatrogenesis as it relates to implementing an electronic health record (EHR)
Key Terms
Best of breed, 277
Big bang, 284
Phased go-live, 284
Scope creep, 276
Tall Man lettering, 276
Workarounds, 279
Abstract
The decision to implement a new electronic health record (EHR) or to upgrade a current system is based on several factors, including providing safe and up-to-date patient care, meeting federal mandates and Meaningful Use requirements, and leveraging advanced levels of clinical decision support. Implementing EHRs entails multilayered decisions at each stage of the implementation. Major decisions include evaluating vendor and system selection, determining go-live options, redesigning workflow, and developing procedures and policies. The timeline and scope of the project is primarily dictated by expenses, staff, resources, and the drop-dead date for go-live. Success depends on variables such as a well-thought-out and detailed project plan with regular review and updating of the critical milestones, unwavering support from the organization's leadership, input from users during the design and build phases, mitigation of identified risk factors, and control of scope creep. The implementation of an EHR is never finished. Medication orders, nonmedication orders, and documentation screens or fields will continuously need to be added, modified, or inactivated; patches will be installed and tweaks to workflows and functionality will be ongoing.
Introduction
This chapter focuses on the implementation of healthcare information systems. Of course, many different types of applications are used within a healthcare information system. The general principles for implementing these many different applications are the same; however, for the purposes of discussion this chapter will focus mainly on the implementation of an electronic health record (EHR) to demonstrate these general principles. In 2004 President George W. Bush promoted the idea of a fully functional electronic medical record (EMR) for Americans within 10 years.1 This proposal officially initiated the massive changes that we are now witnessing in health informatics. Healthcare information systems are widely used today in many diverse settings. Small hospitals, ambulatory clinics, and small physician practices generally implement a simple and streamlined system with limited features but tailored for quicker implementation and easier long-term maintenance. Large medical centers, multifacility enterprises, and multiphysician practices with more complex needs typically opt to install a more robust system that allows for customizations. However, there are still hospitals and physician practices without an EHR or that have an outdated system that cannot accommodate recent regulatory mandates. An outdated system may be one reason to implement or upgrade a health information technology (health IT) solution, but there are others.
Reasons to Implement or Upgrade a Healthcare Information System
There are several reasons why a health organization (hospital organization, physician office, or clinic) may decide that a major change is needed. A careful review of the reasons for the change will start the process of deciding whether to install a new information system or upgrade the current system. One of the primary reasons for making such a major change is changing government regulations.
The American Recovery and Reinvestment Act (ARRA)
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 is that each person in the United States would have a certified health record by 2014, including the electronic exchange of health information across healthcare institutions to improve quality of healthcare. As discussed in detail in Chapters 24 and 25, the HITECH Act created a $27 billion federally funded incentive program providing Medicare and Medicaid payments over 5 to 10 years to three groups: (1) eligible providers (EP), (2) eligible hospitals (EH), and (3) Critical Access Hospitals (CAH). CAH are defined as rural hospitals certified to receive cost-based reimbursement from Medicare. Within the HITECH Act there are two EHR incentive programs: the Medicare EHR Incentive Program administered by the Centers for Medicare & Medicaid Services (CMS) and the Medicaid EHR Incentive Program, which is governed by individual states and territories.
It is important to note that these incentive programs were not established to cover the cost of implementing an EHR system but to encourage or “incentivize” healthcare organizations and healthcare providers to use an EHR in a meaningful way, called Meaningful Use (MU), and to foster much-needed faster adoption across the nation.2 Additional requirements include the submission of detailed and timely reports to CMS and the states demonstrating MU adoption. Other terms often used for this incentive program are “stimulus funds,” “stimulus package,” or simply “ARRA funds.”3
To meet these MU requirements an EHR should 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) Authorized Testing and Certification Body. Complete EHR certification means that the system has the functionality, required data elements, and logic to support ambulatory, emergency room, outpatient, and inpatient MU requirements. EHR module certification means that the ancillary application meets one or more requirements. Most hospitals and physician offices purchase a commercial system that is deemed certified, meaning that the vendor incorporated these essential capabilities. A search engine providing a list of certified products can be found at http://oncchpl.force.com/ehrcert?q=chpl and each product has links to other pages that include information about that product.
MU criteria do not require purchasing a commercial, certified product. Hospitals and eligible providers may have developed their own “homegrown” EHRs that may or may not include commercial components, and have no need to purchase a new product. For example, legacy systems at Intermountain Healthcare and the Regenstrief Institute are accepted systems developed over decades.4 CMS welcomes organizations to certify their systems using the three-step EHR Alternative Certification for Healthcare Providers (EACH) program established by the Certification Commission for Health Information Technology (CCHIT). The three-step process provides a mechanism to determine whether the system measures up to U.S. Department of Health & Human Services (HHS) requirements to support MU and to obtain certification for an existing EHR system that is not already covered by a vendor certification. Major medical centers that successfully opted for this alternative include Health Management Associates, New York University, Langone Medical Center, Northwestern University, Tenet Health System, and Medical University of North Carolina.4
A 2011 survey conducted by the American Hospital Association found that the percentage of U.S. hospitals that had adopted EHRs more than doubled from 16% to 35% between 2009 and 2011. Moreover, 85 percent of hospitals report that they intend to take advantage of the incentive payments made available through the Medicare and Medicaid EHR Incentive Programs by 2015.5
The Transition from ICD-9-CM to ICD-10-CM Codes and from HIPAA Version 4010 to HIPAA Version 5010
Complicating implementation of the MU criteria is the change in the International Classification of Diseases (ICD) coding. ICD-10-CM is a U.S. modification of the tenth revision of the International Classification of Diseases, which is used to report medical care and cause of deaths, process payments, calculate trends, and perform statistical analyses. Older versions of healthcare information systems cannot adopt the new ICD-10-CM codes because they were configured to accept the old ICD-9-CM codes consisting of three to five numeric-only characters. The ICD-10-CM codes have three to seven characters. Making things even more complex, the first and third characters are always alpha characters, the second character is always numeric, and characters four through seven can be either alpha or numeric.6 The ICD-9-CM system has 17,000 codes to define diagnoses and procedures. In contrast, the ICD-10-CM version contains 155,000 codes, which allows for a more detailed definition and better reporting for reimbursement and biosurveillance (Tables 17-1 and 17-2).7 The United States lags behind other countries in implementation of ICD-10 codes. Already, 138 other countries are using ICD-10 codes to track mortality and 99 countries are using these codes to track morbidity (Table 17-3).6 The original deadline for adopting ICD-10-CM codes was October 1, 2011. However, the Secretary of Health & Human Services delayed the mandatory adoption of ICD-10-CM until October 1, 2014.
In addition, all health plans, healthcare providers, and clearinghouses that conduct business electronically were required to convert to the Health Insurance Portability and Accountability Act (HIPAA) standard for electronic transactions: Version 5010. Failure to comply means that any electronic transactions using the old Version 4010 standard form that were submitted to CMS as of June 30, 2012, were rejected. The upgrade to Version 5010 is also important because the new version is able to accommodate the forthcoming and mandatory ICD-10-CM and ICD-10-PCS code sets.
TABLE 17-1 Comparison of ICD-9-CM and ICD-10-CM Codes
CHARACTERISTIC ICD-9-CM ICD-10-CM
Field Length 3-5 characters 3-7 characters
Available Codes Approximately 13,000 codes Approximately 68,000 codes
Code Composition (i.e., Numeric, Alpha) Digit 1 = alpha or numeric Digit 1 = alpha
Digits 2-5 = num Digit 2 = numeric
Digits 3-7 = alpha or numeric
Character Position within Code Characters 1-3 = Category Characters 1-3 = Category
Characters 4-5 = Anatomic site, etiology, manifestation*
Characters 4-6 = Anatomic site, etiology, severity, or clinical detail Character 7 = Extension
Available Space for New Codes Limited Flexible
Overall Detail Embedded within Codes Ambiguous Very Specific
Laterality Does not identify right vs. left Often identifies right versus left
Sample Code 438.11, Late effect of cerebrovascular disease, speech and language deficits, aphasia
I69.320, Speech and language deficits following cerebral infarction, aphasia following cerebral infarction
rom ICD-10 State Medicaid Readiness Medicaid ICD10 Implementation Handbook.docx. Retrieved January 14, 2013 from http://www.medicaid.gov/Medicaid-CHIP-Program-Information/By-Topics/Data-and-Systems/ICD-Coding/Downloads/icd-10-implementation-assistance-handbook.pdf.
ICD, International Classification of Diseases.
* Not always the case for ICD-9-CM.
† Not always the case for ICD-10.
Best Practices: Evidence-Based Content and Clinical Decision Support (CDS) Systems
With each new release, information systems are more robust, enabling them to incorporate evidence-based content (called evidenced-based practice or EBP) and to use clinical decision support (CDS) features in the system. Detailed information is included in Chapter 3; however, one of the most frequently quoted definitions for EBP is one proposed by Sackett, Rosenberg, Gray, Haynes, and Richardson: 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.”8(p71) 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.”9(p7)
TABLE 17-2 Comparison of ICD-9-CM and ICD-10-PCS Codes
CHARACTERISTIC
ICD-9-CM
ICD-10-PCS
Field Length
3-4 characters
7 alpha-numeric characters; all are required
Available Codes
Approximately 3,000
Approximately 72,081
Technology
Based on outdated systems
Consistent with current medical technology and advances
Available Space for New Codes
Limited
Flexible
Overall Detail Embedded within Codes
Ambiguous
Very Specific
Precisely defines procedures with detail regarding anatomic site, approach, device used, and qualifying information
Laterality
Code does not identify right vs. left
Code identifies right versus left
Terminology for Body Parts
Generic description
Detailed description
Procedure Description
Lacks description of approach for procedures
Detailed description of approach for procedures. Precisely defines procedures with detail regarding anatomic site, approach, device used, and qualifying information
Character Position within Code
N/A
There are 16 PCS sections that identify procedures in a variety of classifications (e.g., medical surgical, mental health, etc.). Between these sections, there may be variations in the meaning of various character positions, though the meaning is consistent within each section. For example, in the Medical Surgical section, Character 1 = Name of Section* Character 2 = Body System* Character 3 = Root Operation* Character 4 = Body Part* Character 5 = Approach* Character 6 = Device* Character 7 = Qualifier*
Example Code Laparoscopic Appendectomy
47.01
ODTJ4ZZ
From ICD-10 State Medicaid Readiness Medicaid ICD10 Implementation Handbook.docx. Retrieved January 14, 2013 from http://www.medicaid.gov/Medicaid-CHIP-Program-Information/By-Topics/Data-and-Systems/ICD-Coding/Downloads/icd-10-implementation-assistance-handbook.pdf.
ICD, International Classification of Diseases.
* For the “Medical Surgical” codes.
TABLE 17-3 Countries That Use ICD-10 Codes
YEAR ADOPTED COUNTRY
1994 to 1997 Scandinavian countries (Denmark, Finland, Iceland, Norway, Sweden)
1995 United Kingdom
1997 France
1998 Australia
1999 Belgium
2000 Germany
2001 Canada
2014 or 2015 (projected) United States
Original compliance date was October 1, 2013
• AMA and HHS requested delay to October 1, 2014, but this will probably be extended to 2015
Adapted from Brooks P (2010) ICD-10 Overview. http://www.cms.gov/Medicare/Medicare-Contracting/ContractorLearningResources/downloads/ICD-10_Overview_Presentation.pdf, slide 15. 2010.
A major stumbling block to EBP is the continuous discovery of new knowledge and the resulting changes to the recommended best practices guidelines 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 to meet some of the specific MU mandates, such as alerts for critical lab results or a history of MRSA (methicillin-resistant Staphylococcus aureus) 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.
•Defines local or facility-owned orderables (elements that can be ordered using computerized provider order entry, or CPOE) available at that setting.
•Triggers alerts and other CDS features based on locally built logic (rules). For instance, an alert may be triggered if (1) blood products are ordered on patients who request no blood products be administered, (2) pregnancy category teratogenic medications are ordered on patients of child-bearing age with an unknown pregnancy status, or (3) the potassium level is below a preset level on patients receiving digoxin medications.
•Collects detailed metrics for specific reports required to demonstrate meeting MU criteria. These reports address a variety of MU requirements such as patient education, smoking status assessment, native language, discharge instructions, deep vein thrombosis prophylaxis in select patient populations, and the use of thrombolytic and antithrombotic medications in stroke patients.
•Enables a more timely update of treatment plans based on best practices. The study Translating Research Into Practice (TRIP), conducted by researchers sponsored by the Agency for Healthcare Research and Quality (AHRQ) in 1999, concluded that it took an average of 10 to 20 years to incorporate new clinical findings into general clinical practice.10 This time lag between the discovery of new treatment options and the use of this new knowledge at the point of care is sometimes call the “fatal lag.” CDS and EBP are likely to accelerate the incorporation of new findings into clinical practice.
Patient Safety and Improved Quality of Care
Before MU rules were initiated most healthcare leadership and professionals cited patient safety as the primary reason for implementing an EHR, but it now may seem to some that the sole reason for implementing an EHR is to qualify for the incentive package. In response to this concern, leadership needs to communicate to staff that the primary deciding factors for implementing or upgrading an EHR include patient safety, improved quality of patient care, and efficiency. ARRA is not the reason for the implementation or upgrade but rather is the match that has ignited the process. Reinforcing this message on a regular basis through all the stages of the implementation cycle helps to counteract resistance to using the system due to major changes in workflows.
For example, EHRs help to decrease medication errors, especially if closed-loop bedside bar-coding medication administration is an integral piece of the system. 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 of the positive functionalities and advantages of the EHR, staff also need to be well informed on what the EHR cannot do.
Major implementations can include major pushbacks from hospital staff for a variety of reasons. A primary reason is that a major implementation often involves changes in workflows and processes. This will result 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, the individual practitioner may be more aware of the disadvantages for them as individuals. For example, with initial implementations that move processes from paper to computer, clinicians accustomed to writing orders quickly or checking off boxes on a preprinted order set often resist spending their time entering orders on a computer. Although more time is needed to enter orders electronically, other gains are made, such as a decrease in medication errors, reduced time between order entry and delivery of services, and a dramatic decrease in telephone calls from nursing and pharmacy to physicians about illegible or questionable orders.
In a paper world, some healthcare providers created their own personal order sets for their practice and titled them using their own name, such as Dr. Smith's Routine Admission Orders for Surgery. Once records become electronic, personalized order sets are discouraged. Each specialty should collaborate to create a single 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 nightmare 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.11
The number of unnecessary verbal or telephone orders has long been a major patient safety issue even though certifying organizations voice strong warnings against using them too often for convenience reasons. The Joint Commission (TJC) has a standard requiring that all verbal and telephone orders be recorded and “read back” to the ordering healthcare provider.12 This scenario exemplifies another source of clinician frustration because the clinician must remain on the telephone while the person recording the verbal order retrieves the electronic record, enters it into the system, goes through all prompts, and reads the order back to the ordering practitioner. One study examined the number of verbal and telephone orders pre-CPOE and post-CPOE and reported a 12% reduction in the number of verbal orders and a 34% decrease in unsigned verbal orders after implementation.13
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, Sittig, Dykstra, Campbell, and Guappone identified nine types of unintended consequences and corresponding interventions to minimize each of these risks.14 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 best practices for a successful implementation discussed below.15 Weiner, Kfuri, Chan, and Fowles coined a new term, e-iatrogenesis, to describe the most critical of the new type of errors seen in EHRs.16 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 to 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.17
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 in their EHRs.
New Implementation Versus an Upgrade
Once the decision has been made that a major change is needed in the current information system, the next question is whether to upgrade or implement a new system. Answering the question “do we need to make a change?” begins to answer the follow-up question: “What specific changes are needed?” The institution or healthcare provider should begin by determining what level or degree of change is needed to achieve MU. If there already is a well-established homegrown system, it usually is wiser to upgrade. However, this can best be determined by using the EACH process.
Decision Factors to Implement or Upgrade a System
Many competing factors must be evaluated in deciding whether to implement a new system or upgrade the current system.
Sufficient Resources
The three major resources that will have the most impact on this decision are staff, budget, and physical or environmental constraints. Having a sufficient number of available and knowledgeable staff with the specific skill sets needed for each step in the process is imperative to the success of the project. The needed skill sets relate to the following:
•Installing and testing new hardware, software, and wireless networks
•Designing, building, and modifying applications
•Testing new applications and interfaces
•Providing staff education and support
•Maintaining hardware, software, and wireless networks.
The project manager will usually create a grid of all resource assignments for easy tracking and reference. Regardless of the type of project, informatics projects are expensive and often incur unexpected costs for unexpected items such as adding computer memory, upgrading wireless systems, and developing new interfaces. Funds must be allocated for staff, servers, hardware such as new computers, scanners, printers, wiring, antennas, training rooms, software, and postlive vendor support. Physical requirements may include creating additional space in the clinical units, patient rooms, dictation areas, doctor lounges, etc.
Risk Factors
A good project plan identifies all probable and possible risk factors that may interfere with achieving a successful project completed on time, with sufficient quality, and within budget. A risk management plan lists corresponding reasonable strategies to mitigate the identified risks. Some risk factors can be anticipated with plans to minimize their effect, such as an upcoming accreditation inspection, the possibility of a strike by workers, new construction, and remodeling. Unexpected risk factors may be a loss of key project players, a publicized sentinel event, or a natural disaster in the area.
Scope Creep
Scope creep is one of the most frequent causes of project delays. Scope creep occurs when requirements are added after the initial project is defined and those added requirements are substantial enough to affect the project timeline. Well-defined objectives for the parameters of the project and strong project management can help to minimize scope creep. However, even with the best planning some informatics projects must be expanded for valid yet unanticipated reasons. There are several reasons for scope creep. Sometimes users do not understand the product until they interact with it. They then realize that the system will not meet their needs, creating an impetus to incorporate changes in the product and project plan. Likewise, the extent of workflow changes may not be apparent until the EHR is piloted. Sometimes projects that begin as an upgrade shift to the implementation of a totally new system due to changes in leadership and management, new regulations, and new enhancements or options that are now viewed as critical.
Best of Breed versus an Integrated Health System
There are two approaches to implementing an EHR: (1) best of breed and (2) monolithic or fully integrated EHR. The best of breed approach involves reviewing several vendors for their “best” module or application, such as an admission, discharge, and transfer (ADT) system or emergency department module. Then multiple modules are purchased from different vendors to create a full suite of functions. Purchase decisions are based on each module's or application's most desired or robust features and connectivity capabilities. This approach typically provides the customer with tools to customize the application according to local, specialized needs. Vendors typically incorporate enhancement requests more quickly in a hot fix (fast fix), through software patches (fixes), or in the next version. Both of these advantages can be important to large medical or research-intensive university centers. The disadvantages to this approach are the need for multiple complex interfaces to integrate all of the products; the need for highly skilled and specialized IT staff to support the different interfaces; and the existence of various hardware platforms and operating systems that may be on different versions of software and therefore complicate integration. Lastly, each module may have a different user interface, meaning that each application looks and acts differently to the end users. All of these factors make the best of breed approach more expensive and resource intensive but it is frequently selected by large medical, university, and research medical centers.
A monolithic or fully integrated health information system is an electronic health record system that includes a suite of modules to support care. It is typically easier to install and easier to support and usually has a similar-looking user interface across modules, which helps users to learn the EHR more quickly. Because all applications share a common database, the information exchange among the modules is quicker. The initial installation is frequently faster and less expensive because a scaled-down IT department is required at the local site. Smaller medical facilities and those not wanting large IT departments tend to favor this approach. The downside is that the system may not have specific features that the health facility needs and vendors often have applications that are excellent for some areas and less optimal for others. In addition, the customer cannot easily customize the system without assistance from the vendor, which may involve a work order and additional cost. System changes can incur long delays from large vendors as they prioritize changes across many clients. For example, orders for TPN (total parenteral nutrition) are generally customized to the patient's needs and are difficult to construct for CPOE (computerized provider order entry). Thus TPN orders may remain on paper and be faxed to the Pharmacy department. Of course, having both paper and electronic orders creates a fragmented health record, potential safety issues, and issues with workflow.
Opportunities for Improvement
The decision to implement a new system or to upgrade an existing one provides an opportunity to increase patient safety and quality of care, enhance communication, increase EBP, and create more efficient workflows and processes. A new system allows the organization to thoroughly evaluate, correct, and clean up a current database to address common issues such as misspellings, order names that do not comply with established naming conventions, and the addition of helpful aliases for orders. In most scenarios multiple analysts will build the EHR system, especially in a multifacility enterprise. The IT team, which includes members with technical and clinical expertise, must emphasize that all analysts use the same style, such as a specified naming convention and uniform data assays (or elements), so that all orders or charting screens have a consistent look and feel. Defining a naming convention includes decisions about details such as building applications using all capitals or mixed case and commas versus dashes, colon or a space, and an understanding to not use specific special characters, such as semi-colons, ampersands, or backward slashes, in order names that may be misinterpreted as a part of a Health Level Seven (HL7) message. Sometimes order names were originally built in an ancillary system such as a laboratory or radiology system and abbreviated with archaic or cryptic acronyms that are understood only by that department but are not meaningful to the clinician. These department-specific systems were likely stand-alone applications that did not interface with other applications. Once they are integrated, older department-specific orders need to be reviewed and renamed to be more user-friendly to clinicians. When different builders are constructing new orders and not adhering to a naming convention over the lifespan of the CPOE application, the orderables cannot be found easily by clinicians. For example, radiology may have orders that start with a modality like “CT Head w Cont.” Other computed tomography (CT) orders may start with the body part, as in “Head CT w/o Cont.” Some orders may spell out “with” or abbreviate it using “w” or “w/.” This lack of standardization can result in alphabetized lists that clinicians do not understand, long search times by clinicians, and sending incorrect orders to radiology. This issue is very important in CPOE applications because orders will not line up alphabetically when a clinician searches for “CT HEAD” if dashes, colons, or spaces are used inconsistently.
A common mistake in the implementation of a new EHR is replacing a legacy system but designing the new system with old workflows and processes. Organizations should resist building a new system to imitate the current system or current workflows; rather, they should evaluate the system and transform to more updated evidence-based efficient processes. If this is ignored, a risk exists that the new EHR will merely automate and magnify broken processes that exist in the current organization and system.
Another improvement that often accompanies a new implementation or an upgrade is the introduction of more advanced decision support features not available in the older system. Features not available in older EHRs typically are duplicate order checking; codified (coded) allergies; allergy checking against medication and diet orders; drug–drug, drug–food, and drug–diagnosis interactions; dose checking; weight-based medication dosages; suggested drug level monitoring; automatic discontinuation of controlled substances; and the display of critical lab values during order entry before orders are placed. Older pharmacy systems performed these checks after order entry, requiring the pharmacist to contact the ordering healthcare provider when alerts were displayed, thereby delaying the first medication dose to the patient. More recent EHRs employ logic, allowing the institution to create rule-based logic for specific scenarios or variables, such as patient gender, age, weight, diagnosis, patient location, active order list, and other miscellaneous attributes. Examples of rule-based logic follow:
•Patient allergies and the patient's height and weight must be entered in the system before orders on a patient are entered but can be overridden in emergencies
•An alert is triggered when a provider orders a blood product be administered to a patient who is a Jehovah's Witness
•An alert is triggered when a clinician orders a radiology test that requires contrast on a patient with a documented allergy to iodine
Implementation and the Systems Life Cycle
Successful implementations follow the systems life cycle introduced in Chapter 2. To summarize, the main phases of the systems life cycle are as follows:
•Analyze: The existing environment and systems are evaluated. Major problems and deficiencies are identified using informal or formal methods. A needs assessment is developed. Gaps are noted and current capabilities and limitations are outlined. Initial user and system requirements are formulated.
•Plan: The proposed system is planned comprehensively. Planning includes strategic levels, such as whether the system will be developed internally, purchased and tailored, or designed and developed jointly with a vendor.
•Develop or purchase: At this stage either the system is purchased or the new system development begins. New components and programs are obtained and installed. For vendor-supported solutions, extensive tailoring occurs.
•Test: At this stage extensive testing occurs just before Stage 5 and “go” or “no go” decisions are made about deadlines. Toward the end of this phase, marketing and communication efforts are accelerated to make users aware of the impending change.
•Implement or go-live: The system is implemented using a selected method best suited to the organization and its tolerance for risk. User training is completed.
•Maintain and evolve: Once the system has been formally acknowledged as passing user acceptance testing, typically at 90 or 120 days after go-live, it enters a maintenance phase.
•Evaluate: Activities in each phase are assessed for their quality and effectiveness.
For purposes of discussion, Chapter 16 assumes that the institution would purchase a new system. This chapter follows up after that point by presenting reasons to upgrade. Once an option is selected, the institution will move forward to the implementation phase of the systems life cycle.
Project Planning
The process of project planning occurs throughout the systems life cycle. Two key points in the life cycle when planning becomes more intense are (1) the planning required for system selection and (2) the planning required for system implementation. Chapter 16 discusses planning related to system selection. In this chapter the discussion focuses on the process of project planning as it relates to system implementation. Students interested in more information about project planning and project management principles can consult the Project Management Institute (www.pmi.org) or a project management text. Large organizations typically employ a project manager certified in project management techniques.
Defining Success
One of the first planning steps includes defining the project and its success factors. Before an implementation can be called a success, the term success must be defined using measurable terms or goals. An example might be reducing medication errors by 15% by installing medication and bar-coding applications. Any required baseline metrics should be determined and measured before implementation if post go-live comparisons are required (Box 17-1). Other examples are pre and post statistics for the number of pharmacy callbacks to physicians; the volume of nonformulary medications; and the time between order entry and first medication dose, especially for critical medications such as tissue plasminogen activator (tPA); the time between “stat” order entry and order completion; the percentage of suspected acute myocardial infarction patients who receive aspirin within 24 hours before or after arrival at the emergency department; the number of duplicate laboratory or radiology orders; and the number of verbal or telephone orders with a documented read-back.18
Box 17-1 Factors for a Successful Electronic Health Record (EHR) Implementation
• Project team defines a clear scope of the project.
• Senior leadership, clinical leaders, and EHR champions provide enthusiastic and unwavering support for the project.
• Employ a health IT professional to lead the project and be sure to have adequate resources.
• Solicit input from representatives from each discipline at every stage of the initiative.
• Have default clinical information and responses to order prompts on orders and fill in as much as possible on order sets.
• Consider mandatory use of computerized provider order entry (CPOE).
• Educate users, particularly physicians, on the trade-off of initial reduced productivity and time to perform ordinary tasks such as order entry with long-term positive gains of reduced callbacks, reduced time between order entry and first dose medications and “stat” orders, and “everywhere” access to the chart. If clinicians understand and are educated on why the change was made, they tend to be accepting of the change.
• Examine and develop collaborative detailed plans for the anticipated changes in current workflows early in the project with a sign-off from each user group.
• Provide one-on-one education to physicians and a dedicated physician liaison.
• TEST, TEST, TEST the system from every user's perspective.
• TRAIN, TRAIN, TRAIN: Provide ample education to IT staff and end-users.
• Use the “train the trainer” approach for maximum mileage.
• Use superusers for go-live and post go-live support.
• Provide abundant support during go-live and 7 to 10 days following go-live.
• Anticipate user resistance and plan for it.
• Possess an understanding that there is no finish line for EHR maintenance.
• Have a strong resolve, knowing that the project will be difficult.
Whether undertaking a new implementation or an upgrade, organizations will want to adhere to solid project management principles, such as the use of a project plan. It is essential that the implementation team creates a comprehensive and detailed project plan that includes all of the critical milestones, assumptions, and tasks with target dates and assigned resources. The project plan can be created using Microsoft Office Excel but most facilities use more sophisticated applications specifically designed for project planning, such as Microsoft Office Project (Fig. 17-1). The project plan includes resources across the organization in IT and clinical and the use of superusers. Superusers are selected staff who receive extra training and help to provide additional support during the go-live process.
Facilities should develop a go-live theme, such as giving the implementation project an official name and a slogan, reference the project name each time the implementation is discussed, and start early with a slogan and use it continuously throughout the project for activities such as project marketing with pamphlets, posters, flyers, and announcements. Some organizations will also select a color scheme and use it for all publicity, communications, updates, banners, posters, table tents, and T-shirts or buttons that support staff may wear during the go-live. Large facilities will have a marketing plan for the project, especially closer to go-live.
Executive Management Support
A second planning step includes eliciting the support of organization executives. One of the key factors for a successful implementation or upgrade is public attestation and repeated unwavering support for the project by the executive team. This kind of support is needed from the project's kickoff day to after go-live. Leaders need to communicate this message to the organization at every possible opportunity and on a regular basis.19,20 This commitment is especially critical when users, particularly physicians, repeatedly escalate EHR issues, such as difficulties with CPOE, to the executive suite with requests that could undermine the project. Regarding issues with CPOE, some healthcare organizations mandate that physicians enter orders into CPOE modules with a few well-defined exceptions. Organizations that have more success with such mandates include those that employ a large percentage of physicians, such as the military and Veterans Health Administration. Other tactics used to deal with CPOE resistance include policies that instruct nurses and unit secretaries to inform physicians that they are not allowed to enter orders on a physician's behalf. However, if the physician submits a complaint against a staff member as a result, executive management must support this policy when challenged.
Engage Stakeholders
Another important factor in planning is to solicit input from representatives in every discipline from the beginning and continue to inform them of the progress of the project.21 Informatics governance structures discussed in Chapter 10 provide representation for stakeholder groups. Savvy implementers will ensure that voices from each group are heard. One of the most effective methods for engaging stakeholders is to involve them in the analysis of current workflow processes and the redesign of those processes.
Redesigned Workflows
As mentioned earlier, a new system will change the current workflows, processes, and policies. Redesigned workflows require preparation so that professional practice processes match the available EHR functions. This early work is imperative to preclude modified workflows or negative workarounds (a method used to circumvent a problem without solving it). New policies need to be adopted for new workflows. All current workflows and processes need to be assessed in successful implementations. The best approach to obtaining this information is to schedule separate meetings with representatives from each department, being certain to include unit secretaries, who frequently know the unofficial workarounds. Actual end-users are important to include in the process. While department or unit managers can easily provide the organization's approved workflows and processes,
FIG 17-1 Sample timeline. The timeline in its entirety is posted with the Evolve resources for this chapter. CPOE, Computerized provider order entry.
(Copyright McKesson Corporation.)
they may not be aware of the unofficial workarounds used by the staff. In short, the goals of scheduled meetings with each department are to identify all current official and unofficial workflows and processes and to plan the future workflows and processes using the EHR's new functionalities so that users can anticipate how their jobs will change. At these separate meetings the areas of overlap or instances where workflow moves from one department to another should be noted. These can be critical and sometimes difficult points in planning a redesigned workflow. Redesigned workflows and planned changes must be included and thoroughly reviewed in all end-user training classes.
Building or Tailoring the Product
Once the current workflow is understood and redesigned, teams work to build or tailor the EHR to match the new workflow. Typically, clinical analysts work with vendor analysts to tailor a product for the current environment or actual end-users may be involved in the process. At a minimum, once a module is initially tailored analysts have end-users assess the module in an iterative fashion. The following tips can be useful in this design process:
•Design and build the system to keep the number of clicks and amount of scrolling to an absolute minimum. Physicians in particular will calculate the time it takes to perform common tasks. Excess clicking can be a huge user dissatisfier and can discourage users. To avoid excessive clicks, implementation analysts often use what is commonly referred to as the 80/20 rule. The term 80/20 refers to a mathematical formula proposed by an Italian economist in 1906 that states that 80% of our results or outcomes are derived from 20% of our efforts or causes.22 An example of applying the 80/20 rule in health informatics is to assign default responses when a specific response is selected 80% of the time. For instance, builders will prefill as many of the fields as possible in order entry with prompts such as “Routine” for the priority and “Once” for the frequency for all laboratory and radiology orders to facilitate faster order entry. The underlying rule is to minimize all keystrokes and excessive scrolling whenever possible. Default settings can be especially useful in saving time but they also need to be evaluated carefully to ensure that they do not increase safety issues.
TABLE 17-4 Different Types of Testing during an Implementation and Post Go-Live
Chapter 17 Implementing and Upgrading an Information System Solution
Christine D. Meyer
No matter whether the electronic health record (EHR) is new or an upgrade, the ultimate goal in implementations is to provide the highest level of care at the lowest cost with the least risk.
Objectives
At the completion of this chapter the reader will be prepared to:
1.Discuss the regulatory and nonregulatory reasons for implementing or upgrading an electronic information system
2.Compare the advantages and disadvantages of the “best of breed” and integrated system approaches in selecting healthcare information system architecture
3.Explain each step in developing an implementation plan for a healthcare information system
4.Develop strategies for the successful management of each step in the implementation of a healthcare information system
5.Analyze the benefits of an electronic information system with an integrated clinical decision support system
6.Explain the implications of unintended consequences or e-iatrogenesis as it relates to implementing an electronic health record (EHR)
Key Terms
Best of breed, 277
Big bang, 284
Phased go-live, 284
Scope creep, 276
Tall Man lettering, 276
Workarounds, 279
Abstract
The decision to implement a new electronic health record (EHR) or to upgrade a current system is based on several factors, including providing safe and up-to-date patient care, meeting federal mandates and Meaningful Use requirements, and leveraging advanced levels of clinical decision support. Implementing EHRs entails multilayered decisions at each stage of the implementation. Major decisions include evaluating vendor and system selection, determining go-live options, redesigning workflow, and developing procedures and policies. The timeline and scope of the project is primarily dictated by expenses, staff, resources, and the drop-dead date for go-live. Success depends on variables such as a well-thought-out and detailed project plan with regular review and updating of the critical milestones, unwavering support from the organization's leadership, input from users during the design and build phases, mitigation of identified risk factors, and control of scope creep. The implementation of an EHR is never finished. Medication orders, nonmedication orders, and documentation screens or fields will continuously need to be added, modified, or inactivated; patches will be installed and tweaks to workflows and functionality will be ongoing.
Introduction
This chapter focuses on the implementation of healthcare information systems. Of course, many different types of applications are used within a healthcare information system. The general principles for implementing these many different applications are the same; however, for the purposes of discussion this chapter will focus mainly on the implementation of an electronic health record (EHR) to demonstrate these general principles. In 2004 President George W. Bush promoted the idea of a fully functional electronic medical record (EMR) for Americans within 10 years.1 This proposal officially initiated the massive changes that we are now witnessing in health informatics. Healthcare information systems are widely used today in many diverse settings. Small hospitals, ambulatory clinics, and small physician practices generally implement a simple and streamlined system with limited features but tailored for quicker implementation and easier long-term maintenance. Large medical centers, multifacility enterprises, and multiphysician practices with more complex needs typically opt to install a more robust system that allows for customizations. However, there are still hospitals and physician practices without an EHR or that have an outdated system that cannot accommodate recent regulatory mandates. An outdated system may be one reason to implement or upgrade a health information technology (health IT) solution, but there are others.
Reasons to Implement or Upgrade a Healthcare Information System
There are several reasons why a health organization (hospital organization, physician office, or clinic) may decide that a major change is needed. A careful review of the reasons for the change will start the process of deciding whether to install a new information system or upgrade the current system. One of the primary reasons for making such a major change is changing government regulations.
The American Recovery and Reinvestment Act (ARRA)
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 is that each person in the United States would have a certified health record by 2014, including the electronic exchange of health information across healthcare institutions to improve quality of healthcare. As discussed in detail in Chapters 24 and 25, the HITECH Act created a $27 billion federally funded incentive program providing Medicare and Medicaid payments over 5 to 10 years to three groups: (1) eligible providers (EP), (2) eligible hospitals (EH), and (3) Critical Access Hospitals (CAH). CAH are defined as rural hospitals certified to receive cost-based reimbursement from Medicare. Within the HITECH Act there are two EHR incentive programs: the Medicare EHR Incentive Program administered by the Centers for Medicare & Medicaid Services (CMS) and the Medicaid EHR Incentive Program, which is governed by individual states and territories.
It is important to note that these incentive programs were not established to cover the cost of implementing an EHR system but to encourage or “incentivize” healthcare organizations and healthcare providers to use an EHR in a meaningful way, called Meaningful Use (MU), and to foster much-needed faster adoption across the nation.2 Additional requirements include the submission of detailed and timely reports to CMS and the states demonstrating MU adoption. Other terms often used for this incentive program are “stimulus funds,” “stimulus package,” or simply “ARRA funds.”3
To meet these MU requirements an EHR should 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) Authorized Testing and Certification Body. Complete EHR certification means that the system has the functionality, required data elements, and logic to support ambulatory, emergency room, outpatient, and inpatient MU requirements. EHR module certification means that the ancillary application meets one or more requirements. Most hospitals and physician offices purchase a commercial system that is deemed certified, meaning that the vendor incorporated these essential capabilities. A search engine providing a list of certified products can be found at http://oncchpl.force.com/ehrcert?q=chpl and each product has links to other pages that include information about that product.
MU criteria do not require purchasing a commercial, certified product. Hospitals and eligible providers may have developed their own “homegrown” EHRs that may or may not include commercial components, and have no need to purchase a new product. For example, legacy systems at Intermountain Healthcare and the Regenstrief Institute are accepted systems developed over decades.4 CMS welcomes organizations to certify their systems using the three-step EHR Alternative Certification for Healthcare Providers (EACH) program established by the Certification Commission for Health Information Technology (CCHIT). The three-step process provides a mechanism to determine whether the system measures up to U.S. Department of Health & Human Services (HHS) requirements to support MU and to obtain certification for an existing EHR system that is not already covered by a vendor certification. Major medical centers that successfully opted for this alternative include Health Management Associates, New York University, Langone Medical Center, Northwestern University, Tenet Health System, and Medical University of North Carolina.4
A 2011 survey conducted by the American Hospital Association found that the percentage of U.S. hospitals that had adopted EHRs more than doubled from 16% to 35% between 2009 and 2011. Moreover, 85 percent of hospitals report that they intend to take advantage of the incentive payments made available through the Medicare and Medicaid EHR Incentive Programs by 2015.5
The Transition from ICD-9-CM to ICD-10-CM Codes and from HIPAA Version 4010 to HIPAA Version 5010
Complicating implementation of the MU criteria is the change in the International Classification of Diseases (ICD) coding. ICD-10-CM is a U.S. modification of the tenth revision of the International Classification of Diseases, which is used to report medical care and cause of deaths, process payments, calculate trends, and perform statistical analyses. Older versions of healthcare information systems cannot adopt the new ICD-10-CM codes because they were configured to accept the old ICD-9-CM codes consisting of three to five numeric-only characters. The ICD-10-CM codes have three to seven characters. Making things even more complex, the first and third characters are always alpha characters, the second character is always numeric, and characters four through seven can be either alpha or numeric.6 The ICD-9-CM system has 17,000 codes to define diagnoses and procedures. In contrast, the ICD-10-CM version contains 155,000 codes, which allows for a more detailed definition and better reporting for reimbursement and biosurveillance (Tables 17-1 and 17-2).7 The United States lags behind other countries in implementation of ICD-10 codes. Already, 138 other countries are using ICD-10 codes to track mortality and 99 countries are using these codes to track morbidity (Table 17-3).6 The original deadline for adopting ICD-10-CM codes was October 1, 2011. However, the Secretary of Health & Human Services delayed the mandatory adoption of ICD-10-CM until October 1, 2014.
In addition, all health plans, healthcare providers, and clearinghouses that conduct business electronically were required to convert to the Health Insurance Portability and Accountability Act (HIPAA) standard for electronic transactions: Version 5010. Failure to comply means that any electronic transactions using the old Version 4010 standard form that were submitted to CMS as of June 30, 2012, were rejected. The upgrade to Version 5010 is also important because the new version is able to accommodate the forthcoming and mandatory ICD-10-CM and ICD-10-PCS code sets.
TABLE 17-1 Comparison of ICD-9-CM and ICD-10-CM Codes
CHARACTERISTIC
ICD-9-CM
ICD-10-CM
Field Length
3-5 characters
3-7 characters
Available Codes
Approximately 13,000 codes
Approximately 68,000 codes
Code Composition (i.e., Numeric, Alpha)
Digit 1 = alpha or numeric
Digits 2-5 = num
Digit 1 = alpha
Digit 2 = numeric
Digits 3-7 = alpha or numeric
Character Position within Code
Characters 1-3 = Category
Characters 4-5 = Anatomic site, etiology, manifestation*
Characters 1-3 = Category
Characters 4-6 = Anatomic site, etiology, severity, or clinical detail†
Character 7 = Extension
Available Space for New Codes
Limited
Flexible
Overall Detail Embedded within Codes
Ambiguous
Very Specific
Laterality
Does not identify right vs. left
Often identifies right versus left
Sample Code
438.11, Late effect of cerebrovascular disease, speech and language deficits, aphasia
I69.320, Speech and language deficits following cerebral infarction, aphasia following cerebral infarction
From ICD-10 State Medicaid Readiness Medicaid ICD10 Implementation Handbook.docx. Retrieved January 14, 2013 from http://www.medicaid.gov/Medicaid-CHIP-Program-Information/By-Topics/Data-and-Systems/ICD-Coding/Downloads/icd-10-implementation-assistance-handbook.pdf.
ICD, International Classification of Diseases.
* Not always the case for ICD-9-CM.
† Not always the case for ICD-10.
Best Practices: Evidence-Based Content and Clinical Decision Support (CDS) Systems
With each new release, information systems are more robust, enabling them to incorporate evidence-based content (called evidenced-based practice or EBP) and to use clinical decision support (CDS) features in the system. Detailed information is included in Chapter 3; however, one of the most frequently quoted definitions for EBP is one proposed by Sackett, Rosenberg, Gray, Haynes, and Richardson: 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.”8(p71) 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.”9(p7)
TABLE 17-2 Comparison of ICD-9-CM and ICD-10-PCS Codes
CHARACTERISTIC
ICD-9-CM
ICD-10-PCS
Field Length
3-4 characters
7 alpha-numeric characters; all are required
Available Codes
Approximately 3,000
Approximately 72,081
Technology
Based on outdated systems
Consistent with current medical technology and advances
Available Space for New Codes
Limited
Flexible
Overall Detail Embedded within Codes
Ambiguous
Very Specific
Precisely defines procedures with detail regarding anatomic site, approach, device used, and qualifying information
Laterality
Code does not identify right vs. left
Code identifies right versus left
Terminology for Body Parts
Generic description
Detailed description
Procedure Description
Lacks description of approach for procedures
Detailed description of approach for procedures. Precisely defines procedures with detail regarding anatomic site, approach, device used, and qualifying information
Character Position within Code
N/A
There are 16 PCS sections that identify procedures in a variety of classifications (e.g., medical surgical, mental health, etc.). Between these sections, there may be variations in the meaning of various character positions, though the meaning is consistent within each section. For example, in the Medical Surgical section, Character 1 = Name of Section* Character 2 = Body System* Character 3 = Root Operation* Character 4 = Body Part* Character 5 = Approach* Character 6 = Device* Character 7 = Qualifier*
Example Code Laparoscopic Appendectomy
47.01
ODTJ4ZZ
From ICD-10 State Medicaid Readiness Medicaid ICD10 Implementation Handbook.docx. Retrieved January 14, 2013 from http://www.medicaid.gov/Medicaid-CHIP-Program-Information/By-Topics/Data-and-Systems/ICD-Coding/Downloads/icd-10-implementation-assistance-handbook.pdf.
ICD, International Classification of Diseases.
* For the “Medical Surgical” codes.
TABLE 17-3 Countries That Use ICD-10 Codes
YEAR ADOPTED
COUNTRY
1994 to 1997
Scandinavian countries (Denmark, Finland, Iceland, Norway, Sweden)
1995
United Kingdom
1997
France
1998
Australia
1999
Belgium
2000
Germany
2001
Canada
2014 or 2015 (projected)
United States
• Original compliance date was October 1, 2013
• AMA and HHS requested delay to October 1, 2014, but this will probably be extended to 2015
Adapted from Brooks P (2010) ICD-10 Overview. http://www.cms.gov/Medicare/Medicare-Contracting/ContractorLearningResources/downloads/ICD-10_Overview_Presentation.pdf, slide 15. 2010.
A major stumbling block to EBP is the continuous discovery of new knowledge and the resulting changes to the recommended best practices guidelines 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 to meet some of the specific MU mandates, such as alerts for critical lab results or a history of MRSA (methicillin-resistant Staphylococcus aureus) 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.
•Defines local or facility-owned orderables (elements that can be ordered using computerized provider order entry, or CPOE) available at that setting.
•Triggers alerts and other CDS features based on locally built logic (rules). For instance, an alert may be triggered if (1) blood products are ordered on patients who request no blood products be administered, (2) pregnancy category teratogenic medications are ordered on patients of child-bearing age with an unknown pregnancy status, or (3) the potassium level is below a preset level on patients receiving digoxin medications.
•Collects detailed metrics for specific reports required to demonstrate meeting MU criteria. These reports address a variety of MU requirements such as patient education, smoking status assessment, native language, discharge instructions, deep vein thrombosis prophylaxis in select patient populations, and the use of thrombolytic and antithrombotic medications in stroke patients.
•Enables a more timely update of treatment plans based on best practices. The study Translating Research Into Practice (TRIP), conducted by researchers sponsored by the Agency for Healthcare Research and Quality (AHRQ) in 1999, concluded that it took an average of 10 to 20 years to incorporate new clinical findings into general clinical practice.10 This time lag between the discovery of new treatment options and the use of this new knowledge at the point of care is sometimes call the “fatal lag.” CDS and EBP are likely to accelerate the incorporation of new findings into clinical practice.
Patient Safety and Improved Quality of Care
Before MU rules were initiated most healthcare leadership and professionals cited patient safety as the primary reason for implementing an EHR, but it now may seem to some that the sole reason for implementing an EHR is to qualify for the incentive package. In response to this concern, leadership needs to communicate to staff that the primary deciding factors for implementing or upgrading an EHR include patient safety, improved quality of patient care, and efficiency. ARRA is not the reason for the implementation or upgrade but rather is the match that has ignited the process. Reinforcing this message on a regular basis through all the stages of the implementation cycle helps to counteract resistance to using the system due to major changes in workflows.
For example, EHRs help to decrease medication errors, especially if closed-loop bedside bar-coding medication administration is an integral piece of the system. 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 of the positive functionalities and advantages of the EHR, staff also need to be well informed on what the EHR cannot do.
Major implementations can include major pushbacks from hospital staff for a variety of reasons. A primary reason is that a major implementation often involves changes in workflows and processes. This will result 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, the individual practitioner may be more aware of the disadvantages for them as individuals. For example, with initial implementations that move processes from paper to computer, clinicians accustomed to writing orders quickly or checking off boxes on a preprinted order set often resist spending their time entering orders on a computer. Although more time is needed to enter orders electronically, other gains are made, such as a decrease in medication errors, reduced time between order entry and delivery of services, and a dramatic decrease in telephone calls from nursing and pharmacy to physicians about illegible or questionable orders.
In a paper world, some healthcare providers created their own personal order sets for their practice and titled them using their own name, such as Dr. Smith's Routine Admission Orders for Surgery. Once records become electronic, personalized order sets are discouraged. Each specialty should collaborate to create a single 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 nightmare 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.11
The number of unnecessary verbal or telephone orders has long been a major patient safety issue even though certifying organizations voice strong warnings against using them too often for convenience reasons. The Joint Commission (TJC) has a standard requiring that all verbal and telephone orders be recorded and “read back” to the ordering healthcare provider.12 This scenario exemplifies another source of clinician frustration because the clinician must remain on the telephone while the person recording the verbal order retrieves the electronic record, enters it into the system, goes through all prompts, and reads the order back to the ordering practitioner. One study examined the number of verbal and telephone orders pre-CPOE and post-CPOE and reported a 12% reduction in the number of verbal orders and a 34% decrease in unsigned verbal orders after implementation.13
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, Sittig, Dykstra, Campbell, and Guappone identified nine types of unintended consequences and corresponding interventions to minimize each of these risks.14 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 best practices for a successful implementation discussed below.15 Weiner, Kfuri, Chan, and Fowles coined a new term, e-iatrogenesis, to describe the most critical of the new type of errors seen in EHRs.16 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 to 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.17
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 in their EHRs.
New Implementation Versus an Upgrade
Once the decision has been made that a major change is needed in the current information system, the next question is whether to upgrade or implement a new system. Answering the question “do we need to make a change?” begins to answer the follow-up question: “What specific changes are needed?” The institution or healthcare provider should begin by determining what level or degree of change is needed to achieve MU. If there already is a well-established homegrown system, it usually is wiser to upgrade. However, this can best be determined by using the EACH process.
Decision Factors to Implement or Upgrade a System
Many competing factors must be evaluated in deciding whether to implement a new system or upgrade the current system.
Sufficient Resources
The three major resources that will have the most impact on this decision are staff, budget, and physical or environmental constraints. Having a sufficient number of available and knowledgeable staff with the specific skill sets needed for each step in the process is imperative to the success of the project. The needed skill sets relate to the following:
•Installing and testing new hardware, software, and wireless networks
•Designing, building, and modifying applications
•Testing new applications and interfaces
•Providing staff education and support
•Maintaining hardware, software, and wireless networks.
The project manager will usually create a grid of all resource assignments for easy tracking and reference. Regardless of the type of project, informatics projects are expensive and often incur unexpected costs for unexpected items such as adding computer memory, upgrading wireless systems, and developing new interfaces. Funds must be allocated for staff, servers, hardware such as new computers, scanners, printers, wiring, antennas, training rooms, software, and postlive vendor support. Physical requirements may include creating additional space in the clinical units, patient rooms, dictation areas, doctor lounges, etc.
Risk Factors
A good project plan identifies all probable and possible risk factors that may interfere with achieving a successful project completed on time, with sufficient quality, and within budget. A risk management plan lists corresponding reasonable strategies to mitigate the identified risks. Some risk factors can be anticipated with plans to minimize their effect, such as an upcoming accreditation inspection, the possibility of a strike by workers, new construction, and remodeling. Unexpected risk factors may be a loss of key project players, a publicized sentinel event, or a natural disaster in the area.
Scope Creep
Scope creep is one of the most frequent causes of project delays. Scope creep occurs when requirements are added after the initial project is defined and those added requirements are substantial enough to affect the project timeline. Well-defined objectives for the parameters of the project and strong project management can help to minimize scope creep. However, even with the best planning some informatics projects must be expanded for valid yet unanticipated reasons. There are several reasons for scope creep. Sometimes users do not understand the product until they interact with it. They then realize that the system will not meet their needs, creating an impetus to incorporate changes in the product and project plan. Likewise, the extent of workflow changes may not be apparent until the EHR is piloted. Sometimes projects that begin as an upgrade shift to the implementation of a totally new system due to changes in leadership and management, new regulations, and new enhancements or options that are now viewed as critical.
Best of Breed versus an Integrated Health System
There are two approaches to implementing an EHR: (1) best of breed and (2) monolithic or fully integrated EHR. The best of breed approach involves reviewing several vendors for their “best” module or application, such as an admission, discharge, and transfer (ADT) system or emergency department module. Then multiple modules are purchased from different vendors to create a full suite of functions. Purchase decisions are based on each module's or application's most desired or robust features and connectivity capabilities. This approach typically provides the customer with tools to customize the application according to local, specialized needs. Vendors typically incorporate enhancement requests more quickly in a hot fix (fast fix), through software patches (fixes), or in the next version. Both of these advantages can be important to large medical or research-intensive university centers. The disadvantages to this approach are the need for multiple complex interfaces to integrate all of the products; the need for highly skilled and specialized IT staff to support the different interfaces; and the existence of various hardware platforms and operating systems that may be on different versions of software and therefore complicate integration. Lastly, each module may have a different user interface, meaning that each application looks and acts differently to the end users. All of these factors make the best of breed approach more expensive and resource intensive but it is frequently selected by large medical, university, and research medical centers.
A monolithic or fully integrated health information system is an electronic health record system that includes a suite of modules to support care. It is typically easier to install and easier to support and usually has a similar-looking user interface across modules, which helps users to learn the EHR more quickly. Because all applications share a common database, the information exchange among the modules is quicker. The initial installation is frequently faster and less expensive because a scaled-down IT department is required at the local site. Smaller medical facilities and those not wanting large IT departments tend to favor this approach. The downside is that the system may not have specific features that the health facility needs and vendors often have applications that are excellent for some areas and less optimal for others. In addition, the customer cannot easily customize the system without assistance from the vendor, which may involve a work order and additional cost. System changes can incur long delays from large vendors as they prioritize changes across many clients. For example, orders for TPN (total parenteral nutrition) are generally customized to the patient's needs and are difficult to construct for CPOE (computerized provider order entry). Thus TPN orders may remain on paper and be faxed to the Pharmacy department. Of course, having both paper and electronic orders creates a fragmented health record, potential safety issues, and issues with workflow.
Opportunities for Improvement
The decision to implement a new system or to upgrade an existing one provides an opportunity to increase patient safety and quality of care, enhance communication, increase EBP, and create more efficient workflows and processes. A new system allows the organization to thoroughly evaluate, correct, and clean up a current database to address common issues such as misspellings, order names that do not comply with established naming conventions, and the addition of helpful aliases for orders. In most scenarios multiple analysts will build the EHR system, especially in a multifacility enterprise. The IT team, which includes members with technical and clinical expertise, must emphasize that all analysts use the same style, such as a specified naming convention and uniform data assays (or elements), so that all orders or charting screens have a consistent look and feel. Defining a naming convention includes decisions about details such as building applications using all capitals or mixed case and commas versus dashes, colon or a space, and an understanding to not use specific special characters, such as semi-colons, ampersands, or backward slashes, in order names that may be misinterpreted as a part of a Health Level Seven (HL7) message. Sometimes order names were originally built in an ancillary system such as a laboratory or radiology system and abbreviated with archaic or cryptic acronyms that are understood only by that department but are not meaningful to the clinician. These department-specific systems were likely stand-alone applications that did not interface with other applications. Once they are integrated, older department-specific orders need to be reviewed and renamed to be more user-friendly to clinicians. When different builders are constructing new orders and not adhering to a naming convention over the lifespan of the CPOE application, the orderables cannot be found easily by clinicians. For example, radiology may have orders that start with a modality like “CT Head w Cont.” Other computed tomography (CT) orders may start with the body part, as in “Head CT w/o Cont.” Some orders may spell out “with” or abbreviate it using “w” or “w/.” This lack of standardization can result in alphabetized lists that clinicians do not understand, long search times by clinicians, and sending incorrect orders to radiology. This issue is very important in CPOE applications because orders will not line up alphabetically when a clinician searches for “CT HEAD” if dashes, colons, or spaces are used inconsistently.
A common mistake in the implementation of a new EHR is replacing a legacy system but designing the new system with old workflows and processes. Organizations should resist building a new system to imitate the current system or current workflows; rather, they should evaluate the system and transform to more updated evidence-based efficient processes. If this is ignored, a risk exists that the new EHR will merely automate and magnify broken processes that exist in the current organization and system.
Another improvement that often accompanies a new implementation or an upgrade is the introduction of more advanced decision support features not available in the older system. Features not available in older EHRs typically are duplicate order checking; codified (coded) allergies; allergy checking against medication and diet orders; drug–drug, drug–food, and drug–diagnosis interactions; dose checking; weight-based medication dosages; suggested drug level monitoring; automatic discontinuation of controlled substances; and the display of critical lab values during order entry before orders are placed. Older pharmacy systems performed these checks after order entry, requiring the pharmacist to contact the ordering healthcare provider when alerts were displayed, thereby delaying the first medication dose to the patient. More recent EHRs employ logic, allowing the institution to create rule-based logic for specific scenarios or variables, such as patient gender, age, weight, diagnosis, patient location, active order list, and other miscellaneous attributes. Examples of rule-based logic follow:
•Patient allergies and the patient's height and weight must be entered in the system before orders on a patient are entered but can be overridden in emergencies
•An alert is triggered when a provider orders a blood product be administered to a patient who is a Jehovah's Witness
•An alert is triggered when a clinician orders a radiology test that requires contrast on a patient with a documented allergy to iodine
Implementation and the Systems Life Cycle
Successful implementations follow the systems life cycle introduced in Chapter 2. To summarize, the main phases of the systems life cycle are as follows:
•Analyze: The existing environment and systems are evaluated. Major problems and deficiencies are identified using informal or formal methods. A needs assessment is developed. Gaps are noted and current capabilities and limitations are outlined. Initial user and system requirements are formulated.
•Plan: The proposed system is planned comprehensively. Planning includes strategic levels, such as whether the system will be developed internally, purchased and tailored, or designed and developed jointly with a vendor.
•Develop or purchase: At this stage either the system is purchased or the new system development begins. New components and programs are obtained and installed. For vendor-supported solutions, extensive tailoring occurs.
•Test: At this stage extensive testing occurs just before Stage 5 and “go” or “no go” decisions are made about deadlines. Toward the end of this phase, marketing and communication efforts are accelerated to make users aware of the impending change.
•Implement or go-live: The system is implemented using a selected method best suited to the organization and its tolerance for risk. User training is completed.
•Maintain and evolve: Once the system has been formally acknowledged as passing user acceptance testing, typically at 90 or 120 days after go-live, it enters a maintenance phase.
•Evaluate: Activities in each phase are assessed for their quality and effectiveness.
For purposes of discussion, Chapter 16 assumes that the institution would purchase a new system. This chapter follows up after that point by presenting reasons to upgrade. Once an option is selected, the institution will move forward to the implementation phase of the systems life cycle.
Project Planning
The process of project planning occurs throughout the systems life cycle. Two key points in the life cycle when planning becomes more intense are (1) the planning required for system selection and (2) the planning required for system implementation. Chapter 16 discusses planning related to system selection. In this chapter the discussion focuses on the process of project planning as it relates to system implementation. Students interested in more information about project planning and project management principles can consult the Project Management Institute (www.pmi.org) or a project management text. Large organizations typically employ a project manager certified in project management techniques.
Defining Success
One of the first planning steps includes defining the project and its success factors. Before an implementation can be called a success, the term success must be defined using measurable terms or goals. An example might be reducing medication errors by 15% by installing medication and bar-coding applications. Any required baseline metrics should be determined and measured before implementation if post go-live comparisons are required (Box 17-1). Other examples are pre and post statistics for the number of pharmacy callbacks to physicians; the volume of nonformulary medications; and the time between order entry and first medication dose, especially for critical medications such as tissue plasminogen activator (tPA); the time between “stat” order entry and order completion; the percentage of suspected acute myocardial infarction patients who receive aspirin within 24 hours before or after arrival at the emergency department; the number of duplicate laboratory or radiology orders; and the number of verbal or telephone orders with a documented read-back.18
Box 17-1 Factors for a Successful Electronic Health Record (EHR) Implementation
• Project team defines a clear scope of the project.
• Senior leadership, clinical leaders, and EHR champions provide enthusiastic and unwavering support for the project.
• Employ a health IT professional to lead the project and be sure to have adequate resources.
• Solicit input from representatives from each discipline at every stage of the initiative.
• Have default clinical information and responses to order prompts on orders and fill in as much as possible on order sets.
• Consider mandatory use of computerized provider order entry (CPOE).
• Educate users, particularly physicians, on the trade-off of initial reduced productivity and time to perform ordinary tasks such as order entry with long-term positive gains of reduced callbacks, reduced time between order entry and first dose medications and “stat” orders, and “everywhere” access to the chart. If clinicians understand and are educated on why the change was made, they tend to be accepting of the change.
• Examine and develop collaborative detailed plans for the anticipated changes in current workflows early in the project with a sign-off from each user group.
• Provide one-on-one education to physicians and a dedicated physician liaison.
• TEST, TEST, TEST the system from every user's perspective.
• TRAIN, TRAIN, TRAIN: Provide ample education to IT staff and end-users.
• Use the “train the trainer” approach for maximum mileage.
• Use superusers for go-live and post go-live support.
• Provide abundant support during go-live and 7 to 10 days following go-live.
• Anticipate user resistance and plan for it.
• Possess an understanding that there is no finish line for EHR maintenance.
• Have a strong resolve, knowing that the project will be difficult.
Whether undertaking a new implementation or an upgrade, organizations will want to adhere to solid project management principles, such as the use of a project plan. It is essential that the implementation team creates a comprehensive and detailed project plan that includes all of the critical milestones, assumptions, and tasks with target dates and assigned resources. The project plan can be created using Microsoft Office Excel but most facilities use more sophisticated applications specifically designed for project planning, such as Microsoft Office Project (Fig. 17-1). The project plan includes resources across the organization in IT and clinical and the use of superusers. Superusers are selected staff who receive extra training and help to provide additional support during the go-live process.
Facilities should develop a go-live theme, such as giving the implementation project an official name and a slogan, reference the project name each time the implementation is discussed, and start early with a slogan and use it continuously throughout the project for activities such as project marketing with pamphlets, posters, flyers, and announcements. Some organizations will also select a color scheme and use it for all publicity, communications, updates, banners, posters, table tents, and T-shirts or buttons that support staff may wear during the go-live. Large facilities will have a marketing plan for the project, especially closer to go-live.
Executive Management Support
A second planning step includes eliciting the support of organization executives. One of the key factors for a successful implementation or upgrade is public attestation and repeated unwavering support for the project by the executive team. This kind of support is needed from the project's kickoff day to after go-live. Leaders need to communicate this message to the organization at every possible opportunity and on a regular basis.19,20 This commitment is especially critical when users, particularly physicians, repeatedly escalate EHR issues, such as difficulties with CPOE, to the executive suite with requests that could undermine the project. Regarding issues with CPOE, some healthcare organizations mandate that physicians enter orders into CPOE modules with a few well-defined exceptions. Organizations that have more success with such mandates include those that employ a large percentage of physicians, such as the military and Veterans Health Administration. Other tactics used to deal with CPOE resistance include policies that instruct nurses and unit secretaries to inform physicians that they are not allowed to enter orders on a physician's behalf. However, if the physician submits a complaint against a staff member as a result, executive management must support this policy when challenged.
Engage Stakeholders
Another important factor in planning is to solicit input from representatives in every discipline from the beginning and continue to inform them of the progress of the project.21 Informatics governance structures discussed in Chapter 10 provide representation for stakeholder groups. Savvy implementers will ensure that voices from each group are heard. One of the most effective methods for engaging stakeholders is to involve them in the analysis of current workflow processes and the redesign of those processes.
Redesigned Workflows
As mentioned earlier, a new system will change the current workflows, processes, and policies. Redesigned workflows require preparation so that professional practice processes match the available EHR functions. This early work is imperative to preclude modified workflows or negative workarounds (a method used to circumvent a problem without solving it). New policies need to be adopted for new workflows. All current workflows and processes need to be assessed in successful implementations. The best approach to obtaining this information is to schedule separate meetings with representatives from each department, being certain to include unit secretaries, who frequently know the unofficial workarounds. Actual end-users are important to include in the process. While department or unit managers can easily provide the organization's approved workflows and processes,
FIG 17-1 Sample timeline. The timeline in its entirety is posted with the Evolve resources for this chapter. CPOE, Computerized provider order entry.
(Copyright McKesson Corporation.)
they may not be aware of the unofficial workarounds used by the staff. In short, the goals of scheduled meetings with each department are to identify all current official and unofficial workflows and processes and to plan the future workflows and processes using the EHR's new functionalities so that users can anticipate how their jobs will change. At these separate meetings the areas of overlap or instances where workflow moves from one department to another should be noted. These can be critical and sometimes difficult points in planning a redesigned workflow. Redesigned workflows and planned changes must be included and thoroughly reviewed in all end-user training classes.
Building or Tailoring the Product
Once the current workflow is understood and redesigned, teams work to build or tailor the EHR to match the new workflow. Typically, clinical analysts work with vendor analysts to tailor a product for the current environment or actual end-users may be involved in the process. At a minimum, once a module is initially tailored analysts have end-users assess the module in an iterative fashion. The following tips can be useful in this design process:
•Design and build the system to keep the number of clicks and amount of scrolling to an absolute minimum. Physicians in particular will calculate the time it takes to perform common tasks. Excess clicking can be a huge user dissatisfier and can discourage users. To avoid excessive clicks, implementation analysts often use what is commonly referred to as the 80/20 rule. The term 80/20 refers to a mathematical formula proposed by an Italian economist in 1906 that states that 80% of our results or outcomes are derived from 20% of our efforts or causes.22 An example of applying the 80/20 rule in health informatics is to assign default responses when a specific response is selected 80% of the time. For instance, builders will prefill as many of the fields as possible in order entry with prompts such as “Routine” for the priority and “Once” for the frequency for all laboratory and radiology orders to facilitate faster order entry. The underlying rule is to minimize all keystrokes and excessive scrolling whenever possible. Default settings can be especially useful in saving time but they also need to be evaluated carefully to ensure that they do not increase safety issues.
TABLE 17-4 Different Types of Testing during an Implementation and Post Go-Live
TESTING TYPE
DESCRIPTION
EXAMPLES
ADT testing (see Fig. 17-2)
ADT testing involves testing for every possible type of ADT transaction used in the organization for inpatients, outpatients, serial patients, and preadmits. These transactions include admit; discharge; transfer; cancel admit; cancel discharge; cancel transfer; change beds, rooms, or departments; merge accounts; etc.
The tester will ask registration to admit several new patients. Tester will verify that patient is in correct department, room, and bed and all data entered during admission are correct. Admissions then will cycle through the various transactions with the tester validating each change.
Unit testing and functional testing
Unit testing is a very basic type of testing where the tester runs through the basic functionalities and features of an application. It is a high-level cursory walk-through of the application. The goal is to identify deviations from the expectations and to correct these unexpected results. The tester will not test every order or documentation field but will need to test every possible scenario.
For a CPOE application the tester will enter interfaced and noninterfaced orders in the application and follow them through. The tester will verify that order details display appropriately and that orders are received in the ancillary system.
Integrated testing
Integrated testing tests the transmission of messages between all systems such as the healthcare information system, laboratory, radiology, pharmacy, dietary, cardiology, etc. This test includes testing all bidirectional order messages and results going across the interface(s).
The tester will enter different kinds of orders in the CPOE system to interfaced ancillary applications like laboratory, radiology, pharmacy, dietary, and cardiology and then cycle through all actions that are permitted per user role, including canceling the order, discontinuing the order, modifying the order, holding the order, etc. This also includes testing “unsolicited” orders, orders that originate in an ancillary system. An example of an unsolicited order is when the laboratory system initiates an order in response to the result of a previous order such as performing an HIV Western blot if HIV antibody is positive.
Hardware testing
Hardware testing includes the capability of hardware interfacing with the EHR such as computers, printers, label printers, bar code printers, tablets, scanners, modems, etc.
The IT team will test that diet requisitions print in the dietary department but dietitian consults print to the dietitian's office at the specific times based on table settings. Another example is that lab labels print in the patient departments for specimens that are collected by the nurse but print in the lab for specimens that are collected by lab personnel.
Volume testing
Volume testing is sometimes called “stress testing.” Systems are built to accommodate the largest number of users accessing the system at the same time with no or minimal reduction in overall performance.
Early morning physician rounding and early afternoons are typically peak times for accessing the EHR. This type of testing may include asking a large group of students to log on and perform a variety of tasks simultaneously.
Security testing
Different staff members will have different reasons to access an EHR and their roles will define what they can and cannot do in the system. Security testing checks that each provider type is able to perform functionalities specific to the role (entering orders, vital signs, nursing documentation, viewing results, medication reconciliation, etc.) but is prohibited from unauthorized actions, viewing, or access.
The IT department will validate that nursing assistants have the security to document vital signs, height, weight, I&O, and percentage of meals consumed but not be able to review the chart or enter orders. Another example is that a physician or RN can perform medication reconciliation with a change in the level of care but a nursing assistant cannot.
ARRA-related Meaningful Use testing
With the introduction of Meaningful Use, eligible providers, hospital organizations, and Critical Access Hospitals (CAH) must test their ability to collect required information and demonstrate that they meet Meaningful Use criteria.
A few of the CMS requirements for MU Stage 1 include:
•Assessing all patients for VTE prophylaxis
•Recording smoking status on more than 50% of patients 13 years and older
•Recording advance directives for more than 50% of patients 65 years and older
•Providing more than 50% of patients with an electronic copy of their discharge instructions at time of discharge, upon request
•Reporting hospital clinical quality measures to CMS or the states
ADT, Admission, discharge, and transfer; ARRA, American Recovery and Reinvestment Act; CMS, Centers for Medicare & Medicaid Services; CPOE, computerized provider order entry; EHR, electronic health record; I&O, intake and output; IT, information technology; RN, registered nurse; VTE, venous thromboembolism.
•Do not ask clinicians to respond to prompts that they cannot answer. For example, most radiology systems have a mandatory prompt for “Method of Transportation.” Physicians most likely do not know if the patient requires a gurney or a wheelchair, and will typically select the first option to place the order. Some organizations now use a default of “Wheelchair” or a term such as “Call Unit” for the “Method of Transportation.” Avoid the overuse of alerts in order to minimize alert fatigue. Alert fatigue occurs when a user becomes desensitized to pop-ups or alerts if too many are triggered during an average session. Set the level of sensitivity so that only critical medical alerts fire and those with marginal clinical significance are suppressed.
•Maintain a consistent look and feel to the screens so the same information is always found in the same place and color coding is consistent on every screen. Ideally this consistency should extend across vendors and institutional departments.
Testing
Implementing or upgrading an electronic health system involves extensive testing. The different types of testing must be carefully planned and conducted throughout the project. These include hardware, software, and functional testing. Functional testing is used to determine whether the system functions as designed and works effectively with the newly structured work processes. All testing should be done first within a module. Once all modules are functioning correctly, integrated testing across modules is performed using patient flow scenarios. Table 17-4 outlines several different types of testing that are often part of the testing protocol.
A test plan is often created in a spreadsheet format. The plan should include fields for the name of the test, date of the test, name of the tester, log-in used for the test, role of the tester (MD, NP, RN, RT, US, etc.), test objective, and test instructions. An example of such a test plan is shown in Figure 17-2.
The testing process requires that a testing environment be created within the organization's electronic system. Box 17-2 lists the different environments that are usually created in order to install and maintain a healthcare information system. These environments can be conceptualized as copies of the same application. Using the test environment to execute test plans, the implementation team will develop detailed test
FIG 17-2 Sample test plan. The plan in its entirety is posted with the Evolve resources for this chapter. ADT, Admission, discharge, and transfer; HIS, healthcare information system; Pt, patient.
(Copyright McKesson Corporation.)
plans for each staff group such as healthcare providers (physicians and mid-level providers such as physician assistants and advanced practice registered nurses), staff nurses, pharmacists, unit secretaries, and ancillary personnel for each application. Test plans evaluate information and data flow throughout the application including, for example, messages, allergies, orders, test and other diagnostic results, automatic and manually demanded reports, and archiving of the patient's record postdischarge. If this is an upgrade implementation, medical facilities often have ready-made test plans that they use with each upgrade but modify to accommodate changed or new functionalities, improved features, and fixes to previous defects. An upgrade test plan differs from a new implementation test plan in that the upgrade test plan typically has a short list of test items or orders for each department versus a new implementation that involves testing every item in the order item dictionary as well as every prompt and combination of prompt responses on each order. Testing includes all devices such as computers, printers, handheld devices, bar code scanners, etc.
Box 17-2 Healthcare Information System Online Environments
• Live or Production environment refers to the healthcare information system application's actual use with patient and hospital data. Testing and teaching should not be done using this environmnet since changes are very likely to affect patient care.
• Build environment refers to a copy of a healthcare information system application that is used to configure and customize an application. Building usually occurs at the module level. Once a module is designed it is moved to the test environment.
• Test environment refers to a copy of the healthcare information system application that is used to test the application. It should be a complete copy of the most recent version of the actual application. The test version of the software should not be an empty shell but should reflect the actual type and amount of data one would expect to see in the live environment.
• Teaching environment refers to a copy of the healthcare information system application that is used for teaching users. Like the test version of the software, this version should not be an empty shell but should reflect the actual type and amount of data one would expect to see in the live environment.
• Teaching/testing environment refers to the combined use of a healthcare information system application for both testing and teaching activities. This does require careful scheduling since testing should not occur at the same time that a class is using the environment for teaching. However, the advantages are that this approach saves resources and using the test environment for teaching provides additional testing for the application.
Preparing for Go-Live
Preparing for go-live involves deciding on the go-live approach, developing the go-live plan and schedule, and preparing the end-users.
Big Bang or Incremental Go-Lives
There are two approaches to a go-live: big bang or incremental (also called a phased or a staged approach). The big bang approach occurs when all applications or modules are implemented at once. This approach is favored by vendors and facilities conducting large upgrades. With a phased go-live approach, both paper and electronic environments exist at the same time within the healthcare institution; however, the existence of both paper and electronic environments forces the clinician to use different work flows in patient units that have implemented the system than in units that have not, potentially creating safety concerns. The advantages of the big bang approach are that it is usually less expensive and implementation time is shorter, allowing staff to return to a new normal and see early improvements in the project metrics more quickly. The negatives associated with the big bang approach are the significant reductions in productivity seen immediately at go-live and for a short time afterwards due to users' unfamiliarity with the new system and a large influx of requests to tweak the system (Box 17-3).
The incremental approach is usually selected when a facility has limited resources that cannot support a housewide implementation or when the facility has a low tolerance for or ability to respond to institutional changes. There are a variety of ways to employ this method. Some facilities may decide to go-live with specific staff groups such as nurses, unit secretaries, and ancillary staff, including laboratory, pharmacy, radiology, respiratory therapy, physical therapy, occupational therapy, speech therapy, and dietary, followed by physicians and other clinicians a short time later. Others may choose to go-live with select clinical departments or product lines (e.g., patient flow within a specialty such as surgery). Reasons for selecting the first units to go-live may be based on their perceived support and enthusiasm for the project or their low number of admissions, transfers, and discharges. Advantages of the incremental approach are that it allows time to make changes to the build or the workflows and does not decrease productivity housewide while creating constant change for end-users. The early adopters or the new users of the initial departments normally will share their experiences, perceptions, and satisfaction with others. However, this communication can either support or speak against the project. The disadvantages include the potential for errors due to multiple systems and the possibility that the project can be protracted and workflow disruptions will occur over a longer period, although on a smaller scale. Another factor to consider with the incremental approach is the availability of support for each successive unit. Most vendors typically like to transition from their implementation or services team to the support team 2 to 4 weeks after initial go-live. Continued support can be expensive for organizations. This also means that the organization will be calling vendor employees who may not be familiar with the build, workflows, and customizations when issues arise with each new mini go-live. Repetitive go-lives also tax the IT department and the superusers and delay the deployment of fixes and physician requests from the initial go-live departments. Sometimes the rollout is more prolonged than originally planned or it may even stall indefinitely due to user dissatisfaction. The early go-live users who do not see quick resolution of easily fixed issues will complain because the support staff is too busy with the next go-live unit (Box 17-4).
Box 17-3 Advantages and Disadvantages of the Big Bang Approach
ADVANTAGES
DISADVANTAGES
Eliminates staff having to use two systems or processes in different departments, which decreases the number of errors
Total cost of entire implementation is lower
Project is less likely to stall and is more likely to fully implement the system
Shorter implementation cycle and shorter implementation pain
Quicker improvements in electronic health record–related metrics (decreased use of nonformulary medications, decreased pharmacy callbacks)
Immediate compliance with American Recovery and Reinvestment Act–mandated requirements for Meaningful Use to receive “stimulus” funds
On-site and remote support personnel and implementation consultants from the vendor are available for the initial days of the go-live
Significant decrease in productivity in the initial days and immediately after go-live with a gradual return to baseline
Less time to make changes to the build or workflows
Changes in workflows and processes are turned on housewide with everyone on same learning curve, making implementation pain and anxiety greater
Must plan for large number of support personnel in the information technology department and roaming superusers to all departments
Box 17-4 Advantages and Disadvantages of the Incremental Approach
ADVANTAGES
DISADVANTAGES
Allows time to make changes to build and workflows with each new batch of users
Early reports of success breed enthusiastic support for the upcoming departments
Less impact on productivity
Restricts implementation pain to a smaller number of select users or departments
Staff that circulate through the organization must use two workflows, which can increase the number of errors
Project may stall due to users' dislike of using different processes or workflows in different departments and changes that are made after each mini go-live
Total cost of entire implementation is higher due to extended support and training
Longer implementation time with feelings that system is “not ready for prime time” and will not end soon enough
Delays compliance with American Recovery and Reinvestment Act–mandated requirements for Meaningful Use to receive “stimulus” funds
Most vendors transition customers to their support division within 2 to 4 weeks post go-live
Early reports of dissatisfaction may dissuade others from embracing the system
Detailed Go-Live Plan
A detailed go-live plan includes each planned activity as a line item assigned to a specific individual or team with a completion date for each task. The go-live plan should include critical tasks that are scheduled to be completed a few days to a few weeks before the go-live date. Some project managers may break down the immediate days before go-live to the number of hours before go-live, marking tasks that must precede other tasks.
Education and Training
A common mistake in an implementation or upgrade is not planning sufficient time to thoroughly train end-users or failure to allot a sufficient budget to conduct training.23 Education of all end-users is a mini project and is best assigned to a person or facility education department that can coordinate or oversee all of its components. In fact, training is complex enough that software support in the form of a learning management system (LMS) is often used. An LMS includes planning and tracking the end-users trained and the results of any competency tests. A training plan must address the development of teaching plans, training manuals, and job aids that provide instructions on common tasks and can be used during training and on the job. Different types of training must be developed for the different groups of end-users, including physicians, nurses, pharmacists, unit secretaries, students, and ancillary personnel such as respiratory therapy, rehabilitative services, clergy, quality control, etc. For example, physicians will need instruction on using CPOE, viewing test results, viewing charting, and performing medication reconciliation, while nurses will need education related to order entry, nursing documentation, and medication administration.
Questions to consider in planning education hours are the number of users to be educated, education methodology, the timing and length of the classes for each user group, the number of training rooms and training devices available, the training schedule, and trainers for each group. The content of the course should reflect the scope and standards for practice with role-specific processes, decisions, tasks, and supportive EHR functions for each group of users. During training, common user errors or system quirks should be highlighted to help the users to avoid them. MU-related tasks such as assessing smoking status, advance directives, and immunization status should also be addressed so that users understand the importance of completing those data fields. Privacy and security policies, including not sharing one's log-in and password and accessing only those medical records the user needs to review, should be emphasized in every class. The consequences for violating privacy and security policies and practices should also be stated clearly.
Trainers
Depending on the organization's structure, the trainers might be in-house staff, vendor educators, temporary consultants, superusers or power users, or a mix of these. If the organization is using a big bang approach, it will often need to bring in temporary trainers in order to get all users trained and then revert to in-house educators or superusers following go-live for new hires, system upgrades, and remediation training. The advantages of using in-house educators are that they are familiar with the organization's policies and usually have a background in adult education. Vendor educators and consultants frequently know the application very well but are not familiar with the organization's future workflows and policies. Superusers who can spend time with students who are having difficulties are valuable as assistants in the classroom. Training is an ongoing process that will continue after go-live to orient new hires and to address new responsibilities or changes in staff roles that consequently cause changing workflows.
Training Methodology
Most organizations use a combination of different training methods. One of the most popular methods is an instructor-led class in a classroom that contains all of the equipment needed to demonstrate essential functionalities, including printers, bar code scanners, identification bands, medication labels, etc. The advantages of instructor-led training are the ability for end-users to ask questions, quick clarification of complex concepts, and easy identification of users who may need additional help. The primary disadvantages are the expense and resources needed to have multiple instructor-led classes. In addition, the number of students per session is limited and no-shows are common among nurses and physicians since training competes with patient care needs. Another common training method includes a blended approach in which end-users complete an “anytime/anywhere” online module about EHR basics and then attend a brief instructor-led session. These are also used as mini-refreshers or primers during upgrades.24 A major drawback to using a variety of approaches is the constant need to update all of the training materials with the introduction of new functionalities. No matter the approach, the use of competency tests to assess proficiency is recommended.
With a CPOE implementation, most organizations create a new position for CPOE liaisons who are dedicated to clinician training 24 hours a day, 7 days a week. Physicians may be unable or unwilling to attend scheduled classes and prefer just-in-time or one-on-one education.25 Some organizations employ physician liaisons who are dedicated exclusively to assisting physicians. Even though this is a labor-intensive strategy, physicians quickly become adept at their new workflows, report greater user satisfaction, and have a greater likelihood of using and being satisfied with the new system.
Length of Class and Class Schedule
Depending on the EHR functions needed, class time will vary. For example, CPOE classes for unit secretaries in an organization where prescribers will be expected to use CPOE may be 2 to 3 hours whereas the same classes for nurses may require 6 to 8 hours. Once the total number of users and the number of hours for each learning module are determined a training schedule is developed, often using the LMS mentioned earlier. With a housewide go-live, training will need to be provided around the clock. If users must attend class during their off-duty time, organizations will have to consider paying overtime. Alternately, if user education is incorporated into the 40-hour workweek, replacement staff may be required. End users should not be expected to attend class immediately after a shift when they are most likely tired and may not be able to leave their department when planned. Education should be conducted as close to the go-live date as possible to facilitate retention of the new knowledge and skills with a goal of no more than 4 weeks prelive. Once a majority of employees has completed the training, the institution is ready for go-live.
Go-live
During the initial weeks of the go-live, organizations must plan to provide close support (“elbow-to-elbow” support) for end-users. Many institutions will provide 24/7 support for a week or two and a few may offer it for several weeks. Assigning superusers wearing easily identifiable apparel to roam departments offering assistance to users is an excellent tactic that is well received by the end users. Issues, questions, and misunderstandings should be reported to the project team, which then catalogues, prioritizes, and tracks them for resolution and future reference.16 Additional tips include the following:
•Avoid a go-live date that falls on a weekend, a Monday or Friday, or close to a major holiday when vendor support personnel may be less available. Two exceptions to this guideline are the implementation of a new financial system that must start at midnight on the first day of the month for billing purposes and a big-bang implementation, which is typically scheduled to start on a weekend to minimally affect surgery and procedure services.
•Set up an organized and well-equipped command center for the go-live that includes:
•A highly publicized hotline number for assistance; incoming calls need to roll over to a bank of well-staffed phones.
•A system for reporting, cataloging, assigning criticality, and assigning skilled resources to identified issues and problems.
•A hotline number is one communication method, but urgent issues need to be addressed and, if necessary, escalated immediately to the vendor or IT department for resolution. Stock the command center with supplies such as whiteboards, poster boards, phones with outside access, preprinted “Issue Reporting”' forms, printers, office supplies, meals, snacks, and water. Devices must be loaded with new software and integrated with upstream (ADT) and downstream (laboratory, radiology, pharmacy, dietary, electrocardiography, etc.) systems for immediate troubleshooting.
•Devise several different mechanisms to obtain and give user feedback in a timely manner.
•Include clearly identified people associated with the command center and project. For example, roaming superusers could wear an identifying T-shirt, vest, or large easy-to-read badge in the project ‘color.’
Other go-live tactics include the following:
•Give small gifts to units (donuts or bakery items, boxes of candy, popcorn tins, balloons for desks).
•Use posters or banners in main lobbies, atriums, and waiting rooms.
•Provide a well-publicized process for end-users to communicate with the implementation team and change-control committee (which collects and prioritizes system changes).
•Generic email address for users to ask questions, request a change or new item, or make suggestions, with prompt feedback to users' questions and requests.
•Suggestion box that allows anonymous input and has scheduled collections.
•Notebooks in staff lounges with scheduled pickups and returns.
•Emails to all users that include FAQs and “Tips and Tricks.”
POSTLIVE Maintenance
A vendor-supported implementation is officially over when the system formally transitions from the vendor's services team to its support division. With in-house development, the project leader announces when the go-live is over. Maintenance is an ongoing process that involves a variety of tasks such as applications updates, patches for identified defects, and a continuous revision of the system in response to users' requests. This includes revising documentation screens, adding new content, creating new orders such as new medications, and inactivating obsolete content such as outdated interventions and medications that are no longer in the hospital formulary. The change control committee receives input for new content, such as newly defined order sets, as well as requests for revisions to current order sets so that they align with updated best practices. Users may discover system flaws that were not detected during testing and these need to be submitted to the change control committee and vendor. IT departments may conduct regularly scheduled rounds to the clinical units to solicit input from the users.
As mentioned earlier, major reasons to implement EHRs are patient safety, improved patient care, and clinical outcomes. One of the final tasks in the implementation plan is to evaluate whether and how the system made a difference according to the metrics identified and collected during the preimplementation phase. This collection of data is typically performed approximately 3 to 6 months after the go-live to allow users to become more proficient with the EHR. Implementing a new EHR or upgrading an older version is a process without a definitive end point. After installation an EHR will require software upgrades, new hardware, ongoing training of staff, and education of IT staff.23
Conclusion and Future Directions
Meeting MU for Stage 2, expected to begin in 2014, and Stage 3 in 2016 will continue to spur growth of EHRs. In the future patients will likely interact with their healthcare providers more frequently via electronic means to set up appointments; send questions and requests for prescription refills; and be able to retrieve and review their health record, including test results. There will be movement away from stand-alone outpatient EHR systems and toward integrated systems. Mobile devices such as smartphones and iPads will play a larger role in patient–clinician relationships and nurse–patient–family relationships in the home. Health-related apps that allow for home monitoring of vital signs, blood glucose levels, electrocardiography monitoring, and fetal monitoring will become more commonplace.
In the future the U.S. may develop a registry to track EHR-related safety issues. The registry could be used to monitor safety and adverse issues and initiate timely notifications to medical providers and patients.26 In a similar vein, the Institute of Medicine advocates the creation of a new federal agency or National EHR Safety Board under the auspices of HHS to oversee EHR safety. Presently there is no formal national or global process through which organizations or individual users can report possible EHR-related safety issues. The IOM also recommends that the federal agency have the authority to (1) require IT vendors to register their products and communicate negative events associated with their applications, (2) establish mandatory IT safety criteria, and (3) publish an annual report on identified safety issues and strategies in an effort to minimize or eliminate them.27–29
No matter whether the EHR is new or an upgrade, the ultimate goal in implementations is to provide the highest level of care at the lowest cost with the least risk.
References
1.
The White House: Promoting innovation and competitiveness: President Bush's technology agenda. 2004, The White House, http://www.whitehouse.gov/infocus/technology/economic%20policy200404/innovation.pdf.
2.
One Hundred Eleventh Congress of the United States of America: The American Recovery and Reinvestment Act of 2009, Title XIII. 2009, Heath Information Technology, http://www.gpo.gov/fdsys/pkg/BILLS-111hr1enr/pdf/BILLS-111hr1enr.pdf.
3.
Healthcare Information Technology Standards Panel (HITSP): HITSP quality measures technical note ED, VTE, and stroke examples for implementation of the HITSP quality interoperability specification: HITSP/TN906. 2011, HITSP, http://www.hitsp.org/ConstructSet%20Details.aspx?&PrefixAlpha=5&PrefixNumeric=906.
4.
Manos, D: CCHIT certification for homegrown EHRs proves worthwhile. 2011, Healthcare IT News, Accessed February 19, 2012 http://www.healthcareitnews.com/news/cchit-certification-homegrown-ehrs-proves-worthwhile.
5.
American Hospital Association (AHA): AHA survey on hospitals’ ability to meet Meaningful Use requirements of the Medicare and Medicaid electronic health records incentive programs. 2011, AHA, http://www.aha.org/content/11/11EHRsurveyresults.pdf.
6.
Centers for Medicare & Medicaid Services (CMS): ICD-10 overview. 2012, CMS, http://www.cms.gov/ContractorLearningResources/Downloads/ICD-10%20Overview%20Presentation.pdf.
7.
Department of Health & Human Services (HHS): HHS proposes adoption of ICD-10 code sets and updated electronic transaction standards. 2008, HHS, Accessed April 1, 2012 http://www.dhhs.gov/news/press/2008pres/08/20080815a.html.
8.
Sackett, DL, Rosenberg, WM, Gray, JA, Haynes, RB, Richardson, WS: Evidence based medicine: what it is and what it isn't. Brit Med J. 312(7023), 1996, 71–72.
9.
Berner, ES: Clinical decision support systems: state of the art. 2009, Agency for Healthcare Research and Quality, Accessed April 1, 2012 http://healthit.ahrq.gov/images/jun09cdsreview/09%200069%20ef.html.
10.
Agency for Healthcare Research and Quality (AHRQ): Translating research into practice (TRIP)-II: fact sheet. 2001, AHRQ, http://www.ahrq.gov/research/trip2fac.htm.
11.
Menachemi, N, Collum, T: Benefits and drawbacks of electronic health record systems. Risk Manag Healthc Policy. 4, 2011, 47–55, doi:10.2147/RMHP.S12985.
12.
Joint Commission of Accreditation of Healthcare Organizations: Hospitals’ national patient safety goals. 2004, The Joint Commission, Accessed April 1, 2012 http://www.jointcommission.org/PatientSafety/NationalPatientSafetyGoals/04%20npsgs.htm.
13.
Kaplan, JM, Ancheta, R, Jacobs, BR: Clinical informatics outcomes research group: inpatient verbal orders and the impact of computerized provider order entry. J Pediatr. 149, 2006, 461–467.
14.
Ash, JA, Sittig, DF, Dykstra, R, Campbell, E, Guappone, K: The unintended consequences of computerized provider order entry: findings from a mixed methods exploration. Int J Med Inform. 78, 2009, S69–S76, doi:10.1016/j.ijminf2008.07.15.
15.
Ash, JA, Stavri, Z, Kuperman, GJ: A consensus statement on considerations for a successful CPOE implementation. J Am Med Inform Assn. 10, 2003, 229–234, doi:10.1197/jamia.M1204.
16.
Weiner, JP, Kfuri, T, Chan, K, Fowles, JB: e-Iatrogenesis: the most critical unintended consequence of CPOE and other HIT. J Am Med Inform Assn. 14, 2007, 387–388, doi:10.1197/jamia.M2338.
17.
Institute for Safe Medication Practices (ISMP): FDA and ISMP lists of look-alike drug names with recommended Tall Man letters. 2011, ISMP, http://www.ismp.org/tools/tallmanletters.pdf.
18.
Agency for Healthcare Research and Quality (AHRQ): Percentage of verbal orders: 2009 AHRQ http://healthit.ahrq.gov/portal/server.pt/gateway/PTARGS%200%203882%20868890%200%200%2018/Percent%20of%20Verbal%20Orders.pdf.
19.
Ash, JA, Fournier, L, Zoë Stavri, P, Dykstra, R: Principles for a successful computerized physician order entry implementation. AMIA Annu Symp Proc. 2003, 36–40, http://www.ncbi.nlm.nih.gov/pmc/articles/PMC1480169/pdf/amia2003_0036.pdf.
20.
Sklardin, NT, Granovsky, SJ, Hagerty-Paglia, J: Electronic health record implementation at an academic cancer center: lessons learned and strategies for success. American Society of Clinical Oncology 2011 Educational Book http://www.asco.org/ASCOv2/Home/Education%20&%20Training/Educational%20Book/PDF%20Files/2011/zds00111000411.PDF, Accessed January 2, 2013.
21.
McGonigle, D, Mastrain, K: Nursing Informatics and the Foundation of Knowledge . 2009, Jones and Bartlett Publishers, Sudbury, MA.
22.
Hafner, AW: Pareto's principle: the 80-20 rule. 2003, Ball State University, Accessed July 28, 2012 http://www.bsu.edu/libraries/ahafner/awh-th-math-pareto.html.
23.
Grant, JT: Allow time to implement EHR. Ophthalmology Times. 35(7), 2010, 54–56.
24.
Jain, V: Evaluating EHR systems. Health Manag Technol. 31(8), 2010, 22–24.
25.
Classen, DC: Leading patient safety expert speaks on CPOE implementation strategy and success factors. J Healthc Inf Manag. 18, 2004, 15–17.
26.
Consumer Reports: Dangerous devices. Consumer Reports. 77(5), 2012, 24–28.
27.
Goedert, J: New report echoes call for national EHR safety board. HealthData Management. 2011.
28.
Institute of Medicine (IOM): Health IT and patient safety: building safer systems for better care. 2011, IOM, Accessed April 7, 2012 http://www.iom.edu/hitsafety.
29.
Sittig, DF: Safe electronic health record use requires a comprehensive monitoring and evaluation framework. J Amer Med Assoc. 303(5), 2010, 450–451, doi:10.1001/jama.2010.61.
Discussion Questions
1. Discuss why some healthcare providers continue to use a paper medical record.
2. What effects will a fully implemented EHR have on patients? How might it change the cost of care?
3. Why did the ONC elect to use the term electronic health record (EHR) and not electronic medical record (EMR)?
4. If EHRs significantly reduce medication errors and increase the quality of care through the use of evidence-based protocols, should insurers and certifying organizations such as The Joint Commission require healthcare providers and organizations to implement a certified EHR as a standard practice of good medicine?
5. Should insurers offer incentives to patients to select healthcare providers who have an EHR?
6. Review the EMR Adoption Model (EMRAM), an eight-step scale developed by the Healthcare Information and Management Systems Society (HIMSS) to monitor hospitals' and health systems' EHR progress toward a paperless or near paperless system, at www.himssanalytics.org/home/index.aspx. What are the characteristics of the organizations who have successfully achieved Stage 7 status?
7. What are the advantages and disadvantages of a Healthcare Information Technology Standards Panel (HITSP)–certified health IT system versus a homegrown IT system that meets certification standards?
8. What do you anticipate will be barriers to meeting the requirements for Meaningful Use Stage 2?
9. Identify creative strategies to encourage physicians and other clinicians to participate in the implementation of a new health IT system.
10. Discuss ramifications and causes regarding interoperability issues among electronic health systems and applications.
Case Study
Middleville Hospital, located in a small rural town, is a 58-bed acute care facility with both inpatient and outpatient services. The hospital consists of more than 600 employees and more than 300 volunteers. It is a community owned, not-for-profit hospital dedicated to providing compassionate, accessible healthcare close to home. The facility primarily serves one major county and nine surrounding counties.
The hospital has a homegrown electronic health record (EHR) system but it has the functionality to allow the hospital to barely meet Meaningful Use Stage 1. The hospital's primary goal is to implement a certified EHR but the leaders are weighing the benefits of two options: recruiting a skilled professional to rebuild the current system or purchasing a commercial system. There is pressure to make a decision as soon as possible.
What are the musts, constraints, and barriers?
•The new system must be fully implemented and operational no later than June 2014.
•The EHR must be able to meet MU Stages 2 and 3.
•The EHR must be capable of accepting new ICD-10 codes.
•The hospital has a very small IT department and a modest budget.
•Physicians do not enter orders in the current system. Nurses, unit secretaries, and ancillary personnel enter orders in the EHR from written orders on a paper chart.
•The new EHR requires larger servers, new devices, central monitors, printers, and tablets.
•The wireless infrastructure must be upgraded to eliminate known dead spots in areas of the facility.
•The hospital wants to take advantage of select features such as clinical decision support and incorporate best practices or evidence-based medicine.
Discussion Questions
1. Based on what you read in this chapter and the case study, compile an initial list of functional requirements (functions needed) for the new EHR.
2. Create a brief evaluation plan by developing five or six criteria for evaluating vendors' products.
Case Study Follow-Up
The hospital made a list of all pros and cons of rebuilding a homegrown system or buying a commercial product. Realizing that regulations governing healthcare and reimbursement will only become more complicated, the hospital decided to go with a vendor-supplied EHR. Ultimately, it decided to purchase a fully integrated electronic health system that shares a common database to eliminate the issues often seen with interfaces.
Fourteen months later the EHR went live housewide for all staff, including housekeeping and pastoral services. The implementation included the functionality to meet MU and the installation of new servers and hardware in addition to an upgrade of the wireless network. All staff can even view a large monitor showing occupied, clean, and dirty beds that is updated by housekeeping.
The new EHR benefits are many. Initially the physicians grumbled about having to do “secretaries' work” in CPOE but they gradually came to realize the benefits for their patients. Pharmacy reports a 55% decrease in nonformulary medications and a 73% reduction in physician callbacks. The time between a “stat” medication order and administration of the medication and the time between a “stat” lab test order and posting of the lab results have also decreased significantly. Due to the introduction of order sets based on best practices and evidence-based medicine, the hospital has seen a dramatic decrease in its 30-day readmission rates for heart attack, heart failure, and pneumonia patients compared to the U.S. national average and has the lowest rate in the county.
Discussion Question
1. Brainstorm two additional factors you would evaluate for this installation.
Pageburst Integrated Resources
As part of your Pageburst Digital Book, you can access the following Integrated Resources:
Bibliography and Additional Readings
Bonus Image e17-1
Bonus Image e17-2
Web Resources
Chapter 17 Implementing and Upgrading an Information System Solution
Christine D. Meyer
No matter whether the electronic health record (EHR) is new or an upgrade, the ultimate goal in
implementations is to provide the highest level of care at the lowest cost with the least risk.
Objectives
At the completion of this chapter the reader wil
l be prepared to:
1.Discuss the regulatory and nonregulatory reasons for implementing or upgrading an electronic
information system
2.Compare the advantages and disadvantages of the “best of breed” and integrated system
approaches in selecting hea
lthcare information system architecture
3.Explain each step in developing an implementation plan for a healthcare information system
4.Develop strategies for the successful management of each step in the implementation of a
healthcare information s
ystem
5.Analyze the benefits of an electronic information system with an integrated clinical decision support
system
6.Explain the implications of unintended consequences or e
-
iatrogenesis as it relates to implementing
an electronic health record (
EHR)
Key Terms
Best of breed, 277
Big bang, 284
Phased go
-
live, 284
Scope creep, 276
Tall Man lettering, 276
Workarounds, 279
Abstract
The decision to implement a new electronic health record (EHR) or to upgrade a current system is based
on several factor
s, including providing safe and up
-
to
-
date patient care, meeting federal mandates and
Meaningful Use requirements, and leveraging advanced levels of clinical decision support. Implementing
EHRs entails multilayered decisions at each stage of the implementa
tion. Major decisions include
Chapter 17 Implementing and Upgrading an Information System Solution
Christine D. Meyer
No matter whether the electronic health record (EHR) is new or an upgrade, the ultimate goal in
implementations is to provide the highest level of care at the lowest cost with the least risk.
Objectives
At the completion of this chapter the reader will be prepared to:
1.Discuss the regulatory and nonregulatory reasons for implementing or upgrading an electronic
information system
2.Compare the advantages and disadvantages of the “best of breed” and integrated system
approaches in selecting healthcare information system architecture
3.Explain each step in developing an implementation plan for a healthcare information system
4.Develop strategies for the successful management of each step in the implementation of a
healthcare information system
5.Analyze the benefits of an electronic information system with an integrated clinical decision support
system
6.Explain the implications of unintended consequences or e-iatrogenesis as it relates to implementing
an electronic health record (EHR)
Key Terms
Best of breed, 277
Big bang, 284
Phased go-live, 284
Scope creep, 276
Tall Man lettering, 276
Workarounds, 279
Abstract
The decision to implement a new electronic health record (EHR) or to upgrade a current system is based
on several factors, including providing safe and up-to-date patient care, meeting federal mandates and
Meaningful Use requirements, and leveraging advanced levels of clinical decision support. Implementing
EHRs entails multilayered decisions at each stage of the implementation. Major decisions include
