Transcript Survey of Medical Informatics

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 lowreliability 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 nonconsequential 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