PSO Common Formats for Patient Safety Event Reporting (Text Version)

AHRQ 2008 Annual Conference

Slide Presentation from the AHRQ 2008 Annual Conference

On September 7, 2008, William B. Munier, made this presentation at the 2008 Annual Conference. Select to access the PowerPoint® presentation (270 KB; ).

Slide 1

Patient Safety Organization (PSO) Common Formats for Patient Safety Event Reporting

AHRQ Annual Conference 2008
William B. Munier, MD, MBA
7 September 2008

Slide 2

The Patient Safety and Quality Improvement Act of 2005

• Encourages formation of PSOs to improve the quality & safety of health care.
• AHRQ will administer rules for listing qualified PSOs.
• Department of Health & Human Services (HHS) Office for Civil Rights will be responsible for enforcing confidentiality.

Slide 3

• Rather than a patchwork of State-by-State protections, there will now be national uniform protections; that is, confidentiality & privilege for clinicians & entities performing patient safety activities.

Slide 4

Common Formats

• PSOs will collect, aggregate, & analyze information on quality & safety of care.
• Statute authorizes collection of this information in a standardized manner.
• Common Formats
  • Allow aggregation of comparable data at local, PSO, & national level.
  • Facilitate the exchange of information.
  • Underlie the ability to compare & learn.

Slide 5

• Common Formats can provide a common language for patient safety reporting across the nation.

Slide 6

Common Formats

• Planning for Common Formats was initiated by AHRQ in 2005.
• Secretary Leavitt authorized their development & deployment in 2006.
• AHRQ began:
  • Developing a conceptual framework.
  • Compiling an inventory of reporting systems.

Slide 7

World Health Organization (WHO) International Classification of Patient Safety (ICPS) Framework

The chart shows the framework for the WHO International Classification of Patient Safety.

• Event Modifiers:
  • Preventative factors (+).
  • Recovery factors.
  • Mitigating factors.
• The Event Modifiers influence:
  • Contributing factors*, which lead to.
  • Event Types**.
    • Have Patient characteristics.
    • Have Event characteristics.
  • Which lead to Patient impact/outcomes** and Organization outcomes.
  • Actions taken.

• Note: *Includes active factors & latent factors.
• Note: **Core framework class vs. framework class.

Slide 8

Design Goals

• Be as short & simple as possible.
• Be driven by envisioned uses.
• Be dynamic; meet altered needs & circumstances.
• Be modular.
• Permit controlled expansion/revision.
• Use existing definitions & data elements to the extent consistent with conceptual requirements.

Slide 9

Conceptual Framework

• Limit scope to safety: preventing harm to patients from the delivery of health care.
• Develop for specific delivery settings.
• Construct in modules.
  • Those concerns that apply to all events being reported, e.g., who, what, when, where.
  • Those concerns that pertain to specific types of events, e.g., falls, medication errors.
• Specify requirements adequately to support software system development.

Slide 10

Modularized Common Formats

The chart shows squares in a clock-like formation with arrows radiating from the top square, "PSE [Patient Safety Event] Overview." In clockwise order they read as follows:

• PSE Overview
  • Identity
  • Facility
  • Time
  • Location
  • Reporter
  • Narrative
  • Link to forms
• Mitigating Actions
  • Recovery
  • Rescue
• Consequential Actions
  • Internal
  • External
• Immediate Impacts
  • Organizational
  • Care processes
• Event-Specific Details
  • About 24 types of events
• Patient Information (1, 2, 3)
  • Demographics
  • Harm
• Staff Information
  • Demographics
  • Harm
• Associated Inputs
  • Administrables (medications, etc)
  • Consumables
  • Devices
  • Research

Slide 11

Modularized Common Formats

The chart shows squares in a clock-like formation with arrows radiating from the top square, "Healthcare Event Reporting Form (HERF)." In clockwise order they read as follows:

• Healthcare Event Reporting Form (HERF)
  • Identity
  • Date, Time
  • Location
  • Reporter
  • Narrative
  • Link to other forms
• Final Assessment Form (FAF)
  • Assessment of
  • Preventability
  • Final narrative
  • Encoding
• Event-Specific Forms
  • Nine types of
  • Events, e.g.
  • Fall
  • HAI
  • Medication
• Patient Information Form (PIF) (1, 2, 3)
  • Demographics
  • Harm
  • Mitigating Actions
  • Interventions

Slide 12

AHRQ Evidence Base of Reporting Systems

The pyramid lists from top to bottom:

• 64 PSERS*.
• >100 PSE reporting forms.
• >1,000 Definitions of PSE terms.
• >10,000 PSE reporting variables.
• Supporting documentation.
  (PSERS descriptions, PSE reporting forms, encoding schemes, patient safety reports, etc.)

• Note: *Patient Safety Event Reporting System.

Slide 13

Inventory Findings

• Few systems collect information on the complete improvement cycle.
• Commonality found for some definitions.
• Variability found for many
  • Clinical event, e.g., adverse drug reaction.
  • Accident, e.g., fall.
  • Demographic, e.g., provider type, facility type.

Slide 14

Common Format Development

• Developed initial common formats with Federal agencies with reporting systems (Centers for Disease Control and Prevention [CDC], Food and Drug Administration [FDA], Department of Veterans Affairs [VA], Department of Defense [DoD], National Institutes of Health [NIH]).
• Conducted two pilot tests in hospitals.
• Contracted with the National Quality Forum (NQF) to receive coordinate feedback.
• Published notice of availability of Common Formats, version 0.1 Beta, in Federal Register on August 29th.

Slide 15

Common Formats Development Cycle

The chart shows the overall process of the common formats development cycle including:
draft event description, soliciting and analyzing feedback, draft event report, and completion and implementation issues.

Slide 16

Common Formats Development Cycle

• Formats will not be subject to:
  • Federal regulatory processes.
  • NQF formal consensus process.
• Formats will:
  • Be updated annually as guidance.
  • Have tight version control.

Slide 17

Your questions?