HRS White Paper on interoperability of data from cardiac implantable electronic devices (CIEDs)
2019; Elsevier BV; Volume: 16; Issue: 9 Linguagem: Inglês
10.1016/j.hrthm.2019.05.002
ISSN1556-3871
AutoresDavid J. Slotwiner, Robert L. Abraham, Sana M. Al‐Khatib, H. Vernon Anderson, T. Jared Bunch, Martha Ferrara, Neal Lippman, Gerald A. Serwer, P. Steiner, James E. Tcheng, Niraj Varma, Bruce L. Wilkoff,
Tópico(s)Healthcare Technology and Patient Monitoring
ResumoThis HRS Needs Assessment is in the category of the Heart Rhythm Society (HRS) documents delineating a future direction of research, technology development, or health care policy and adheres to the following requirements set forth by the HRS:1.There are no clinical practice recommendations.2.The Chair and Vice-Chair of the document are free of any relationships with industry and other entities (RWIs).3.The remainder of the writing committee may have RWIs, with no dollar limit, but may not have relevant stock, stock options, equity, or royalties or be employed by industry.4.The writing committee is encouraged to gain information from advisors. Advisors must be physicians or health care providers who are not able to serve as writing committee members because they have relevant stock, stock options, equity, or royalties. Advisors cannot be employed by industry and do not participate in writing.5.The writing committee uses industry forums to engage representatives of industry, the U.S. Food and Drug Administration, or other third-party organizations in a dialogue to provide an exchange of information.6.A full disclosure of RWIs for each writing committee member and each advisor is provided in an appendix. Cardiac implantable electronic device (CIED) technologies have improved significantly over the past decade, and indications for these devices have expanded. This has led to an increasing number of patients being managed with CIEDs, resulting in an exponential quantity of data that needs to be sorted, interpreted, acted upon, and stored. The basic settings and diagnostic and therapeutic capabilities of CIEDs are similar regardless of manufacturer. Each has developed proprietary nomenclature, technical standards, and communication protocols to describe similar if not identical features and functionalities. Clinicians, primarily concerned with evaluating battery status, programmed parameters, arrhythmias, and therapies delivered, must pull together data from multiple settings (hospital, office, remote monitoring) and multiple vendors in order to manage large numbers of CIED patients. Traditional electronic health records (EHR) used for both inpatient and outpatient care are not well suited to managing CIED data, and stand-alone products designed for this purpose struggle with mixed success to unlock the data from proprietary formats. The Heart Rhythm Society (HRS), in partnership with CIED manufacturers and the EHR industry, has been leading an effort since 2006 to overcome these challenges by developing a standard lexicon of CIED terminology1IEEE Standards AssociationIEEE 11073-10103-2012 - Health informatics--Point-of-care medical device communication Part 10103: Nomenclature--Implantable device, cardiac.https://standards.ieee.org/standard/11073-10103-2012.htmlDate accessed: December 10, 2018Google Scholar as well as a vendor-neutral platform for communicating CIED data across electronic systems.2Integrating the Healthcare EnterprisePCD implantable device cardiac observation.https://wiki.ihe.net/index.php/PCD_Implantable_Device_Cardiac_ObservationDate accessed: December 10, 2018Google Scholar Industry participants include Biotronik; Boston Scientific Corporation; Medtronic, Inc; Abbott (formerly St. Jude Medical); EPIC; GE Healthcare; Geneva Health Solutions; Heartbase; ImplicityTM; Lille Corporation; LindaCare; MicroPort Scientific Corporation (formerly Sorin Group); MURJ; and NEXTGEN Healthcare. A similar collaboration between the American College of Radiology and the radiology vendor industry led to the development of one of the most successful data standards in medicine: the Digital Imaging and Communications in Medicine (DICOM) standard. DICOM is used for storing, transmitting and archiving medical images and is now the universal standard for managing medical images. In this document, we provide a brief overview of U.S. federal initiatives to promote interoperability of data, the requirements needed to communicate data between information technology (IT) systems in a way that permits the sending and receiving systems to understand and process the data, a summary of the work of HRS to date, and, finally, strategies for clinicians seeking an environment in which they can manage their CIED patient data in a single IT system. From the outset, EHRs were heralded as tools that would simplify work for clinicians, improve quality by enabling timely access to data by health care provider, empower patients to take charge of their own data, and ultimately improve the quality and efficiency of health care. While almost all of health care has shifted from paper to electronic record keeping, the anticipated benefits have not materialized, with increased documentation and administrative burdens associated with EHRs directly contributing to the increased rates of physician burnout.3Downing N.L. Bates D.W. Longhurst C.A. Physician burnout in the electronic health record era: are we ignoring the real cause?.Ann Intern Med. 2018; 169: 50-51Crossref PubMed Scopus (188) Google Scholar, 4Shanafelt T.D. Dyrbye L.N. Sinsky C. et al.Relationship between clerical burden and characteristics of the electronic environment with physician burnout and professional satisfaction.Mayo Clin Proc. 2016; 91: 836-848Abstract Full Text Full Text PDF PubMed Scopus (546) Google Scholar One key contributor to the frustration of clinicians with present EHR systems is that they are not interoperable: data are siloed within separate systems, often even within an individual health system. Information transfer still requires transmission of hard copies (paper, facsimile) or another electronic medium (CD/DVD-ROM) that is subsequently converted to electronic format into another EHR, creating redundancy and the potential for human error. To address these challenges, a bipartisan majority of the U.S. Congress passed the 21st Century Cures Act of 2016 (The Cures Act) requiring the U.S. Department of Health and Human Services and the Office of the National Coordinator for Health Information Technology (ONC) to improve the interoperability of health information.5Office of the National Coordinator for Health Information TechnologyAchieving the interoperability promise of 21st Century Cures.https://www.healthit.gov/buzz-blog/interoperability/achieving-the-interoperability-promise-of-21stcentury-curesDate accessed: January 22, 2019Google Scholar Broadly, the requirements fall into 4 categories:1.Promoting patient, clinician, and payer access to clinical data via open and accessible application programming interfaces (APIs). APIs allow one software program to access the data and services provided by another software program.2.Prohibition of information blocking. Information blocking is defined as impediments to the free and open (authorized) access to clinical information.6Office of the National Coordinator for Health Information TechnologyReport to Congress. Report on health information blocking.https://www.healthit.gov/sites/default/files/reports/info_blocking_040915.pdfDate accessed: January 22, 2019Google Scholar The Cures Act seeks to confront this practice by prohibiting information blocking by health care providers, health IT developers, exchanges, and networks, establishing disincentives and imposing penalties for information blocking.3.Development of a Trusted Exchange Framework and Common Agreement to improve data sharing across disparate health information networks.7Office of the National Coordinator for Health Information TechnologyTrusted exchange framework and common agreement.https://www.healthit.gov/topic/interoperability/trusted-exchange-framework-and-common-agreementDate accessed: January 22, 2019Google Scholar Currently there are over 100 health information exchanges, most organized at the state or regional level to facilitate secure sharing of health information between organizations and health care providers. The original vision was that individual health information exchanges would securely share information, creating a nationwide network. This approach has been hindered primarily because of variability of participation agreements across exchanges. The Cures Act calls on ONC to develop or support a trusted exchange framework and common agreement to address this challenge, thereby enabling a provider, health system, or patient who joins one regional health information exchange to also have access to data from all the other exchanges, providing access to a patient’s medical record across all exchanges and across the country.4.Reduction of clinician burden in the use of EHR systems, especially administrative and reporting burden.8Office of the National Coordinator for Health Information TechnologyStrategy on reducing burden relating to the use of health IT and EHRs.https://www.healthit.gov/topic/usability-and-provider-burden/strategy-reducing-burden-relating-use-health-it-and-ehrsDate accessed: January 22, 2019Google Scholar This will be undertaken largely through another branch of Health and Human Services, the Centers for Medicare & Medicaid Services (CMS). New Evaluation and Management codes, to be released at the end of 2019, aim to reduce the administrative burden of often unnecessary documentation. In parallel, CMS has renamed the EHR Incentive Program for Electronic Health Records (also known as “Meaningful Use”) to “Promoting Interoperability.”9The Centers for Medicare and Medicaid ServicesCMS proposes changes to empower patients and reduce administrative burden.https://www.cms.gov/newsroom/press-releases/cms-proposes-changes-empower-patients-and-reduce-administrative-burdenDate accessed: February 2, 2019Google Scholar The work described herein supports these initiatives by identifying and specifying a common, shared lexicon for CIED management, a key requirement of data interoperability, as outlined next. The Institute for Electrical and Electronics Engineering (IEEE) defines interoperability as the “ability of two or more systems or components to exchange information and to use the information that has been exchanged.”10IEEE Standards AssociationIEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries (New York, NY: 1990).https://ieeexplore.ieee.org/document/182763/definitions?anchor=definitions#definitionsDate accessed: December 12, 2018Google Scholar There are 2 components required to achieve this:1.The ability of 2 or more systems to exchange formatted information:•Syntactic interoperability refers to the format of data, such that sending and receiving systems can transmit and receive the data; in other words, syntax refers to the structure of the message.2.The ability of those systems to understand and use the information that has been exchanged:•Semantic interoperability refers to the meaning of the message, such that the data exchanged are understood by both systems to have the same meaning. This requires use of a common data lexicon used by all parties, with common shared definitions and a controlled vocabulary. When these 2 conditions are met, the communicating computer systems can transmit, receive, process, tabulate, calculate, analyze, and use the exchanged data. Otherwise, while the data can be stored and retrieved generically, the data will have only limited use due to incompatible formats and/or differences in semantic meaning. Below are the 4 broad categories of requirements to achieve data interoperability.1.Development of a controlled vocabularyA controlled vocabulary is a standardized set of words and phrases that define and describe concepts. Controlled vocabularies are used to organize information for subsequent retrieval and overcome the ambiguities of natural language.2.Specification of data elementsEach concept of a controlled vocabulary and its associated metadata must be clearly defined as data elements. Typically, this includes not only the name of the data element but also the allowed (permissible) values (also known as the “value set”), definitions of the allowed values, data format, data rules (range, cardinality, optional vs required), reference resource information, and (when it exists) the terminology binding (linkage of the concept to an existing information model such as Logical Observation Identifiers Names and Codes [LOINC] or Systematized Nomenclature of Medicine-Clinical Terms [SNOMED-CT]).3.Agreement on data management frameworkCapture, transmission, and use of structured data necessitate technical data models (the framework for management of the data itself in database systems), as well as specification of data transmission “handshake” standards for communication between systems. This specification of the physical management of data and accompanying metadata in a consistent, validated, and testable manner is the keystone to enabling the use and dissemination of data as a resource.11WikipediaData modeling.https://en.wikipedia.org/wiki/Data_modelingDate accessed: January 22, 2019Google Scholar4.Structured ReportingFinally, the process for data capture and validation must be integrated into consistent clinical workflows. These best practice processes must be tuned to the specific context (eg, CIED implantation or removal, in-person clinic follow-up, remote monitoring). The general principles of structured reporting include the acquisition of information as data (rather than prose) by the individual closest to the data, along with the use of the data for multiple purposes (eg, procedure reporting, quality assessment, registry reporting). Given the incredible breadth of clinical medicine and the nuances of language, achieving interoperability is a daunting task that requires a coalition of clinicians, informaticians, industry, process engineers, and EHR/health IT vendors. The circumscribed and definable parameters delineating CIED management seem a natural fit for accomplishing interoperability. In 2005, HRS accepted the invitation from the American College of Cardiology to form a cardiac electrophysiology subcommittee of the Cardiology Domain of the Integrating the Healthcare Enterprise (IHE).12Winters S.L. Kusumoto F.M. Miller J.M. Slotwiner D.J. The role of the Heart Rhythm Society in integrating the healthcare enterprise.HeartRhythm. 2007; 4: 122-124Scopus (6) Google Scholar The first stage of the work required clinicians and engineers from the 4 major CIED manufacturers to identify the key concepts required to manage patients with these devices and then develop the CIED controlled vocabulary. Participants agreed upon the vocabulary and then specified the data elements and metadata of the nomenclature in a vendor-neutral fashion. Once this was completed, the controlled vocabulary was brought to the IEEE, the standards development organization responsible for oversight of this domain of medical terminology. Per IEEE protocol, members of IEEE (engineers and clinicians) reviewed the proposed new nomenclature standard and voted on approval (Figure 1).13IEEE Standards AssociationDevelop standards.https://standards.ieee.org/develop/process.htmlDate accessed: December 9, 2018Google Scholar IEEE approved the controlled vocabulary as an IEEE standard (11073-10103) on August 27, 2012. Subsequently, it was approved as an international standard by the International Standards Organization (ISO) and recognized by the U.S. Food and Drug Administration.1IEEE Standards AssociationIEEE 11073-10103-2012 - Health informatics--Point-of-care medical device communication Part 10103: Nomenclature--Implantable device, cardiac.https://standards.ieee.org/standard/11073-10103-2012.htmlDate accessed: December 10, 2018Google Scholar, 14WikipediaInternational Organization for Standardization.https://en.wikipedia.org/wiki/International_Organization_for_StandardizationDate accessed: December 2, 2018Google Scholar, 15Food and Drug AdministrationRecognized consensus standards.https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfstandards/detail.cfm?standard__identification_no=34083Date accessed: December 9, 2018Google Scholar Once the nomenclature was complete, clinicians and industry engineers turned their focus toward developing a standards-based IHE profile to specify CIED data transmission and communication across IT platforms while maintaining the relative structural arrangement of the data. IHE leverages existing standards (such as the IEEE 11073-10103 CIED controlled vocabulary and Health Care Level 7) to create “plug-and-play” health care equipment and electronic medical records that communicate with each other. The work product of this collaboration was the Implantable Device Cardiac Observation (IDCO) Profile (Figure 2).2Integrating the Healthcare EnterprisePCD implantable device cardiac observation.https://wiki.ihe.net/index.php/PCD_Implantable_Device_Cardiac_ObservationDate accessed: December 10, 2018Google Scholar Importantly for the vendors, both the IEEE nomenclature and IDCO Profile were constructed to allow vendor-specific features and functionalities to be included. Furthermore, reports maintain individual vendor characteristics and the standards anticipate ongoing improvements in proprietary diagnostic and therapeutic features. An essential component of developing an IHE profile is the testing of systems at IHE Connectathon events leading to IHE certification. IHE Connectathons are cross-vendor, live, supervised, and structured testing events to advance health IT interoperability where industry leaders test implementations of IHE Profiles. At a Connectathon, both sending and receiving vendors test their product to ensure that the profile has been implemented correctly and that the systems are able to send and/or receive the data accurately. All tests are evaluated on interoperability and conformance to IHE Profiles found in IHE’s Technical Frameworks.16Integrating the Healthcare EnterpriseCardiology technical framework.https://www.ihe.net/resources/technical_frameworks/#cardiologyDate accessed: December 12, 2018Google Scholar The test floor is overseen by IHE’s technical project managers, providing a safe, neutral test environment and an unparalleled opportunity for industry collaboration and problem resolution. IHE Connectathons take place annually in the United States, Europe, and Asia. The IDCO Profile was first tested in draft version at a Connectathon in 2009, even before the final IEEE endorsement of the 11073-10103 nomenclature. Following the IEEE approval of the vocabulary and IHE certification of the IDCO Profile, vendors began implementing support for both in commercially available products. However, as with many initial introductions of new standards, the IDCO Profile failed to become widely implemented and used for several reasons. First, only CIED vendors implemented it. EHR vendors were preoccupied at the time with meeting the requirements of the EHR Incentive Program (“Meaningful Use”) and reported that customers were not requesting support for the IDCO Profile. EHR vendors saw no financial incentive to support the profile. In addition, EHR and CIED vendors received no requests from physicians for support of the profile, which they interpreted as a lack of demand for data interoperability from the clinical community. Following the implementation of the IDCO Profile detailed above with the 2012 version of the ISO/IEEE 11073 Health informatics – Medical / health device communication standards1IEEE Standards AssociationIEEE 11073-10103-2012 - Health informatics--Point-of-care medical device communication Part 10103: Nomenclature--Implantable device, cardiac.https://standards.ieee.org/standard/11073-10103-2012.htmlDate accessed: December 10, 2018Google Scholar for CIEDs, deficiencies became apparent that necessitated revisions of the nomenclature. The most significant and unanticipated problem was that CIED manufacturers did not implement the full IEEE-approved controlled vocabulary. As a result, only a limited set of data could be transmitted in the IDCO Profile. This led other industry partners and clinicians to believe that the IEEE nomenclature was insufficiently robust and unable to support clinical patient care. Additional challenges included ambiguities in the data element definitions and the introduction of new CIED technologies after the nomenclature was completed in 2012. In 2017, HRS convened the HRS Interoperability Workgroup to address these limitations. The workgroup was expanded to include HRS members, representatives from the American College of Cardiology, the 4 major CIED vendors, EHR vendors, and remote monitoring IT vendors, along with participation by the U.S. Food and Drug Administration. The HRS Interoperability Workgroup holds monthly calls to review the existing nomenclature, develop new data elements, and define parameters for communicating notifications from remote monitoring servers to EHRs and remote monitoring vendors. After each monthly call, workgroup members vote electronically on the recommendations discussed during the call. Engineers from the vendors meet weekly to develop the technical standard based upon the outcome of the monthly calls and votes. As noted previously, the most significant problem with the initial implementation of the IEEE vocabulary by industry was the selective and incomplete support of IEEE data elements. For example, battery status might be communicated in the IEEE nomenclature, but pacing capture thresholds might not be supported. To address this, the workgroup developed the concept of mandatory vs optional data elements per device class (pacemaker, implantable cardioverter-defibrillator, cardiac resynchronization therapy) that a vendor must provide to be in compliance with proper implementation of the vocabulary. Data elements required for quality clinical care, such as device type, serial number, lead sensing, impedances, capture thresholds, programmed settings, etc, were identified as being mandatory for reporting. If the data could be provided by the device but the relevant feature had been programmed “Off,” this information must be communicated using the appropriate flag. Data elements that were not essential for clinical care were labeled as optional. If an optional data element was not available, it could be eliminated from the interoperability message while not needing to be labeled “not available.” Allowances were made to address different manufacturers providing similar but not identical information to describe the same concept. Figure 3, prepared by the Engineering in Medicine and Biology (EMB/11073/EMBS_WG) Working Group of the IEEE Engineering in Medicine and Biology Society/11073 Committee (EMB/11073), represents a sample of the nomenclature in a human readable report. On the figure, data elements that the workgroup deemed mandatory are presented in black, and data elements deemed optional are presented in gray. (See Appendix A for a full example.) The workgroup is expanding the nomenclature to achieve more complete coverage of CIED content, to include the Unique Device Identifier,17Food and Drug AdministrationUnique device identifier - UDI.https://www.fda.gov/medicaldevices/deviceregulationandguidance/uniquedeviceidentification/Date accessed: April 1, 2019Google Scholar and it is addressing the recent technological advances, such as the broader use of remote monitoring, by including new features in the nomenclature. It is important to note that the nomenclature makes allowances for individual proprietary vendor features and it does not limit vendors from offering new and distinguishing diagnostic or therapeutic functions for their devices. One goal of the IEEE nomenclature and IDCO Profile is to allow clinicians to review and manage their CIED patient data on a single EHR or remote monitoring data management platform. As such, alert-related information for abnormal findings needs to be communicated from the remote monitoring server to the EHR or remote monitoring platform. The notification information will be included in the revised nomenclature and is illustrated in the example below: Scenario: The device indicates that a high ventricular rate during high atrial rates has been detected. Two notifications in the IDCO message: Notification 1:•Type(s) (the coded categories, which do apply for this notification):-High Atrial Rate-High Ventricular Rate•Priority (equivalent to the alert levels or colors in the vendor systems): Medium•Description (original vendor defined text): “Mean ventricular heart rate during mode switch mode or atrial burden high.” Notification 2:•Type(s)-High Ventricular Rate•Priority: Medium•Description: “VT detected” When technical issues arise that require harmonization of device characteristics amongst the CIED manufacturers, which is beyond the clinical scope and expertise of the workgroup, the workgroup escalates the request to the Association for Advancement of Medical Instrumentation (AAMI) Cardiac Rhythm Management Device Committee. AAMI is a nonprofit organization dedicated to the mission of developing and managing safe and effective health care technology. It is the primary source of consensus standards, both national and international, for the medical device industry. All of the CIED manufacturers are AAMI members and have engineering representation at the Cardiac Rhythm Management Device Committee. Example: There is tremendous variability in representing the battery longevity information among manufacturers. This information may also vary between pacemakers and defibrillators from a single vendor (Table 1).Table 1Illustration of the variation in defining the battery statusBattery statusBattery voltageBattery impedanceBattery longevityBattery percentageOtherVendor A PMOK, Explant, Battery Capacity DepletedN/AN/AYes, years (if ≥1 year) or months (if <1 year) remaining until explantYes, percentage remaining until explantCharge remaining, power consumption, magnet rate ICD/CRT-DOK, Explant, Battery Capacity DepletedN/AN/AYes, years (if ≥1 year) or months (if <1 year) remaining until explantYes, percentage remaining until explantCharge remaining, power consumptionVendor B PMBOS, MOS, RRT, EOS, UnknownYes if availableN/AFor some, remaining longevity in monthsYes, percentage remaining until explantBattery RRT trigger ICD/CRT-DBOS, MOS, RRT, EOS, UnknownYes if availableN/AFor some, remaining longevity in monthsYes, percentage remaining until explantBattery RRT triggerVendor C PMEOS or EOL, ERI or RRTYesFor someFor some, remaining longevity in years/monthsPM ICD/CRT-DEOS or EOL, ERI or RRTYesFor someFor some, remaining longevity in years/months ILRGood, RRT, EOSNoNoNoNo PMEOS or EOL, ERI or RRTYesFor someFor some, remaining longevity in years/months ICD/CRT-DEOS or EOL, ERI or RRTYesFor someFor some, remaining longevity in years/monthsVendor D PMBOS, ERI, EOS, OK for someYesFor someFor newer devices,∗Availability may vary between remote monitoring and programmer. remaining longevity in years/monthsFor someBar graph ICD/CRT-DBOS, MOS 1, MOS 2,†MOS 1/MOS 2 no longer present in future device generations. ERI, EOSYesNoRemaining service time after ERI detection onlyYesBar graph ILRBOS, ERI, EOSYesNoNoYesBar graphBattery Capacity Depleted = functionality is limited, therapies can no longer be guaranteed; BOS = beginning of service; CRT-D = cardiac resynchronization therapy device; EOL = end of life; EOS = end of service; ERI = elective replacement indicator; Explant = the battery is nearing depletion, generator replacement must be scheduled; ICD = implantable cardioverter-defibrillator; ILR = implantable loop recorder; MOS = middle of service; N/A = not available; OK = battery is OK; PM = pacemaker; RRT = recommended replacement time.∗ Availability may vary between remote monitoring and programmer.† MOS 1/MOS 2 no longer present in future device generations. Open table in a new tab Battery Capacity Depleted = functionality is limited, therapies can no longer be guaranteed; BOS = beginning of service; CRT-D = cardiac resynchronization therapy device; EOL = end of life; EOS = end of service; ERI = elective replacement indicator; Explant = the battery is nearing depletion, generator replacement must be scheduled; ICD = implantable cardioverter-defibrillator; ILR = implantable loop recorder; MOS = middle of service; N/A = not available; OK = battery is OK; PM = pacemaker; RRT = recommended replacement time. The lack of standardization is a barrier when implementing an interoperable nomenclature within the IEEE framework. The workgroup requested AAMI’s assistance with this challenge. The AAMI Cardiac Rhythm Management Device Committee reviewed this request and agreed to develop a single consistent standard to express the battery longevity. This AAMI project is in its infancy and should be available in the coming years. These revisions and clarifications will expand the capabilities of the IDCO Profile and ISO/IEEE-11073 nomenclature,1IEEE Standards AssociationIEEE 11073-10103-2012 - Health informatics--Point-of-care medical device communication Part 10103: Nomenclature--Implantable device, cardiac.https://standards.ieee.org/standard/11073-10103-2012.htmlDate accessed: December 10, 2018Google Scholar making it less ambiguous to the clinicians and more specific for industry to implement, thereby improving patient care; and expanding its use to more device and electrode types, including leadless pacemakers, subcutaneous ICDs, and implantable loop recorders. The current state of CIED data management and the variability across the industry in reporting basic device functions such as battery status adversely affects patient care and should not be accepted by patients or the electrophysiology community. Implementation of the ISO/IEEE 11073 nomenclature and IHE IDCO Profile will provide benefits for CIED developers/manufacturers, EHR developers, remote monitoring vendors, clinicians, clinical investigators, and, most importantly, patients. Patients will
Referência(s)