Upload
madeleine-phelps
View
222
Download
0
Embed Size (px)
Citation preview
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