Section 19.5: Case Study – Governance Failure Analysis

19.5.1 The “Why”: The Proactive Power of Learning from Failure

In healthcare, we are trained to strive for perfection. As a pharmacist, your entire career has been built on a foundation of precision, accuracy, and the relentless pursuit of zero errors. Yet, despite our best efforts and intentions, mistakes happen. Systems fail. Patients are harmed. In these moments, the character of an individual and the maturity of an organization are revealed. A low-reliability organization responds with blame, seeking to punish the individual who made the final error in a long chain of system failures. A high-reliability organization, in contrast, responds with a deep, almost obsessive curiosity. It asks not “Who did this?” but “Why did our system allow this to happen?” This fundamental shift in perspective is the heart of a just culture and the engine of all meaningful safety improvement.

Nowhere is this more critical than in health informatics. A flawed piece of clinical software is not like a single misfilled prescription that affects one patient at one point in time. A flawed clinical decision support (CDS) alert or a poorly designed order set is a latent error—a hidden trap—that can be replicated hundreds or thousands of times, endangering countless patients until it is discovered. For this reason, we cannot afford to wait for our own failures to learn. We must become students of failure, actively seeking out and dissecting the mistakes of others to proactively identify and mitigate the same vulnerabilities within our own systems. Performing a rigorous Root Cause Analysis (RCA) on a governance failure is not an academic exercise; it is an essential professional competency for any informatics leader.

This section is designed to be your masterclass in that process. We will step into the role of safety investigators and perform a detailed forensic analysis of a fictional but highly realistic case study: a patient harm event caused not by a single clinician’s mistake, but by a catastrophic breakdown in informatics governance. We will peel back the layers of this failure, moving from the sharp end of the error—the harm itself—to the blunt end, where the flawed decisions were made months or years earlier. By understanding how a series of seemingly small deviations from good governance can cascade into a tragedy, you will learn to recognize the early warning signs in your own organization. This deep dive will equip you with the analytical tools to not only respond to failures but, more importantly, to build the resilient, well-governed systems that prevent them from ever happening in the first place.

19.5.2 The Case of the Silent Alert: A Governance Failure at General Hospital

To understand the anatomy of a governance failure, we will examine the story of General Hospital, a respected 300-bed community hospital, and their well-intentioned but ultimately disastrous project to improve the safety of Direct Oral Anticoagulants (DOACs).

The Initial Spark: A Good Catch and a Good Idea

The story begins, as many safety initiatives do, with a “good catch.” An experienced renal pharmacist, Dr. Lena Hanson, is reviewing orders for a 78-year-old patient with Stage 4 Chronic Kidney Disease (CKD), whose creatinine clearance (CrCl) was calculated at 22 mL/min. The hospitalist had ordered the standard dose of apixaban, 5 mg twice daily, for atrial fibrillation. Dr. Hanson recognized that the FDA-approved labeling for apixaban calls for a dose reduction to 2.5 mg twice daily in patients with at least two of the following criteria: age ≥ 80 years, body weight ≤ 60 kg, or serum creatinine ≥ 1.5 mg/dL. While this patient only met one criterion (SCr > 1.5), Dr. Hanson’s clinical judgment, supported by various clinical guidelines, suggested that the full dose was likely unsafe given the patient’s very poor renal function.

She contacted the hospitalist, who readily agreed to the dose reduction, and she filed a safety report documenting the near-miss. In the report, she wrote, “This was a potentially significant overdose averted by pharmacist intervention. The EHR provided no warning to the prescriber about the potential need for a DOAC dose adjustment in this renally impaired patient. We should build a CDS alert to prevent this.”

The Rogue Project: The “Skunkworks” Solution

The hospital’s Chief of Hospital Medicine, Dr. Alan Reed, saw Dr. Hanson’s report. Dr. Reed was a technology enthusiast and a hospital leader known for “getting things done.” Frustrated by what he perceived as the slow pace of the formal IT governance process, he decided to fast-track a solution. He approached a talented but junior EHR analyst in the IT department, David Chen, directly.

“David,” Dr. Reed said, “I need an alert. A simple one. If a physician orders apixaban, rivaroxaban, or edoxaban, and the patient’s most recent creatinine clearance is less than 30 mL/min, I want a pop-up that says ‘Severe renal impairment detected. Consider dose adjustment or alternative anticoagulant.’ Can you build that for me?”

David, eager to please a senior physician leader, agreed. He saw it as a simple, straightforward request. Dr. Reed and David worked on the logic together over a few days. They did not consult the Pharmacy & Medication Safety CAG. They did not involve nursing informatics. They did not present the proposal to any formal governance body. They believed they were being agile and responsive, cutting through bureaucratic red tape to implement a needed safety improvement. They called it the “DOAC Task Force,” a team of two.

The Flawed Build and the “Paper” Test

David built the alert. The logic seemed simple on the surface. However, he made a critical, and invisible, technical error. The EHR had two different fields for creatinine clearance: one that was automatically calculated by the system based on lab values, and another that could be manually entered by a pharmacist in a clinical note. David’s alert logic, for technical reasons he didn’t fully understand, only pulled from the manually entered field. He was unaware that this field was only used by pharmacists in about 30% of cases; for 70% of patients, the field was blank, even if the system-calculated value was readily available elsewhere in the chart.

To “test” the alert, David pulled up a test patient, manually entered a CrCl of 15 mL/min into the pharmacist note field, ordered apixaban, and the alert fired correctly. Dr. Reed reviewed this test on David’s computer screen and approved it. “Looks perfect,” he said. “Let’s get it live next week.” They submitted the change request to the Change Control Board as an “expedited” request, with Dr. Reed’s signature as the clinical sponsor. The CCB, seeing the signature of a senior physician leader and a seemingly simple technical change, approved it for deployment without questioning the lack of formal CAG approval.

The Silent Failure and the Tragic Outcome

Two months after the “silent” go-live (announced only in a low-priority IT newsletter), Mr. Charles Davis, an 82-year-old male weighing 58 kg, was admitted for pneumonia. His baseline serum creatinine was 1.8 mg/dL, and the EHR’s lab system automatically calculated his CrCl to be 24 mL/min. He had a history of atrial fibrillation, and the admitting physician ordered apixaban 5 mg twice daily.

The physician, Dr. Miller, placed the order. The alert did not fire. Because no pharmacist had manually entered a CrCl into the specific note field the alert was looking for, the alert’s logic found a null value and did not trigger. Dr. Miller, a busy resident, assumed that the absence of an alert meant the dose was appropriate for the patient’s renal function. The order was verified by a busy evening-shift pharmacist, who also assumed that any critical dosing guidance would be handled by the EHR’s advanced decision support.

Mr. Davis received apixaban 5 mg twice daily for three days. On the fourth day, he had a massive gastrointestinal bleed. He was transferred to the ICU, required multiple blood transfusions, and ultimately suffered a stroke related to hemorrhagic shock. He survived but was left with permanent neurological deficits and required discharge to a skilled nursing facility.

19.5.3 The Root Cause Analysis (RCA): Deconstructing the Failure

Mr. Davis’s tragic outcome triggered an immediate, high-priority safety investigation. The initial reaction from some leaders was to blame Dr. Miller for not manually checking the dose or the verifying pharmacist for missing the error. However, the hospital’s patient safety officer, guided by the principles of a just culture, insisted on a formal Root Cause Analysis to understand the systemic failures that allowed the error to occur. As the lead informatics pharmacist, you are tasked with co-leading this RCA.

The RCA team’s first step is to visually map out the contributing factors using a fishbone diagram (also known as an Ishikawa diagram). This tool helps to move beyond the single “cause” and explore the multiple latent failures across different domains that all contributed to the adverse event.

Fishbone Diagram: The Systemic Failures Leading to the ADE