2016 ACC/ASE/ASNC/HRS/SCAI Health Policy Statement on Integrating the Healthcare Enterprise

PREAMBLE

This document has been developed as a health policy statement by the American College of Cardiology (ACC), in conjunction with the American Society of Echocardiography, American Society of Nuclear Cardiology, Heart Rhythm Society, and Society for Cardiovascular Angiography and Interventions. This document is an ACC health policy statement and is intended to promote or advocate a position, to be informational in nature, and to offer guidance to the stakeholder community regarding the ACC’s stance on healthcare policies and programs. Health policy statements are not intended to offer clinical guidance and do not contradict existing ACC clinical policy. They are overseen by the ACC Clinical Quality Committee, the group responsible for developing and implementing all health policy statement policies and procedures related to topic selection, commissioning writing committees, and defining document development methodologies. The Clinical Quality Committee brings together various areas of the College such as the Advocacy Committee; the National Cardiovascular Data Registry (NCDR); the ACC/American Heart Association (AHA) Task Forces on Guidelines, Performance Measurement, and Cardiovascular Data Standards; and the Appropriate Use Criteria Task Force. The Clinical Quality Committee recommended the development of this health policy statement to document the College’s official position on the need for a standards-based approach to achieve interoperability of health information and to engage clinicians, manufacturers, and regulators in the process.

To avoid actual, potential, or perceived conflicts of interest that may arise as a result of industry relationships or personal interests among the writing committee, all members of the writing committee, as well as peer reviewers of the document, are asked to disclose all current healthcare-related relationships, including those existing 12 months before initiation of the writing effort. The ACC Clinical Quality Committee reviews these disclosures to determine what companies make products (on market or in development) that pertain to the document under development. On this basis of this information, a writing committee is formed to include a majority of members with no relevant relationships with industry (RWI), led by a chair with no relevant RWI. RWI is reviewed on all conference calls and is updated as changes occur. Author and peer reviewer RWI pertinent to this document are disclosed in Appendixes 1 and 2, respectively. Additionally, to ensure complete transparency, authors’ comprehensive healthcare-related disclosure information—including RWI not pertinent to this document—is available online (see Online Appendix). The ACC disclosure policy for clinical document development is also available online.

The work of the writing committee was supported exclusively by the ACC without commercial support. Writing committee members volunteered their time to this effort. Conference calls of the writing committee were confidential and were attended only by committee members and relevant ACC staff.

Richard J. Kovacs, MD, FACC, Chair

ACC Clinical Quality Committee

1. INTRODUCTION

In 2009, as part of the American Recovery and Reinvestment Act, the Federal Government set aside $19.2 billion to increase the use of electronic health records (EHRs) (1). Core to its charge is the development and adoption of a nationwide health information infrastructure whose purpose includes the exchange of patient health information. Despite its original charge, the U.S. healthcare data infrastructure’s lack of interoperability has emerged as a significant barrier compromising the potential of health information systems to improve health care and reduce costs. In a call for an overhaul of the EHR environment, the American Medical Association has emphasized “data liquidity” as 1 of 8 keys to improving EHR usability (2). In an October 2014 press conference, U.S. Health and Human Services Secretary Sylvia Burwell acknowledged interoperability to be the key to unlocking the real value of healthcare information systems for practicing physicians and all healthcare consumers (3).

Interoperability is important partly because it facilitates easier extraction of accurate, high-quality data from clinical records. Clinical research and quality measurement are both, in turn, dependent on this data extraction. Presently, this is a time- and labor-intensive process that requires substantial resourcing. Data are the fundamental building blocks of clinical research and observational registries. As noted in an editorial by O’Gara and Harrington, “Clinical research provides the evidence base for American College of Cardiology (ACC) documents that help guide clinical practice, including expert consensus documents, guidelines, performance measures, and appropriate use criteria” (4). By capturing and reporting high-quality data, the NCDR serves as a tool to measure, benchmark, and improve cardiovascular care (5). Methods such as adoption of Integrating the Healthcare Enterprise (IHE) standards and profiles can increase autopopulation of NCDR data emanating from EHR systems and enhance the American Medical Association’s key aim of “data liquidity.”

IHE is an initiative undertaken by healthcare professionals and industry to facilitate and strengthen the sharing of clinical data among health information technology (IT) systems. Systems developed in accordance with IHE communicate with one another more readily and completely, are easier to implement, and enable care providers to use information more effectively. Stated simply, the goal of IHE is to support specifications that increase software and hardware functionality and usability in health IT.

2. DATA STANDARDS

The past several decades have witnessed tremendous growth in healthcare information systems, driven by rapid advances in computer technology and accelerated by regulations such as the Physician Quality Reporting System and the EHR “Meaningful Use” Incentive Program. However, most healthcare information systems were developed with a focus on documentation to facilitate charge capture largely without regard to the needs or workflows of clinicians. As a consequence, the exchange of information between systems, at both the semantic (the exchange of the meaning of the content) and syntactic (the structure needed to capture and convey semantics) levels, has not been the priority (6). Data interoperability thus continues to be a work in progress.

Currently, establishing even limited data transfer between systems is typically the responsibility of local IT departments and each clinical department within an institution on a case-by-case basis. Moreover, with each upgrade or change of vendor, the integrity of data communication must be revalidated. Even if health enterprise IT departments could maintain these communication connections, without the implementation of interoperability and data standards, the overall information environment within 1 healthcare enterprise will differ markedly from another.

The foundation for data exchange and interoperability requires standardized and internationally recognized data element definitions and data interchange standards. A number of organizations have been formed to develop these definitions and standards (e.g., Health Level 7, the Digital Imaging and Communications in Medicine [DICOM] standards, and the Institute of Electrical Engineers standards). The American Health Information Management Association lists 16 standards development organizations and 45 groups working on structure and content standards for the EHR (7). Importantly, the creation and maintenance of standards for data elements and data interchange are not within the purview of IHE. Rather, the role of IHE is to leverage and extend existing foundational work to improve the operational efficiency and effectiveness of healthcare delivery because data standards alone lack sufficient specificity to accomplish this. IHE is in a unique position to formalize the use of existing standards to support clinically relevant work-flows and improve efficiency.

The solution to the problem of having information trapped within clinical departments and proprietary software formats is to develop data interoperability and transmission frameworks that link systems without customization and continuous revision. In addition, the acquisition and management of data must be integrated into the workflow. These are the central tenets of the IHE initiative.

3. IHE: FACILITATING INTEROPERABILITY

3.1. Overview

IHE is a nonprofit international organization that develops standards-based frameworks called “integration profiles” (Table 1) for sharing information within care sites and across networks. It leverages existing data standards to facilitate communication of information between and among healthcare information systems.

TABLE 1.

IHE Constructs and Artifacts (From www.ihe.net)

IHE Profiles	IHE Profiles provide a standards-based framework for sharing information within care sites and across networks. They address critical interoperability issues related to information access for care providers and patients, clinical workflow, security, administration, and information infrastructure. Each profile defines the actors, transactions, and information content required to address the clinical use case by referencing appropriate standards. There are 2 types of IHE Profiles: Integration Profiles, which specify workflow interactions (cardiology profiles containing the word “workflow”) Content Profiles, which specify the composition of documents, data, and messages transported in Integration Profiles (cardiology profiles containing the word “content”)
Integration Statement	IHE Integration Statements are documents prepared and published by vendors to describe the intended conformance of their products with the IHE Technical Framework. They identify the specific integration capabilities a product is designed to support in terms of the key concepts of IHE: Actors and Integration Profiles.
Technical Framework	The IHE Technical Framework is a detailed, rigorously organized document that provides a comprehensive guide to implementing the defined integration capabilities. The Technical Framework delineates standards-based transactions among systems (generically defined as IHE Actors) required to support specific workflow and integration capabilities.
Connectathons	IHE has been testing the interoperability of health IT systems for more than a decade. At IHE Connectathons held regularly in several international locations, trained technical experts supervise testing of vendor systems, making use of advanced testing software developed by IHE and several partner organizations. More than 250 vendors worldwide have implemented and tested products with IHE capabilities.
IHE Actors	Information systems or applications that produce, manage, or act on information are represented as functional units called IHE Actors. Each actor supports a specific set of IHE transactions. A given information system may support 1 or more IHE actors.
Transactions	Transactions are exchanges of information between actors using messages based on established standards (such as HL7, DICOM, and W3C). Each transaction is defined with reference to a specific standard and additional detailed information, including use cases. This is done to add greater specificity and ensure a higher level of interoperability between systems.

DICOM = Digital Imaging and Communications in Medicine; HL7 = Health Level 7; IHE = Integrating the Healthcare Enterprise; IT = information technology; W3C = World Wide Web Consortium.

IHE focuses on practical integration challenges defined via specific use cases. Typical examples of integration challenges include the reconciliation of patient demographics, image–patient encounter workflows, and assurance of the consistency of image presentation. For example, the repetitive re-entry of patient demographic and ordering information when laboratory studies are performed is addressed via 1 IHE integration profile. IHE is also concerned with information security and protecting private health information. Profiles such as the Audit Trail and Node Authentication (ATNA) integration profile establish security measures that, together with the Security Policy and Procedures, provide patient information confidentiality, data integrity, and user accountability (8).

3.2. Historical Context

IHE is divided into 12 clinical domains (Figure 1). Each domain develops integration profiles. These define the actors, transactions, and information content required to address a use case within a clinical practice area. The work is compiled into IHE Technical Frameworks—detailed technical documents that serve as implementation guides. All documents and artifacts are available free of charge at the IHE Web site (www.ihe.net) and do not require licensing.

FIGURE 1.

IHE Clinical Domains and Year of Domain Inception (www.IHE.net)

IT = information technology.

The IHE was established in 1998 as an initiative sponsored by the Healthcare Information and Management Systems Society and the Radiological Society of North America to promote a higher level of interoperability among imaging and information systems. From the start, it comprised a working group of key members—medical society members, industry representatives, standards experts, clinicians, and other interested parties. IHE succeeded in substantially improving radiology work-flows via an initial set of integration profiles. With success in the radiology sector, IHE approached the ACC to develop and support the IHE cardiology domain. The charge was to connect the heterogeneous vendor platforms across the cardiovascular technology space. In 2003, the IHE Cardiology Domain was formed in a partnership between IHE USA and the ACC. The work products of the Cardiology Domain are discussed in Section 4 of this document.

3.3. Integration Profile Development Cycle

Each year, the cardiology domain holds an open call for proposals to identify clinical use case scenarios that could be enhanced by improved data interoperability. Technical experts from the relevant manufacturers then work together to create detailed communication specifications—i.e., integration profiles—to address the use case. Industry implements these specifications. The planning and technical committees review each other’s recommendations to ensure clinical relevance and technical accuracy. The final step of the development cycle occurs at the annual IHE Connectathon, where a system must be shown to be interoperable with at least 3 different vendors to be deemed in compliance with an integration profile (Figure 2).

FIGURE 2.

IHE Integration Profile Development Cycle

3.4. Benefits of Interoperability/IHE

The digital revolution has led to countless diagnostic and therapeutic healthcare advances. To the frustration of all who consume or participate in the delivery of health-care services—patients, healthcare providers, payers, researchers, and regulators—the immediate access to data that has transformed so many aspects of our lives, from banking, to shopping, and to communication, has been slow to reach the field of health care. Results from the most advanced diagnostic tests and therapeutic interventions continue to be distributed as printed reports (or digital equivalents siloed within proprietary health IT systems).

The objective of IHE is to improve the way computer systems in health care share information. In a clinical setting, IHE profiles allow seamless exchange of high-quality data that can be repurposed without the redundancy and risk of error associated with copying and re-entering data or the expensive and time-consuming task of building custom interfaces. This saves time and resources and can minimize billing delays and rejections. It also facilitates the completion of analytic and administrative tasks by taking a systems-based approach of collecting data once for use many times. The interoperability of high-quality granular data that retains both its semantic and syntactic elements will enable quality improvement, evaluation of care efficiency and effectiveness, and ultimately even clinical research—all with data that is captured only once.

Importantly, IHE serves a crucial role in the request for proposal process by providing purchasers with a tool to specify interoperability requirements from bidding vendors. For instance, Dr. Michael Mirro has piloted the Implantable Device Cardiac Observation profile to allow seamless transmission of data from cardiovascular implantable electronic devices into the EHR (9–12). Technology solutions built to support IHE profiles can be implemented by local IT shops on the basis of free, open-source, unrestricted licensing solutions that have been carefully documented, reviewed, and tested and are supported by industry partners. By specifying IHE profile support within requests for proposals, purchasers send a powerful signal to industry that vendor-agnostic data interoperability is a high priority in the bidding process. Important examples are illustrated in Table 2.

TABLE 2.

Characteristics of Information Systems With and Without IHE

Phase	Key Elements of Desired State	Typical Health IT	Health IT With IHE
Information system selection and maintenance contracting	Reduced technology and human resource requirements for installation and maintenance Reduced complexity of the overall IT environment “Plug and play” data interoperability among systems	Each IT system acts largely as an independent island with little data interchange Expensive interfaces to connect systems that are dependent on the vendors to develop and maintain Each interface must be built, tested, and maintained separately	Request For Proposal processes that include vendor agnostic interface and interoperability specifications Implementation by local IT departments based on standards supported by industry partners that have been carefully documented, reviewed, and tested Free, open-source, unrestricted licensing solutions that can be implemented at any facility
Clinical use of information systems	Seamless exchange of high quality, reusable data across systems Reduced redundancy and repetition of procedures, tests, and documentation Reduced time requirements to document and deliver healthcare Cross-context access to information in patient records Minimized billing delays and rejections	Wasted time and effort due to processes designed without clinician input Data trapped within IT systems Repetitive, potentially unnecessary tests and treatments Inefficient and ineffective communication Uncoordinated and delayed treatments Costs of obtaining and managing outside records, usually on paper	Uniform patient identification across systems Reduced manual and repetitive transcription of healthcare data Reduced duplicate testing and procedures Reuse of data for clinical care processes (e.g., allergy checking, clinical decision support) Effective and efficient communication of information at transitions of care Increased efficiency and throughput of charge posting, facilitating revenue cycle operations and compliance
Post-Care analytics	Analysis of clinical and administrative data across systems to improve quality, efficiency, and effectiveness of care delivery	Manual collation, aggregation, and analysis of data extracted from multiple IT systems, conducted as individual projects	Systems-based approaches that embrace a “collect once, use many times” construct of data reuse Semi-automated data management processes for continuous quality improvement, submission of data to clinical registries

4. CARDIOLOGY PROFILES

4.1. Overview of the Profiles

Within the cardiology domain, 14 profiles have completed the development cycle and have been tested and validated at a Connectathon testing event (Table 3) (13).

TABLE 3.

Brief Description of Cardiology Profiles (13)

Profile Name	Description
CATH	Cardiac Catheterization Workflow integrates ordering, scheduling, imaging acquisition, storage, and viewing for Cardiac Catheterization procedures.
ECHO	Echocardiography Workflow integrates ordering, scheduling, imaging acquisition, storage, and viewing for digital echocardiography.
ECG	Retrieve ECG for Display provides access throughout the enterprise to electrocardiogram documents for review purposes.
REWF	Resting ECG Workflow describes the workflow for collecting ECG data in both ordered and unordered procedures, data storage and access, and ECG reporting.
ED CARD	Evidence Documents adds cardiology-specific content to the Radiology ED profile for DICOM Structured Reports.
STRESS	Stress Testing Workflow provides ordering and collecting multimodality data during diagnostic stress testing procedures.
DRPT	Displayable Reports manages creation and distribution of “display ready” (PDF or CDA) clinical reports from the creating application to the department and the enterprise.
CIRC	Cardiac Imaging Report Content format for a CDA report of a cardiac diagnostic imaging procedure, including discrete data elements.
IEO	Image-Enabled Office Workflow integrates an imaging suite with an EHR system in an ambulatory office setting, including ordering, imaging, report
EPRC-IE	Electrophysiology Report Content format for a CDA report of an Electrophysiology Implant/Explant Procedure, including discrete data elements.
IDCO	Implantable Device Cardiac Observation transfers information from an interrogated implantable cardiac rhythm management device to an information management system.
CRC	Cath Report Content format for a CDA report of a cardiac Cath/PCI procedure, including discrete data elements.
RCS-C	Registry Content Submission-CathPCI format for a CDA report to facilitate submission of NCDR® CathPCI V4.4 data elements to the NCDR® CathPCI Registry®, promoting the accurate and seamless transfer of data into clinical registries.
NMI	Nuclear Medicine Image (Cardiology) was developed in 2007 as a shared development between radiology and cardiology.

CDA = clinical document architecture; DICOM = Digital Imagine and Communications in Medicine; ECG = electrocardiogram; ED = Evidence Documents; EHR = electronic health record; PCI = Percutaneous Coronary Intervention; PDF = portable document format.

4.2. Cardiac Catheterization Workflow

The IHE Cardiac Catheterization Workflow profile integrates the ordering, scheduling, imaging acquisition, storage, and viewing of cardiac catheterization procedures (14). The use cases focus on the continuity, integrity, and integration of basic patient, order, clinical, and procedure data across all of the participating systems. The profile deals specifically with consistent handling of patient identifiers and demographic data, including the emergency patient presentation, where the actual patient identity may not be established until after the beginning of the procedure (e.g., emergency primary angioplasty for acute myocardial infarction). It minimizes the submission of missing data and also specifies the scheduling and coordination of procedure data across a variety of imaging, measurement, and analysis systems, with provisions for reliable storage in an archive.

4.3. Echocardiography Workflow

The Echocardiography Workflow profile describes the workflow associated with digital echocardiography, including transthoracic, transesophageal, and stress echocardiography procedures (15). Similar to the Cardiac Catheterization Workflow profile, it includes patient identifiers and demographic data, orders, scheduling, clinical data, status reporting, multistage examinations (e.g., stress echocardiography), and data storage. The profile accommodates the multiple workflows typical of echocardiography, anticipating that a sonographer will acquire preliminary measurements and transfer the data to a reporting workstation for the final interpretation and reporting by a physician. It also specifically addresses the issues of acquisition modality devices that are only intermittently connected to the network, such as portable echocardiography machines.

4.4. Retrieve Electrocardiogram for Display Content Profile

The Retrieve Electrocardiogram (ECG) for Display profile simplifies and standardizes the ECG access and viewing process, allowing multiple clinicians to view an ECG simultaneously, and provides images in a diagnostic display resolution (16). As a content (not a workflow) profile, it does not address the ordering, interpretation, or storage of ECG tracings.

4.5. Resting Electrocardiogram Workflow Profile

The Resting ECG Workflow (REWF) profile extends the Retrieve Electrocardiogram for Display content profile (17). Similar to other workflow profiles, it encompasses the acquisition and management of patient identifiers, orders, scheduling, status reporting, and recording. It accounts for the potentially urgent nature of ECG acquisition when demographic data are not available, as well as the workflow technical challenge associated with obtaining data from devices that are only intermittently connected to the network. The profile does not address the workflow associated with ECG interpretation.

4.6. Evidence Documents

Evidence documents are nonimage data objects that are typically produced in the context of performing a procedure. For example, a modality that performs measurements during an echocardiogram to record dimensions and calculate an ejection fraction might create an evidence document containing those values that is sent to the archive with the study images. Evidence documents often include preliminary findings that will be verified and used as part of the procedure report. The Evidence Documents for Cardiology profile adds cardiology workflow-specific content to the radiology evidence documents profile for DICOM Structured Reports (18). Presently, cardiology evidence document options include nonimaging data from cardiac angiography, echocardiography, stress testing, and cardiac computed tomography/magnetic resonance imaging.

4.7. Stress Testing Workflow

The Stress Testing Workflow profile defines a means of ordering and performing cardiac stress tests involving both ECG and imaging (echocardiographic or nuclear) procedure components (19). All of the acquired data are collected in a uniform format (DICOM). It extends the Echocardiography Workflow profile to include multimodality coordination and stress test–specific data requirements.

4.8. Displayable Reports Profile

The Displayable Reports profile manages the creation and distribution of the clinical report in a human readable format (20). The reports are displayed in either portable document format or the Health Level 7 Clinical Document Architecture format. Clinical Document Architecture is emerging as the preferred vehicle because it provides a structure to communicate the actual data content and not just the image of the report typical of portable document format. Furthermore, the Office of the National Coordinator (ONC) has supported Clinical Document Architecture as the standard for document exchange in the EHR “Meaningful Use” Incentive Program.

The profile also resolves discrepancies that occur when several clinicians contribute to a single procedure such as a transcatheter aortic valve replacement procedure, which includes an interventional cardiologist, echocardiographer, anesthesiologist, and cardiothoracic surgeon. Additionally, the profile describes and implements a workflow to allow reports to be exposed in a preliminary format and then ultimately to be signed or amended. The profile also resolves report updates when there are changes to the patient demographics, when new relationships to other content in the storage media arise, or when relationships are no longer valid.

4.9. Cardiac Imaging Report Content

The Cardiac Imaging Report Content profile specifies the content and the structure for a clinical report of a cardiology imaging study (21). This includes indications, description of the procedure performed, medications, complications, and findings. The specific examinations included in this profile are echocardiography (transthoracic, transesophageal, and stress), computed tomography (angiography and coronary artery calcium scores), cardiac magnetic resonance imaging, cardiovascular nuclear medicine (single-photon emission computed tomography [SPECT] perfusion imaging and positron emission tomography [PET] imaging), diagnostic coronary angiography, and percutaneous coronary intervention. Although not a workflow profile, the Cardiac Imaging Report Content profile describes the process by which a clinician reviews and enters coded data from the procedure, patient history, medications, indications, and findings, including assessment and plan. Once these data have been entered they are ready for viewing and/or distribution in the Image-Enabled Office profile (viewing only), in the Displayable Reports (for distribution and viewing within an enterprise), or by the Cross Enterprise Document Sharing profile (to view outside of the originating facility).

4.10. Image-Enabled Office Workflow

The Image-Enabled Office (IEO) profile was created to facilitate viewing images from a Picture Archiving and Communications System (PACS) or imaging device directly within an office EHR (22). It is of particular utility to providers in an office setting who want to view images obtained during an in-patient hospital admission. It provides bidirectional integration, including ordering/scheduling of imaging examinations, status reporting for that examination, report creation, and web-based imaging examination review.

4.11. Electrophysiology Laboratory Report Content—Implant/Explant

The Electrophysiology Laboratory Report Content profile for device Implant/Explant specifies the data elements to be included in a pacemaker, defibrillator, or loop recorder implant/explant procedure (23). Although this profile does not describe the complete content of an associated imaging study, there are no constraints on the inclusion of narrative text or figures. This profile structure is similar to the Cath Report Content profile.

4.12. Implantable Device Cardiac Observations

The Implantable Device Cardiac Observations (IDCO) content profile describes a means of transferring data (including model and serial number as well as any clinical data) from any implantable cardiac implantable electronic device (CIED) (e.g., pacemakers, implantable cardioverter-defibrillators, cardiac resynchronization therapy devices, and cardiac monitor devices) to any information management system (e.g., cardiovascular information system, electrophysiological device management system, EHR, and so on) (24). The nomenclature was developed through collaboration between the Heart Rhythm Society and device manufacturers.

4.13. Cardiac Cath Report Content

The Cardiac Cath Report Content profile specifies the content structure for a clinical report of a diagnostic cardiac catheterization and percutaneous coronary intervention that is performed in an adult (25). Similar to other content profiles, it includes indications, description of the procedure(s) performed, medications, complications, and findings.

4.14. Registry Content Submission

The Registry Content Submission profile specifies the content structure and value sets for reporting the data collected during a cardiac catheterization and/or percutaneous coronary intervention to the NCDR (26).

4.15. Nuclear Medicine Image

The IHE Nuclear Medicine Image Cardiology profile was developed in 2007 in collaboration with the Radiology domain (27). The display types supported include static and dynamic cine display of all frames; gated displays of electrocardiographically gated images; tomographic displays allowing cine display of all frames through an acquisition; reconstructed tomographic images, including gated images; and display of polar plots. The permitted display formats include comparison displays of 2 sets of data such as stress compared to rest or 2 sets of data differentiated by time. The profile also allows for the acquisition and display of attenuation-corrected or prone acquisition data. The standardized display from the ACC/American Heart Association was specified as part of the profile (28). The profile does not address first-pass imaging, equilibrium radionuclide angiography, or PET imaging. Implementation of related profiles, such as Scheduled Workflow, Reporting Workflow, or Cross Enterprise Document Sharing, will be necessary to fully integrate the Nuclear Medicine Image profile into the daily workflow of the nuclear cardiology laboratory.

4.16. Profiles in Development

The profiles listed in Table 4 are in development and will be tested and released for use in the coming year.

TABLE 4.

Profiles in Development

Profile Name	Description
Structural Heart Procedures	Extends the Cath Report Content (CRC) profile to include new interventional structural heart therapies (e.g., transcatheter aortic valve replacement, mitral valve repair, atrial occlusion device implantation, and septal defect repair).
Registry Content Submission—Electrophysiology	Supports data collection from the Electrophysiology Report Content Profile for submissions to the ICD, AFib, and LAAO modules of the NDCR.
Intravascular Imaging (IVI)	Extends the existing Cardiac Catheterization Workflow (CATH) profile to include intravascular imaging.

AFib = atrial fibrillation; ICD = implantable cardioverter-defibrillator; LAAO = left atrial appendage occlusion; NCDR = National Cardiovascular Data Registry.

5. CLINICAL RESEARCH AND QUALITY METRICS

Although presently there is a wealth of information captured in EHR systems, extracting the data elements (as explicit data needed for these additional purposes) is costly and labor intensive, limiting the ability of institutions to engage in these activities. The ACC completed an independent assessment of various approaches to abstracting data for the purposes of quality metric reporting to the NCDR and determined that the IHE profile approach provided the best opportunity to achieve this strategic objective. Several IHE profiles from both the Cardiology domain and Quality Research and Public Health domain (described in the following section) bring together patient and episode-of-care-specific data to expedite and facilitate clinical research and quality metric reporting.

The IHE technical profiles noted in Table 5 provide the syntax to facilitate data exchange. For instance, adoption of these standards can facilitate the automated transfer of structured data from the EHR to NCDR registries.

TABLE 5.

IHE Technical Profiles

Profile	Description
Retrieve Form for Data Capture (RFD)	IHE has engaged the industry to create a content profile, Retrieve Form for Data Capture (RFD), to gather research data during an EHR session. This content profile will enable automatic population of RFD forms, resulting in greater data capture efficiencies among clinical trial sponsors, investigators, and research sites.
Clinical Research Document (CRD)	The Clinical Research Document (CRD) describes the content structure pertinent to the clinical research use case for RFD within the IT Infrastructure Framework.
Clinical Research Process Content (CRPC)	Clinical Research Process Content (CRPC) specifies the content appropriate to automate the sharing of information amongsystems during the clinical research process, based upon transactions from the Retrieve Process for Execution (RPE)profile. Using the transactions from the RPE profile, CRPC improves the setup, subject recruitment, and performance aspects of clinical studies.
Data Element Exchange (DEX)	Data Element Exchange (DEX) leverages the concept of a metadata registry to add mapping metadata to an annotated data capture form at the point of form design rather than at the level of the exchange of data.
Research Matching (RM)	Research Matching (RM) publishes research process definitions to EHR systems to match patients and investigators with appropriate research studies.
Registry Submission Workflow (RCS-C)	Supports data collection from the Cardiac Cath Report content profile for submissions to the Cath/PCI module of the NCDR.
Registry Content Submission—Electrophysiology* (RCS-EP)	Supports data collection from the Electrophysiology Report content profile for submissions to the ICD as well as the AFib and LAAO Registry modules of the NCDR.

^*In development, previously listed in Section 4.

AFib = atrial fibrillation; EHR = electronic health record; ICD = implantable cardioverter-defibrillator; IHE = Integrating the Healthcare Enterprise; IT = information technology; LAAO = left atrial appendage occlusion; NCDR = National Cardiovascular Data Registry; PCI = percutaneous coronary intervention.

6. PROMOTING THE IHE INTEROPERABILITY FRAMEWORK

The need for a data interoperability framework within the U.S. health IT infrastructure is appreciated by all stakeholders: patients, healthcare providers, administrators of healthcare facilities and organizations, healthcare regulatory agencies, as well as the healthcare-related industries, from health IT providers, to pharmaceutical and medical device manufacturers, and to health insurance companies. Each of these stakeholder groups must align behind a common approach if it is to succeed. The IHE framework and collaborative profile development process has been identified by a broad range of healthcare providers and industry as a practical tool for developing a data interoperability framework for the U.S. health IT infrastructure.

ACC is promoting adoption of IHE through several means:

• Engaging support from healthcare system executives by encouraging specification of support for IHE integration profiles in all requests for proposals;

• Encouraging end users to request support for IHE integration profiles;

• Lobbying the ONC to support the IHE Technical Frameworks in the EHR Incentive Program and beyond; and

• Collaborating with other organizations such as the American Heart Association and the Joint Commission.

6.1. Request for Proposals

A tool frequently used by executive leadership, the request for proposal is critical to drive industry change such as support for IHE interoperability profiles. IHE provides a common language that allows clinicians, executives, and healthcare vendors to identify data interoperability needs and solutions with a single concept. Using IHE profiles mitigates the need for hundreds of pages of technical document interface engines and on-site testing.

IHE has developed a publication to assist in this process, titled Purchasing Using IHE Cardiology (29). This white paper sets out for vendors the recommended specific verbiage that should be used in the request, ensuring that the delivered product will perform as expected. The target audience of the white paper comprises hospital executive suite administrators and initial decision makers.

6.2. Advantages to Vendors/Users

IHE provides several advantages for facilities and vendors who comply with IHE profiles, particularly in improving healthcare delivery and reducing healthcare costs.

First and foremost, IHE profiles provide predictable applications of known technologies. Each profile is built with an emphasis on applying international standards to specific clinical problems. Although a profile does not prevent a vendor from creating or using proprietary devices or software, it does increase the likelihood that the solution will successfully connect and share data across the enterprise. This benefit comes from the open and collegial nature of the IHE domain; when a vendor joins the effort, there is an intentional emphasis placed on sharing information and mutual success. Each profile that is developed receives insights and contributions from other vendors as well as clinicians and medical societies, which provide valuable feedback on the profile’s use in the clinical setting. For example, at the annual IHE testing event, the Connectathon, vendor teams that compete in the marketplace must work together to complete tasks that allow clinical data to flow from one proprietary system to another. The successful data exchange must be verified by a third party for the vendor to receive IHE certification. This ensures that results are predictable and reproducible.

The second benefit of applying IHE profiles is transparency. Each step of profile development, from the original submission of an idea to improve clinical work-flows to the final approved specification, takes place in an open, public environment. All stakeholders are encouraged to view, comment, and improve on the ideas presented within a profile while it is in development. With the diverse membership of IHE, this ensures that the profiles are intellectually rigorous and have the guidance of different clinical and technical perspectives.

6.3. Office of the National Coordinator

The principal federal entity charged with overseeing the nationwide implementation of health IT, the ONC is intimately involved in the Medicare and Medicaid EHR Incentive Programs to provide financial incentives for the “meaningful use” of certified EHR technology. The intention of the deferral EHR Incentive Program is to improve quality, safety, and efficiency and to reduce healthcare disparities. Other goals are to engage patients and family, improve care coordination, improve population and public health, and maintain the privacy and security of patient health information. It is hoped that compliance with the EHR Incentive Program will result in better clinical outcomes, improved population health outcomes, increased transparency and efficiency, empowered individuals, and more robust research data on health systems. Through the Health IT Certification Program, the ONC provides assurance to purchasers and other users that a system meets the technological capability, functionality, and security requirements adopted by the U.S. Department of Health and Human Services. Until recently, the Health IT Certification Program has focused on the initial transformation from paper to EHRs, support of the objectives and clinical quality measures defined by the Centers for Medicare and Medicaid Services, and collecting some quality metrics. Along with usability, a major criticism of the EHR Meaningful Use program has been the lack of emphasis on interoperability among electronic health information systems (30).

Signaling that interoperability has become a priority, the ONC released a document in 2015 titled “Connecting Health and Care for the Nation: A Ten Year Vision to Achieve Interoperable Health IT Infrastructure” (31). The document outlines critical actions for both public and private stakeholders to advance our nation toward an interoperable health IT ecosystem, advance research, and ultimately achieve a learning healthcare system. The guiding principles reflect many of the core strengths of IHE: the ability to build upon existing health IT infrastructure; the fact that individual IHE profiles are developed organically between healthcare providers and industry, thus leveraging market demands and resources; and the fact that IHE profiles build upon existing data standards.

The ONC’s plan to work with federal and state entities to advance payment, policy, and programmatic levers that drive development and implementation of truly interoperable health IT systems will encourage industries to devote the necessary resources to comply with certification requirements and hold the greatest hope for advancing meaningful progress toward achieving maximum interoperability. The document explicitly states: “Moving forward, the ONC’s Data Access Framework initiative (DAF) is evolving existing IHE and Health Level 7 standards to support next-generation query services” (31). The ONC has mentioned numerous profiles for data capture, clinical research, and quality across the spectrum of clinical specialties. This demonstrates how IHE can provide the leadership and tools necessary for achieving interoperability (32). The ACC applauds the ONC’s recognition and support for IHE.

6.4. Measuring Success

One can measure adoption of IHE technical frameworks by looking at the number of workflows implemented in a given IHE domain by each vendor. Moreover, success can also be defined as implementing the frameworks into real day-to-day workflow to reduce errors and improve outcome. For example, adapting the DICOM modality worklist to echo modalities allows the sonographer to pull the demographics directly from the ADT (Admit, Discharge, Transfer) feed, eliminating transcription errors or duplicate patient accounts. In the United States, implementation of the IHE technical frameworks remains, admittedly, a somewhat distant aspiration that will require sustained collaboration from all stakeholders. Clinical organizations in particular can drive the implementation of profiles and provide valuable data to further improve their effectiveness and new avenues for developing new solutions.

7. THE PATIENT’S PERSPECTIVE ON INTEROPERABILITY AND QUALITY

Patients expect high-quality, efficient, and compassionate care. They expect that their primary physician will work with specialists to identify appropriate care plans and that the clinicians will communicate recommendations and treatment status. Patients also expect that clinicians will have an ongoing dialogue and a robust exchange of data regarding treatment status throughout the course of treatment. Information should be easily accessible to all clinicians involved in the care of a patient, regardless of where it was obtained (e.g., office, hospital, or urgent care center) and the EHR system used for documentation. This can be aided by the patient’s opt-in consent for release of medical data among health-care providers, which can be less cumbersome when incorporated as a part of an EHR system. This is particularly important during transitions of care, when patients are most vulnerable and have the greatest need for their healthcare providers to have access to other providers’ records (33). The present information environment—requiring lengthy and often cumbersome paper-based requests for copies of medical records—delays clinical decision making and can result in unnecessary duplicate testing. Errors associated with the selective and manual transcription of data between source documents are also of concern. Ultimately, it is the patient’s right to expect that the clinical systems using and retaining his or her data are interoperable, standards-based, portable, and readily accessible.

8. CONCLUSIONS

The lack of interoperability of health IT prevents the field of health care from realizing the full potential of the Information Age that has revolutionized so many fields of human endeavor. Using internationally recognized standards, IHE provides a construct to create the technical frameworks to exchange healthcare data while maintaining the granular syntactic and semantic attributes needed to accommodate the needs of the diverse consumers of healthcare information. We should not underestimate the complexity of true interoperability. Developing meaningful interoperability across the diverse and complex field of health care will require leadership from medical societies as well as federal and state organizations in the form of policies and financial incentives that will steer industry to develop and implement the infrastructure and systems that consumers require. Although we cannot overemphasize the enormity of this process, IHE will allow the rapid dissemination of best practices through efforts in standardization.

The ACC believes that meaningful interoperability of data, agnostic of proprietary vendor formatting, is crucial for optimal patient care as well as the many associated activities necessary to support a robust and transparent healthcare delivery system. IHE serves a unique role and fills a critical gap in pursuit of this goal.

APPENDIX 1. AUTHOR LISTING OF RELEVANT RELATIONSHIPS WITH INDUSTRY AND OTHER ENTITIES—2016 ACC/ASE/ASNC/HRS/SCAI HEALTH POLICY STATEMENT ON INTEGRATING THE HEALTHCARE ENTERPRISE

Committee Member	Employment	Consultant	Speakers Bureau	Ownership/ Partnership/ Principal	Personal Research	Institutional/ Organizational or Other Financial Benefit	Expert Witness
John R. Windle (Chair)	University of Nebraska Medical Center—Professor and Chief, Internal Medicine Division of Cardiology	None	None	None	None	None	None
Alan S. Katz (Vice Chair)	Catholic Health Services—Vice President, Medical Informatics	None	None	None	None	Chartwise Medical Systems*	None
J. Paul Dow Jr.	American College of Cardiology—Healthcare Technology Associate	None	None	None	None	None	None
Edward T.A. Fry	St. Vincent Medical Group—Interventional Cardiologist	None	None	None	None	None	None
Andrew M. Keller	Danbury Hospital—Chief of Cardiology	None	None	None	None	None	None
Terran Lamp	Shionogi, Inc.—Pharmaceutical Sales Consultant	None	None	None	None	None	None
Alexander Lippitt, Jr.	Health Information Management and Systems Society—Senior Director, Interoperability and Standards (former employment during writing effort)	None	None	None	None	None	None
Marianne P. Paruche	NYU Langone Medical Center, EP Lab—Administrative Director	None	None	None	None	None	None
Frederic S. Resnic	Lahey Clinic Medical Center—Chairman, Department of Cardiovascular Medicine	St. Jude Medical	None	None	None	None	None
Gerald A. Serwer	University of Michigan Congenital Heart Center, University of Michigan Health Systems—Professor of Pediatric Cardiology	Medtronic	None	None	None	None	None
David J. Slotwiner	Weill Cornell Medical College—Assistant Professor of Medicine	None	None	None	None	None	None
James E. Tcheng	Duke University Medical Center—Professor of Medicine	None	None	None	None	Philips Medical Systems	None
Peter L. Tilkemeier	Greenville Health System—Chairman of Internal Medicine	None	None	None	None	None	None
Bonnie H. Weiner	St. Vincent Hospital—Training Director	Stryker	None	Imaging Core Lab Services*	None	None	None
William S. Weintraub	Christiana Care Health System—Section Chief, Cardiology	None	None	None	None	None	None

This table represents the relationships of committee members with industry and other entities that were determined to be relevant to this document. These relationships were reviewed and updated in conjunction with all meetings and/or conference calls of the writing committee during the document development process. The table does not necessarily reflect relationships with industry at the time of publication. A person is deemed to have a significant interest in a business if the interest represents ownership of ≥5% of the voting stock or share of the business entity, or ownership of ≥$5,000 of the fair market value of the business entity; or if funds received by the person from the business entity exceed 5% of the person’s gross income for the previous year. Relationships that exist with no financial benefit are also included for the purpose of transparency. Relationships in this table are modest unless otherwise noted. According to the ACC, a person has a relevant relationship IF: a) the relationship or interest relates to the same or similar subject matter, intellectual property or asset, topic, or issue addressed in the document; b) the company/entity (with whom the relationship exists) makes a drug, drug class, or device addressed in the document, or makes a competing drug or device addressed in the document; or c) the person or a member of the person’s household, has a reasonable potential for financial, professional or other personal gain or loss as a result of the issues/content addressed in the document.

^*No financial benefit.

APPENDIX 2. PEER REVIEWER LISTING OF RELEVANT RELATIONSHIPS WITH INDUSTRY AND OTHER ENTITIES (RELEVANT)—2016 ACC/ASE/ASNC/HRS/SCAI HEALTH POLICY STATEMENT ON INTEGRATING THE HEALTHCARE ENTERPRISE

Reviewer	Representation	Employment	Consultant	Speakers Bureau	Ownership/ Partnership/ Principal	Personal Research	Institutional, Organizational, or Other Financial Benefit	Expert Witness
Piers C.A. Barker	Official Reviewer—ASE	Duke University Medical Center—Professor of Pediatrics and Obstetrics/Gynecology Section Head, Pediatric Cardiac Non-Invasive Imaging	None	None	None	None	None	None
Ralph G. Brindis	Official Reviewer—ACC Clinical Quality Committee	University of California, San Francisco Department of Medicine & the Philip R. Lee Institute for Health Policy Studies—Clinical Professor of Medicine; ACC National Cardiovascular Data Registry—Senior Medical Officer, External Affairs	None	None	None	None	None	None
Timothy A. Dewhurst	Official Reviewer—ACC Board of Governors	UT Southwestern Medical Center—Associate Professor of Internal Medicine	None	None	None	Biotronik	None	None
Peter L. Duffy	Official Reviewer—SCAI	FirstHealth of the Carolinas at Pinehurst, North Carolina—Medical Director, Reid Heart Center	None	None	None	None	None	None
Dmitriy N. Feldman	Official Reviewer—SCAI	Weill Cornell Medical College Interventional Cardiac and Endovascular Laboratory—Director, Endovascular Services; Director, Interventional Observation/Telemetry Unit, Associate Professor of Medicine	None	None	None	Biotronik	None	None
Osvaldo S. Gigliotti	Official Reviewer—SCAI	University of Texas at Austin, Dell School of Medicine—Assistant Professor of Medicine; Seton Hall Institute—Interventional Cardiologist	None	None	None	Medtronic*	None	None
Christopher L. Hansen	Official Reviewer—ASNC	Thomas Jefferson University—Professor of Medicine and Radiology	Digirad	None	General Electric*	None	None	None
Neal Lippman	Official Reviewer—HRS	Arrhythmia Consultants of Connecticut, LLC—Attending Electrophysiologist; University of Connecticut Health Center—Clinical Assistant Professor of Medicine	Medtronic St. Jude Medical*	None	None	None	None	None
Michael J. Mirro	Official Reviewer—HRS	Parkview Health System—Senior Vice President, Chief Academic Research Officer	McKeson ZOLL Medical	None	Medical Informatics Engineering*	Biotronik† St. Jude Medical	None	None
John S. Rumsfeld	Official Reviewer—ACC Board of Trustees	U.S. Veterans Health Administration—National Director of Cardiology	None	None	None	None	None	None
Joyce Sensmeier	Organizational Reviewer—HIMSS	HIMSS North America—Vice President Informatics	None	None	None	None	None	None
H. Vernon Anderson	Content Reviewer—NCDR Management Board	University of Texas Health Science Center, McGovern Medical School, Houston, Texas—Professor of Medicine	None	None	None	MedPace Medical Devices (DSMB)	None	None
Shyam Bhakta	Content Reviewer—Advocacy Steering Committee	Northeast Ohio Medical University College of Medicine—Assistant Professor of Internal Medicine; Cleveland Clinic Akron General	None	None	None	None	None	None
Gilead I. Lancaster	Content Reviewer—Advocacy Steering Committee	Bridgeport Hospital/Yale New Haven Health System—Director, Non-Invasive Cardiology	None	None	None	None	None	None
William A. Van Decker	Content Reviewer—Advocacy Steering Committee	Temple University Hospital—Assistant Professor of Medicine	None	None	None	None	None	None
Paul G. Varghese	Content Reviewer—Data Standards Task Force	Harvard Medical School—National Library of Medicine Informatics Fellow	None	None	ChartWise Medical*	None	None	None
Siqin Kye Ye	Content Reviewer—Informatics and Health Information Technology Task Force	Columbia University Medical Center—Assistant Professor of Medicine, Division of Cardiology, Department of Medicine	None	None	None	None	None	None

This table represents the relationships of reviewers with industry and other entities that were disclosed at the time of peer review and determined to be relevant to this document. It does not necessarily reflect relationships with industry at the time of publication. A person is deemed to have a significant interest in a business if the interest represents ownership of ≥5% of the voting stock or share of the business entity, or ownership of ≥$5,000 of the fair market value of the business entity; or if funds received by the person from the business entity exceed 5% of the person’s gross income for the previous year. A relationship is considered to be modest if it is less than significant under the preceding definition. Relationships that exist with no financial benefit are also included for the purpose of transparency. Relationships in this table are modest unless otherwise noted. Names are listed in alphabetical order within each category of review. According to the ACC, a person has a relevant relationship IF: a) the relationship or interest relates to the same or similar subject matter, intellectual property or asset, topic, or issue addressed in the document; b) the company/entity (with whom the relationship exists) makes a drug, drug class, or device addressed in the document, or makes a competing drug or device addressed in the document; or c) the person or a member of the person’s household, has a reasonable potential for financial, professional or other personal gain or loss as a result of the issues/content addressed in the document.

^*Significant relationship.

^†No financial benefit.

ACC indicates American College of Cardiology; ASE, American Society of Echocardiography; ASNC, American Society of Nuclear Cardiology; DSMB, data and safety monitoring board; HIMSS, Healthcare Information and Management Systems; HRS, Heart Rhythm Society; NCDR, National Cardiovascular Data Registry, and SCAI, Society of Cardiovascular Angiography and Interventions.

APPENDIX 3. ABBREVIATIONS

AC

American College of Cardiology

ATNA

Audit trail and node authentication

CATH

Cardiac Catheterization Workflow

CDA

Clinical Document Architecture

CIED

Cardiac Implantable Electronic Device

CIR

Cardiac Imaging Report Content

CR

Cath Report Content

CRD

clinical research document

CRP

clinical research process content

DEX

data element exchange

DICOM

Digital Imaging and Communications in Medicine

DRPT

Displayable Reports

ECG

electrocardiogram

ECHO

Echocardiography Workflow

ED

evidence documents

ED CARD

Evidence Documents-Cardiology

EHR

electronic health record

EPRC-IE

Electrophysiology Report Content-Electrophysiology Implant/Explant Procedure

HL7

Health Level 7

IDCO

Implantable Device Cardiac Observation

IEO

Image-Enabled Office Worfkflow

IHE

Integrating the Healthcare Enterprise

IT

information technology

NCDR

National Cardiovascular Data Registry

NMI

nuclear medicine image

ON

Office of the National Coordinator for Health Information Technology

PACS

picture archiving and communications system

PCI

percutaneous coronary intervention

PDF

portable document format

PET

positron emission tomography

RCS-

Registry Content Submission-CathPCI

REWF

Resting ECG Worfklow

RFD

Retrieve Form for Data Capture

RM

research matching

RPE

retrieve process for execution

RWI

relationships with industry

SPECT

single-photon emission computed tomography

STRESS

Stress Testing Worfklow

W3

World Wide Web Consortium