Certification of Electronic Health Record Technology: A Roadmap to Achieving Interoperability White Paper

Transcription

1 1 Certification of Electronic Health Record Technology: A Roadmap to Achieving Interoperability White Paper 2013 Baltimore, Maryland

2 2 The Public Health Data Standards Consortium (PHDSC, The Consortium) is a national non-profit membership-based organization of federal, state and local health agencies, professional associations, academia, public and private sector organizations, international members, and individuals. The Consortium is committed to bringing a common voice from the public health community to the national efforts of standardization of health information technology and population health data in order to improve individual and community health. To fulfill its mission the Consortium: Identifies priorities for new national standards for population health data; Promotes integrating health-related information systems to meet the needs of public and private organizations, agencies and individuals; Participates in national and international efforts to standardize health-related information; Represents public health interests in standards development organizations, data content committees and standards harmonization entities; and Educates the public health community about health information technology standards and the health information technology community about public health. 111 South Calvert Street Baltimore, MD Phone: (410) Fax: (866)

3 3 DISCLAIMER This document was developed under the Cooperative Agreement with the Centers for Disease Control and Prevention (CDC), Assuring HIT Standards for Public Health, Grant No.: 5U38HM The material in this document has not been subject to agency review and approval for publication as a Centers for Disease Control and Prevention (CDC) report. Mention of trade names, products, or services, does not convey, and should not be interpreted as conveying official CDC approval, endorsement, or recommendation. 3

4 4 CONTRIBUTING ORGANIZATIONS AND ACKNOWLEDGEMENTS Centers for Disease Control and Prevention (CDC) Ms. Michelle Williamson and Ms. Hetty Khan, National Center for Health Statistics, Project Officers. Public Health Data Standards Consortium (PHDSC, The Consortium) Dr. Anna Orlova, PHDSC s Executive Director and Visiting Associate Professor, Johns Hopkins School of Medicine, Principal Investigator. 4

5 5 Table of Contents INTRODUCTION... 6 TERMS AND BACKGROUND... 8 US CERTIFICATION PROGRAMS FOR HEALTH INFORMATION TECHNOLOGY BEGINNING: CCHIT AND STANDARDS CONTINUATION: TEMPORARY CERTIFICATION PROGRAM ( ) ONC PERMANENT HIT CERTIFICATION PROGRAM ( ) ONC PERMANENT CERTIFICATION PROGRAM, STANDARDS AND INTEROPERABILITY ACHIEVING INTEROPERABILITY THROUGH CERTIFICATION BUSINESS RELATED DATA EXCHANGE REQUIREMENTS LEVEL OF READINESS OF STANDARDS TO SUPPORT BUSINESS NEEDS FOR DATA EXCHANGE ALIGNING BUSINESS NEEDS FOR DATA EXCHANGE WITH EHR TECHNOLOGY CONCLUSIONS

6 6 INTRODUCTION Since 2009, the Public Health Data Standards Consortium (PHDSC), with the support from the Centers for Disease Control and Prevention (CDC)/National Center for Health Statistics (NCHS), has been facilitating the PHDSC Electronic Health Record - Public Health (EHR-PH) Task Force to develop the Health Level Seven International (HL7) Electronic Health Record-System (EHR-S) Public Health Functional Profile (PHFP). 1 The PHFP conforms to the HL7 EHR-S Functional Model (FM) Release 1.1 (R1.1) 2 and identifies the functional requirements needed to support data exchange among care providers, patients, consumers, industry and public health stakeholders at all levels of government (local, state and federal public health agencies) as they apply to eight public health programs (domains), namely: Birth Defects Chronic Disease Cancer Surveillance Deep Vein Thrombosis and Pulmonary Embolism (DVT/PE) Early Hearing Detection and Intervention (EHDI) Health Statistics (HS) Occupational Disease, Injury and Fatality (ODIF) Public Health Laboratory Interactions (Orders/Reports) (PHLI) Vital Records (VR) In , the Task Force completed mapping of the PHFP to the EHR-S FM Release 2 (R2) that was balloted at HL7 for comment in May The Task Force intends to use the PHFP as a reference for certification of EHR systems that include functionality to support various public health domains (programs). Since 2005, the Office of the National Coordinator for Health Information Technology (ONC) 3 has been working on establishing the certification program for EHR technology, beginning with the Certification Commission for Health Information Technology (CCHIT) 4 and, more recently, through the ONC Permanent Certification Program. 5 Despite these efforts, the survey data 6 show that the EHR users are dissatisfied with currently certified EHR systems. In the White Paper entitled "Reboot: Re-Examining the Strategies Needed to Successfully Adopt Health IT", a group of US senators stated that "electronic sharing of 1 Health Level Seven (HL7). EHR-System Functional Model Public Health Functional Profile. Release 1. URL: 2 Health Level Seven International (HL7) Electronic Health Record Systems (EHR-S) Functional Model (FM) Release 1. URL: 3 Office of the National Coordinator for Health Information Technology (ONC). URL: 4 Certification Commission for Health Information Technology (CCHIT). URL: 5 ONC Permanent Certification Program. URL: 6 McCann E. Black Book says unstable EHR market getting agitated. Government Heath IT. July 23,

7 7 data among health care providers <i.e., interoperability across EHR systems> has to date proven very difficult to establish." 7 The Task Force examined CCHIT s approach to the certification of EHR technology ( ) and ONC Certification Programs ( ) to understand why interoperability between healthcare systems has remained elusive. This paper describes a proposed approach for developing certification criteria based on the HL7 EHR-S FM aligned with (a) business process standards; (b) EHR information system functions (e.g., collect, manage, integrate, analyze data and generate output); and (c) interoperability standards supporting these functions. The proposed approach describes the HL7 EHR-S FM as a framework for the development of certification criteria based on existing standards. Additionally, it may serve as a roadmap for the development of new standards and offer guidance for EHR pilot implementations and adoption based on realistic expectations supported by mature standards. The PHFP, based on the EHR-S FM standard, could become the domain-specific framework of business requirements, EHR functions and supporting standards that, in turn, could be used to drive standards-based certification criteria for the domain-specific EHR modules. 7 Thune J, Alexander L, Roberts P, Burr R, Coburn T, Enzi M. Reboot: Re-Examining the Strategies Needed to Successfully Adopt Health IT. White Paper. US Senate. April 13,

8 8 TERMS AND BACKGROUND Certification 8 refers to the confirmation of certain characteristics of an object, person, or organization. Product certification refers to processes (conformity assessments) intended to determine whether a product meets certain requirements (criteria, standards). The International Organization of Standardization (ISO) and International Electrotechnical Commission (IEC) Guide 2 9 defined the three major terms used in the field: conformity - fulfillment of a product, process or service of specified requirements; conformity assessment - any activity concerned with determining directly or indirectly that relevant requirements are fulfilled; and conformity testing - conformity assessment by means of testing. The purpose of conformity assessment is to provide confidence that applicable requirements have been met. Such confidence contributes to the market acceptance of these products, services and systems. Conformity assessment includes sampling and testing, inspection, supplier s declaration of conformity, certification and management system assessment and registration. The conformity assessment is often, but not always, provided by some form of external review, assessment, or audit conducted by a third party, or accreditation of the competence of those activities by a third party and recognition (usually by a government agency) of an accreditation program s capability. 10,11 Certification of software products is closely tied to the conformity assessment, testing, inspection, and accreditation processes as conformation of an ability of a software product to meet certain requirements (criteria, standards) E.Tran. Verification/Validation/Certification. Carnegie Mellon University b Dependable Embedded Systems. Spring URL: process 9 International Organization of Standardization (ISO) and International Electrotechnical Commission (IEC). ISO/IEC Guide 2. Standardization and Related Activities -- General vocabulary URL: 10 Conformity Assessment System: National Conformity Assessment Principles for the U.S. URL: 11 Gray M, Goldfine A, Rosenthal L, Carnahan L. Conformance Testing. National Institute of Standards and Technology. URL: 12 Rosenthal L, Skall M, Carnahan L. Conformance Testing and Certification Framework. WHITE Paper. NIST. April

9 9 Testing is the action of carrying out one or more technical operations (tests) that determine one or more characteristics or performance of a given product, material, equipment, organism, person's qualifications, physical phenomenon, process, or service according to a specified technical procedure (test method). 13 Software testing is used in association with verification and validation: Verification: Have we built the software right (i.e., does the software correctly implement the requirements)? Validation: Have we built the right software (i.e., do the requirements satisfy the customer)? The terms verification and validation are commonly used interchangeably in the industry. They are also defined differently by different organizations. For example, the Institute of Electrical and Electronic Engineers (IEEE) Standard Glossary of Software Engineering Terminology 14 defines them as follows: Verification is the process of evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase. Validation is the process of evaluating a system or component during or at the end of the development process to determine whether it satisfies specified requirements. The International Organization of Standardization (ISO) 9000 standard 15 defines the terms as follows: Verification is confirmation by examination and through provision of objective evidence that specified requirements have been fulfilled. Validation is confirmation by examination and through provision of objective evidence that the requirements for a specific intended use or application have been fulfilled. The National Institute of Standards and Technology (NIST) White Paper on the Conformance Testing and Certification Framework 16 states: 13 US Conformity Assessment System: National Conformity Assessment Principles For the U.S. URL: 14 IEEE Standard Glossary of Software Engineering Terminology. URL: 15 International Organization of Standardization (ISO). Standard URL: 16 Rosenthal L, Skall M, Carnahan L. Conformance Testing and Certification Framework. White Paper National Institute of Standards and Technology (NIST). April

10 10 "Validation as the process of testing implementations for conformance. Conformance involves two major components: (1) a test tool and (2) a testing program. A conformance testing program usually includes: Standard or specification or profile Test tool (e.g., tool, suite, and/or reference implementation) Procedures for testing Organization(s) to do testing, issue certificates of validation, and arbitrate disputes. A Profile is a subset of the overall standard (specification) that includes functionality necessary to satisfy the requirements of a particular community of users, i.e., it specifies the constraints on the standard aimed to the needs of specific constituencies or purposes (use cases). The test cases are developed based on these profiles according to the conformance clauses of the original standard. Testing programs are usually initiated for specifications or standards for critical applications, for interoperability with other applications, and/or for security of the systems. The decision to establish a program is based on a comparison of the risk of nonconformance versus the costs of creating and running a program. Certification is the acknowledgment that a validation process has been completed and that the criteria established by the certifying organization for issuing a certificate has been met. When validation is coupled with certification, successful completion of conformance testing results in the issuance of a certificate (or brand) indicating that the implementation conforms to the appropriate specification or profile. It is important to note that certification cannot exist without validation, but validation can exist without certification. Similarly, validation cannot exist without conformance testing (i.e., a test suite), but conformance testing can be performed without validation." The process of certification conducted by an organization is called accreditation. An Accreditation Body is an entity that oversees the certification process. The Accreditation Body accredits the Notified Bodies, i.e., the third parties that execute the certification process. Third-party certification involves an independent assessment declaring that specified requirements pertaining to a product, person, process or management system have been met -- all this is in order to ensure and assess compliance to the defined requirements, but also to provide an official certification mark or a declaration of conformity. 17 Figures 1 and 2 present components that are used for certifying EHR-S E.Tran. Verification/Validation/Certification. Carnegie Mellon University b Dependable Embedded Systems. Spring URL: process 18 Rosenthal L. EHR-S Conformance Considerations. National Institute of Standards and Technology (NIST). Presentation. April

11 11 Figure 1. Conformance Assessment Components Figure 2. Conformance Testing Components 11

12 12 In the United States, certification policies are regulated by the Code of Federal Regulation (CFR) 15 Part 287, Guidance on Federal Conformity Assessment Activities 19. According to Section 12 of the National Technology Transfer and Advancement Act (NTAA) of , the National Institute of Standards and Technology was appointed to coordinate conformity assessment activities of federal, state and local entities. The goal of this coordination is to eliminate any unnecessary duplication of conformity assessment activities. Certain federal government organizations are responsible for the certification of different products (as specified in their mission statements) and are delegated by Congressional activities via the general national conformity assessment and certification policies. 21 For example, the Food and Drug Administration (FDA) is in charge of the certification of medical devices. The Federal Aviation Administration (FAA) is in charge of the certification of aircraft and specifically, the airborne systems software certification that is based on the RTCA/DO-178B standard. 22 This standard provides information about the software certification process and includes the following sections: software planning process, software development process, software verification process, and the certificate liaison process. The software verification process includes more than testing, since testing that is based on the test cases, in general, cannot show the absence of errors. Therefore, the software verification process is usually a combination of review, analysis, and testing. Reviews and analyses are performed on the following components: Requirements analyses - To detect and report requirements errors that may have surfaced during the software requirements and design process. Software architecture - To detect and report errors that occurred during the development of the software architecture. Source code - To detect and report errors that developed during source coding. Outputs of the integration process - To ensure that the results of the integration process are complete and correct. Test cases and their procedures and results - To ensure that the testing is performed accurately and completely. 23 The two main objectives of the software testing process are to demonstrate that it satisfies all the requirements and to demonstrate that errors leading to unacceptable 19 Code of Federal Regulation (CFR) 15 Part 287. Guidance on Federal Conformity Assessment Activities. URL: 20 Public Law National Technology Transfer and Advancement Act (NTAA). Section URL: 21 Conformity Assessment System: National Conformity Assessment Principles for the U.S. URL: 22 Software Considerations in Airborne Systems and Equipment Certification Requirements. Requirements and Rechnical Concepts for Aviation (RTCA/DO-178B). URL: 23 Rushby J. Formal Methods and Their Role in Certification of Critical Systems. Technical Report CSL March

13 13 failure conditions are removed. The testing process includes the following three different types of testing: Hardware/software integration testing - to verify that the software is operating correctly in the computer environment. Software integration testing - to verify the interrelationships between the software requirements and components, and the implementation of the requirements and components in the software architecture. Low-level testing - to verify the implementation of software low-level requirements. Ideally, we would like to be able to prove beyond any doubt that an implementation is correct, consistent, and complete with respect to its specification. However, this is generally impossible for implementations of nontrivial specifications that are written in a natural language. 24 Testing cannot show the absence of errors because testing often focuses on a certain component/aspect of the system (test case), but not the system at large (Figure 2). In software, the method of inferring properties of the totality of possible behaviors from tests on a selected sample is much less secure. It cannot be assumed that neighboring cases are essentially similar to one another, so there is little justification for extrapolating from tested to untested cases. 25 Testing is, in fact, a "falsification testing, which subjects an implementation to various combinations of legal and illegal inputs, and compares the resulting output to a set of corresponding "expected results." Testing can show presence of errors not their absence, prove non-conformance for aspects of the system, but can never prove total system conformance. 26 In addition, testing is conducted by individuals (testers) with varied skills and knowledge. 27 Thus certification proves that a system has met certain requirements (criteria, standards) set by the certifying agency. The certificate shows that a product has met certain criteria, but it does not mean that the system at large is correct. If certification is based only on testing of a specific standard (or profile) for the validation purpose (Figures 1 and 2), it may be deficient because it does not review and analyze the requirement analysis for the development of the standard and software architecture that defines how a specific standard will be utilized in the application. 24 Gray M, Goldfine A, Rosenthal L, Carnahan L. Conformance Testing. National Institute of Standards and Technology (NIST). URL: 25 Rushby J. Formal Methods and Their Role in Certification of Critical Systems. Technical Report CSL March Rosenthal L. EHR-S Conformance Considerations. National Institute of Standards and Technology (NIST). Presentation. April E.Tran. Verification/Validation/Certification. Carnegie Mellon University b Dependable Embedded Systems. Spring URL: process 13

14 14 US CERTIFICATION PROGRAMS FOR HEALTH INFORMATION TECHNOLOGY Beginning: The Certification Commission for Healthcare Information Technology (CCHIT) 28 was established in 2004 to develop certification criteria for EHR software. It became the first Notified Body to perform certification of health information technology (HIT) products. Its initial funding came from several national trade associations and was then supplemented with substantial federal funding from the Office of the National Coordinator for Health Information Technology (ONC). 29 One of the driving needs behind CCHIT s initial formation was the expressed intent by the Centers for Medicare and Medicaid Services (CMS) to reward the use of EHR systems in its Pay for Performance initiatives. In 2006, CCHIT released its first set of EHR certification criteria designed for medical ambulatory settings, with medical inpatient settings and specialty settings soon to follow. CCHIT clarified the scope and limitations of its first set of the certification criteria as follows: The 2006 Ambulatory EHR Criteria represent basic requirements that the Commission and its Workgroups believe are appropriate for many common ambulatory care settings. CCHIT acknowledges that these Criteria may not be suitable for settings such as behavioral health, emergency departments, or specialty practices and our current certification makes no representation for these. Purchasers should not interpret a lack of CCHIT Certification as being of significance for specialties and domains not yet addressed by CCHIT Criteria. 30 During its operation from 2005 through 2009, CCHIT drew from the HL7 Electronic Health Records System Functional Model (EHR-S FM) 31 in the development of the EHR certification criteria and test scenarios 32. HL7 released a first draft standard of the EHR-S FM for test use in early 2004 and completed and approved the Release 1 (R1) of the standard in Many of the EHR-S FM functions were generic to all settings, e.g., scheduling, progress notes, security, document scanning/imaging, workflow, medication management, decision support and others. For its ambulatory care criteria, CCHIT used those functions within the model that were designated as most essential for primary care medical settings and most easily testable. By 2007, more than 50 software companies had attained CCHIT certification for their products under the current medical ambulatory care standards Certification Commission for Health Information Technology (CCHIT). URL: 29 Office of National Coordinator for Health Information Technology (ONC). URL: 30 CCHIT Certification Handbook - Ambulatory EHR Products - Version April 18, Health Level Seven International (HL7) Electronic Health Records (EHR) Functional Model (FM) Release 1. URL: 32 CCHIT Test Scripts for 2006 Certification of Ambulatory EHRs - Version Preparing for Future Standards by Implementing an Electronic Health Record System Now. Paper Prepared by Mental Health Corporations of America, Inc., Software and Technology Vendors Association (SATVA) and National Council for Community Behavioral Healthcare (National Council) p. 14

15 15 In 2007, CCHIT received federal funding to focus explicitly on select specialty areas. CCHIT selected four specialties from 14 specialty areas that responded to the call for participation. Specialty-EHR criteria were developed as a result of these activities. CCHIT relied heavily on the HL7 EHR-S Functional Profiles developed from the HL7 EHR-S FM R1 for specific domains. For example, the HL7 Pediatric Special Interest Group (SIG) had developed the HL7 Child Health Functional Profile 34 to guide the development of the certification criteria for pediatric EHR systems. The Profile specified the full list of functions and conformance criteria of the EHR-S FM R1 applicable to a full pediatric EHR system. However, this list was too broad to manage in the certification process. Therefore, the CCHIT Pediatric Workgroup developed their certification criteria for the pediatric EHR functions that they viewed to be most essential and most easily testable. These functions had not been directly aligned with the EHR-S FM functions specified in the HL7 Child Health Functional Profile. CCHIT and Standards. CCHIT selected for its criteria only the realistic, testable HL7 EHR-S FM conformance criteria as well as criteria that had been supported by existing standards. For example, CCHIT did not have interoperability certification criteria due to lack of interoperability standards at that time. CCHIT dealt with the lack of standards by developing a roadmap from the HL7 EHR-S FM, so some criteria could be tested today; other criteria could be tested in the future on available standards. This meant that certification of EHR systems was limited to the specific, certifiable components. The impact of CCHIT certification was significant to the EHR industry. Several states included requirements for CCHIT certification in their Request for Proposals (RFPs). The CCHIT certification criteria development process also provided important feedback to improve future releases of the HL7 EHR-S FM. 35 Figure 3 presents the overall approach for certification managed by CCHIT that focused on the functional certification of EHR technology based on the HL7 EHR-S FM R1 standard, specialty (domain)-specific HL7 functional profiles derived from the EHR-S FM, and correspondent domain-specific certification criteria that were not directly aligned (mapped) to the HL7 Functional Profiles. 34 Health Level Seven International (HL7). Pediatric Special Interest Group (SIG). Child Health Functional Profile. Release 1. URL: 35 Preparing for Future Standards by Implementing an Electronic Health Record System Now. Paper Prepared by: Mental Health Corporations of America, Inc., Software and Technology Vendors Association (SATVA) and National Council for Community Behavioral Healthcare (National Council) p. 15

16 16 Figure 3. EHR Technology Certification: CCHIT Approach Continuation: Since 2009, the Office of Standards & Interoperability (S&I) within ONC has official responsibility to oversee certification programs for HIT. 36 The ONC Certification Program has been established to operationalize the certification of HIT for Meaningful Use (MU). 37 The goal of certification is to "provide assurance to purchasers and other users that an EHR system, or other relevant technology, offers the necessary technological capability, functionality and security to help users meet the MU criteria established for a given phase." Eligible providers who seek to qualify for incentive payments under the CMS EHR Incentive Programs 38 are required by statute to use Certified EHR Technology (CEHRT). Once certified, complete EHRs and EHR modules used together would be able to meet the statutory requirement for CEHRT. Thus, CMS incentive programs that were envisioned as a driver for EHR technology certification during the CCHIT era are serving as the driving force under the MU regulations. The standards, implementation specifications, and certification criteria adopted by the Department of Health and Human Services (HHS) Secretary established the minimum requirements that Certified EHR Technology must include to support the achievement of MU Stage 1 or Stage 2 by Eligible Providers (EPs) and Eligible Hospitals (EHs) under the CMS EHR Incentive Programs. 39 In 2010, ONC established a Temporary Certification Program (TCP) in order to ensure the availability and functionality of certified EHR technology to support the first stage of the EHR incentive programs authorized by the Health Information Technology for Economic and Clinical Health (HITECH) Act. 40 The HITECH Act defines a timetable as 36 Office of the National Coordinator for Health IT (ONC). Electronic Health Record (EHR) Certification Program. URL: 37 Office of the National Coordinator for Health IT (ONC). What is Meaningful Use?. URL: 38 Centers for Medicare and Medicaid Services (CMS). EHR Incentive Programs. URL: 39 Office of the National Coordinator for Health IT (ONC). Electronic Health Record (EHR) Certification Program. Standards & Certification Criteria. URL: OR URL: 40 American Recovery and Reinvestment Act of Title XIII. Health Information Technology for Economic and Clinical Health (HITECH) Act. URL 111publ5/html/PLAW-111publ5.htm 16

17 17 well as expectations for how Eligible Providers and Eligible Hospitals must demonstrate the meaningful use of certified HIT. In January 2011, ONC issued the final rule for the Permanent Certification Program (PCP). The Temporary Certification Program was in effect until October 4, 2012, when the processes necessary for the Permanent Certification Program were established. Temporary Certification Program ( ). In the Temporary Certification Program (TCP), ONC managed the ONC-Authorized Testing and Certification Bodies (ONC- ATCBs) -- six organizations (Notified Bodies) which performed the actual testing and certification of EHR and EHR modules. These ONC-ATCBs underwent an open and rigorous application and proficiency testing to demonstrate that they had the necessary capabilities, competencies and capacity to test and certify EHR products at their facility as well as remotely. ONC-Authorized Testing & Certification Bodies included: 1. CCHIT 2. The Drummond Group, Inc. 3. InfoGard Laboratories, Inc. 4. SLI Global Solutions 5. Surescripts LLC 6. ICSA Labs. ONC Permanent HIT Certification Program ( ). The ONC HIT Certification Program includes both certification and testing activities. Testing is performed by Accredited Testing Laboratories (ATLs). If the product meets the testing requirements, certification is conducted by ONC-Authorized Certification Bodies (ONC-ACBs). One organization can serve in both roles, e.g., CCHIT is both ATL and ACB. To become an ONC-ACB, certification bodies apply for accreditation by the ONC- Approved Accreditor (ONC-AA), American National Standards Institute (ANSI), and then seek authorization from ONC. To become an ATL, testing laboratories will apply for accreditation by the National Institute of Standards and Technology. The Permanent Certification Program for EHR Technology Final Rule published in February included several aspects different from the Temporary Certification Program: Single ONC-Approved Accreditor (ONC-AA) ANSI; All certification bodies must apply to ONC for ONC-Authorized Certification Body, ONC-ACB status. ONC-ATCBs authorized under the Temporary 41 Office of National Coordinator for Health Information Technology (ONC). Permanent Certification Program for HER Technology. URL: 17

18 18 Certification Program did not automatically become ONC-ACBs; they have to be accredited by the ONC-AA to be eligible for ONC-ACB status; Organizations can conduct testing or certification activities, or both; Gap certification is available when new and/or revised certification criteria are adopted. To track certified software products, ONC maintains the web-based Certified HIT Products List (CHPL) tool version the authoritative, comprehensive listing of certified complete EHRs and EHR module(s). Each complete EHR and EHR module listed on CHPL has been tested and certified by an authorized testing and certification body against applicable standards and certification criteria adopted by the HHS Secretary. EHR technologies that have been certified under the ONC HIT Certification Program are eligible to be used for the CMS EHR Incentive Program. The CHPL provides CMS EHR Certification ID for qualified products to be used in the CMS EHR Incentive Programs. Eligible Providers and Eligible Hospitals can specify their attestation to use EHR technology that is certified to the 2011 or 2014 Edition Certification Criteria or a combination of 2011 and 2014 Edition Certification Criteria to generate a CMS EHR Certification Identification (ID) for Meaningful Use attestation that is submitted to CMS as part of attesting to Meaningful Use of Certified EHR Technology (Figure 4). Figure 4. Certification Criteria Attestation under Certified HIT Products List Tool An Eligible Provider or Eligible Hospital can request a CMS EHR Certification ID after adding certified complete EHR product(s) or a combination of EHR module(s) to their cart that meets 100% of the requirements for the selected edition of EHR Certification Criteria. Solely adopting certified EHRs does not qualify an EP or EH to receive incentive payments. EPs and EHs must "meaningfully use" the certified EHR and successfully attest to demonstrating MU to qualify for an incentive payment through the EHR Incentive Programs administered by CMS (Figure 5). 42 Office of the National Coordinator for Health IT (ONC). Electronic Health Record (EHR) Certification Program. Certified HIT Products List (CHPL). URL: OR URL: 18

19 19 Figure 5. Certified EHT Technology and Meaningful Use 43 Table 1 presents the numbers of EPs and EHs that received CMS incentive payments for Meaningful Use of Certified EHR Technology. Table 1. Eligible Providers and Hospitals Received CMS Incentive Compensation for the Use of Certified EHR Technology Office of the National Coordinator for Health IT (ONC). Electronic Health Record (EHR) Certification Program. Certification and EHR Incentives. URL: 44 Davidson A. A Glimpse into Stage 3 Meaningful Use. Presentation at the Electronic Health Record (EHR) Group, Centers for Disease Control and Prevention (CDC). June 17,

20 20 Figure 6 presents the overall approach for certification of EHR technology managed by ONC based on the 2011, 2014 and the combination of MU Certification Criteria. Figure 6. EHR Technology Certification: ONC Approach ONC Permanent Certification Program, Standards and Interoperability. In the White Paper entitled "Reboot: Re-Examining the Strategies Needed to Successfully Adopt Health IT", a group of US senators stated that "early reports suggest that federal incentive payments are being made without clear evidence that providers can achieve meaningful use, or the ability to use the health IT program internally, and without an adequate plan to ensure providers can share information with each other." Specifically, the White Paper indicated that the HITECH Act was enacted to facilitate the electronic sharing of data among health care providers. This function, called interoperability, was envisioned to encourage physicians, hospitals, and other healthcare providers across the country to share patient information, such as medical histories or results of diagnostic tests, through a secure network. Supporters view this network as necessary to achieve the potential cost savings and quality improvements promised by health IT. Sharing patient information was supposed to improve care and allow healthcare providers to coordinate by preventing duplicate testing and preventing harmful drug interactions. Ideally, hundreds of thousands of providers, from small family practitioners to very large hospital systems, all need to be using a network and infrastructure that allows for the sharing of information. The network will have to be robust and secure enough to prevent any misuse of sensitive patient information. Such a system somehow has to be developed to work with the hundreds of thousands of IT systems already in place. Moreover, this system must also be flexible enough to accommodate future changes in technology. Additionally, this system must be affordable and simple enough for the wide range of providers to implement. Interoperability is the key to achieving efficiencies in care with health IT; however, interoperability has proven very difficult to establish." Thune J, Alexander L, Roberts P, Burr R, Coburn T, Enzi M. Reboot: Re-Examining the Strategies Needed to Successfully Adopt Health IT. White Paper. US Senate. April 13,

21 21 The MU regulation specified some standards to be used for EHR technology for specific MU objectives, e.g., the 2014 Edition Standards & Certification Criteria (S&CC) Final Rule includes the following statements regarding EHR systems interoperability 46 : 1. In many instances, certification criteria reference single vocabulary and context exchange standards for recording and representing clinical health information for use during electronic health information exchange. 2. Adopted transport standards for the exchange of transitions of care/referral summaries as well as the transmission of patient summaries as part of the view, download, and transmit to a third party certification criterion. 3. The transitions of care certification criterion focused on receipt was revised to include the display of previously adopted summary care record standards: CCD/C32 and CCR, providing a form of backwards compatibility. 4. The test procedure for the transitions of care/referral certification criteria is expected to ascertain EHR technology s ability to engage in standards-based exchange with any other EHR technology that has also implemented the adopted transport standards. 5. Adopted a new certification criterion focused on improving the exchange of laboratory test results between hospitals and ambulatory providers as well as a certification criterion focused on the receipt of laboratory test results which references a common interface standard for ambulatory EHR technology. 6. Adopted certification criteria that improve EHR technology s ability to report information to public health agencies, including reporting cancer case information to cancer registries. These statements present a step forward in comparison with the CCHIT certification program that did not include interoperability due to the lack of standards at that time. The question remains as to whether interoperability could even be clearly defined or supported by these statements. What are those "transport standards" or "a common interface standards" that have to be implemented to support interoperability? What "single vocabulary and context exchange standards" are referenced "for recording and representing clinical health information for use during electronic health information exchange"? Are these three categories of standards sufficient to support interoperability? Are those standards ready to support interoperability? Have EHR vendors implemented these standards in their products to date? With regards to public health, it is questionable as to whether the MU rules Stages 1 and 2 objectives for syndromic surveillance, laboratory and immunization reporting to public health effectively support and promote a standards-based approach to enable interoperability. The MU regulation named one specific standard for public health reporting, i.e., HL7 V2.5.1 in Stage 1 for the three above mentioned domains; and HL7 CDA R2 in Stage 2 for cancer and other public health domains. Is it sufficient to enable interoperability to name one standard in the regulation and thus certify EHR systems against this one standard? The Health Information Technology Standards Panel (HITSP) 47 identified 107 standards needed to support the charge for the 2005 Biosurveillance Use Case: "Transmit 46 ONC Fact Sheet: 2014 Edition Standards & Certification Criteria (S&CC) Final Rule. URL: 21

22 22 essential data from electronically enabled healthcare to authorized public health agencies in real-time." 48 Table 2 provides the number of identified standards by category. Table 2. Biosurveillance Use Case: Number of Standards by Category Standards Categories Number of Standards Data Standards 28 Information Content Standards 17 Information Exchange Standards 46 Identifiers Standards 11 Privacy and Security Standards 5 Functional Standards 0 Total 107 The public comments for the proposed rules for the MU Stage 3 objectives demonstrated that standards for public health reporting in selected domains are not mature or do not exist. Table 3 presents quotations from public comments to ONC and CMS regarding proposed MU Stage 3 objectives. 49 Table 3. Examples of MU Stage 3 Objectives and Their Readiness with Regards to Standards Objective # Domain Objective Statements, Comments 401A (11) Immunization Certification criteria: EHR is able to receive and present a standard set of structured, externally-generated, immunization history and capture the act and date of review within the EP/EH practice. Comments: This objective requires CEHRT and health department readiness Readiness/maturity of bidirectional information exchange capabilities, as well as data and interoperability standards Excessive burden for providers with patients from different states with different immunization requirements 402A (II) E-lab reporting 47 Health Information Technology Standards Panel (HITSP). URL: 48 Information Technology Standards Panel (HITSP). Biosurveillance Interoperability Specification (IS-02). URL: a=1&aprefix=is&prefixnumeric=02 49 Davidson A. A Glimpse into Stage 3 Meaningful Use. Presentation at the Electronic Health Record (EHR) Group, Centers for Disease Control and Prevention, June 17,

23 23 Measure: Successful ongoing submission of electronic reportable laboratory results from Certified EHR Technology to public health agencies for the entire EHR reporting period. Comment: An updated Implementation Guide needs to be developed with strict enforcement of LOINC and SNOMED 404 (II) Cancer Certification criteria: EHR is able to build and then send a standardized report (e.g., standard message format) to an external mandated registry, maintain an audit of those reports, and track total number of reports sent. Comment: Standards to submit data from an EHR to a registry are not yet mature. 404 (IV) Cancer Registry Certification criteria: EHR is able to build and then send a standardized report (e.g., standard message format) to an external mandated registry, maintain an audit of those reports, and track total number of reports sent. Comments: Standardize reporting requirement concerns: Suggestions for a national effort to standardize the formats of state registries In practice this is proving to be difficult because of inconsistent standards. We encourage maintaining tight standards for sending and receiving systems in Stage 3 The certification criteria leave a lot of room for the vendor to generate the files in various formats yet the actual state or federal bodies (mostly state) require very specific formats that are not met by the vendors since the vendors most likely will not develop formats for all states This objective is premature since many receiving registries are not yet ready for the data stream 405 (II) Additional Registries Certification criteria: EHR is able to build and then send a standardized report (e.g., standard message format) to an externally mandated or voluntary registry, maintain an audit of those reports, and track total number of reports sent. Comment: Need a standard format for reporting 401B 113 Immunization-Clinical Decision Support (CDS) Certification criteria: 1. Ability to track CDS triggers, how the provider responded, and the reason for overriding (as appropriate) to improve the effectiveness of CDS interventions 2. Ability for EHRs to consume external CDS interventions (e.g., rules for drug-drug interactions, immunization recommendations and rules, preference-sensitive care lists) Comment: At present there is no standard to represent immunization rules Based on the survey data, 50 the EHR users, all of which indicated a high degree of dissatisfaction with the currently certified EHR systems, had cited numerous cases of software vendors underperforming with unmet requests for sophisticated interfaces with other practice programs, complex connectivity and networking schemes, i.e., system non-interoperability. With 81 percent of responders considering a system switch to another vendor, 80 percent said the solution does not meet the practices' individual 50 McCann E. Black Book says unstable EHR market getting agitated. Government Heath IT. July 23,

24 24 needs; and 77 percent of respondents cited solution design as ill-fitted for their medical practice or specialty. The survey data lead to the following two questions: 1. Do MU criteria used for certification adequately represent the providers needs? 2. Although EHR vendor products may meet the needs of certification, are they also designed to meet providers requirements? Vendors generally respond to the customers needs. Functional requirements that are needed by providers are sometimes overlooked by the attempt to create a "one size fits all" solution. The usability requirements will be what really solidifies the <EHR> market", said Brian Ahier of Advanced Health Information Exchange Resources (AHIER) and a DirectTrust Board member. 51 Integration Profiles that support both practice activities and systems interoperability have been under development by the Integrating the Healthcare Enterprise (IHE) since early 2000 s. 52 Developed by EHR vendors in partnership with the major professional medical associations, these Integration Profiles, however, have the following limitations: They are available for particular aspects (use cases) of care delivery and they do not yet support the whole process of care delivery; Many of them are new and need to mature and stabilize to assure correct support of the users needs; and They have not yet penetrated into the commercial EHR system products. Several chief information officers, congressmen, EHR vendors and industry associations have been calling for a pause or delay in EHR adoption until ,54 These delays will allow standards to mature and to penetrate into EHR products. There are two main lessons learned from certification of EHR technology efforts conducted to date, as follows: 1. Certification has to be based on criteria supported by a suite of standards to assure true interoperability; and 2. Standards need time to mature, stabilize and be adopted by the EHR vendors. The following section attempts to address these lessons further. 51 Sullivan T. The great EHR market shakeout. Government Heath IT.September 03, Integrating the Healthcare Enterprise (IHE). Technical Frameworks. URL: 53 Sullivan T. The great EHR market shakeout. Government Heath IT.September 03, Gelzer RD, Co-Facilitator, HL7 Records Management and Evidentiary Support Workgroup 24

25 25 ACHIEVING INTEROPERABILITY THROUGH CERTIFICATION The ultimate goal of certification of EHR systems is to achieve interoperability that will improve population health. Some industry experts suggest that despite certification efforts conducted to date, certified EHR systems cannot exchange data, i.e., EHR systems are not interoperable. 55,56, The following are two topics related to EHR systems interoperability certification that we attempt to discuss further: I. Why do certified EHR systems fail to meet common data exchange expectations? II. What would it take to assure that certified EHR technology can meet data exchange expectations thus leading to true EHR system adoption? Business-related data exchange requirements and level of readiness of standards that are capable of supporting business-related data exchange requirements must be considered as key aspects of interoperability. If EHR technology certification is aimed at enabling data exchanges, it has to take into account both of these aspects. Business-related data exchange requirements. As described in the Terms section above, the first step in the certification process is defining the certification criteria. There are two major issues that should be taken into account when defining the certification criteria. First, they have to be "meaningful", i.e., represent the business needs; and second, they have to be supported by existing standards. The developers of CCHIT certification attempted to align their certification criteria with the business needs by using HL7 EHR-S FM as a model, which they believed represented healthcare business needs. The CCHIT process for selecting certification criteria was based on the HL7 EHR-S FM. What does the HL7 EHR-S FM represent? The Functional Model is a table of various business activities grouped by certain healthcare business categories and subcategories. Figure 7 presents a graphical view of the model organization for the Release 1.1 standard and Release 2 (May 2013). The total number of functions and their conformance criteria (N) under Release 1.1 was 1,421 and under Release 2 is 2, Thune J, Alexander L, Roberts P, Burr R, Coburn T, Enzi M. Reboot: Re-Examining the Strategies Needed to Successfully Adopt Health IT. White Paper. US Senate. April 13, McCann E. Black Book says unstable EHR market getting agitated. Government Heath IT. July 23,