Structured Data Capture (SDC) Patient Safety Event & Adverse Event Reporting Sub-Working Group

1. Structured Data Capture (SDC)Patient Safety Event & Adverse Event ReportingSub-Working Group February 3, 2014

2. Meeting Etiquette From S&I Framework to Participants: Hi everyone: remember to keep your phone on mute  All Panelists • Remember: If you are not speaking, please keep your phone on mute • Do not put your phone on hold. If you need to take a call, hang up and dial in again when finished with your other call • Hold = Elevator Music = frustrated speakers and participants • This meeting is being recorded • Another reason to keep your phone on mute when not speaking • Use the “Chat” feature for questions, comments and items you would like the moderator or other participants to know. • Send comments to All Panelists so they can be addressed publically in the chat, or discussed in the meeting (as appropriate).

3. Agenda

4. Why are we here today?Our Elevator Pitch… Let’s discuss… • How EHRs can be used to collect and transmit data for patient safety and adverse event reporting • What the benefit of this new functionality is for you • Decrease data collection burden by providers and staff • Provide standardized and structured approach for collection and transmission of data • Reduce need to customize EHR and Health IT systems • Remove barriers to volunteer adverse events • Why you should become a Pilot Site • Advance testing and validation of standards that will be included in Meaningful Use and EHR Certification Criteria • Early adopter benefit of implementing new functionality 4

5. Background: SDC Scope of Work • Develop a standards-based architecture so that a structured set of data can be accessed from EHRs and be stored for merging with comparable data for other relevant purposes to include: • The electronic Case Report Form (eCRF) used for clinical research including PCOR • The Incident Report used for patient safety reporting leveraging AHRQ ‘Common Formats’ and FDA Standard Form 3500/3500a • The Surveillance Case Report Form used for public health reporting of infectious diseases • The collection of patient information used for Determination of Coverage 5

6. Background: SDC Standards Focus • SDC standards identified are not ‘new’; most are mature standards being used across industry to meet specific interoperability specifications. • SDC Standards are specified via the SDC Implementation Guide (consensus voting will begin this week) SDC Initiative has identified four *standards that specify how EHR systems can capture and store structured data: • Standard for the structure of the CDEs that will be used to fill the specified forms or templates • Standard for the structure or design of the form or template (container) • Standard for how EHRs interact with the form or template • Standard to auto-populate form or template 6

7. Structured Data Capture (SDC) Initiative:Standards & Harmonization WGs and Timeline APR-MAY 13 FEB-MAR 13 JUN-JUL 13 AUG-SEP 13 OCT-NOV 13 DEC 13 JAN-FEB 14 Use Case & Functional Requirements Standards & Harmonization Pilots & Testing … Kick Off 1/23/13 Pre-Discovery Evaluation... SDC All-Hands Work Group Use Case WG Standards & Harmonization WG Technical Work Stream • Forms SWG • CDE Structure Standard • Container/Template Standard Standards SWG EHR Interaction Standard Auto-populate standard Content Work Stream PH Tiger Team CDC Lead PSE/AE SWG… AHRQ/FDA Lead PCOR Content SWG… NLM Lead

8. PSE/AE SWG Goals & Objectives • Goal: • Validate, test and pilot the S&I SDC interoperability standards that specify how electronic health records (EHRs) can capture and transmit structured data for Patient Safety Event (PSE) and Adverse Event (AE) reporting • Objectives: • Identify Common Data Elements (CDEs) and associated value sets, leveraging AHRQ Common Formats, that can be used for PSE and AE reporting from EHRs • Identify structured forms/templates these CDEs will populate, leveraging AHRQ Common Formats and FDA Form 3500/3500a • Develop PSE and AE Reporting end-to-end workflow (from EHR system to AHRQ Repository and from EHR system to FDA repository) • Identify 2 or more organizations to test and pilot the SDC Implementation Guide in a production or near production environment

9. PSE/AE SWG Approach 1 2 4 3 1 1 1 1 Evaluate Pilots & Update Standards Identify & Execute Pilot Projects Identify Content Requirements Crosswalk Content Requirements to SDC Standards Phases • Review Pilot Performance Metrics • Identify Performance Trends • Gather recommendations for SDC IG updates/revisions • Develop PSE/AE IG Companion Guide (as applicable) • Identify evaluation criteria for Pilot Proposals • Review Pilot Proposals • Finalize PSE/AE Pilot Projects • Kick-off PSE & AE Pilot Projects • Monitor Pilot Progress • Review & validate CF terminology standards • Finalize PSE CDEs & Forms • Finalize AE CDEs & Forms • Identify PSE reporting workflow • Identify AE reporting workflow • Harmonize PSE/AE CDEs • Map PSE & AE CDEs and Forms to SDC IG Specifications • Review SDC IG against workflow requirements • Develop Gap Mitigation Plan for Pilots Activities • Pilot Performance Trends Report • PSE/AE IG Companion Guide • Pilot Evaluation Criteria • Pilot Proposals • Pilot Performance Metrics Report • Pilot Status Reports • SDC Compliant PSE & AE CDEs & Forms • SDC IG & PSE/AE Workflow Crosswalk • PSE/AE Pilot Gap Mitigation Plan • PSE CDEs & Forms • AE CDEs & Forms • PSE Workflow • AE Workflow Outputs ~ 4 months ~ 6 to 10 months

10. PSE/AE SWG Timeline: Feb 2014 – Feb 2015 CF Terminology Standards PSE & AE Reporting CDEs & Forms Review PSE & AE Reporting Workflow Development PSE & AE CDEs/Forms Mapping to SDC Specifications SDC IG & PSE/AE Workflow Crosswalk PSE/AE Pilot Gap Mitigation Plan PSE/AE Pilot Proposal Review PSE/AE Pilot Monitoring & Evaluation PSE/AE Companion Guide Development PSE/AE Pilots Wrap-Up PSE/AE SWG Launch PSE/AE Pilots Gap Mitigation Plan Complete PSE/AE Pilots Close PSE/AE CDEs/Forms Mapped Milestones PSE/AE Companion Guide Complete PSE/AE Workflows Complete

11. SDC IG Specifications Mapping Structured Data Capture Implementation Guide Document Section 2.4: Specifies the attributes or characteristics (‘metadata’) by which to define data elements. Section 2.5: Specifies the attributes or characteristics (‘metadata’) by which to define the structure of forms used for data entry.

12. SDC IG Transactions Crosswalk PSE & AE Reporting Workflow Generic Workflow Structured Data Capture Implementation Guide Document SDC Transactions

13. Out of Scope Activities • Identification of new AHRQ Common Formats data elements (DEs) and forms • Will leverage Version 1.2 of the Common Formats • If new DEs are identified, they will be reviewed for inclusion in future versions • Identification of new FDA Adverse Event Reporting data elements and forms • Will leverage FDA Regulated Medical Product Terminologies listed in NIH NCI EVS and MedWatch Standard Form 3500/3500a • Identification of a new library, repository or registry to curate and manage PSE and AE DEs and forms • Automating the selection of proper forms for PSE/AE submission

14. Patient Safety Event Reporting Dr. William Munier, Director, Center for Quality Improvement and Patient Safety Rory Jaffe, MD MBA, Executive Director California Hospital Patient Safety Organization

15. Role of Common Formats in SDC • AHRQ developing Common Formats over the past six years • Common Formats represent common language for patient safety reporting • Provide generic module outlining core Data Elements • Provide representation for event-specific Patient Safety Report

16. Common FormatsData Elements (DEs) & Forms Event Specific DEs Category Specific Forms • Blood & Blood Products • Device & Medical or Surgical Supply • Fall • Healthcare-Associated Infection • Etc…. + Generic DEs • Reporter • Location • Harm Level • Patient Demographics • Etc… Generic Form 16

17. Structured Data Capture Conceptual Workflow CDE Library 1 Sends request for form/template Form/ Template Form Library Repository Metadata 2 Source Sends requested form/template External Data EHR System Repository SDC Scope 3 Converts, populates & displays form Specified Structured Displayed Form/Template Captured Data Form xx 4 Fills, stores/transmits structured data John Doe x x x x x 5 Actor Key Forms Filler Extract, Transform, & Load Data by form/ template Forms Manager External Repository

18. SDC PSE Data Flow: Provider to PSO to NPSD To be validated by SWG in Phase 1 AHRQ National Quality Reports Incident Reporting Provider Environment System Patient Safety Network of Patient Work Product Safety Databases (NPSD) Patient Safety Provider Evaluation System Non-identifiable Researchers/ Policy Makers

19. SDC Use Case:Patient Safety User Story A patient in a hospital setting receives healthcare services and the corresponding information (e.g., lab results, medication or medical product information, etc.) is entered or uploaded into the EHR system. One dose of diazepam 10 mg was ordered for the patient at 20:00. The order was not discontinued by the system and was listed on the Medication Administration Record (MAR). The patient was given a second dose of diazepam on the same day at 22:00. Patient remembers getting out of bed during the night to use the bathroom and falling. He was found lying next to his bed with forehead laceration requiring suturing.  The adverse event has been identified by the Provider, and the known adverse event report form is requested within the EHR system, rendered, and populated with related patient information from the EHR. The auto-populated form is then displayed within the EHR System. Once initial information is entered by the Provider, the partially completed report is then stored in the organization’s incident reporting system. The patient safety/quality manager, risk manager, healthcare practitioner or other staff enters any additional informationand completes the report.  Once completed, additional analysis can be performed locally at the healthcare facility and/or the completed report can be sent to the organization’s PSO.

20. Why Use EHRs for PSE Reporting? The Problem • HHS Office of Inspector General Reports: • 13.5% of hospitalized Medicare beneficiaries experience series adverse events; additional 13.5% experienced temporary harm events • Hospital staff did not report 86% of events to Incident Reporting Systems • Inconsistent identification of adverse events within hospitals and across hospitals • Confusion among front line staff regarding what constitutes an event to be reported • Additional provider and staff burden to complete and submit a Patient Safety Event report (in addition to other reporting requirements)

21. Why Use EHRs for PSE Reporting? The Solution • Decrease data collection burden for providers and staff • Single sign on enables collection and submission of data using one system • EHRs using SDC standards can readily access and render AHRQ authorized Common Formats (CF) • CF provide comprehensive set of modules for capturing patient safety event data from ANY patient safety concern • CF provide standardized data elements and forms that can be rendered by any EHR system using SDC standards • Reduce need to make site-specific modifications to EHR system and affiliated systems to enable participation in patient safety event reporting • Remove barriers to volunteer adverse event to AHRQ leading to improvements in population health

22. Adverse Event Reporting MitraRocca, Associate Director, Medical Informatics, FDA

23. SDC Use Case:Adverse Event, Medical Device User Story • On April 1, 2011, a 75 year old male with known heart disease was rushed to the Cardiac Catheterization Lab and a coronary stent was deployed per hospital protocol. After stent insertion, the deployment balloon was unable to be deflated.  The balloon had to be forcibly retracted back into the guiding catheter.  A second stent was introduced without problems.  The scanning of multiple stents triggered a dialogue box within the EHR asking “Why is this device being returned?”  If the answer indicates an adverse event,the EHR retrieves a FDA 3500A form, (or FDA 3500 form for voluntary reporting) auto-populates with patient and incident-specific data, and enters any additional information or text into the form.  The ‘preliminary report’ is then stored on the hospitals Incident System and referred to the Patient Safety Officer/Risk Manager for further evaluation.  Upon completion, the Safety Officer/Risk Manager can:  1) identify the root-cause and suggest/request corrective action; 2a) submit to FDA or FDA Center for Devices and Radiological Health, if necessary;2b) submit a copy tothe device manufacturer; and/or 3) submit tohospital affiliated PSO.

24. Background • 2005: Formed an interagency committee to develop AHRQ Common Formats • Collaborated with CDER, CDRH and CBER to gather adverse event reporting requirements • 2013: Continued Collaboration with CDRH to include UDI in AHRQ’s Common Formats • Interest in aligning workflow for AE reporting from EHRs with that of PSE reporting from EHRs • FDA conducted the following demonstration projects: • ASTER • Collaborated in the pilot with Partners Healthcare System and Pfizer • Conducted the pilot (FHA Interoperability Showcase, HIMSS 2010) • ASTER-D • DIA Interoperability Showcase 2011 • Demonstration Project with Mercy Health (ended 12-31-2013)

25. FDA AE Reporting Regulations:Drugs 21CFRPart11, Section: 314.80 Adverse drug experience. Any adverse event associated with the use of a drug in humans, whether or not considered drug related, including the following: An adverse event occurring in the course of the use of a drug product in professional practice; an adverse event occurring from drug overdose whether accidental or intentional; an adverse event occurring from drug abuse; an adverse event occurring from drug withdrawal; and any failure of expected pharmacological action.

26. FDA AE Reporting Regulations:Devices 21CFR803.3 Medical Device Reporting (or reportable event) • An event that user facilities become aware of that reasonably suggests that a device has or may have caused or contributed to a death or serious injury; or • An event that manufacturers or importers become aware of that reasonably suggests that one of their marketed devices: • May have caused or contributed to a death or serious injury, or • Has malfunctioned and that the device or a similar device marketed by the manufacturer or importer would be likely to cause or contribute to a death or serious injury if the malfunction were to recur.

27. Types of FDA AE Reporting • Mandatory Adverse Event Reporting • Leveraging Standard Form 3500a • Voluntary Adverse Event Reporting • Leveraging Standard Form 3500

28. Mandatory AE reporting: MedWatch Standard Form 3500A 28

29. Voluntary AE reporting: MedWatch Standard Form 3500 29

30. AE Reporting GuidelinesExample

31. FDA Drug & Common Formats: Data Element Overlap SAMPLE FDA Drug Data Elements AHRQ Common Formats Data Elements • Patient Identifiers • Provider Identifiers • Preexisting Medical • History • Frequency • Indication • ….. • Stage of Process, when event occurred? • Compounded preparation • … • RoA/ Intended administration route • Expiration Date 31

32. FDA Device & Common Formats: Data Element Overlap SAMPLE FDA Device Data Elements AHRQ Common Formats Data Elements • Concomitant Medical • Products and Therapy Dates • User Facility or Importer Name/Address • Relevant Tests • Lab Data, Including Dates • Other Relevant History, Including Preexisting Medical Conditions • … • Briefly describe the location where the event occurred or where the unsafe condition exists • ‭Patient's Medical Record No. • Was any intervention attempted in order to "rescue" the patient (i.e., to prevent, to minimize, or to reverse harm)? • … ‬ • Was a device intended for a single use reused in the event or unsafe condition?‬ • Report Date • Gender • UDI • Model No. • Serial No. • Reporter’s Job 32

33. AE Device Conceptual Workflow Example AE Device Workflow (source: Mercy Health)

34. AE Reporting Conceptual Workflow Healthcare Provider Environment Incidence Reporting System PSO Report Uses AHRQ Common Formats FDA Forms 3500/3500A Uses ICSR

35. Why Use EHRs for AE Reporting? • Data collection is incorporated at the point of care • Fits into the healthcare providers workflow • Eliminate duplicate data entry • Light foot print for EHRs and other affiliated clinical information systems • Remove barriers to voluntary adverse event reporting to FDA and mandatory as appropriate leading to improvements in population health

36. AHRQ – FDA Data Element Harmonization Effort FDA Individual Case Safety Reports

37. SDC PSE/AE Pilot Program

38. Aim for Pilot Program • Bring awareness on available national standards that will facilitate how PSE and AE data is collected and reported by EHR systems • Identify additional content and workflow requirements for reporting • Provide tools and guidance for managing and evaluating SDC PSE & AE Pilot Projects • Create a forum to share lessons learned and best practices • Real world evaluation of SDC Implementation Guide (IG) • Is this implementable? Useable? • Harmonize PSE & AE data elements and forms

39. Why Pilot SDC Standards? • Demonstrate compliance with AHRQ PSE & FDA AE Reporting Requirements • Increase efficiency of development and maintenance of SDC standards • Advance Stage 3 Meaningful Use of EHRs Learning Health System where patient information can flow securely from EHRs to other systems • Validate criteria for inclusion in ONC EHR Certification Program • Reduce data collection burden on health care providers • Improve comparability of data to better inform research, quality reporting and ultimately, influence patient care • Contribute to the PSO community • Be recognized as an early adopter

40. Efficiencies in Reporting to Federal Agencies MedWatch MedWatch Patient Safety Vaccine Safety Work Product Form 3500 Form 3500a Provider

41. Call for Participation • The Patient Safety Event and Adverse Event Sub-working Group (PSE/AE SWG) is open for anyone to join. • This sub-working group will meet weekly by webinar and teleconference. • Meeting information can be found on the SDC Wiki: • http://wiki.siframework.org/Structured+Data+Capture+Initiative • PSE/AE SWG Wiki Page • http://wiki.siframework.org/Structured+Data+Capture+Patient+Safety+Event+and+Adverse+Event+SWG • To make this sub-workgroup a success, we need the help of community members who are eager to make rapid progress on this important project.

42. Next Steps • Step 1: If you are not yet a member of the SDC Initiative, please follow the steps for joining here • http://wiki.siframework.org/Structured+Data+Capture+Join+the+Initiative • Step 2: Join the PSE/AE SWG • http://wiki.siframework.org/SDC+PSE+and+AE+SWG+Signup • Step 3: Attend the weekly PSE/AE SWG Meetings Meeting Name: SDC PSE/AE SWG Day: Mondays (weekly) – Next Meeting is February 10 Time: 1:00 - 2:00 pm Eastern URL: https://siframework1.webex.com/ Dial In Number: 1-650-479-3208 Access code: 665 726 037 • Step 4: Participate as a Reference Implementation / Pilot Site…

43. Step 4: Participate as a PilotGet Started – Fill out the Pilots Interest Survey! http://wiki.siframework.org/Structured+Data+Capture+Pilots If you or your organization are interested in participating, please fill out the short SDC Pilots survey.

44. SDC Community Participation In addition to NIH/NLM, AHRQ and FDA participation in the SDC Initiative, other key stakeholders include: • CMS • CDC • DoD/VA Interagency Program Office • ASPE • PCORi • NCI • Standards Development Organizations: IHE, HL7, CDISC, ISO • Vendors: Allscripts, Siemens, McKesson, Cerner, Greenway, Oz Systems, KBCore

45. SDC PSE/AE SWG Contacts • PSE/AE SWG Community Lead • Dr. Rory Jaffe (rjaffe@chpso.org) • AHRQ Co-Leads • Diane Cousins (Diane.Cousins@ahrq.hhs.gov) • Glenn Egelman (glenn.egelman@ahrq.hhs.gov) • FDA Co-Lead • MitraRocca (mitra.rocca@fda.hhs.gov) • Terrie Reed (terrie.reed@fda.hhs.gov ) • SDC Initiative Coordinator • Evelyn Gallego (evelyn.gallego@siframework.org) • SDC Pilot Support Lead • Jenny Brush (jenny.brush@esacinc.com)