Safety huddles to proactively identify and address electronic health record safety.

OBJECTIVE: Methods to identify and study safety risks of electronic health records (EHRs) are underdeveloped and largely depend on limited end-user reports. "Safety huddles" have been found useful in creating a sense of collective situational awareness that increases an organization's capacity to respond to safety concerns. We explored the use of safety huddles for identifying and learning about EHR-related safety concerns.
DESIGN: Data were obtained from daily safety huddle briefing notes recorded at a single midsized tertiary-care hospital in the United States over 1 year. Huddles were attended by key administrative, clinical, and information technology staff. We conducted a content analysis of huddle notes to identify what EHR-related safety concerns were discussed. We expanded a previously developed EHR-related error taxonomy to categorize types of EHR-related safety concerns recorded in the notes.
RESULTS: On review of daily huddle notes spanning 249 days, we identified 245 EHR-related safety concerns. For our analysis, we defined EHR technology to include a specific EHR functionality, an entire clinical software application, or the hardware system. Most concerns (41.6%) involved " EHR technology working incorrectly, " followed by 25.7% involving " EHR technology not working at all. " Concerns related to "EHR technology missing or absent" accounted for 16.7%, whereas 15.9% were linked to " user errors ."
CONCLUSIONS: Safety huddles promoted discussion of several technology-related issues at the organization level and can serve as a promising technique to identify and address EHR-related safety concerns. Based on our findings, we recommend that health care organizations consider huddles as a strategy to promote understanding and improvement of EHR safety.

INTRODUCTION

Electronic health records (EHRs) may enhance the safety of patient care, but emerging evidence suggests that they also produce new, unique risks. These risks can emerge due to poor system design and usability, ineffective implementation of the system by the health care organization (HCO), or improper use of the system., While some of the risks may not be apparent to users in a complex health care environment, they have significant implications for patient safety.,, Even when a problem is detected, it may be difficult to determine its origin in a complex, distributed clinical computing environment. Despite calls for greater attention to EHR-related safety risks,, most HCOs and providers have limited awareness of these problems. To achieve the transformational benefits promised by pioneering EHR designers and developers, HCOs must ensure that health information technology–related patient safety is an organizational priority. They can facilitate this by “securing commitment from organizational leadership and refocusing the organization’s clinical governance structure to facilitate measurement and monitoring of EHR-related safety risks.” Developing an organizational culture that is amenable to proactively detecting, fixing, and learning from EHR-related safety concerns is critical.

In most HCOs, systematic approaches for identifying EHR-related safety concerns are underdeveloped., Safety concerns are broadly defined as “patient safety events that reached the patient, regardless of whether harm occurred; near misses or close calls, which are patient safety events that did not reach the patient; and unsafe conditions, which are circumstances that increase the probability of a patient safety event.” Incident reporting by end users remains the primary mechanism by which HCOs learn about these concerns, but this method only captures events that have already occurred and has limited value in more real-time identification of safety concerns. Furthermore, awareness of EHR safety concerns is often lacking due to the distributed nature of EHRs and the lack of feedback to end users regarding the consequences of their actions. Thus, there is a compelling need to increase awareness of these “hidden” safety problems and to develop new, proactive strategies to identify EHR-related safety concerns.

Safety huddles could potentially be useful for learning proactively about EHR-related safety concerns. These short, routine debriefings are designed to engage frontline clinical and administrative staff in discussions about existing or emerging safety and performance issues. Safety huddles and safety briefings have been associated with increases in reporting of safety concerns and improvements in patient outcomes. For example, after the introduction of safety huddles in one of the largest US health care systems, reports of safety events increased by 40%. A Veterans Health Administration study found that initiation of checklist-guided preoperative briefings led to significantly higher rates of antibiotic use and deep venous thrombosis prophylaxis.

We conducted a descriptive study of EHR-related safety concerns uncovered during brief, routine safety huddles at a single institution in the United States. Using a previously described conceptual model of safe EHR use, we categorized the content of documented EHR-related problems to better understand them. Our study objective was to evaluate safety huddles as a strategy for identifying and learning about EHR-related safety concerns. We also assessed characteristics and frequencies of those concerns identified during huddles and determined whether huddles could be useful for raising an organization’s awareness of EHR-related safety.

METHODS

Design and setting

We conducted a retrospective analysis of huddle briefing notes obtained from a midsized tertiary-care hospital in the United States. Safety huddles were introduced when the hospital opened in August 2013, which was also when it went live with an EHR. The institution uses Epic, one of the most common EHRs in use across the nation (Epic Systems, Verona, WI, USA). A representative from hospital leadership moderated a 15-minute safety huddle every weekday. Representatives from the clinical, information technology, and administrative departments attended the huddle (see Appendix 1 for details about departments represented in the huddles). Standing members of the safety huddle included department managers from the hospital and 2 affiliated clinics. When standing members were not available, representatives were assigned to attend the huddle in their place. Other participants included frontline staff, many of whom wanted to report on “great catches” or success stories about practices or safe behaviors in the prior 24 hours. On an average day, about 30–40 people participated in the huddle. Although participation was encouraged by the management, attendance was not mandatory.

The huddle followed a structured format. First, significant safety concerns and “great catches” from the prior 24 hours were reported, followed by reports of anticipated safety concerns expected in the next 24 hours. The huddle ended with a question about patient satisfaction (“Is there anyone in the hospital that would not give the hospital a 9 or 10 on our patient satisfaction survey?”). Any concerns requiring further discussion or resolution were addressed in small groups after the huddle ended. Significant safety issues that required immediate attention were directly reported to executive leadership (frequently the chief medical officer), the safety officer within the quality department, risk management, and, if necessary and appropriate, to a peer review committee. To ensure that the huddle process led to closing the loop, all unresolved issues were forwarded to the quality improvement department for follow-up, and actions taken were reported back at a future safety huddle.

The safety huddles were designed to share information, review events, and help teams develop action plans for coordinated patient care. A note-taker recorded all concerns discussed in the safety huddles. We analyzed copies of briefing notes collected from August 2013 to August 2014, the hospital’s first year of operation. This study was a secondary analysis of data collected previously by the participating institution. All necessary Institutional Review Board approvals were obtained.

Data analysis

We conducted a content analysis of the written huddle notes. Content analysis enabled classification of large amounts of textual data, reducing it to conceptually relevant, manageable categories. We used a deductive approach to classify our data. In the first step, 2 investigators (SM and TG) independently read all huddle briefing notes and coded safety concerns that were attributed at least in part to the EHR. Once a set of EHR-related safety concerns was identified and agreed upon by both coders, we used an approach that integrated concepts from an 8-dimensional sociotechnical model of safe and effective health information technology with concepts from existing EHR safety taxonomies (eg, Magrabi 2011, Agency for Healthcare Research and Quality [AHRQ] Hazard Manager and Common Format v1.2) to classify safety concerns. The sociotechnical model describes both technology-related and “social” dimensions of an EHR-enabled health care system: hardware and software; clinical content; human-computer interface; people; workflow and communication; internal organization policies, procedures, and culture; external rules, regulations, and pressures; and system measurement and monitoring (see Table 1 for a description of each dimension of the model). For example, if the report stated that the EHR was missing a structured entry for ordering a specific item for a neonatal intensive care unit (NICU) patient (eg, narrow-gauge endotracheal tube), the concern was categorized as pertaining to “clinical content.” This type of classification was also applied by Castro et al. in categorizing health IT–related sentinel events reported to the Joint Commission.

Table 1.

Types of EHR-related safety concerns categorized along the 6 sociotechnical dimensions

	Type of EHR-related safety concerns
Sociotechnical dimensions, n (%)	EHR technology not working at all	EHR technology working incorrectly	EHR technology missing or absent	EHR-related concerns linked to user errors	Subtotals and totals
Hardware and software (the computing infrastructure used to power, support, and operate clinical applications and devices)	26 (10.6)	48 (19.6)	6 (2.4)	—	80 (32.7)
Hardware malfunction	2 (0.8)	7 (2.9)	—		9 (3.7)
Device failure	2 (0.8)	4 (1.6)	—
Incompatibility between devices	—	3 (1.2)	—
Software malfunction	24 (9.8)	41 (16.7)	6 (2.4)		71 (29.0)
Software unavailable	—	—	1 (0.4)
Unexpected design issue	2 (0.8)	1 (0.4)	2 (0.8)
Loss or delay of data	22 (9.0)	40 (16.3)	3 (1.2)
Clinical content (the text, numeric data, and images that constitute the “language” of clinical applications)	10 (4.1)	23 (9.4)	20 (1.2)	—	53 (21.6)
Incorrect/inappropriate reference information	9 (3.7)	18 (7.3)	20 (8.2)		47 (19.2)
Missing content	—	—	18 (7.3)
Erroneous content	9 (3.7)	18 (7.3)	2 (0.8)
Incorrect/inappropriate charting templates	1 (0.4)	5 (2.0)	—		6 (2.4)
Erroneous content	—	3 (1.2)	—
Inconsistent content	1 (0.4)	2 (0.8)	—
People (everyone who interacts in some way with technology, including developers, users, information technology personnel, and informaticians)	7 (2.9)	4 (1.6)	—	39 (15.9)	50 (20.4)
System configuration issues	6 (2.4)	3 (1.20)	—		9 (3.7)
Human factors	1 (0.4)	1 (0.4)	—	29 (11.8)	31 (12.7)
Failure to carry out duty	1 (0.4)	1 (0.4)	—	11 (4.5)
Inattention	—	—	—	18 (7.3)
Staff qualifications – inadequacies	—	—	—	10 (4.1)	10 (4.1)
Workflow and communication (processes to ensure that patient care is carried out effectively)	7 (2.9)	18 (7.3)	6 (2.4)	—	31 (12.7)
Mismatch between workflow and HIT	7 (2.9)	17 (6.9)	5 (2.0)		29 (11.8)
Communication failure	—	1 (0.4)	—		1 (0.4)
Suboptimal support of teamwork	—	—	1 (0.4)		1 (0.4)
Human-computer interface (all aspects of technology that users can see, touch, or hear as they interact with it)	13 (5.3)	9 (3.7)	6 (2.4)	—	28 (11.4)
Data display errors	7 (2.9)	7 (3.3)	3 (1.2)		18 (7.3)
Data entry errors	6 (2.4)	2 (0.8)	3 (1.2)		10 (4.1)
Internal organizational features (policies, procedures, work environment, and culture)	—	—	3 (1.2)	—	3 (1.2)
Policy in conflict with workflow	—	—	1 (0.4)		1 (0.4)
Absence of protocol/standard process		—	2 (0.8)		2 (0.8)
Total	63 (25.7)	102 (41.6)	41 (16.7)	39 (15.9)	245 (100.0)

Note: Rounding of percentage subtotals may affect totals. HIT: health information technology.

To describe the nature of EHR-related safety issues, we used a modified version of a health IT–related error taxonomy to classify the incidents as arising from: (1) “EHR technology not working at all.” Examples included documents that would not print, an entire clinical software application (eg, order entry interface to pharmacy) that was not available, or hardware systems (eg, computer) that would not turn on; (2) “EHR technology working incorrectly.” Examples included a specific EHR functionality working incorrectly (eg, documents printing in the wrong location), an entire clinical software application working incorrectly (eg, clinical results review displaying the wrong patient’s results), or a hardware system working incorrectly (eg, laptop battery not holding a charge for more than 30 min); (3) “EHR technology missing or absent.” Examples included functionality (eg, dual verification for pediatric medications) that was missing or that needed to be turned on; and (4) “EHR-related concerns linked to user errors.” Examples included duplicate orders being cancelled by 2 separate people due to inattention.

One author (SM) categorized each EHR-related safety concern using the sociotechnical model and error taxonomies. Two authors (DFS and TG) verified these classifications. Discrepant classifications were reviewed, discussed, and revised until all raters reached full agreement. We used ATLAS.ti software (Berlin, Germany) to manage textual data.

RESULTS

From 249 safety huddle reports, we identified 3270 safety concerns (mean: 13/day). Of these, 245 (7%) were EHR-related. The proportion of EHR-related safety concerns was higher in the go-live stage (first 3 months, 12.6%), but remained constant at about 7% in the final 3 months (Figure 1).

Figure 1.

EHR-related safety issues and the 3 most common sociotechnical dimensions identified over the study period

We classified EHR-related safety concerns into 6 of 8 sociotechnical dimensions listed in Table 1; 2 dimensions, “external rules” and “monitoring,” were not found relevant for this purpose. The most common error was “EHR technology working incorrectly” (41.6%), followed by issues with the EHR system not working at all (25.7%). Missing or absent EHR technology was associated with 16.7% of reported safety issues. Finally, EHR concerns regarding user errors were linked to the remaining 15.9% of reports. Boxes 1–3 provide examples of safety issues for each of these according to the 6 sociotechnical dimensions included in this analysis.

Box 1.

Examples of EHR-related safety concerns: EHR Technology not working at all.

Hardware

Device failure: Intravenous (IV) labels printed for both IV and first-dose medications. Incompatibility between devices: Obtaining computed tomography (CT) results proved difficult. System automatically sent numerous images to radiologist.

Software

Unexpected design issue: Scanned medication in Epic did not show as partial package, and patient received 20 mg instead of 10 mg. Loss or delay of data/Errors in data transmission: Orders released failed to flow, and work list was not visible. Loss or delay of data/Error in data display: When patient was added to EHR system, multiple orders were created, and inaccurate information was displayed.

Clinical content

Incorrect/inappropriate reference information: EHR defaulted to 50 units of insulin for a patient who was taking 13 units. Incorrect/inappropriate charting templates: Epic prepopulated protocol for diltiazem (Cardizem) drip; however, there was no protocol.

People

System configuration issues: Intensivist could not order in EHR because system did not allow access. Human factors: Physician failed to enter correct phase of care (enoxaparin [Lovenox] autoverified).

Workflow and communication

Mismatch between workflow and HIT/Mismatch between actual and EHR-reported patient location or status: EHR and lab were not able to process orders of discharged patients as outpatients. Mismatch between workflow and HIT: Epic changed NICU TMP process without notification, requiring sign-off by 2 pharmacists.

Human-computer interface

Errors in data display: Though physician had signed and held orders, they were not visible. Data entry errors/Excessive time demand: Entering newborn in system required 1.5 hours, which forced using downtime orders for lab.

aNote: These examples illustrate the types of errors described in Table 1.

Box 3.

Examples of EHR-related safety concerns: EHR Technology missing or absent and EHR-related concerns linked to user errors.

Software

Software unavailable: Disparity in Epic reporting statistics; no unified reporting across system, requiring staff to count. Unexpected design issue: During downtime, software put medication on auto-hold, and a patient missed a dose during transfer from MS/S to OR. Loss or delay of data/Error in data display: EHR failed to flag methicillin-resistant Staphylococcus aureus (MRSA) in returning patients. Loss or delay of data/Error in data transmission: AVS print did not list pending appointment in EHR.

Clinical content

Incorrect/inappropriate reference information/Missing content: EHR could not document pain scale (missing safety feature). Incorrect/inappropriate reference information/Erroneous content: EHR misplaced renal protocol with infusion protocols.

People (user errors)

Human factors/Failure to carry out duty: Personnel failed to follow policy or procedure. Human factors/Inattention: Data were entered incorrectly. Staff qualifications/Inadequacies: Inadequate training, knowledge, or experience, including inability of nurses to perform when Epic did not have workup for suspected transfusion reaction.

Workflow and communication

Mismatch between workflow and HIT: Epic had no process for checking patient back in if procedure took multiple days. Mismatch between workflow and HIT: Lab work list in EHR did not include “collect,” requiring workaround.

Human-computer interface

Errors in data display: Epic had no method for tagging patients on dialysis. Data entry errors: Epic did not ask for dual verification with total parental nutrition (TPN). Dual verification for pediatric medications was missing.

Internal organizational features

Policy in conflict with workflow: EHR would not admit patient unless baby was born. Absence of protocol/Standard process: No standard process in place for scanning handwritten prescriptions into EHR.

aNote: These examples illustrate the types of errors described in Table 1.

Of the sociotechnical dimensions, “hardware/software,” “clinical content,” and “people” accounted for nearly three-quarters (74.7%) of all safety issues identified (Table 1). Most EHR-related issues found were related to the “hardware/software” dimension (80/245, or 32.7%), which included 2 subcategories: “hardware malfunction” (9/80) and “software malfunction” (71/80). In breaking down the category further, we determined that errors related to “loss or delay of data” accounted for four-fifths of all issues within the “hardware/software” dimension (65/80). “Loss or delay of data” included 24 concerns related to errors in data transmission, including failure of transmission of laboratory orders from the laboratory system to the EHR and failure of the EHR to display accurate information. This subcategory also included 11 instances where various aspects of the EHR software, such as results display or order entry, were not available for use.

The “clinical content” dimension accounted for the second largest share of issues (53/245, or 21.6%), and it included errors related to “incorrect/inappropriate reference information” (47/53) and “incorrect/inappropriate charting templates” (6/53). The reference information issues were mostly related to erroneous or missing information in the EHR.

The “people” dimension accounted for 20.4% of issues (50/245). These included user errors such as “failure to carry out clinical duties” (11/50), “inattention to detail” (18/50), and “shortcomings in staff qualifications” (10/50). The remaining issues in the “people” dimension resulted from local system administrators following poor system configuration procedures, such as assigning incorrect role-based access privileges to some clinicians.

The remaining quarter of EHR safety issues were related to “workflow and communication” (31/245, or 12.7%), “human-computer interface” (28/245, or 11.4%), and “internal organizational features” (3/245, or 1.2%). “Mismatches between workflow and health IT” were responsible for nearly all issues identified in the “workflow and communication” dimension (29/31). The “human-computer interface” dimension was characterized by concerns with “errors in data display” (18/28) and by “data entry errors” (10/28). The 3 events classified as concerns in “internal organizational features” were “policy in conflict with existing clinical workflow” (1/3) and “absence of a protocol or standard process” (2/3).

DISCUSSION

Despite calls for greater attention to EHR-related safety risks,, most HCOs do not have well-developed systems to identify and address such concerns. Our analysis of 249 daily safety huddle briefing reports identified 245 instances (7%) of EHR-related safety concerns, suggesting that EHR safety discussions represent a noteworthy proportion of all patient safety discussions within huddles. While direct comparisons might be somewhat limiting, compared with previous studies of EHR-related safety events reported in large databases,,, this study found a much higher frequency of EHR-related safety concerns. For example, Magrabi et al. found that only 0.1% of all reports in the Food and Drug Administration’s Manufacturer and User Facility Device Experience (MAUDE) database involved health IT–related errors. In another study, Magrabi et al. examined reports from a voluntary incident reporting database and found that only 0.2% involved information technology systems. Although incident reporting offers a valuable source of information regarding safety issues, such voluntary reporting systems are likely to underreport the number of actual errors. Several factors, such as perceived difficulty in using the system, lack of training in use of the incident reporting process, and time required to report errors, can lead to underreporting of safety issues. In our study, safety concerns were communicated verbally during the daily huddle briefings and provided a less burdensome and more conversational mechanism by which to discuss sensitive issues. Additionally, incentives attached to the “great catch” program run by the hospital to report “near-miss” safety events possibly encouraged staff members to report safety issues.

Our analysis revealed that problems with hardware/software accounted for one-third of EHR-related safety concerns. Errors related to EHR technology working incorrectly were the most common problems encountered. The ECRI Institute Patient Safety Organization’s Deep Dive analysis of more than 170 health IT–related events found that system configuration issues (ie, errors created by those responsible for setting up the EHR rather than its developers) (44%) and software functionality concerns (64%) were among the top 5 safety issues reported by HCOs. Another study, based on 149 reports of health information technology patient safety–related incidents reported to the National Healthcare System in Wales, found that the majority of incidents (77%) were machine-related (technical problems), such as access problems, computer system down or too slow, display issues, and software malfunctions. The types of EHR-related safety incidents identified during the huddle briefings were similar to those reported in the previous studies. However, the relative proportion of technology-related issues might be lower, because we used a broader sociotechnical framework to analyze these concerns.

Previous studies have used various sources, such as claims databases, incident reporting systems,, case reports, and adverse and sentinel event reports to the Joint Commission, to examine EHR-related safety issues. However, outside of research endeavors, organizations often do not routinely monitor EHR safety issues, and the analysis and learning from these new types of risks are not well integrated with an HCO’s traditional patient safety program. Institutional programs that foster a culture of EHR-related safety are essential but rudimentary. The usual retrospective data sources capture events that occurred days, weeks, or even months in the past, making it more difficult to achieve “collective mindfulness” at an organizational level to proactively detect and address new problems. This is compounded by the distributed nature of these systems and lack of feedback to end users regarding the consequences of their actions.,

Because raising awareness of EHR-related safety concerns may require collaboration across departments and specialties, institutional safety huddles can be an effective strategy to share information about actual or potential EHR concerns with the entire health care team. Studies of huddle implementation show improved communication and collaboration among team members.,,, By providing a platform for team discussion and collaboration among IT and non-IT stakeholders (such as laboratory and pharmacy personnel, clinicians, and administrative leadership), safety huddles can increase various team members’ situational awareness about EHR-related safety, facilitating identification of concerns and development of plans to mitigate those concerns. The “blame-free” culture created by safety huddles supports open communication, and using this proactive approach could allow earlier identification of safety issues and swift resolution as issues emerge. We found a consistent increase in the number of overall safety issues reported during the 13-month study period. To encourage reporting of safety issues, “great catches” were rewarded through an internal recognition program, which was enthusiastically supported by the frontline staff. Within the “safe place” created by the huddle, participants became increasingly comfortable to report safety issues, which ultimately led to increases in reporting and discussion.

Other HCOs could consider safety huddles as a venue to raise concerns and share information about ongoing EHR safety issues, a process that could also involve the vendors. This could foster greater interdepartmental communication and situational awareness than could be garnered from other current methods, including incident reporting. Although identifying EHR-related safety risks is the first crucial step toward improving safety, the impact of this strategy comes from evaluating how those issues are resolved. The huddle methodology discussed herein could offer HCOs a potential strategy to keep track of unresolved safety issues and develop mechanisms to address such concerns.

Our study has several limitations. Daily huddles only lasted ∼20 minutes, and notes on the brief discussions that ensued were manually compiled by a single note-taker. We could not confirm the validity of safety concerns documented, and the reports often lacked sufficient details about why these issues emerged. Thus, underlying causes of these events could not always be determined. Representatives from the EHR vendor were not involved in huddle discussions, which could limit discussion on how key issues, such as organizational configuration decisions, EHR design, or functionality, could contribute to the safety issue being discussed.

We could not ask additional questions (probing) to clarify reported safety concerns. Although safety huddles provided a convenient platform for reporting concerns, they relied on health care team members’ ability to recognize an EHR-related safety issue as well as their willingness to bring up the issue during the huddle. If team members did not attend the huddle or did not recognize that the EHR system contributed to the issue, it is likely that the huddle missed key information. Furthermore, reporting safety issues in an open group-discussion setting can introduce some bias. For example, it could be possible that relatively fewer serious safety events (near misses) would be reported during the huddle briefings. Finally, our findings were based on data from a single hospital and might not be representative of all types of EHR-related safety issues. Despite these limitations, safety huddle briefings provided an efficient mechanism for sharing information about a wide range of ongoing EHR-related safety concerns.

CONCLUSION

In conclusion, our study suggests that the “blame-free” culture created by safety huddles supports open communication among key administrative, clinical, and information technology staff. Safety huddles could potentially serve as an important methodology for institutions to identify, understand, and address the complexity of EHR-related patient safety concerns. Based on our findings, we recommend that other HCOs consider them as a strategy to promote understanding and improvement of EHR safety.

SUPPLEMENTARY MATERIAL

Supplementary material are available at Journal of the American Medical Informatics Association online.

FUNDING

This study was funded by the Agency for Healthcare Research and Quality (R01 HS022087). In addition, Dr Singh’s research is supported by the VA Health Services Research and Development Service (CRE 12-033; Presidential Early Career Award for Scientists and Engineers USA 14-274), the VA National Center for Patient Safety, AHRQ (R21HS023609), and in part by the Houston VA HSR&D Center for Innovations in Quality, Effectiveness and Safety (CIN 13–413). Dr Giardina is a VA Health Services Research postdoctoral fellow supported by the VA Office of Academic Affiliations, Advanced Fellowships in Health Services Research.

COMPETING INTERESTS

None.

Click here for additional data file.

Box 2.

Examples of EHR-related Safety concerns: EHR technology working incorrectly.

Hardware

Device failure: BCA computer failed to print reports needed for downtime.

Software

Unexpected design issue: Preadmission orders inaccessible, and software created another account after admission. Loss or delay of data/System unavailable: Epic quit flowing from monitors in all areas, which required 5–20 min offline to restart. Loss or delay of data/Error in data display: System failed to display an EHR pain assessment previously reviewed.

Clinical content

Incorrect/inappropriate reference information: Epidural label default was off by a decimal. Incorrect/inappropriate charting templates: Lab orders placed by clinic physicians were not linked to patient appointments.

People

System configuration issues: System configuration prevented access by dialysis nurses. Human factors: Prescription for blood pressure medication filled incorrectly, error went undetected through 4 steps, and medication was received by patient.

Workflow and communication

Mismatch between workflow and HIT: Unable to document gynecological operating room in EHR if patient was not in labor. Mismatch between workflow and HIT: Mother’s and newborn’s charts neither linked nor merged.

Human-computer interface

Errors in data display: Orders for patients transferred to other units were not visible on new unit. Data entry errors: Unable to scan in EHR, requiring manual override for emergency blood transfusions.

aNote: These examples illustrate the types of errors described in Table 1.

1. CMO – Chief Medical Officer

2. COO/CNO – Chief Operating Officer/Chief Nursing Officer

3. COC Director – Continuity of Care Director

4. CEO – Chief Executive Officer

5. CFO – Chief Financial Officer

6. Asst. CMO – Assistant Chief Medical Officer

7. Legal Counsel

8. Perioperative Supply

9. Women and Children Coordinator

10. Emergency Department

11. Biomedical Engineering

12. Director of Laboratory

13. Clinical Informatics

14. Clinic Nurse Manager

15. Respiratory

16. Clinic Operations

17. Supply Chain

18. Clinical Education

19. System Director of Facilities

20. Pharmacy

21. Radiology

22. NICU Manager – Neonatal Intensive Care Unit Manager

23. Patient Relations Manager

24. PACU/OR Manager – Post–Anesthesia Care Unit/Operating Room

25. Dialysis Manager

26. Manager of Information Services

27. ICU Manager

28. Director of Operating Room/Endoscopy/Day Stay

29. Medical and Surgery

30. Marketing Director

31. Director of Integrated Services

32. Director of Support Services

33. Director of Rehabilitation Services

34. Manager Catheterization Lab

35. Pediatrics

36. Staff Services

37. Medical Director of Quality and Safety

38. Infection Prevention Manager

39. Facility Manager

40. Director of Patient Access