1. Webinar Series 2014 Integrating the Healthcare Enterprise International

2. Cardiology Domain Update Nick Gawrit, heartbase Nandhini Kuntipuram, ACC Chris Melo, Philips Healthcare Antje Schroeder, Siemens Healthcare

3. Problems 1-3

4. We are All Part of the Solution

5. Cardiology Domain Update Agenda Cardiology Domain Overview Domain Profiles & Technical Frameworks o New profiles in 2013/2014 o Additional profiles highlighted for 2015 Connectathon o Technical Framework overview Domain Organization o Planning & Technical Committees o IHE International Membership Q&A Session

6. Cardiology Domain Overview IHE Cardiology was formed in 2003 to address issues specific to clinical workflow, information sharing and improved patient care in the clinical domain of cardiology. Care Settings: hospital and cardiology physician practices Sponsors: American College of Cardiology, American Society of Echocardiography, American Society of Nuclear Cardiology, Heart Rhythm Society Closely related domains o Radiology o Patient Care Coordination o IT Infrastructure o Patient Care Devices o Quality, Research and Public Health

7. Cardiology Domain – Key Trends Care Coordination Demands o Consistent use of HL7 Clinical Document Architecture across all clinical domains o Common standards based nomenclature o Support for Meaningful Use objectives and certification criteria Registries, quality improvement programs, and research o Profiling of standard data elements for both clinical and secondary use Expanded use of Electronic Health Record Systems in both the in-patient and ambulatory environments o Need to access, exchange, and incorporate cardiology images and imaging information

8. Cardiology Domain - Current Focus Discrete data capture and codification profiles leveraging clinical guidelines and C-CDA: 2013/14 Electrophysiology Report Content – Implant/Explant (EPRC-IE) 2013/14 Registry Content Submission - CathPCI (RCS-C) 2012 Cath Report Content (CRC) – updated (Rev 1.3) in 2013 2011 Cardiac Imaging Report Content (CIRC) Cardiology workflow profiles with best practice in general imaging: Cath/Echo/Nuclear-Medicine/ECG specializations to existing imaging workflow and evidence gathering profiles. Displayable Reports (DRPT) Image Enabled Office (IEO)

9. New Profiles in 2013/2014

10. Electrophysiology Implant/Explant Report Content (EPRC-IE) Completes the original 2011-2012 proposal request for a cardiac electrophysiology report content profile. Leverages Cardiac EP Key Data Elements white paper published in 2011: http://www.ihe.net/Technical_Framework/upload/IHE_CARD_W P_Cardiac_EP_Key_Data_Elements_Rev1-0_PC_2011-08- 05.pdf http://www.ihe.net/Technical_Framework/upload/IHE_CARD_W P_Cardiac_EP_Key_Data_Elements_Rev1-0_PC_2011-08- 05.pdf Existing IHE profiles like IDCO, CRC and CIRC Standardized Nomenclature – IEEE 11073 MDC IDC, LOINC, SNOMED Registry Specifications – ACC NCDR – ICD HL7 CDA, Consolidate CDA Brings the benefits of structured reports to the EP lab. This is a critical first step to a profile that uses the EP procedure clinical report as pre- population data for submission to a registry. Includes ICD, PPM/IPG, IPG and lead implants and explants. TRIAL New Supplement target for 2015 connectathon

11. EPRC-IE Electrophysiology Lab Procedure Reporting TRIAL <code code=“34896-1” displayName=“Interventional Procedure Note - Cardiology” codeSystem=“2.16.840.1.113883.6.1” codeSystemName=“LOINC”/> Cardiac Catheterization Report <confidentialityCode code=“N” displayName=“Normal” codeSystem=“2.16.840.1.113883.5.25” codeSystemName=“Confidentiality”/> <id extension=“IHE-CardtemplateId” root=“1.3.6.1.4.1.19376.1.4.1.3.1”/> <code code=“425435003” codeSystem=“2.16.840.1.113883.6.96” codeSystemName="SNOMED CT" displayName="Implantation of cardioverter defibrillator with one electrode lead “> –“EP Lab Report Content” profile defines a HL7 CDA structured report (XML) to facilitate consistency, accuracy, and semantic interoperability of ICD and lead implants and explant procedure reports and findings –Based on “NCDR ICD Registry version 1.2 Coder’s Data Dictionary” –Affected systems include: Cardiovascular Information Systems, EHR systems, EP lab analysis and reporting workstations –Aligned with HL7 Implementation Guide for CDA Release 2: IHE Health Story Consolidation, Release 1.1 DSTU –Related links: http://www.ihe.net/Technical_Framework/index.cfm #cardiology http://www.ihe.net/Technical_Framework/index.cfm #cardiology http://wiki.ihe.net/index.php?title=Electrophysiolog y_Report_Content http://wiki.ihe.net/index.php?title=Electrophysiolog y_Report_Content http://ihe.net/uploadedFiles/Documents/Cardiology /IHE_CARD_Suppl_EPRC-IE.pdf http://ihe.net/uploadedFiles/Documents/Cardiology /IHE_CARD_Suppl_EPRC-IE.pdf http://ihe.net/uploadedFiles/Documents/Cardiology /IHE_CARD_Suppl_EPRC-IE_Rev1.1_TI_2014-04- 30_SampleXMLDocument_(noXSL).xml http://ihe.net/uploadedFiles/Documents/Cardiology /IHE_CARD_Suppl_EPRC-IE_Rev1.1_TI_2014-04- 30_SampleXMLDocument_(noXSL).xml

12. EP Report Content (EPRC-IE) TRIAL Based on >100 discrete EP procedure data elements, fully modeled using non-proprietary SNOMED, LOINC, DICOM, and IEEE 11073- 10103 MDC IDC terminologies Created as a new HL7 CDA document template ID using existing sections and entries wherever feasible. –IHE Cardiology CRC content profile –HL7 Implementation Guide for CDA Release 2: IHE Health Story Consolidation, Release 1.1 DSTU -July 2012 (C-CDA) Procedure Note. Structured representation of devices including generators, batteries, and leads, and testing results Supported data import into longitudinal patient tracking databases First step to wider secondary use of report data (outcomes research, quality metrics and quality improvement) Leveraged HL7 CDA capability for both human readable narrative and robust XML-encoded data elements. Reviewed existing industry leading EP facilities focused on reporting workflow and report content.

13. EP Implant/Explant Report Content (EPRC-IE) Why you need it! Context, use cases, and actors Header elements Section content modules Entry content modules Vocabulary constraints and value sets

14. Why you need it! Standard Conformance – enables semantic interoperability o HL7 C-CDA, MDC IDC 11703, SNOMED, LOINC, RxNorm, ICD9/10 Consumption – downstream use is easier with common semantics o EHR, CVIS, o Hospital network, hospital, Physician Practice, HIE Reporting – enables re-use for additional purposes o Procedure Note o Device Manufacturers o ACC NCDR Cost Control o Reduced FTEs needed in the EP lab o Reduced FTEs required for data collection o Reduced FTEs required for transcription Quality Improvement o Device appropriate use o Accurate reporting o Check and balance to registry reporting

15. EPRC-IE Context Clinical Reports for procedures performed in an Electrophysiology Laboratory, including: Implantable Cardioverter Defibrillator (ICD) Implant Permanent Pacemaker (PPM) / Implantable Pulse Generator (IPG) Implant Implantable Cardiac Monitor Implant Lead Implant ICD Explant Generator Change Lead Explant Lead Abandonment Imaging associated with Implant/Explant (e.g. venogram) Future EP procedures report content profiles will focus on EP studies, ablation, and cardioversion. There may be a DICOM Study associated with the exam. In addition to reference images, this study may include discrete data elements encoded in DICOM Structured Report information objects that may be transcoded into the discrete data elements specified in this profile. There are no constraints on the narrative text and figures that the electrophysiologist could include in the report document, although there are requirements on minimum data elements reflecting expert consensus (ACC-NCDR ICD data elements).

16. EPRC-IE Use Cases Report generated for ICD and/or lead implant/explant procedure in the EP Lab Addresses the creation of an EP Implant/Explant procedure note that utilizes industry standards and accepted industry nomenclature. Big benefit, the included discrete data points may be consumed by another system, like an EHR or CVIS. And since standards are being used, data can flow between any system using this format, even if generated from different sending systems. Review Procedure Report Other secondary uses of this report that may it even more valuable. These users include: The referring physician who instigated/ordered the procedure, and other healthcare providers who manage subsequent patient care activities. Another person involved in downstream clinical or administrative data processing e.g., someone validating/source-checking for QA the original report as part of JCAHO audits. The Device Manufacturer who will receive registration of device information.

17. EPRC-IE Actors and Options Actors: Content Creator and Content Consumer Content Creator Create an EPRC-IE document populating the required header elements, sections, and entry content modules Group with a Time Client actor to synchronize its clock Content Consumer Receive and process an EPRC-IE document, parsing the relevant header elements, sections, and entries Implement the View option, the Discrete Data Import option, or both If implements the Document Import or Section Import options, must also implement the View option Options: ActorOption NameOptionalityDescription Content Consumer ViewODemonstrate rendering; print; display with original style sheet; support traversal of any links in document Document ImportOStore the document; access document from storage Section ImportOImport one or more sections as free text Discrete Data ImportOImport structured data from one or more sections Content CreatorNo options defined

20. EP Report - Summary Narrative form of the summary information including the major highlights from each section: Patient demographics History and Physical Procedures and Interventions Findings and Results Equipment and configuration Complications Notes Key images and graphics

21. EP Report – Pre-procedure Documents the key elements from the information gathered prior to the EP procedure being performed, including: Patient demographics Medical, family, and social history Allergies Known problems and symptoms Current medications Physical exam and vital signs Prior procedures and interventions Existing implanted devices and configuration information Pre-procedure results

22. EP Report - Procedure Documents the key elements from the information gathered during the EP procedure including: Procedures performed Medications administered Equipment used, including configuration of leads and generator Device testing performed Complications

23. EP Report – Results and Interpretations Documents the key results, including measurements, findings, and observations, for the EP procedure performed, including: Device configurations Device testing results including impedance measurements Diagnoses Plan of care Additional notes

24. EPRC–IE Relationship with other Profiles Other Content Profiles Cardiac Imaging Report Content (CIRC) Profile – in Trial Implementation Cath Report Content (CRC) Profile – in Trial Implementation Registry Content Submission –Cath/PCI (RCS-C) Profile – Cath/PCI – in Trial Implementation Actor Required Grouping Consistent Time (CT) – for Legal Authentication timestamp to be accurate Cross Profile Considerations – grouping of Content Creator/Content Consumer with actors of workflow profiles that manage interchange of clinical data Displayable Reports (DRPT) - to exchange the EPRC content between Report Creator and Report Manager Cross-enterprise Document Sharing (XDS), Cross-enterprise Document Media Interchange (XDM), Cross-enterprise Reliable Interchange (XDR), Cross-enterprise Document Sharing for Imaging (XDS-I), and Cross-enterprise Reliable Document Interchange for Imaging (XDR-I) - to exchange the EPRC content Cross Enterprise Portable Data for Imaging (PDI) - to exchange the EPRC content via removable media. Retrieve Form for Data Capture (RFD) - to use the EPRC content for pre-population of data entry Document Digital Signature (DSG) – to allow digital signing of the EPRC content

25. EPRC–IE Relationship to C-CDA EPRC is realm agnostic – so it can be specialized for deployments Deviates from C-CDA (US Realm) by not specifying format of addresses, telcoms, names, NPI Utilizes documentation style of C-CDA for defining constraints Where constraints defined in C-CDA were not modified, the constraint remains as the C- CDA constraint identifier (e.g., CONF:5361). If only the value set was modified, then the constraint is considered unchanged. Where constraints defined in C-CDA were modified, the original constraint ID is also modified by appending “-EPRC” (e.g., CONF:5253-EPRC). Modifications could include changes in the cardinality. Where new constraints were introduced, a new constraint identifier was defined (e.g., CONF:EPRC-xxx) Use of C-CDA Sections and Entries If there are no new or modified constraints for a section or entry or if only the value sets are constrained, then the definition of the section or entry is considered unchanged from the C- CDA definition and the C-CDA template ID will be used. These unchanged sections/entries are referenced directly from the C-CDA specification and are not included in this specification. If there are new or modified constraints for a section or entry, then that section or entry is assigned a new IHE Card specific template ID.

26. EPRC–IE Header Elements code - is selected from a value set specific for EP lab reporting. recordTarget – identifies the patient whose health information is described in this clinical document for the procedure. author – represents the creator(s) of the clinical document content. custodian – represents the organization that is in charge of maintaining the clinical document. legalAuthenticator – identifies the single person legally responsible for the document. This profile does not support the exchange of preliminary unapproved procedure reports. authenticator – identifies participants that attest to the accuracy of the information in the clinical document. inFulfillmentOf – represents orders that are fulfilled by this clinical document. For EPRC, the order/id is the Accession Number used in the DICOM imaging data. authorization – contains information about patient consents for the procedure and for the anesthesia. componentOf – contains information about the encompassing encounter for the clinical procedures documented in this report. This includes the clinical setting (location and organization). It also allows for the referring provider, the referring cardiologist, an attending physician and a responsible physician to be identified. documentationOf/serviceEvent – represents the EP procedures that are being documented. This also documents the primary performer and any assistants involved in each procedure.

27. EPRC–IE Section Content Modules (20 total) New sections (3) Document Summary - EPRC Includes a summary of most significant aspects of the procedures in a narrative form. It is a condensed form of the full narrative report whose structure has no constraint. Procedure Description – Cardiac EPIE Adds support for device specific observations. Procedure Results – Cardiac EPIE Adds support for device specific observations. Re-used from CRC profile (4) Medical History – Cardiac Adds support for coded problem observation and procedures. Pre-Procedure Results – Cardiac Adds support for results in external documents. Plan of Care – Cardiac Includes specialized Plan of Care Activity Act with elements. Key Images – Cardiac Contains narrative description of and references to DICOM Image Information Objects that illustrate the findings of the procedure reported. Unchanged sections (13) Allergies Family History Social History Physical Exam Vital Signs Planned Procedure Procedure Indications Anesthesia Medications Administered Procedure Disposition Complications Postprocedure Diagnosis DICOM Object Catalog

28. EPRC–IE Entry Content Modules Unchanged entry content modules (~35) New entry content modules (5) Procedure Device Organizer – Cardiac EPIE contains a set of observations related to a device used during a procedure Device Observation –EPIE represents observations made of devices used during a procedure Procedure Activity Procedure – Cardiac EPIE Extends to support entryRelationship to a Procedure Device Organizer and a Lesion Observation Result Observation – Cardiac EPIE Extends to support an entryRelationship to a Severity Observation Procedure Results Organizer – Cardiac EPIE Extends to include entryRelationship to a Lesion Observation Re-used CRC entry content modules (3) Problem Observation – Cardiac Extends the Problem Observation Entry with an entryRelationship for a Severity Observation Result Organizer – Cardiac Extends to support references to external documents for results Plan of Care Activity Act – Cardiac Extends to support code, statusCode, and effectiveTime elements

29. EPRC–IE Vocabulary Constraints Result observation constraints – defines complete sets of elements for observations, including codes and allowed values Value sets provided for EP specific concept domains Cardiac Problems/Concerns Body Site Cardiovascular Family History Contrast Agents Classes for Adverse Reactions Cardiac Lab Results Vital Sign Results Procedure Indications Contrast Agents Cardiac Activity Procedures Drug Classes and Specific Cardiac Drugs Rx Recommendations Procedure Findings Types Postprocedure Diagnoses Supported File Types Complications

30. Registry Content Submission – Cath/PCI(RCS-C) Develop a CDA implementation guide for data elements to be submitted to registries, including NCDR Cath/PCI registry. Leverages the C-CDA codification and structuring done in CRC profile, expanded to capture the additional information needed for NCDR Registry submission. Authoring of profile led by the ACC-NCDR organization. Aims to make the rich registry data collection needs from multiple clinical/administrative sources more efficient for Registry participants. Aligns data content for Registry collection with emerging best- practice in wider clinical data exploitation initiatives. TRIAL New Supplement target for 2015 connectathon

31. NCDR Today Non-standard NCDR Non-standard NCDR Hospitals using home grown systems Hospitals using ACC’s web tool Hospitals using software vendors Software Vendors Benchmarks & Dashboards FDA Post Approval ACC certification

32. An Interconnected Future Standardized NCDR ICD,CPT, LOINC, SNOMED, NDC Standardized NCDR ICD,CPT, LOINC, SNOMED, NDC Hospitals Using EMRs / EHRs Hospitals Using Home Grown Systems Hospitals Using ACC’s web tool Hospitals Using Software Vendors EHRs & Software Vendors Benchmarks & Dashboards FDA Pre & Post Approval Health Info Exchange Industry Standard Profiles Patients Remote Devices CMS & Other Federal Govt Aligned with CMS Meaningful Use Application Providers Health Plans Health & Fitness Device

33. Getting there … Harmonize Data Definitions Code the definitions using established vocabulary standards (example: SNOMED- CT, LOINC, RxNorm etc.) Represent the encoding, structure and semantics of the clinical content using a standard architecture (HL7 CDA) Use a modular approach that facilitates re-use (HL7 CDA Templates) The interconnected future depends on standards Registry Submission Transaction HL7 Clinical Document Architecture Constraints and Rules

34. What is RCS-C ? RCS-C is a content profile, published as a supplement to IHE Cardiology framework. It provides specification for data submission to the CathPCI Registry v4.4.

35. RCS-C Summary Major highlights from each section: Patient Demographics History and Risk Factor Pre-procedure Activities Procedure Session Events Discharge

37. RCS-C Volume 1 Content creator harvest the relevant encounter data for a submission period, organize them into a series of CDA document(s), and transmits the data as a single package to the clinical registry. –System can harvest data in RCS-C format directly from EMR or similar systems –System can harvest data in RCS-C format from other IHE profiles such as CRC The clinical registry (system) receives the RCS-C document for import. The data is transformed and added to the registry.

38. Multiple Paths to NCDR Registry Submission

39. RCS-C profile Three primary artifacts: 1)RCS-C Content Profile 2)Sample RCS-C CDA Document (XML) 3)Sample RCS-C Data Collection Form (PDF)

40. Other Profiles highlighted for the 2015 Connectathon

41. Image-Enabled Office Bi-directional integration of medical imaging equipment and office EHR Leverages in-patient workflow concepts to minimize impact on imaging devices, but adapted to use with office EHR (EHR-S) EHR – PACS image display integration using Web technologies Integrated EHR-System is an optional integration of an EHR with the image “order filler” (scheduling and management) function Can be implemented with 3 rd party software components without having to expose internal order transactions Agnostic to EHR and PACS deployment technology (on-site, hosted, SaaS, cloud, etc.) TRIAL

42. Cath Report Content (CRC) TRIAL Based on >100 discrete cath & PCI procedure data elements, fully modeled using non-proprietary SNOMED, LOINC, and DICOM terminologies Is not a direct specialization of any existing HL7 CDA document template ID. However, some parts were based on: –IHE Cardiology CIRC content profile –HL7 Implementation Guide for CDA Release 2: IHE Health Story Consolidation, Release 1.1 DSTU -July 2012 (C-CDA) Procedure Note. Allows structured representation of lesions, coronary anatomy and devices Supports data import into longitudinal patient tracking databases First step to wider secondary use of report data (outcomes research, quality metrics and quality improvement) Leverages HL7 CDA capability for both human readable narrative and robust XML-encoded data elements.

43. Technical Framework Overview

44. Profiles & Technical Frameworks IHE Technical Frameworks Final Text: Current version 5.0 Trial Implementation: Supplements http://www.ihe.net/Technical_Framework/index.cfm#cardiology Brief descriptions of Profiles developed by Cardiology Domain http://wiki.ihe.net/index.php?title=Profiles #IHE_Cardiology_Profileshttp://wiki.ihe.net/index.php?title=Profiles #IHE_Cardiology_Profiles Overview FINAL TRIAL

45. Profiles & Technical Frameworks Workflow in the in-patient environment Profiles aligned with IHE Radiology workflow –Scheduled and unscheduled cardiac imaging exams, including multimodality –Management of data, demographic and procedure identifiers –Cardiovascular Information Systems, PACS, imaging and waveform modalities: X-ray and hemo (cath lab), Echo, Nuclear imaging analysis and reporting workstations –Consistent, robust workflow minimizes manual procedure management tasks Cardiac Catheterization Workflow Echocardiography Workflow Stress (ECG + imaging) Workflow Evidence Documents (cardiology specialization) Displayable Reports Workflow Intravascular Imaging Option for Cardiac Catheterization Workflow FINAL TRIAL

46. Profiles & Technical Frameworks Workflow in the ambulatory environment Image-Enabled Office –Bi-directional integration of medical imaging equipment and office EHR –Not limited to cardiology – applies to orthopedics, women’s health, gastroenterology, even primary care –Ambulatory office EHRs, mini-PACS (or cloud PACS), imaging modalities –Supports the 2014 USA Meaningful Use criteria for EHR with imaging (is this still true?) TRIAL

47. Displayable Report Workflow (DRPT) Cardiology reports typically include lots of graphics Addresses workflow between a reporting application and the departmental info system and/or the EMR −Possible report archiving to PACS Report format may be PDF or HL7 CDA Applicable to other clinical domains! TRIAL Profiles & Technical Frameworks Reporting Report Content: CDA structured report (XML) to facilitate consistency, accuracy, and semantic interoperability of imaging findings: Cardiac Imaging Report Content (CIRC) −Based on ACC/AHA 2008 Key Data Elements for Cardiac Imaging Cath Report Content (CRC) −Based on ACC/AHA 2008 Cardiac Catheterization Report Prototype and ACC-NCDR CathPCI Registry v4.4 Coder’s Data Dictionary Electrophysiology Report Content −Based on 2011 Cardiac EP Key Data Elements white paper published in 2011 Registry Content Submission – Cath/PCI (RCS-C) −Based on …

48. Profiles & Technical Frameworks ECG Workflow Retrieve ECG for Display –Access to ECGs from everywhere in the hospital –Resting ECGs, Holter ECGs –ECG Management Systems, EMRs, workstations –Simplified and standardized Web-based access to ECGs; No need for ‘printed ECGs ’ Resting ECG Workflow –Multi-system workflow for the most common cardiology exam –Scheduled/unscheduled, post- exam reconciliation –Cardiovascular Information Systems, ECG Management Systems, ECG devices and workstations, PACS and imaging workstations, EMRs –Components and workflow shared with imaging TRIALFINAL

49. Profiles & Technical Frameworks Radiology –Scheduled Workflow (CT/MR/NM) –Nuclear Medicine Image (cardiac) –Evidence Documents, Key Image Note –Portable Data for Imaging, XDS-I, Import Reconciliation Patient Care Devices –Implantable Device - Cardiac - Observations –Device Enterprise Communication –Waveform Content Message Patient Care Coordination –Medical Summary –ED Referral IT Infrastructure –XDS, ATNA, Consistent Time –PIX, PDQ, PAM –Retrieve Form fo r Data Capture Cardiology Relevant Profiles in Other Domains

50. Domain organization

51. IHE Cardiology Planning Committee Contact Information Secretary Paul Dow pdow@acc.org pdow@acc.org Co-Chair Alan Katz, MD alan.katz@chsli.org alan.katz@chsli.org Co-Chair David Slotwiner, MD dslotwin@nshs.edu dslotwin@nshs.edu Committee’s wiki page http://wiki.ihe.net/index.php?title =Cardiology_Planning_ Committee http://wiki.ihe.net/index.php?title =Cardiology_Planning_ Committee Responsibilities Identifying priority issues for the cardiology community −Liaison to sponsor organizations Soliciting and developing IHE Profile Proposals −Now soliciting proposals! Evaluation of Technical Committee work Marketing IHE Cardiology profiles to user community

52. IHE Cardiology Technical Committee Contact Information Secretary Paul Dow pdow@acc.org pdow@acc.org Co-Chair Nick Gawrit ngawrit@heartbase.net ngawrit@heartbase.net Co-Chair Antje Schroeder aschroeder@siemens.com aschroeder@siemens.com Committee’s wiki page http://wiki.ihe.net/index.php?title =Cardiology_Technical_Committ ee http://wiki.ihe.net/index.php?title =Cardiology_Technical_Committ ee Responsibilities Development of IHE Profiles and white papers Maintenance of IHE Cardiology Technical Frameworks Liaison with other IHE domains Support for Planning Committee marketing

53. How to Participate in IHE Cardiology? Apply for IHE International Organizational Membership Visit: www.ihe.net/applywww.ihe.net/apply Approved monthly by IHE International Board Review IHE's 400+ Organizational Members Participate in IHE Domains & Committees IHE Organizational Members only 12 Clinical and Operational Domains Each Domain has one planning and one technical committee Non-members participate in comment periods and implement IHE Technical Frameworks IHE International Membership is Free.

54. How to Participate in IHE Cardiology? Committee work typically follows the IHE Profile Cycle Annual cycle ~18 months from profile proposal to Connectathon Each IHE domain has its own independent schedule Opportunities for IHE members and non-members to participate in cycle IHE’s Profile Development Cycle

55. IHE Profiles Drafted & Revised months 5-11 TrialImplementationPosted Published For Public Comment IHE Technical Framework Supplement Developed Install Interoperable products in Clinical Settings worldwide Demonstrate at a or ACC / HRS / ESC … Demonstrate at a or ACC / HRS / ESC … IHE Improves, Safety, Quality and Efficiency in Clinical Settings IHE Call for Proposals Opens Profile Selection by Committees months 1-4 months 12-18 Publish in IHE’s Product Registry Test at IHE Connectathons

56. Thank you for your attention Questions?

57. Backup

58. Learn More about IHE International Sign up for the IHE International News Email secretary@ihe.netsecretary@ihe.net Apply for IHE International’s Free Membership Visit: www.ihe.net/applywww.ihe.net/apply Important Links and Information

59. Profiles & Technical Frameworks Workflow in the ambulatory environment Image-Enabled Office –Bi-directional integration of medical imaging equipment and office EHR –Not limited to cardiology – applies to orthopedics, women’s health, gastroenterology, even primary care –Ambulatory office EHRs, mini-PACS (or cloud PACS), imaging modalities –Supports the 2014 Meaningful Use criteria for EHR with imaging TRIAL

60. Image-Enabled Office (IEO) Workflow

61. Image-Enabled Office Leverages in-patient workflow concepts to minimize impact on imaging devices, but adapted to use with office EHR (EHR-S) EHR – PACS image display integration using Web technologies Integrated EHR-System is an optional integration of an EHR with the image “order filler” (scheduling and management) function Can be implemented with 3 rd party software components without having to expose internal order transactions Agnostic to EHR and PACS deployment technology (on-site, hosted, SaaS, cloud, etc.) TRIAL

62. Profiles & Technical Frameworks Cath Procedure Reporting TRIAL <code code=“18745-0” displayName=“Cardiac catheterization study report” codeSystem=“2.16.840.1.113883.6.1” codeSystemName=“LOINC”/> Cardiac Catheterization Report <confidentialityCode code=“N” displayName=“Normal” codeSystem=“2.16.840.1.113883.5.25” codeSystemName=“Confidentiality”/> <id extension=“IHE-CardtemplateId” root=“1.3.6.1.4.1.19376.1.4.1.3.1”/> <code code=“1234097013” codeSystem=“2.16.840.1.113883.6.96” codeSystemName="SNOMED CT" displayName="Diagnostic Coronary Angiography“> –“Cath Report Content” profile defines an HL7 CDA structured report (XML) to facilitate consistency, accuracy, and semantic interoperability of Diagnostic Cath, Angiography, and PCI procedure reports and findings –Based on “ACC/AHA 2008 Cardiac Catheterization Report Prototype” and “ACC- NCDR CathPCI Registry v4.4 Coder’s Data Dictionary” –Affected systems include: Cardiovascular Information Systems, EHR systems, cardiac cath lab analysis and reporting workstations –Aligned with HL7 Implementation Guide for CDA Release 2: IHE Health Story Consolidation, Release 1.1 DSTU –Related links: http://wiki.ihe.net/index.php?title=Cath_Report_ Contenthttp://wiki.ihe.net/index.php?title=Cath_Report_ Content http://www.ihe.net/Technical_Framework/upload/ IHE_CARD_Suppl_CRC.pdfhttp://www.ihe.net/Technical_Framework/upload/ IHE_CARD_Suppl_CRC.pdf http://www.ihe.net/Technical_Framework/index.cfm #cardiology http://www.ihe.net/Technical_Framework/index.cfm #cardiology

63. Cath Report Content (CRC) TRIAL Based on >100 discrete cath & PCI procedure data elements, fully modeled using non-proprietary SNOMED, LOINC, and DICOM terminologies Is not a direct specialization of any existing HL7 CDA document template ID. However, some parts were based on: –IHE Cardiology CIRC content profile –HL7 Implementation Guide for CDA Release 2: IHE Health Story Consolidation, Release 1.1 DSTU -July 2012 (C-CDA) Procedure Note. Allows structured representation of lesions, coronary anatomy and devices Supports data import into longitudinal patient tracking databases First step to wider secondary use of report data (outcomes research, quality metrics and quality improvement) Leverages HL7 CDA capability for both human readable narrative and robust XML-encoded data elements.

64. CDA is the schema for those documents The HL7 Clinical Document Architecture (CDA) is a document markup standard that specifies the structure and semantics of “clinical documents” for the purpose of exchange. HL7 Clinical Document Architecture Release 2 is a HL7 V3 normative standard. C-CDA defines a set of CDA documents The HL7 Consolidated CDA is an Implementation Guide which specifies a library of templates and details their use for a set of specific clinical document types. HL7 C-CDA Release 1.1 is an HL7 DSTU. HL7 CDA and C-CDA

65. HL7 Consolidated CDA (C-CDA) HL7 Implementation Guides for CDA Release 2: IHE Health Story Consolidation, DTSU Release 1.1 – US Realm It contains a library of CDA templates incorporating and harmonizing previous efforts from HL7, IHE, and HITSP Consolidates previous document templates into a single library and resolves conflicts and ambiguities. It includes 9 CDA document types Continuity of Care Document (CCD) / HITSP C32 History and Physical Note Discharge Summary Consultation Note Diagnostic Imaging Report Procedure Note Operative Note Progress Note Unstructured Document (non-XML body) It includes all required CDA templates in the Final Rules for Meaningful Use Stage 1 and can support Meaningful Use Stage 2 requirements.

66. Cath Report Content (CRC) General – context, use cases, and actors Header elements Section content modules Entry content modules Vocabulary constraints and value sets

67. CRC - Context Clinical Reports for cardiology procedures recorded in a Cardiac Catheterization Laboratory, including: Diagnostic Catheterization Angiography PCI Does not include imaging studies, EP procedures, and non- cardiology procedures (e.g. peripheral angiography). It is assumed that there is a DICOM Study associated with the exam. If there is not a DICOM Study, this report content may not be appropriate. There are no constraints on the narrative text and figures that the cardiologist could include in the report document, although there are requirements on minimum data elements reflecting expert consensus (ACC-NCDR Cath PCI data elements).

68. Cath Report - Summary Narrative form of the summary information including the major highlights from each section: Patient demographics History and Physical Procedures and Interventions Findings and Results Equipment Complications Notes Key images and graphics

69. Cath Report – Pre-procedure Documents the key elements from the information gathered prior to the cath procedure being performed, including: Patient demographics Medical, family, and social history Allergies Known problems and symptoms Current medications Physical exam and vital signs Prior procedures and interventions Pre-procedure results

70. Cath Report - Procedure Documents the key elements from the information gathered during the cath procedure including: Procedures performed Equipment used Medications administered Anatomical locations addressed Specimens obtained Complications

71. Cath Report – Results and Interpretations Documents the key results, including measurements, findings, and observations, for the cath procedure performed, including: Anatomical measurements Cardiac functional measurements Device related measurements Diagnoses Additional notes

72. CRC – Use Cases Compile and Transfer Report of Cardiac Cath Lab Procedure with Use of ACC-NCDR Cath/PCI Data Elements This use case addresses the generation and transfer of a cardiac cath lab report based on the NCDR CathPCI Registry v4.4 Coder’s Data Dictionary data elements. Perform Discrete Data-analysis on Procedure Report Content The goal of this use case is to assist data collection for comparative and research purposes. Based on a report generated in the previous use case an advanced medical data analysis system collects discrete data from multiple patients and their procedure, e.g., for cardiac Clinical Decision Support or for advanced lifetime patient records. Review Procedure Report This is a secondary use-case addressed by this profile involves the direct human use of the procedure report. In most practical cases this will be: The referring physician who instigated/ordered the procedure, and other healthcare providers who manage subsequent patient care activities. Another person involved in downstream clinical or administrative data processing e.g., someone validating/source-checking for QA the original report as part of JCAHO audits, or pre-submission checking on the original reporting data against the case-data imported in the ACC-NCDR Cath/PCI registry- submission application.

73. CRC – Actors and Options Actors: Content Creator and Content Consumer Content Creator Create a CRC document populating the required header elements, sections, and entry content modules Group with a Time Client actor to synchronize its clock Content Consumer Receive and process a CRC document, parsing the relevant header elements, sections, and entries Implement the View option, the Discrete Data Import option, or both If implements the Document Import or Section Import options, must also implement the View option Options: ActorOption NameOptionalityDescription Content Consumer ViewODemonstrate rendering; print; display with original style sheet; support traversal of any links in document Document ImportOStore the document; access document from storage Section ImportOImport one or more sections as free text Discrete Data ImportOImport structured data from one or more sections Content CreatorNo options defined

74. CRC – Relationship with other Profiles Other Content Profiles Cardiac Imaging Report Content (CIRC) Profile – in Trial Implementation Electrophysiology Report Content (EPRC) Profile – currently under development Registry Submission Content (RSC) Profile – Cath/PCI - currently under development Actor Required Grouping Consistent Time (CT) – for Legal Authentication timestamp to be accurate Cross Profile Considerations – grouping of Content Creator/Content Consumer with actors of workflow profiles that manage interchange of clinical data Displayable Reports (DRPT) - to exchange the CRC content between Report Creator and Report Manager Cross-enterprise Document Sharing (XDS), Cross-enterprise Document Media Interchange (XDM), Cross-enterprise Reliable Interchange (XDR), Cross-enterprise Document Sharing for Imaging (XDS-I), and Cross-enterprise Reliable Document Interchange for Imaging (XDR-I) - to exchange the CRC content Cross Enterprise Portable Data for Imaging (PDI) - to exchange the CRC content via removable media. Retrieve Form for Data Capture (RFD) - to use the CRC content for pre-population of data entry Document Digital Signature (DSG) – to allow digital signing of the CRC content

75. CRC – Relationship to C-CDA CRC is realm agnostic – so it can be specialized for deployments Deviates from C-CDA (US Realm) by not specifying format of addresses, telcoms, names, NPI Utilizes documentation style of C-CDA for defining constraints Where constraints defined in C-CDA were not modified, the constraint remains as the C- CDA constraint identifier (e.g., CONF:5361). If only the value set was modified, then the constraint is considered unchanged. Where constraints defined in C-CDA were modified, the original constraint ID is also modified by appending “-CRC” (e.g., CONF:5253-CRC). Modifications could include changes in the cardinality. Where new constraints were introduced, a new constraint identifier was defined (e.g., CONF:CRC-xxx) Use of C-CDA Sections and Entries If there are no new or modified constraints for a section or entry or if only the value sets are constrained, then the definition of the section or entry is considered unchanged from the C- CDA definition and the C-CDA template ID will be used. These unchanged sections/entries are referenced directly from the C-CDA specification and are not included in this specification. If there are new or modified constraints for a section or entry, then that section or entry is assigned a new IHE Card specific template ID.

76. CRC – Header Elements code - is selected from a value set specific for Cath lab reporting. recordTarget – identifies the patient whose health information is described in this clinical document for the procedure. author – represents the creator(s) of the clinical document content. custodian – represents the organization that is in charge of maintaining the clinical document. legalAuthenticator – identifies the single person legally responsible for the document. This profile does not support the exchange of preliminary unapproved procedure reports. authenticator – identifies participants that attest to the accuracy of the information in the clinical document. There may be one for each cath procedure performed (e.g. diagnostic cath and PCI). inFulfillmentOf – represents orders that are fulfilled by this clinical document. For CRC, the order/id is the Accession Number used in the DICOM imaging data. authorization – contains information about patient consents for the procedure(s) and for the anesthesia. componentOf – contains information about the encompassing encounter for the clinical procedures documented in this report. This includes the clinical setting (location and organization). It also allows for the referring provider(s), an attending physician and a responsible physician to be identified. documentationOf/serviceEvent – represents the main cath procedure that is being documented. This also documents the primary performer (potentially one for the diagnostic cath and one for the PCI) and any assistants involved in the procedures.

77. CRC – Section Content Modules (21 total) New sections (2) Document Summary Includes a summary of most significant aspects of the procedures in a narrative form. It is a condensed form of the full narrative report whose structure has no constraint. Key Images – Cardiac Contains narrative description of and references to DICOM Image Information Objects that illustrate the findings of the procedure reported. Specialized sections (5) Medical History – Cardiac Adds support for coded problem observation and procedures. Pre-Procedure Results – Cardiac Adds support for results in external documents. Procedure Description – Cardiac Adds support for device specific observations and identification of lesions. Procedure Results – Cardiac Adds support for lesions. Plan of Care – Cardiac Includes specialized Plan of Care Activity Act with elements. Unchanged sections (14) Allergies Family History Social History Physical Exam Vital Signs Planned Procedure Procedure Indications Anesthesia Medications Administered Procedure Specimens Taken Procedure Disposition Complications Postprocedure Diagnosis DICOM Object Catalog

78. CRC – Entry Content Modules Unchanged entry content modules (~35) New entry content modules (3) Lesion Observation – identifies a lesion of interest, identified by a global ID and one or more target sites Procedure Device Organizer – Cardiac – contains a set of observations related to a device used during a procedure Device Observation – represents observations made of devices used during a procedure Specialized entry content modules (6) Problem Observation – Cardiac Extends the Problem Observation Entry with an entryRelationship for a Severity Observation Result Organizer – Cardiac Extends to support references to external documents for results Result Observation – Cardiac Extends to support an entryRelationship to a Severity Observation Plan of Care Activity Act – Cardiac Extends to support code, statusCode, and effectiveTime elements Procedure Results Organizer – Cardiac Extends to include entryRelationship to a Lesion Observation Procedure Activity Procedure – Cardiac Extends to support entryRelationship to a Procedure Device Organizer and a Lesion Observation

79. CRC – Vocabulary Constraints Result observation constraints – defines complete sets of elements for observations, including codes and allowed values Value sets provided for Cath specific concept domains Cardiac Problems/Concerns Body Site Cardiovascular Family History Contrast Agents Classes for Adverse Reactions Cardiac Lab Results Vital Sign Results Procedure Indications Contrast Agents Cardiac Activity Procedures Drug Classes and Specific Cardiac Drugs Rx Recommendations Procedure Findings Types Postprocedure Diagnoses Supported File Types Complications

80. Intravascular Imaging Intravascular Imaging Option to CATH Workflow Addresses use case to workflow to change a modality during the procedure Requires support for Intravascular Optical Coherence Tomography (OCT) SOP classes Option for Image Manager/Archive and Image Display Actors –Image Manager/Archive actors must store the following SOP Classes Intravascular Optical Coherence Tomography Image Storage – For Presentation Intravascular Optical Coherence Tomography Image Storage – For Processing −Image Displays have to provide the functionality to display Intravascular Optical Coherence Tomography Image Storage – For Presentation objects http://www.ihe.net/Technical_Framework/upload/IHE_CARD_Suppl_IVI_Op tion_for_Cath_Workflow.pdfhttp://www.ihe.net/Technical_Framework/upload/IHE_CARD_Suppl_IVI_Op tion_for_Cath_Workflow.pdf TRIAL New Supplement in 2013 – target for Japan connectathon