Survey of Medical Informatics CS 493 – Fall 2004 October 11, 2004 V. “Juggy” Jagannathan

Survey of Medical Informatics

CS 493 – Fall 2004

October 11, 2004

V. “Juggy” Jagannathan

Adverse Event Analysis

Chapter 6: Patient Safety - Achieving a New Standard of Care.

IOM Report

Adverse Event

Defined as “an event that results in unintended harm to the patient by an act of commission or omission rather than by the underlying disease or condition of the patient”

Detecting adverse events

Voluntary and mandatory reporting Retrospective chart review Automated surveillance of EHR, discharge

summaries, claims data Monitor care plans and track discrepancy

between expected outcome and realized outcome

Comparison of approaches

Automated better than chart review better than voluntary reporting

Approaches are complementary

Data requirements for ADEs

Triggers in a chart review (examples): Unexpected need for blood transfusion Transfer to an ICU Comments about drug reaction in the chart Abnormal lab values Unexpected hypotension Mental state change Page 205, box 6-1

Automated review approach

Four different approaches: ICD-9 codes Reports of new allergy Rule-based

Box 6-2 rules for detecting ADEs., page 207 Data mining of textual reports

Diuretic drug fatigue could be a potential adverse event

Box 6-3, page 208

Monitoring the care process

Diabetes Quality Improvement Project (DQIP) set of measures for assessing the quality of adult diabetes care [Table 6- 1 and 6-2 – pg 209-211]

Hemoglobin A1C management Lipid management Urine protein testing Eye examination Foot examination BP management Smoking cessation Influenza immunization and aspirin use

Table 6-3 Physician Order Entry System – validation modules

Analysis of adverse event systems What – adverse event? Which – process caused the event to occur? When – did the event occur and in what

context? Where – did the event occur?

Addressing Errors of Omission Need more data elements from the patient Eg. DQIP Requires statistical analysis

Implications for data standards Precise definition of terms Minimum datasets with coding and narrative

text – page 219 Explicit Data Collection Processes Integrating data across systems and settings

Future Vision

Increasing importance of automated triggers Definition of core constructs Detection of adverse events using claims

data Integrated approach to detecting and

preventing adverse events

Near-Miss Analysis

Chapter 7: Patient Safety - Achieving a New Standard of Care.

IOM Report

Definition of a near miss

One definition: A near miss is an occurrence with potentially important safety-related effects which, in the end, was prevented from developing into actual consequences.

Alternate definition: A near miss is defined as an act of commission or omission that could have harmed the patient, but did not cause harm as a result of chance, prevention or mitigation.

Synonymous to “potential adverse events” or “close calls”

Near miss

Phases Initial failures Dangerous situation Inadequate defenses Recovery

Figure 7-1 pg 228

Near Miss analysis

Intrinsically, as currently organized is a low-reliability system

Importance of near-miss reporting Goals for Near-Miss systems

Modeling – to gain a qualitative insight Trending – to gain quantitative insight Mindfulness/alertness

Causal Continuum Assumption Causal factors that lead to consequential

accidents causal factors that lead to non-consequential events or near misses

Validated in transportation industry – not in healthcare.

Dual Pathway

Analytical pathway Collecting incident data; analyzing root causes

and acting on it Cultural pathway

Changing the culture of identifying and reporting and addressing near misses

The role of the patient

Patient can play an active role Family and friends can play a role

Fundamental aspects of near-miss systems Database of incidents Root-cause taxonomies

Failure root causes Recovery root causes Context variables Free text

Functional requirements of near-miss system General

Integration with other systems such as adverse event reporting

Comprehensive coverage Quality, environment, reliability, cost

Model-based analysis Organizational learning

System Characteristics

Types and levels Table 7-1, pg 235

Implementation and operational factors Nature of information collected Use of information Tools that assist in collection and analysis Reporting mechanisms Organizational buy-in

Problems of data collection

Action oriented Event focused Consequence driven Technical myopia Variable quality

General Framework

Table 7-2 pg. 241

Implications for data standards Definitions and models Taxonomies (ontologies) Design