IHE-Cardiology Technical Committee EP Key Data Elements

1. IHE-Cardiology Technical CommitteeEP Key Data Elements February 21, 2011 Bryan Jennings - Medical Micrographics Nick Gawrit - HeartBase

2. Abstract Define a medical data format for clinical documents containing at a minimum: • Patient Conditions • EP Lab procedure data • Discharge Summary • Pointers to other material

3. Problem Statement • There is a need to be able to extract these data elements from the medical record in an automated, standards based data model that can operate in a cross-platform environment across multiple electronic health records and cardiac rhythm management devices regardless of vendor.

4. Development of Data Standards Currently, clinical personnel, data managers, clinical investigators, and FDA reviewers must cope with a plethora of data formats and conventions. Some clinical investigators report the presence of many different computer systems for data entry at their sites (for various trials), each of which uses different data conventions. Lack of standardization is not only inefficient, it multiplies the potential for error. …

5. Current StateData Capture: Some Sites Looks Like This The virtual version of this mess – multiple web apps on one workstation – is scant improvement.

6. Standards Used • CDA Release 2.0 • ASTM/HL7 Continuity of Care Document (CCD) • HL7 V3 Laboratory DMIM • HL7 Care Record Summary • LOINC & SNOMED • HIPAA Lab Claim Attachment NPRM • Document Digital Signature

7. Use Case • Health care provider needs to collect data to submit to the ACC NCDR-ICD Registry • EMR System would like to display Key Cardiology data in a meaningful way • EP Lab System produces data but needs to integrate with other systems to facilitate data sharing

8. Systems that contain data (to name a few) Boston Scientific St. Jude Medical Medtronic Biotronik Siemens Syngo Siemens Axiom Sensis Bard EP Medical Prucka (GE) Witt (Phillips) Lumedx Biosense MacLab (GE) Merge McKesson Cerner Epic NextGen Allscripts

9. Goal: A Common Terminology Boston Scientific Medtronic Epic St. Jude Medical Biotronik Siemens EP Medical GE Prucka Philips Witt

10. Scope • The clinical CDA document is: • A report of a set of final results (the fulfillment process being completed) will also be shared later as “historical information”. • Human-readable, shared between care providers of various specialties and patients (e.g. through a PHR) • May contain machine readable coded entries(decision support, registry submissions)

11. A CDA content profile is… • A sharable information component that can be exchanged… • within an HIE or RHIO • via Media or USB Device • via Reliable Messages Point to Point • Document content using standards • CDA Release 2.0 • HL7 Care Record Summary • ASTM/HL7 Continuity of Care Document • More complex documents have a library of reusable parts

12. Where Can Cardiology Use CDA? • Clinical Reports (Cath, Echo, EP, etc.) • to go along with our pretty DICOM images • Analyses of raw image and waveform data • backing up the Clinical Report • Documentation of the procedure • provide context for the raw data and analyses • Input to a clinical and Registry database • for patient care over time, or outcomes analysis

13. Value Proposition • Supports interchange of PHR Information • Patient Demographics • Procedure and Device Information • Current and Prior Results • Medications, Problems, Allergies • Diagnoses History • Other Information

14. ACC-ICD Registry Pre-Populated in Interface

15. ACC-Cath PCI Registry Pre-Populated

16. ICD Data Acquisition Workflow • Patient Encounter in ICD Lab • Case completed in Lab and electronically signed • EP Lab data exported to external processing queue • Data processed into format needed for ICD Registry • EP Lab data validated by clinical user • Non-EP Lab data added for submission completion • Registry Submission validated using NCDR tools

17. Retrieve Forms for Data Capture (RFD) • provides a method for gathering data • within a user’s current application • to meet the requirements of an external system

18. Retrieve Forms for Data Capture • A standard way of displaying external data capture forms inside an EHR. • Many-to-many integration – any EHR can retrieve forms from many external systems. • Low barrier of entry for EHR and external systems. • Flexible profile to accommodate both low-tech and sophisticated implementations.

19. Retrieve Forms for Data capture • Initial Phase – Done! • Define standard format for forms • Define standard method for retrieving and submitting forms • Content Profile Phase for Cardiology – now! • Provide domain-specific form requirements • Enable form population from EHR mapped data

20. A D D D Form Filler Form Archiver Form Archiver Form Archiver B C Form Manager Form Receiver RFD Profile Actors and Transactions Form Filler – Form Archiver(s) pairing is a dynamic, Form Filler defined business relationship that cannot be embedded within the RFD Form Form Manager – Form Receiver pairing is a statically defined business relationship based upon the domain, e.g., clinical trials, drug safety, public health, that can be embedded within the RFD Forms

21. Physician Office RFD World Clinical Trials Sponsor Federal or State Agency Drug Safety Data Collection Agency Paired Form Manager / Form Receiver Paired Form Manager / Form Receiver Disease Registry CN-1 A robust Form Filler

22. Example of RFD Form Filler opened in an EMR

23. RFD Displays and Archives Data for Many Uses

24. IHE Web Site - http://www.ihe.net Technical Frameworks Technical Framework Supplements – Trial Implementation Calls for Participation IHE Fact Sheet and FAQ IHE Integration Profiles: Guidelines for Buyers IHE Connectathon Results Vendors’ Product Integration Statements More Information Questions?