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

2. Adverse Event Analysis Chapter 6: Patient Safety - Achieving a New Standard of Care. IOM Report

3. 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”

4. 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

5. Comparison of approaches Automated better than chart review better than voluntary reporting Approaches are complementary

6. 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

7. 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

8. 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

9. 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?

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

11. 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

12. 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

13. Near-Miss Analysis Chapter 7: Patient Safety - Achieving a New Standard of Care. IOM Report

14. 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”

15. Near miss Phases  Initial failures  Dangerous situation  Inadequate defenses  Recovery Figure 7-1 pg 228

16. 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

17. 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.

18. 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

19. The role of the patient Patient can play an active role Family and friends can play a role

20. Fundamental aspects of near-miss systems Database of incidents Root-cause taxonomies  Failure root causes  Recovery root causes  Context variables  Free text

21. 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

22. 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

23. Problems of data collection Action oriented Event focused Consequence driven Technical myopia Variable quality

24. General Framework Table 7-2 pg. 241

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