# Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology > Briefs, arguments, decisions, and more. URL: https://www.frixlaw.com/law-library/documents/fr%3AE9-31216 ## Record - **Collection:** Federal Register - **Document type:** Rule - **Published:** January 13, 2010 - **Citation:** 75 FR 2014 ## Text DEPARTMENT OF HEALTH AND HUMAN SERVICES Office of the Secretary 45 CFR Part 170 RIN 0991-AB58 Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology AGENCY: Office of the National Coordinator for Health Information Technology, Department of Health and Human Services. ACTION: Interim final rule. SUMMARY: The Department of Health and Human Services (HHS) is issuing this interim final rule with a request for comments to adopt an initial set of standards, implementation specifications, and certification criteria, as required by section 3004(b)(1) of the Public Health Service Act. This interim final rule represents the first step in an incremental approach to adopting standards, implementation specifications, and certification criteria to enhance the interoperability, functionality, utility, and security of health information technology and to support its meaningful use. The certification criteria adopted in this initial set establish the capabilities and related standards that certified electronic health record (EHR) technology will need to include in order to, at a minimum, support the achievement of the proposed meaningful use Stage 1 (beginning in 2011) by eligible professionals and eligible hospitals under the Medicare and Medicaid EHR Incentive Programs. DATES: Effective Date: This interim final rule is effective February 12, 2010. The incorporation by reference of certain publications listed in the rule is approved by the Director of the Federal Register as of February 12, 2010. Comment Date: To be assured consideration, written or electronic comments must be received at one of the addresses provided below, no later than 5 p.m. on March 15, 2010. ADDRESSES: Because of staff and resource limitations, we cannot accept comments by facsimile (FAX) transmission. You may submit comments, identified by RIN 0991-AB58, by any of the following methods (please do not submit duplicate comments). • Federal eRulemaking Portal: Follow the instructions for submitting comments. Attachments should be in Microsoft Word, WordPerfect, or Excel; however, we prefer Microsoft Word. http://www.regulations.gov. • Regular, Express, or Overnight Mail: Department of Health and Human Services, Office of the National Coordinator for Health Information Technology, Attention: HITECH Initial Set Interim Final Rule, Hubert H. Humphrey Building, Suite 729D, 200 Independence Ave., SW., Washington, DC 20201. Please submit one original and two copies. • Hand Delivery or Courier: Office of the National Coordinator for Health Information Technology, Attention: HITECH Initial Set Interim Final Rule, Hubert H. Humphrey Building, Suite 729D, 200 Independence Ave., SW., Washington, DC 20201. Please submit one original and two copies. (Because access to the interior of the Hubert H. Humphrey Building is not readily available to persons without federal government identification, commenters are encouraged to leave their comments in the mail drop slots located in the main lobby of the building.) Inspection of Public Comments: All comments received before the close of the comment period will be available for public inspection, including any personally identifiable or confidential business information that is included in a comment. Please do not include anything in your comment submission that you do not wish to share with the general public. Such information includes, but is not limited to: A person's social security number; date of birth; driver's license number; state identification number or foreign country equivalent; passport number; financial account number; credit or debit card number; any personal health information; or any business information that could be considered to be proprietary. We will post all comments received before the close of the comment period at http://www.regulations.gov. Docket: For access to the docket to read background documents or comments received, go to http://www.regulations.gov or U.S. Department of Health and Human Services, Office of the National Coordinator for Health Information Technology, Hubert H. Humphrey Building, Suite 729D, 200 Independence Ave., SW., Washington, DC 20201 (call ahead to the contact listed below to arrange for inspection). FOR FURTHER INFORMATION CONTACT: Steven Posnack, Policy Analyst, 202-690-7151. SUPPLEMENTARY INFORMATION: Acronyms AHIC American Health Information Community ANSI American National Standards Institute ASP Application Service Provider CAH Critical Access Hospital CCD Continuity of Care Document CCHIT Certification Commission for Health Information Technology CCR Continuity of Care Record CDA Clinical Document Architecture CDC Centers for Disease Control and Prevention CFR Code of Federal Regulations CGD Certification Guidance Document CMS Centers for Medicare & Medicaid Services CPOE Computerized Provider Order Entry EHR Electronic Health Record FIPS Federal Information Processing Standards GIPSE Geocoded Interoperable Population Summary Exchange HHS Department of Health and Human Services HIPAA Health Insurance Portability and Accountability Act of 1996 HIT Health Information Technology HITECH Health Information Technology for Economic and Clinical Health HITSP Healthcare Information Technology Standards Panel HL7 Health Level Seven ICD International Classification of Diseases ICD-9-CM ICD, 9th Revision, Clinical Modifications ICD-10-PCS ICD, 10th Revision, Procedure Coding System ICD-10-CM ICD, 10th Revision, Related Health Problems IHS Indian Health Service LOINC Logical Observation Identifiers Names and Codes MA Medicare Advantage NCPDP National Council for Prescription Drug Programs NCVHS National Committee on Vital and Health Statistics NLM National Library of Medicine NQF National Quality Forum OASIS Organization for the Advancement of Structured Information Standards OCR Office for Civil Rights OIG Office of Inspector General OMB Office of Management and Budget ONC Office of the National Coordinator for Health Information Technology PHSA Public Health Service Act PQRI Physician Quality Reporting Initiative REST Representational state transfer RFA Regulatory Flexibility Act SDOs Standards Development Organizations SNOMED CT Systematized Nomenclature of Medicine Clinical Terms SOAP Simple Object Access Protocol UCUM Unified Code for Units of Measure UMLS Unified Medical Language System UNII Unique Ingredient Identifier XML eXtensible Markup Language Table of Contents I. Background A. ONC Background B. Interdependencies With Other HITECH Provisions and Relationship to Other Regulatory Requirements and Related Activities 1. Medicare and Medicaid EHR Incentive Programs Proposed Rule 2. Health Insurance Portability and Accountability Act of 1996 (HIPAA) Privacy Rule Accounting of Disclosures Regulation 3. Previous Recognition of Certification Bodies and New Authority Under the HITECH Act 4. Other HHS Regulatory Actions a. Health Insurance Portability and Accountability Act of 1996 (HIPAA) Transactions and Code Sets Standards b. Electronic Prescribing Standards C. Standards, Implementation Specifications, and Certification Criteria Processes Before and After the HITECH Act 1. ONC's Processes Prior to the HITECH Act 2. HITECH Act Requirements for the Adoption of Standards, Implementation Specifications, and Certification Criteria D. Future Updates to Standards, Implementation Specifications, and Certification Criteria II. Overview of the Interim Final Rule III. Section-By-Section Description of the Interim Final Rule A. Applicability B. Definitions 1. Definition of Standard 2. Definition of Implementation Specification 3. Definition of Certification Criteria 4. Definition of Qualified Electronic Health Record (EHR) 5. Definition of EHR Module 6. Definition of Complete EHR 7. Definition of Certified EHR Technology 8. Definition of Disclosure C. Initial Set of Standards, Implementation Specifications, and Certification Criteria 1. Adopted Certification Criteria 2. Adopted Standards a. Transport Standards b. Content Exchange and Vocabulary Standards i. Patient Summary Record ii. Drug Formulary Check iii. Electronic Prescribing iv. Administrative Transactions v. Quality Reporting vi. Submission of Lab Results to Public Health Agencies vii. Submission to Public Health Agencies for Surveillance or Reporting viii. Submission to Immunization Registries ix. Table 2A c. Privacy and Security Standards 3. Adopted Implementation Specifications 4. Additional Considerations, Clarifications, and Requests for Public Comments a. Relationship to Other Federal Laws b. Human Readable Format c. Certification Criterion and Standard Regarding Accounting of Disclosures d. Additional Requests for Public Comment IV. Collection of Information Requirements V. Regulatory Impact Analysis A. Introduction B. Why Is This Rule Needed? C. Costs and Benefits 1. Costs 2. Benefits D. Regulatory Flexibility Act Analysis E. Executive Order 13132—Federalism F. Unfunded Mandates Reform Act of 1995 Regulation Text I. Background The Health Information Technology for Economic and Clinical Health Act (HITECH Act), Title XIII of Division A and Title IV of Division B of the American Recovery and Reinvestment Act of 2009 (ARRA) (Pub. L. 111-5), was enacted on February 17, 2009. The HITECH Act amended the Public Health Service Act (PHSA) and created “Title XXX—Health Information Technology and Quality” to improve health care quality, safety, and efficiency through the promotion of health information technology (HIT) and the electronic exchange of health information. Section 3004(b)(1) of the PHSA requires the Secretary of the Department of Health and Human Services (the Secretary) to adopt an initial set of standards, implementation specifications, and certification criteria by December 31, 2009 to enhance the interoperability, functionality, utility, and security of health information technology. It also permits the Secretary to adopt this initial set through an interim final rule. The certification criteria adopted in this initial set establish the capabilities and related standards that certified electronic health record (EHR) technology (Certified EHR Technology) will need to include in order to, at a minimum, support the achievement of the proposed meaningful use Stage 1 by eligible professionals and eligible hospitals under the Medicare and Medicaid EHR Incentive Programs. Throughout this interim final rule, we routinely refer to eligible professionals and eligible hospitals. This is done because we have closely aligned the initial set of standards, implementation specifications, and certification criteria adopted by this rule to focus on the capabilities that Certified EHR Technology must be able to provide in order to support the achievement of the proposed criteria for meaningful use Stage 1 by eligible professionals and eligible hospitals under the Medicare and Medicaid EHR Incentive Programs. This initial focus is not meant to limit or preclude health care providers who do not meet the definitions of eligible professional or eligible hospital from obtaining or adopting Certified EHR Technology. To the contrary, Certified EHR Technology will possess the capabilities that can assist any health care provider to improve the quality, safety and efficiency of the care they deliver. We note that ordinarily we publish a notice of proposed rulemaking in the Federal Register and invite public comment on the proposed rule. The notice of proposed rulemaking includes a reference to the legal authority under which the rule is proposed, and the terms and substances of the proposed rule or a description of the subjects and issues involved. As mentioned above, however, section 3004(b)(1) explicitly authorizes the Secretary to issue this rule on an interim final basis. Moreover, section 3004(b)(1) requires the Secretary to adopt an initial set of standards, implementation specifications, and certification criteria by December 31, 2009. We have therefore decided to proceed directly with this interim final rule. Nevertheless, we are providing the public with a 60-day period following publication of this document to submit comments on the interim final rule. The following discussion provides the background information relevant to the Secretary's adoption of an initial set of standards, implementation specifications, and certification criteria. A. ONC Background Executive Order 13335 (69 FR 24059) established the Office of the National Coordinator for Health Information Technology (ONC) on April 24, 2004. In an effort to “provide leadership for the development and nationwide implementation of an interoperable health information technology infrastructure to improve the quality and efficiency of health care,” the President directed the Secretary to create within the Office of the Secretary the position of National Health Information Technology Coordinator (National Coordinator). The National Coordinator was charged with: Serving as the Secretary's principal advisor on the development, application, and use of HIT and directing the HHS HIT programs; ensuring that the HIT policy and programs of HHS were coordinated with those of relevant Executive Branch agencies; to the extent permitted by law, coordinating outreach and consultation by the relevant Executive Branch agencies with public and private parties of interest; and at the request of the Office of Management and Budget (OMB), providing comments and advice regarding specific Federal HIT programs. Additionally, the National Coordinator was required, to the extent permitted by law, to develop, maintain, and direct the implementation of a strategic plan to guide the nationwide implementation of interoperable HIT in both the public and private health care sectors. Included in Executive Order 13335 as a strategic plan objective, was the goal to “advance the development, adoption, and implementation of health care information technology standards nationally through collaboration among public and private interests, and consistent with current efforts to set health information technology standards for use by the Federal Government.” Section 3001 of the PHSA establishes by statute the ONC within HHS and provides the National Coordinator with additional responsibilities and duties beyond those originally identified in Executive Order 13335. Specifically, the National Coordinator is charged with, among other duties: Reviewing and determining whether to endorse each standard, implementation specification, and certification criterion that is recommended by the HIT Standards Committee (a Federal advisory committee to the National Coordinator) and making such determinations and reporting them to the Secretary; reviewing Federal HIT investments to ensure they meet the objectives of the Federal HIT Strategic Plan; coordinating the HIT policy and programs of HHS with those of other relevant Federal agencies; serving as a leading member in the establishment and operations of the HIT Policy Committee and HIT Standards Committee; updating the Federal HIT Strategic Plan in consultation with other appropriate Federal agencies and through collaboration with public and private entities; keeping or recognizing a program or programs to certify EHR technology; conducting studies and reports; and establishing a governance mechanism for the Nationwide Health Information Network (NHIN). B. Interdependencies With Other HITECH Provisions and Relationship to Other Regulatory Requirements and Related Activities The HITECH Act creates multiple interdependencies between this interim final rule and other regulatory requirements, processes, and programs. 1. Medicare and Medicaid EHR Incentive Programs Proposed Rule In writing the provisions of the HITECH Act, Congress fundamentally tied the standards, implementation specifications, and certification criteria adopted in this interim final rule to the incentives available under the Medicare and Medicaid EHR Incentive Programs by requiring the meaningful use of Certified EHR Technology. Congress outlined several goals for meaningful use one of which includes the “use of certified EHR technology in a meaningful manner.” This means that to qualify for incentives, an eligible professional or eligible hospital must both adopt Certified EHR Technology and demonstrate meaningful use of this technology. Congress further specified that Certified EHR Technology must be certified as meeting the standards adopted by the Secretary, which we adopt in this rule. As referenced in the preamble to the Medicare and Medicaid EHR Incentives Program proposed rule the Medicare and/or Medicaid incentive payments are available to certain eligible professionals and eligible hospitals. We have adopted standards, implementation specifications, and certification criteria in this interim final rule in part to assure that Certified EHR Technology is capable of supporting the achievement of meaningful use by eligible professionals and eligible hospitals under the Medicare and Medicaid EHR Incentive Programs. The certification criteria, adopted by the Secretary, must be used to test and certify that Complete EHRs or EHR Modules have properly implemented the capabilities required by the certification criteria and, where appropriate, the standards and implementation specifications adopted by the Secretary. ONC and the Centers for Medicare & Medicaid Services (CMS) have worked carefully to ensure that this interim final rule and the Medicare and Medicaid EHR Incentive Programs proposed rule are aligned. To inform our collaborative rulemaking processes, ONC and CMS received input from hundreds of technical subject matter experts, health care providers, and other stakeholders who provided written comments to, testified before, and attended meetings held by three HHS Federal advisory committees: the National Committee on Vital and Health Statistics, the HIT Policy Committee, and the HIT Standards Committee. After several meetings of its workgroups and the full committee, the HIT Policy Committee presented and recommended to the National Coordinator at its July 16, 2009 meeting a matrix on meaningful use of Certified EHR Technology that contained: Overall health outcome policy priorities; health care goals; draft objectives for eligible professionals and eligible hospitals for 2011 (beginning of meaningful use Stage 1), 2013 (beginning of meaningful use Stage 2), and 2015 (beginning of meaningful use Stage 3); and specific measures for each of those years. With respect to this interim final rule's relationship to the Medicare and Medicaid EHR Incentive Programs proposed rule, we have adopted certification criteria that directly support CMS's proposed meaningful use Stage 1 objectives. The stages of meaningful use are described and have been proposed by CMS in the Medicare and Medicaid EHR Incentive Programs proposed rule as the following: • Stage 1 (beginning in 2011): The proposed Stage 1 meaningful use criteria “focuses on electronically capturing health information in a coded format; using that information to track key clinical conditions and communicating that information for care coordination purposes (whether that information is structured or unstructured, but in structured format whenever feasible); consistent with other provisions of Medicare and Medicaid law, implementing clinical decision support tools to facilitate disease and medication management; and reporting clinical quality measures and public health information.” • Stage 2 (beginning in 2013): CMS has proposed that its goals for the Stage 2 meaningful use criteria, “consistent with other provisions of Medicare and Medicaid law, expand upon the Stage 1 criteria to encourage the use of health IT for continuous quality improvement at the point of care and the exchange of information in the most structured format possible, such as the electronic transmission of orders entered using computerized provider order entry (CPOE) and the electronic transmission of diagnostic test results (such as blood tests, microbiology, urinalysis, pathology tests, radiology, cardiac imaging, nuclear medicine tests, pulmonary function tests and other such data needed to diagnose and treat disease). Additionally we may consider applying the criteria more broadly to both the inpatient and outpatient hospital settings.” • Stage 3 (beginning in 2015): CMS has proposed that its goals for the Stage 3 meaningful use criteria are, “consistent with other provisions of Medicare and Medicaid law, to focus on promoting improvements in quality, safety and efficiency, focusing on decision support for national high priority conditions, patient access to self management tools, access to comprehensive patient data and improving population health.” 2. Health Insurance Portability and Accountability Act of 1996 (HIPAA) Privacy Rule Accounting of Disclosures Regulation Section 13405(c) of the HITECH Act requires the Secretary to promulgate regulations on what information shall be collected about disclosures for treatment, payment, or health care operations made “through an electronic health record” by a HIPAA covered entity. These regulations, which will be issued by the Secretary through the HHS Office for Civil Rights, must be issued not later than 6 months after the date on which the Secretary adopts standards on accounting for disclosures described in the section 3002(b)(2)(B)(iv) of the PHSA. The certification criterion and standard associated with this requirement and included in this interim final rule are discussed in more detail below in section III.C.4.c. 3. Previous Recognition of Certification Bodies and New Authority Under the HITECH Act Among other responsibilities, section 3001(c)(5) of the PHSA expressly requires the National Coordinator, in consultation with the Director of the National Institute of Standards and Technology, to “keep or recognize a program or programs for the voluntary certification of health information technology as being in compliance with applicable certification criteria adopted” by the Secretary under section 3004. HHS's recognition of certain bodies to conduct HIT certification is not new as a result of the HITECH Act. In August 2006, HHS published two final rules in which CMS and the Office of Inspector General (OIG) promulgated an exception to the physician self-referral prohibition and a safe harbor under the anti-kickback statute, respectively, for certain arrangements involving the donation of interoperable EHR software to physicians and other health care practitioners or entities (71 FR 45140 and 71 FR 45110, respectively). The exception and safe harbor provide that EHR software will be “deemed to be interoperable if a certifying body recognized by the Secretary has certified the software no more than 12 months prior to the date it is provided to the [physician/recipient].” ONC published separately a Certification Guidance Document (CGD) (71 FR 44296) to explain the factors ONC would use to determine whether or not to recommend to the Secretary a body for recognized certification body status. The CGD serves as a guide for ONC to evaluate applications for recognized certification body status and provides the information a body would need to apply for and obtain such status. In section VI of the CGD, ONC notified the public and potential applicants that the recognition process would be formalized through notice and comment rulemaking. After reviewing the new responsibilities assumed under the HITECH Act and the additional purpose to which the certification of the HIT is now tied (qualifying for incentive payments) in combination with ONC's current responsibilities under the CGD, we have decided to propose in a separate rulemaking, processes to replace the CGD and establish HIT certification programs as specified by section 3001(c)(5) of the PHSA. We have decided to proceed with a separate notice and comment rulemaking (which we anticipate publishing shortly after this interim final rule) to establish the policies for the certification of HIT and the process a certification body will need to follow to become an authorized certification body, as determined by the National Coordinator. 4. Other HHS Regulatory Actions a. HIPAA Transactions and Code Sets Standards The Secretary has previously adopted and modified transactions and code sets standards for HIPAA covered entities. Many of these same covered entities are now also eligible to qualify for incentive payments under the Medicare and Medicaid EHR Incentives Program. As a result, we want to assure that Certified EHR Technology positions these eligible professionals and eligible hospitals to qualify for incentive payments and comply with these transactions and code set standards. Most recently, in August 2008, HHS proposed through two rules (73 FR 49742 and 73 FR 49796) the updating of electronic transaction standards, new transaction standards, and the adoption of International Classification of Diseases (ICD), 10th Revision, Related Health Problems (ICD-10-CM) and ICD, 10th Revision, Procedure Coding System (ICD-10-PSC) code sets to replace the ICD, 9th Revision, Clinical Modifications (ICD-9-CM) Volumes 1 and 2, and the ICD-9-CM Volume 3 code sets, respectively. After reviewing and considering public comments on these proposals, in January 2009, HHS adopted in final rules published at 74 FR 3296 and 74 FR 3328 certain updated transaction standards, new transaction standards, and code sets. The rules established a timeline for compliance with some of these updated standards and code sets. For example, all HIPAA covered entities are required to comply with ICD-10-CM and ICD-10-PSC on and after October 1, 2013. In adopting an initial set of standards and implementation specifications as specified at section 3004(b)(1) of the PHSA, we have taken into account HIPAA transactions and code sets standards and their associated implementation timetables. We have ensured that our standards and implementation specifications are consistent with the previously adopted HIPAA transactions and code sets standards and with the established implementation timetable. Further, we intend for our future adoption of standards and implementation specifications for meaningful use Stage 2 and Stage 3 to continue to be consistent with the Secretary's adoption and modification of HIPAA transactions and code sets standards and their timeframes for compliance. b. Electronic Prescribing Standards The Medicare Prescription Drug, Improvement and Modernization Act of 2003 (MMA) provided for, among other things, the Voluntary Prescription Drug Benefit Program. Under that program, electronically transmitted prescriptions and certain other information for covered Part D drugs prescribed for Part D eligible individuals must be sent in a manner that complies with applicable standards that are adopted by the Secretary. The Secretary proposed the first of these standards in a February 2005 rulemaking (70 FR 6256). Subsequently, on June 23, 2006 (71 FR 36020), HHS published an interim final rule that maintained the National Council for Prescription Drug Programs (NCPDP) SCRIPT 5.0 as the adopted standard, but allowed for the voluntary use of a subsequent backward compatible version of the standard, NCPDP SCRIPT 8.1. As a result of pilot testing of six “initial standards” that had been identified in 2005, the Secretary issued a notice of proposed rulemaking on November 16, 2007 (72 FR 64900) which proposed adoption of certain standards. The Secretary also used this proposed rule to solicit comments regarding the impact of adopting NCPDP SCRIPT 8.1 and retiring NCPDP SCRIPT 5.0. Based on the comments that were received, the Secretary issued a final rule (73 FR 18918) on April 7, 2008 that adopted NCPDP SCRIPT Version 8.1 and retired NCPDP SCRIPT Version 5.0. In adopting an initial set of standards to meet the requirement specified at section 3004(b)(1) of the PHSA, we have taken into account these electronic prescribing standards and ensured that our standards are consistent with them. C. Standards, Implementation Specifications, and Certification Criteria Processes Before and After the HITECH Act 1. ONC's Processes Prior to the HITECH Act Prior to the enactment of the HITECH Act, ONC's processes consisted of the “acceptance” and “recognition” of HIT standards, implementation specifications, and certification criteria for the electronic exchange of health information and electronic health records. This prior process and its participants are described in further detail below. Chartered in 2005, the American Health Information Community (AHIC), a Federal advisory committee, was charged with making recommendations to the Secretary on how to accelerate the development and adoption of HIT. Until its sunset in November 2008, AHIC advanced to the Secretary several recommendations related to standards, implementation specifications, and certification criteria. To structure those recommendations, AHIC identified “use cases” to prioritize areas in need of harmonized standards and to enable ONC to guide the work of organizations with specific expertise in those priority areas. A use case provided a description of the activity of stakeholders, a sequence of their actions, and technical specifications for systems and technologies involved when the actors engage in responding to or participating in such activity. Created in 2005 by the American National Standards Institute (ANSI) under a contract with HHS, the Healthcare Information Technology Standards Panel (HITSP)—a cooperative partnership of more than 500 public and private sector organizations—began its work to take into account AHIC identified use cases, as directed by ONC. HITSP was established for the purpose of harmonizing and integrating a widely accepted and useful set of standards to enable and support interoperability among healthcare software systems and the organizations and entities that utilize the systems. HITSP also became a primary forum for HIT standards harmonization after the Consolidated Health Informatics (CHI) initiative, which began in October 2001 as a collaborative effort to adopt Federal government-wide interoperability standards to be implemented by Federal agencies, was gradually phased out. The CHI initiative adopted several standards that were fed into and reused as part of HITSP's standards harmonization processes. As a result, over the course of its three-year existence, AHIC sought testimony from HITSP representatives several times on their standards harmonization work in order to inform potential recommendations for the Secretary. In many cases, after a presentation by HITSP, AHIC would make recommendations to the Secretary regarding standards and implementation specifications for recognition. The Secretary would subsequently review those recommendations and determine whether to recognize some or all of the recommended standards and implementation specifications. Executive Order 13410 (71 FR 51089) acknowledged that the Secretary recognizes interoperability standards for use by certain Federal agencies. 1 This Executive Order also directed those Federal agencies, to the extent permitted by law, to require in their contracts and agreements with certain organizations the use, where available, of health information technology systems and products that meet recognized interoperability standards. Executive Order 13410 was issued on August 28, 2006, to, among other goals, ensure that health care programs administered or sponsored by the Federal government promoted quality and efficient delivery of health care through the use of health information technology. On March 1, 2007, January 23, 2008, and January 29, 2009, HHS published notices in the Federal Register (72 FR 9339, 73 FR 3973, 74 FR 3599, respectively) announcing either the Secretary's acceptance or recognition of certain standards and implementation specifications. In an effort to assist with the implementation and adoption challenges associated with recognized standards, the Secretary chose to first “accept” and then formally “recognize” one year after acceptance, specified standards and implementation specifications. This delay provided Federal agencies with additional time to prepare for Executive Order 13410's directive to “utilize, where available, health information technology systems and products that meet recognized interoperability standards” when they implemented, acquired, or upgraded “health information technology systems used for the direct exchange of health information between agencies and with non-Federal entities.” 1 Executive Order 13410 defines “agency” to mean “an agency of the Federal Government that administers or sponsors a Federal health care program.” It also defines “Federal health care program” as including “the Federal Employees Health Benefit Program, the Medicare program, programs operated directly by the Indian Health Service, the TRICARE program for the Department of Defense and other uniformed services, and the health care program operated by the Department of Veterans Affairs.” For purposes of the Executive Order, “Federal health care program” does not include “State operated or funded federally subsidized programs such as Medicaid, the State Children's Health Insurance Program, or services provided to Department of Veterans' Affairs beneficiaries under 38 U.S.C. 1703.” The third participant besides AHIC and HITSP that played a role in ONC's prior processes was the Certification Commission for Health Information Technology (CCHIT). Founded in 2004, CCHIT established the first comprehensive process to test and certify EHR technology. After establishing a certification criteria development process that included diverse stakeholders and a voluntary, consensus-based approach, CCHIT began certifying ambulatory EHR technology in 2006. Since 2006, CCHIT has expanded its certification program to include inpatient EHR technology, emergency department EHR technology, as well as its certification criteria for EHR technology to meet specific needs of certain health care providers/specialists ( e.g., cardiovascular, child health). On May 16, 2006, CCHIT presented its 2006 ambulatory EHR certification criteria to AHIC and after considering the criteria, AHIC recommended that the Secretary recognize CCHIT-identified certification criteria for functionality, interoperability, and security. This recommendation informed the Secretary's decision to recognize the 2006 ambulatory EHR certification criteria for use by recognized certification bodies in conjunction with published final rules for exceptions to the physician self-referral law and safe harbors to the anti-kickback statute for electronic prescribing and EHR software arrangements (71 FR 45140 and 71 FR 45110, respectively). The exception and safe harbor provide that EHR software will be “deemed to be interoperable if a certifying body recognized by the Secretary has certified the software no more than 12 months prior to the date it is provided to the [physician/recipient].” These provisions of the EHR exception and safe harbor anticipated that: (1) HHS would recognize one or more EHR certifying bodies, and (2) HHS would recognize criteria for the certification of EHRs. The Federal Register notice (71 FR 44295) describing the Secretary's recognition of these certification criteria was published on August 4, 2006. Section 3004(b)(2) of the PHSA provides that in adopting an initial set of standards, implementation specifications, and certification criteria in accordance with section 3004(b)(1), the Secretary may adopt those standards, implementation specifications, and certification criteria that went through the process established by ONC before the date of the enactment of the HITECH Act. We believe that in separately requiring the Secretary to adopt an “initial set” of standards, implementation specifications, and certification criteria under section 3004(b)(1) of the PHSA, Congress provided the Secretary with the discretion to adopt standards, implementation specifications, or certification criteria which had not gone through the prior process. As described above, while the prior process included a significant body of work it did not encompass the entirety of the areas Congress requested the Secretary to focus on in the HITECH Act, nor did it envision the policies and capabilities that would be necessary for Certified EHR Technology to meet the proposed definition of meaningful use Stage 1 included in the Medicare and Medicaid EHR Incentive Programs proposed rule. As a result, we have, after considering the input received through the recommendations of the HIT Policy Committee and HIT Standards Committee, adopted an initial set of standards, implementation specifications, and certification criteria to, at a minimum, support the achievement of what is being proposed for meaningful use Stage 1. We have noted in section III of this rule, where applicable, those standards and implementation specifications that were previously accepted or recognized by the Secretary under this prior process and those that were not. Due to our approach of aligning adopted certification criteria with the proposed definition of meaningful use Stage 1, the Secretary has decided not to adopt previously recognized certification criteria developed in 2006 as any of the certification criteria in this interim final rule. 2. HITECH Act Requirements for the Adoption of Standards, Implementation Specifications, and Certification Criteria With the passage of the HITECH Act, two new Federal advisory committees, the HIT Policy Committee and the HIT Standards Committee, were established as specified in the new sections of the PHSA, 3002 and 3003, respectively. Both are responsible for advising the National Coordinator on different aspects of standards, implementation specifications, and certification criteria and consequently they both have the potential to impact how and when standards, implementation specifications, and certification criteria are adopted by the Secretary. The HIT Policy Committee is responsible for, among other duties, recommending priorities for standards, implementation specifications, and certification criteria while the HIT Standards Committee is responsible for recommending standards, implementation specifications, and certification criteria for adoption under section 3004 of the PHSA. Section 3002 of the PHSA directs the HIT Policy Committee to “make policy recommendations to the National Coordinator relating to the implementation of a nationwide health information technology infrastructure.” Section 3002(b) further specifies the type of policy recommendations expected of the HIT Policy Committee by requiring that the committee focus on “specific areas of standards development” and in so doing “recommend the areas in which standards, implementation specifications, and certification criteria are needed for the electronic exchange and use of health information for purposes of adoption under section 3004.” Section 3002(b) also requires the HIT Policy Committee, after determining the areas where standards, implementation specifications, and certification criteria are needed (a process and analysis that are likely to occur on a periodic basis), to “recommend an order of priority for the development, harmonization, and recognition of such standards, specifications, and certification criteria among the areas so recommended.” After receipt of a recommendation related to a priority order, the National Coordinator is expected to review the priorities identified by the HIT Policy Committee and generally will either accept them as submitted, request adjustments, or reject the priority order in whole or in part. Once the National Coordinator accepts a recommendation for the priority order of standards, implementation specifications, and certification criteria, such priorities will be communicated to the HIT Standards Committee to guide its work. The HIT Policy Committee is charged with making recommendations in at least the following eight areas as specified in section 3002(b)(2)(B) of the PHSA: (1) Technologies that protect the privacy of health information and promote security in a qualified electronic health record, including for the segmentation and protection from disclosure of specific and sensitive individually identifiable health information with the goal of minimizing the reluctance of patients to seek care (or disclose information about a condition) because of privacy concerns, in accordance with applicable law, and for the use and disclosure of limited data sets of such information; (2) A nationwide health information technology infrastructure that allows for the electronic use and accurate exchange of health information; (3) The utilization of a certified electronic health record for each person in the United States by 2014; (4) Technologies that as a part of a qualified electronic health record allow for an accounting of disclosures made by a covered entity (as defined for purposes of regulations promulgated under section 264(c) of the Health Insurance Portability and Accountability Act of 1996) for purposes of treatment, payment, and health care operations (as such terms are defined for purposes of such regulations); (5) The use of certified electronic health records to improve the quality of health care, such as by promoting the coordination of health care and improving continuity of health care among health care providers, by reducing medical errors, by improving population health, by reducing health disparities, by reducing chronic disease, and by advancing research and education; (6) Technologies that allow individually identifiable health information to be rendered unusable, unreadable, or indecipherable to unauthorized individuals when such information is transmitted in the nationwide health information network or physically transported outside of the secured, physical perimeter of a health care provider, health plan, or health care clearinghouse; (7) The use of electronic systems to ensure the comprehensive collection of patient demographic data, including, at a minimum, race, ethnicity, primary language, and gender information; and (8) Technologies that address the needs of children and other vulnerable populations. The HIT Policy Committee is also authorized at 3002(b)(2)(C) to consider other areas to make recommendations such as the “appropriate uses of a nationwide health information infrastructure, including [for] * * * collection of quality data and public reporting,” “telemedicine,” and “technologies that help reduce medical errors.” Section 3003 of the PHSA directs the HIT Standards Committee to “recommend to the National Coordinator standards, implementation specifications, and certification criteria for the electronic exchange and use of health information for purposes of adoption under section 3004.” It also established that the HIT Standards Committee must recommend standards, implementation specifications, and certification criteria they have developed, harmonized, or recognized. We note that in section 3003(b)(2), the HIT Standards Committee is also expressly permitted to recognize harmonized or updated standards from other entities and as a result, we expect the HIT Standards Committee to, where appropriate, consider the standards, implementation specifications, and certification criteria from various entities for recommendation to the National Coordinator. We expect that in determining whether to recognize harmonized or updated standards from other entities, the HIT Standards Committee will look to entities such as HITSP and the National Quality Forum (NQF). Additionally, section 3003(a) requires the HIT Standards Committee to focus on and make recommendations to the National Coordinator on the eight areas in section 3002(b)(2)(B) listed above. The HIT Standards Committee is required to update their recommendations and make new recommendations as appropriate, including in response to a notification sent under section 3004(a)(2)(B) of the PHSA. Section 3004 of the PHSA redefines how the Secretary adopts standards, implementation specifications, and certification criteria. • Section 3004(b)(1) of the PHSA requires a one-time action by the Secretary to adopt an initial set of standards, implementation specifications, and certification criteria. This interim final rule has been published to meet the requirements in section 3004(b)(1). • Section 3004(a) of the PHSA defines a process whereby an obligation is imposed on the Secretary to review standards, implementation specifications, and certification criteria and identifies the procedures for the Secretary to follow to determine whether to adopt any grouping of standards, implementation specifications, or certification criteria included within National Coordinator-endorsed recommendations. The specific elements of the process related to section 3004(a) will be described in greater detail below. • Section 3004(b)(3) of the PHSA entitled “subsequent standards activity” states that the “Secretary shall adopt additional standards, implementation specifications, and certification criteria as necessary and consistent” with the schedule published by the HIT Standards Committee. While we intend to consistently seek the insights and recommendations of the HIT Standards Committee, we note that section 3004(b)(3) provides the Secretary with the authority and discretion to adopt standards, implementation specifications, and certification criteria without having first received a National Coordinator-endorsed HIT Standards Committee recommendation. Under section 3004(a) when a recommendation regarding a standard, implementation specification, or certification criterion is made by the HIT Standards Committee to the National Coordinator, a time limited statutory process is triggered. First, after receiving a recommendation from the HIT Standards Committee, the National Coordinator must review and determine whether to endorse the recommendation as well as report such determination to the Secretary. Upon receipt of an “endorsed recommendation,” the Secretary is required to consult with representatives of other relevant Federal agencies to review the standards, implementation specifications, or certification criteria and determine whether to propose their adoption. The Secretary is required to publish all determinations in the Federal Register . If the Secretary determines to propose the adoption of standards, implementation specifications, or certification criteria, the Secretary is permitted to adopt any grouping of standards, implementation specifications, or certification criteria. On the other hand, if the Secretary determines not to propose the adoption of any grouping of standards, implementation specifications, or certification criteria, the Secretary must notify the National Coordinator and the HIT Standards Committee in writing of such determination and the reasons for not proposing their adoption. The HIT Standards Committee issued recommendations to the National Coordinator on August 20, 2009, and updated those recommendations on September 15, 2009. In fulfilling the duties under section 3001(c)(1)(A) and (B), the National Coordinator reviewed the recommendations made by the HIT Standards Committee and issued a determination endorsing several recommendations for the Secretary's consideration. As specified in section 3004(a)(3), this interim final rule also serves as the Secretary's formal publication of the determinations made regarding the National Coordinator-endorsed recommendations. D. Future Updates to Standards, Implementation Specifications, and Certification Criteria The initial set of standards, implementation specifications, and certification criteria adopted in this interim final rule marks the beginning of what we expect to be an iterative approach to enhancing the interoperability, functionality, utility, and security of HIT. A number of factors including maturity, prevalence in the market, and implementation complexity informed our adoption of the standards, implementation specifications, and certification criteria included in this interim final rule. Our approach to the adoption of standards, implementation specifications, and certification criteria is pragmatic, but forward looking. While a high-level of interoperability nationwide will take time and be challenging, we believe that the HITECH Act has generated a significant amount of momentum and interest in meeting the challenges that lie ahead. We recognize that interoperability and standardization can occur at many different levels. For example, one organization may use an information model to describe patient demographic information as (PatientAge, PatientSex, StreetAddress), while another may describe similar demographic information in a different way (DateOfBirth, Gender, City/State). To achieve interoperability at this information level, these information models would need to be harmonized into a consistent representation. In other cases, organizations may use the same information model, but use different vocabularies or code sets (for example, Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT®) or ICD9-CM) within those information models. To achieve interoperability at this level, standardizing vocabularies, or mapping between different vocabularies (using tools like Unified Medical Language System (UMLS)) may be necessary. For some levels, (such as the network transport protocol), an industry standard that is widely used ( e.g. , Transmission Control Protocol (TCP) and the Internet Protocol (IP), (TCP/IP)) will likely be the most appropriate. Ultimately, to achieve semantic interoperability, we anticipate that multiple layers—network transportation protocols, data and services descriptions, information models, and vocabularies and code sets—will need to be standardized and/or harmonized to produce an inclusive, consistent representation of the interoperability requirements. We anticipate using a harmonization process that will integrate different representations of health care information into a consistent representation and maintain and update that consistent representation over time. For an information model, this process could include merging related concepts, adding new concepts, and mapping concepts from one representation of health care information to another. Similar processes to support standardization of data and services descriptions and vocabularies and codes sets may also be needed. We also recognize that a sustainable and incremental approach to the adoption of standards will require processes for harmonizing both current and future standards. This will allow us to incrementally update our initial set of standards, implementation specifications, and certification criteria and provide a framework to maintain them. Our decision to adopt such updates will be informed and guided by recommendations from the HIT Policy Committee, HIT Standards Committee, public comment, industry readiness, and future meaningful use goals and objectives established for the Medicare and Medicaid EHR Incentive Programs. As a result, we expect, unless otherwise necessary, to adopt standards, implementation specifications, and certification criteria synchronously with and to support a transition to the next stage of meaningful use in the Medicare and Medicaid EHR Incentive Programs. In doing so, we also anticipate increasing the level of specificity we provide related to standards, implementation specifications, and certification criteria as well as phasing out certain alternative standards that have been adopted in this initial set. Furthermore, we anticipate that the requirements for meaningful use will become more demanding over time, and consequently that Certified EHR Technology will need to include greater capabilities as well as the ability to exchange electronic health information in a variety of circumstances with many different types of health information technology. Finally, as will be discussed in more detail in the HIT Certification Programs proposed rule, it is possible that the certification programs established by the National Coordinator could certify other types of HIT, perhaps related to certain specialty products and personal health records. In order for that to occur, specific standards, implementation specifications, and certification criteria related to those types of HIT would need to be developed and adopted. II. Overview of the Interim Final Rule We are adding a new part, part 170, to title 45 of the Code of Federal Regulations (CFR) to adopt the initial set of standards, implementation specifications, and certification criteria required by section 3004(b)(1) of the PHSA. We describe the standards, implementation specifications, and certification criteria adopted by the Secretary and the factors that contributed to their adoption. We anticipate that adopted standards, implementation specifications, and certification criteria will be used to prepare Complete EHRs and EHR Modules for testing and certification. In turn, eligible professionals and eligible hospitals that wish to position themselves to achieve the requirements of meaningful use Stage 1, once finalized, could adopt and implement Certified EHR Technology. In drafting this interim final rule, we considered the input of the National Committee on Vital and Health Statistics, the HIT Policy Committee, and the HIT Standards Committee and the public comments received by each committee. We invite public comment on this interim final rule and have posed several questions on topics for which we are interested in receiving specific public comment. III. Section-By-Section Description of the Interim Final Rule A. Applicability—§ 170.101 This part establishes the applicable standards, implementation specifications, and certification criteria that must be used to test and certify HIT. B. Definitions—§ 170.102 1. Definition of Standard The term standard is used in many different contexts and for many different purposes. The HITECH Act did not define or provide a description of the term, standard, or how it should be used in relation to HIT. As a result, we looked to other sources to inform our definition for the term. As specified in the HIPAA Rules, standard is defined at 45 CFR 160.103 to mean “a rule, condition, or requirement: (1) Describing the following information for products, systems, services or practices: (i) Classification of components. (ii) Specification of materials, performance, or operations; or (iii) Delineation of procedures; or (2) With respect to the privacy of individually identifiable health information.” This definition includes important concepts that we believe are applicable and appropriate for this interim final rule and we have included these concepts in our definition of standard. Other definitions or descriptions of the term standard include “an established policy on a particular practice or method;” “a set of instructions for performing operations or functions;” or “a published statement on a topic specifying the characteristics, usually measurable, that must be satisfied or achieved to comply with the standard.” 2 2 This last definition is referenced in Federal Information Processing Standards 201. We believe the types of standards envisioned by Congress in the HITECH Act that would be most applicable to HIT are standards that are technical, functional, or performance-based. For example, a technical standard could specify that the structure of a message containing a patient's blood test results must include a header, the type of test performed, and the results, and further, that message must always be put in that sequence and be 128 bits long; a functional standard could specify certain actions that must be consistently accomplished by HIT such as recording the date and time when an electronic prescription is transmitted; and a performance standard could specify certain operational requirements for HIT such as being able to properly identify a drug-allergy contraindication 99.99% of the time for patient safety purposes. With this in mind, we have chosen to define standard to mean: a technical, functional, or performance-based rule, condition, requirement, or specification that stipulates instructions, fields, codes, data, materials, characteristics, or actions. 2. Definition of Implementation Specification The term implementation specification is defined at 45 CFR 160.103 of the HIPAA Rules as “specific requirements or instructions for implementing a standard.” We believe that this definition conveys accurately the meaning of the term as used in the HITECH Act, which seeks consistency between these implementation specifications and those adopted under HIPAA. Moreover, the concept it applies complements the definition of standard adopted in this interim final rule. Additionally, this definition is straightforward, easy to understand, and is otherwise consistent with our goals. We have therefore adopted the HIPAA regulatory definition of implementation specification without modification. 3. Definition of Certification Criteria The term certification criteria is described at section 3001(c)(5)(B) of the PHSA to mean “with respect to standards and implementation specifications for health information technology, criteria to establish that the technology meets such standards and implementation specifications.” We have incorporated this description into our definition of certification criteria described below and expanded it to also address how the term is used in various parts of the HITECH Act. The definition consequently encompasses more than just certification criteria that establish technology meets “standards and implementation specifications.” In support of meaningful use, for instance, there are many other capabilities Certified EHR Technology will need to provide under the HITECH Act even though such capabilities do not require a particular standard or implementation specification. As a result, we believe that it is critical for these capabilities to be tested and certified too. To do otherwise would potentially make it difficult for eligible professionals and eligible hospitals to know whether the Certified EHR Technology they have adopted and implemented will support their achievement of meaningful use. For example, if we did not require a certification criterion for medication reconciliation, a proposed meaningful use Stage 1 objective, Certified EHR Technology under this scenario would not provide any assurance to an eligible professional or eligible hospital that the proposed meaningful use Stage 1 requirement could be met. On the other hand, by adopting a certification criterion for medication reconciliation in this interim final rule, eligible professionals and eligible hospitals can be assured that once they adopt and implement Certified EHR Technology, it includes, at a minimum, the medication reconciliation capabilities required to support their achievement of the proposed meaningful use Stage 1 requirement. For these reasons we have defined the term certification criteria to encompass both the statutory description and the statutory use of the term. The definition consequently also includes other certification criteria that are not directly tied to establishing that health information technology has met a standard or implementation specification. We have therefore defined certification criteria to mean: criteria: (1) To establish that health information technology meets applicable standards and implementation specifications adopted by the Secretary; or (2) that are used to test and certify that health information technology includes required capabilities. 4. Definition of Qualified Electronic Health Record (EHR) Qualified EHR is defined at section 3000(13) of the PHSA as “an electronic record of health-related information on an individual that: (A) Includes patient demographic and clinical health information, such as medical history and problem lists; and (B) has the capacity: (i) To provide clinical decision support; (ii) to support physician order entry; (iii) to capture and query information relevant to health care quality; and (iv) to exchange electronic health information with, and integrate such information from other sources.” We have adopted the statutory definition of Qualified EHR without modification. 5. Definition of EHR Module We have defined the term EHR Module to mean any service, component, or combination thereof that can meet the requirements of at least one certification criterion adopted by the Secretary. Examples of EHR Modules include, but are not limited to, the following: • An interface or other software program that provides the capability to exchange electronic health information; • An open source software program that enables individuals online access to certain health information maintained by EHR technology; • A clinical decision support rules engine; • A software program used to submit public health information to public health authorities; and • A quality measure reporting service or software program. While the use of EHR Modules may enable an eligible professional or eligible hospital to create a combination of products and services that, taken together, meets the definition of Certified EHR Technology, this approach carries with it a responsibility on the part of the eligible professional or eligible hospital to perform additional diligence to ensure that the certified EHR Modules selected are capable of working together to support the achievement of meaningful use. In other words, two certified EHR Modules may provide the additional capabilities necessary to meet the definition of Certified EHR Technology, but may not integrate well with each other or with the other EHR technology they were added to. As a result, eligible professionals and eligible hospitals that elect to adopt and implement certified EHR Modules should take care to ensure that the certified EHR Modules they select are interoperable and can properly perform in their expected operational environment. 6. Definition of Complete EHR The term Complete EHR is used to mean EHR technology that has been developed to meet all applicable certification criteria adopted by the Secretary. We believe this definition helps to create a clear distinction between a Complete EHR, an EHR Module, and Certified EHR Technology. The term Complete EHR is not meant to limit the capabilities that a Complete EHR can include. Rather, it is meant to encompass EHR technology that can perform all of the applicable capabilities required by certification criteria adopted by the Secretary and distinguish it from EHR technology that cannot perform those capabilities. We fully expect some Complete EHRs to have capabilities beyond those addressed by certification criteria adopted by the Secretary. 7. Definition of Certified EHR Technology Certified EHR Technology is defined at section 3000(1) of the PHSA as “a qualified electronic health record that is certified pursuant to section 3001(c)(5) as meeting standards adopted under section 3004 that are applicable to the type of record involved.” In this interim final rule, we have slightly revised the definition of Certified EHR Technology to make it more consistent with the initial standards, implementation specifications, and certification criteria that are being adopted. Certification criteria focus on the capabilities of Complete EHRs or EHR Modules and consequently, Certified EHR Technology should be defined in accordance with that approach. We believe defining Certified EHR Technology in that manner will provide greater clarity and meaning for this interim final rule. We have defined Certified EHR Technology to mean: A Complete EHR or a combination of EHR Modules, each of which: (1) Meets the requirements included in the definition of a Qualified EHR; and (2) has been tested and certified in accordance with the certification program established by the National Coordinator as having met all applicable certification criteria adopted by the Secretary. To clarify the meaning of “applicable certification criteria” in this definition's second part, we note that Congress indicated their expectation that different types of HIT would be certified. Congress elaborated on this expectation with a parenthetical in the statutory definition, which references two examples, “an ambulatory electronic health record for office-based physicians” and “an inpatient hospital electronic health record for hospitals.” For a variety of reasons, including that certain proposed meaningful use Stage 1 objectives only apply to an eligible professional or eligible hospital and that these two types of health care providers require different capabilities from Certified EHR Technology, we have adopted specific certification criteria that are only “applicable” to Complete EHRs or EHR Modules designed for use in an ambulatory setting ( e.g. , by eligible professionals) or an inpatient setting ( e.g. , by eligible hospitals). We indicate in Table 1, and in the regulation text below, which certification criteria apply solely to Complete EHRs or EHR Modules designed for use in an ambulatory setting or an inpatient setting. For example, we do not expect Certified EHR Technology that is adopted and implemented by an eligible professional to include the capability to create an electronic copy of discharge instructions. We do, however, expect Certified EHR Technology that is adopted and implemented by an eligible hospital to include this capability. We believe that by adding the word “technology” after “EHR,” Congress intended to convey an expectation that rather than adopt a complete, all-in-one solution, eligible professionals and eligible hospitals would likely adopt and implement some number of technological components or EHR Modules to extend the useful life of their legacy EHR technology or other HIT that may not provide all of the capabilities necessary to achieve meaningful use. In the early stages of the Medicare and Medicaid EHR Incentive Programs, we expect most eligible professionals and many eligible hospitals to opt for a Complete EHR that has met the definition of Certified EHR Technology. However, with the future in mind, and to address those eligible providers and eligible hospitals that may decide to implement their own Complete EHRs or EHR Modules, we have adopted a definition of Certified EHR Technology that we believe is flexible enough to account for innovations in an industry that continues to rapidly evolve. Additionally, we believe this definition of Certified EHR Technology will lead to a more competitive marketplace and allow those who adopt HIT to choose from a variety of offerings ranging from subscription services, to vendor-based products, to open source products. An innovative and competitive HIT marketplace needs to exist much like the marketplace for consumer electronics, where, for the purpose of setting up a home theater, a television, DVD player, and stereo system can be purchased from three different manufacturers, from a single manufacturer, or as a complete system from one manufacturer. To that end, we believe that it will be common in the near future for Certified EHR Technology to be assembled from several replaceable and swappable EHR Modules. For example, an EHR Module specifically designed to enable electronic health information exchange may be implemented for the purposes of interoperability and participation in a health information organization, regional health information organization, or some other consortium whose purpose is to enable the electronic exchange of health information. As another example, a subscription to an application service provider (ASP) for electronic prescribing could be an EHR Module and used to help meet the definition of Certified EHR Technology provided that the electronic prescribing capability the ASP enables has been tested and certified. As long as each EHR Module has been separately tested and certified in accordance with the certification program established by the National Coordinator (which will be discussed in a future rulemaking) to all of the applicable certification criteria adopted by the Secretary, a proper combination of certified EHR Modules could meet the definition of Certified EHR Technology. To clarify, we are not requiring the certification of combinations of certified EHR Modules, just that the individual EHR Modules combined have each been certified to all applicable certification criteria in order for such a “combination” to meet the definition of Certified EHR Technology. The following are examples of Certified EHR Technology: • A complete EHR that is tested and certified to all applicable certification criteria. • The combination of three certified EHR modules that include all of the capabilities required by all applicable certification criteria. (We note that in this circumstance it is the user's responsibility to determine whether the combination of these three certified EHR Modules would meet all of the applicable certification criteria necessary to meet the definition of Certified EHR Technology.) The following are examples of what would not meet the definition of Certified EHR Technology: • Complete EHRs that have not been tested and certified in accordance with the certification program established by the National Coordinator even though it may be claimed that such technology provides the same capabilities as those required by adopted certification criteria. • The combination of three certified EHR modules that do not include all of the capabilities required by all applicable certification criteria. That is, if these three certified EHR modules were purchased by an eligible professional and none of them included the capability to electronically prescribe, the combination of these three modules would not be a proper combination of certified EHR Modules and would not meet the definition of Certified EHR Technology. It is important to note that the capabilities included in the definition of Qualified EHR set the floor for the capabilities that Certified EHR Technology must include. For example, the definition of Qualified EHR does not require capabilities related to privacy and security; however, the Secretary has adopted certification criteria for privacy and security. Therefore, where the Secretary has adopted certification criteria that require capabilities beyond those specified in the definition of a Qualified EHR, a Complete EHR or EHR Module will need to be tested and certified to those adopted certification criteria in order for the definition of Certified EHR Technology to be met. 8. Definition of Disclosure We define disclosure in this interim final rule to have the same meaning specified at 45 CFR 160.103—“the release, transfer, provision of access to, or divulging in any other manner of information outside the entity holding the information.” As previously mentioned, once the Secretary adopts a standard on accounting for disclosures described in section 3002(b)(2)(B)(iv) of the PHSA, the Secretary through the HHS Office for Civil Rights, is required to modify (no later than 6 months after the date on which the Secretary adopts standards on accounting for disclosures) the HIPAA Privacy Rule at 45 CFR 164.528 to require that HIPAA covered entities account for disclosures related to treatment, payment, and health care operations made through an electronic health record and to identify in the regulations the information that shall be collected about each of the disclosures. C. Initial Set of Standards, Implementation Specifications, and Certification Criteria §§ 170.202, 170.205, 170.210, 170.302, 170.304, 170.306 The sections below describe the initial set of standards, implementation specifications, and certification criteria adopted by the Secretary to support, in part, the achievement of meaningful use Stage 1 (which begins in 2011). The standards, implementation specifications, and certification criteria adopted are meant to serve as the basis for the testing and certification of Complete EHRs and EHR Modules and they should in no way be misconstrued as additional detailed requirements for meaningful use Stage 1 itself. In order to prevent confusion, we believe it is necessary to make clear that the standards, implementation specifications, and certification criteria adopted by the Secretary in this interim final rule apply to, and establish the required capabilities for, Certified EHR Technology. These criteria do not establish requirements for health care providers, such as eligible professionals or eligible hospitals to follow. Because certification criteria describe both the required capabilities Certified EHR Technology must include and, where applicable, the standard(s) that must be used by those capabilities, we discuss adopted certification criteria first. Table 1 below displays the certification criteria we have adopted. Next we discuss adopted standards and the purposes for their use. Tables 2A and 2B include the standards referenced by adopted certification criteria for a particular exchange or privacy or security purpose. Lastly we discuss our approach to implementation specifications. To guide our approach to adopting the standards, implementation specifications, and certification criteria below, we established the following goals: • Promote interoperability and where necessary be specific about certain content exchange and vocabulary standards to establish a path forward toward semantic interoperability; • Support the evolution and timely maintenance of adopted standards; • Promote technical innovation using adopted standards; • Encourage participation and adoption by all vendors, including small businesses; • Keep implementation costs as low as reasonably possible; • Consider best practices, experiences, policies, frameworks, and the input of the HIT Policy Committee and HIT Standards Committee in current and future standards; • Enable mechanisms such as the NHIN to serve as a test-bed for innovation and as an open-source reference implementation of best practices; and • To the extent possible, adopt standards that are modular and not interdependent. For example, an adopted vocabulary standard would not be tied to a particular content exchange standard ( e.g., the adoption of Current Procedural Terminology (CPT®) Fourth Edition (CPT-4) codes would not require or preclude the use of a particular patient summary record standard such as the continuity of care document (CCD) or continuity of care record (CCR)). 1. Adopted Certification Criteria At its July 16, 2009 and August 14, 2009 meetings, the HIT Policy Committee made recommendations to the National Coordinator on policies for meaningful use and the certification of HIT, which the National Coordinator has considered. For the purposes of this interim final rule and the adoption of an initial set of certification criteria, we believe that the meaningful use matrix recommended by the HIT Policy Committee as modified in the Medicare and Medicaid EHR Incentive Programs proposed rule provides a logical way to structure our presentation of adopted certification criteria. Furthermore, we found the following recommendations on certification from the HIT Policy Committee to be particularly informative for the scope of this interim final rule and our approach to adopting certification criteria—that certification should focus on meaningful use and be leveraged to improve security, privacy, and interoperability. We agree that for this initial set of certification criteria, supporting the achievement of meaningful use Stage 1, as proposed in the Medicare and Medicaid EHR Incentive Programs proposed rule, is a foremost priority. As a result, we have adopted, based in part on the HIT Policy Committee's recommendation, an initial set of certification criteria to support the achievement by eligible professionals and eligible hospitals of meaningful use Stage 1, as proposed in the Medicare and Medicaid EHR Incentive Programs proposed rule. The meaningful use matrix recommended by the HIT Policy Committee, a revised form of which CMS has included in the Medicare and Medicaid EHR Incentive Programs proposed rule, includes overall health outcome policy priorities and health care goals that are the same for eligible professionals and eligible hospitals. The health outcome policy priorities identified in the Medicare and Medicaid EHR Incentive Programs proposed rule are: “Improving quality, safety, efficiency, and reducing health disparities; engage patients and families in their health care; improve care coordination; improve population and public health; and ensure adequate privacy and security protections for personal health information.” For each policy priority, there are also associated health care goals which are described in more detail in the Medicare and Medicaid EHR Incentive Programs proposed rule. The health care goals served as the bases for the proposed specific meaningful use Stage 1 objectives for eligible professionals and eligible hospitals set forth in the Medicare and Medicaid EHR Incentive Programs proposed rule. We have consequently used the proposed objectives in the Medicare and Medicaid EHR Incentive Programs proposed rule to identify the initial set of certification criteria adopted in this interim final rule and have linked the certification criteria to these objectives. Many of the proposed meaningful use Stage 1 objectives are exactly the same for eligible professionals and eligible hospitals. Where proposed meaningful use Stage 1 objectives were identical for eligible professionals and eligible hospitals, we adopted identical certification criteria for Complete EHRs or EHR Modules. However, there are instances where proposed meaningful use Stage 1 objective and corresponding meaningful use measure are specifically aimed at an eligible professional ( e.g., electronic prescribing) or eligible hospital ( e.g., provision of an electronic copy of discharge instructions). Where the proposed meaningful use Stage 1 objectives were worded differently or only applied to an eligible professional or eligible hospital, we have adopted specific certification criteria to assure that Certified EHR Technology includes the capabilities necessary to meet that objective. Additionally, CMS describes in the Medicare and Medicaid EHR Incentive Programs proposed rule a number of the terms referenced in this table, specifically those in the first column which align directly with the proposed meaningful use Stage 1 objectives. For example, one of the proposed meaningful use Stage 1 objectives is to “perform medication reconciliation at relevant encounters and each transition of care.” We have adopted a certification criterion to assure that a Complete EHR or EHR Module is capable of performing medication reconciliation. However, it is not within the scope of this interim final rule to specify when or how often this needs to occur. Rather, the proposed meaningful use Stage 1 measure for this proposed objective dictates the frequency, and the preamble of the Medicare and Medicaid EHR Incentive Programs proposed rule provides descriptions for what is meant by “relevant encounters” and “each transition of care.” We encourage any reader seeking the meaning or further explanation of a particular term in the objectives to review the Medicare and Medicaid EHR Incentive Programs proposed rule. To improve the readability of Table 1 and illustrate the linkage between adopted certification criteria and proposed meaningful use Stage 1 objectives, in instances where the proposed meaningful use Stage 1 objective was the same in concept for eligible professionals and eligible hospitals but differed slightly with respect to wording, we provided a combined objective and referenced the full proposed objective in a footnote. All certification criteria are prefaced with the statement “A Complete EHR or EHR Module must include the capability to:” in order to create uniformity in the way each certification criterion is read. Finally, we understand that certain types of standards, specifically code sets, must be maintained and frequently updated to serve their intended purpose effectively. Code sets are typically used for encoding data elements, such as medical terms, medical concepts, diagnoses, and medical procedures. As new medical procedures, technologies, treatments, or diagnostic methods are developed or discovered, additional codes must be added or existing codes must be revised. In some cases, new codes are necessary to reflect the most recent changes in medical practice, involving perhaps revised medication dosage, updated treatment procedures, or the discovery of new diseases. In many cases, the new codes must be disseminated and implemented quickly for patient safety and significant public health purposes. To address this need and accommodate industry practice, we have in this interim final rule indicated that certain types of standards will be considered a floor for certification. We have implemented this approach by preceding references to specific adopted standards with the phrase, “at a minimum.” In those instances, the certification criterion requires compliance with the version of the code set that has been adopted through incorporation by reference, or any subsequently released version of the code set. This approach will permit Complete EHRs and EHR Modules to be tested and certified, to, “at a minimum,” the version of the standard that has been adopted or a more current or subsequently released version. This will also enable Certified EHR Technology to be updated from an older, “minimum,” adopted version of a code set to a more current version without adversely affecting Certified EHR Technology's “certified status.” We intend to elaborate in the upcoming HIT Certification Programs proposed rule on how testing and certification would be conducted using standards we have adopted and designated as “minimums” in certain certification criteria. Because we expect to adopt additional code set standards in the future, we believe this approach is necessary. Moreover, we believe the certification of Complete EHRs and EHR Modules should be flexible enough to accommodate current code sets that are regularly maintained and updated. We also believe that this approach will enable and encourage eligible professionals and eligible hospitals to adopt Certified EHR Technology and keep it current, which will promote patient safety, public health safety, and more broadly, improve health care quality. That being said, we understand that this approach has certain limitations. In some cases, for instance, rather than simply maintaining, correcting, or slightly revising a code set, a code set maintaining organization will modify the structure or framework of a code set to meet developing industry needs. We would consider this type of significant revision to a code set to be a “modification,” rather than maintenance or a minor update of the code set. An example of a code set “modification” would be if a hypothetical XYZ code set version 1 were to use 7-digit numeric codes to represent health information while XYZ code set version 2 used 9-digit alphanumeric codes to represent health information. In such cases, interoperability would likely be reduced among Complete EHRs and EHR Modules that have adopted different versions of the structurally divergent code sets. If a code set that we have adopted through incorporation by reference is modified significantly, we will update the incorporation by reference of the adopted version with the more recent version of the code set prior to requiring or permitting certification according to the newer version. The following provides an example of how our approach will work. A proposed meaningful use Stage 1 objective specifies the capability to submit electronic data to immunization registries and, accordingly, we have adopted a certification criterion to assure that a Complete EHR or EHR Module is capable of electronically recording, retrieving, and transmitting immunization information to immunization registries in accordance with the standards specified in Table 2A row 8. Table 2A row 8 references, as a vocabulary standard (code set), the CDC maintained HL7 standard code set CVX-Vaccines Administered. The current version of the CVX code set was published July 30, 2009, and includes new vaccine codes related to the “Novel Influenza-H1N1.” Continuing our CVX example, if the CDC were to publish a new version of CVX on February 1, 2010, we would permit a Complete EHR or EHR Module to be tested and certified according to the minimum adopted version of the standard, the July 30, 2009, version of CVX or the February 1, 2010 version that was subsequently issued as part of the code set's maintenance. For certain certification criteria in Table 1 below, we include a percent symbol “%” superscript to indicate instances where the version of an adopted standard (specified in the regulation text) will be “at a minimum” the version to which a Complete EHR or EHR Module must be tested and certified in order to be considered compliant with the adopted standard. Table 1—Certification Criteria Proposed meaningful use Stage 1 objectives Certification criteria to support the achievement of meaningful use Stage 1 by eligible professionals Certification criteria to support the achievement of meaningful use Stage 1 by eligible hospital A Complete EHR or EHR Module must include the capability to: Use Computerized Provider Order Entry (CPOE) 3 Enable a user to electronically record, store, retrieve, and manage, at a minimum, the following order types: Enable a user to electronically record, store, retrieve, and manage, at a minimum, the following order types: 1. Medications; 1. Medications; 2. Laboratory; 2. Laboratory; 3. Radiology/imaging; and 3. Radiology/imaging; 4. Provider referrals. 4. Blood bank; 5. Physical therapy; 6. Occupational therapy; 7. Respiratory therapy; 8. Rehabilitation therapy; 9. Dialysis; 10. Provider consults; and 11. Discharge and transfer. Implement drug-drug, drug-allergy, drug-formulary checks 1. Automatically and electronically generate and indicate ( e.g., pop-up message or sound) in real-time, alerts at the point of care for drug-drug and drug-allergy contraindications based on medication list, medication allergy list, age, and CPOE. 2. Enable a user to electronically check if drugs are in a formulary or preferred drug list in accordance with the standard specified in Table 2A row 2. 3. Provide certain users with administrator rights to deactivate, modify, and add rules for drug-drug and drug-allergy checking. 4. Automatically and electronically track, record, and generate reports on the number of alerts responded to by a user. Maintain an up-to-date problem list of current and active diagnoses based on ICD-9-CM or SNOMED CT® Enable a user to electronically record, modify, and retrieve a patient's problem list for longitudinal care ( i.e., over multiple office visits) in accordance with the applicable standards % specified in Table 2A row 1. Generate and transmit permissible prescriptions electronically (eRx) Enable a user to electronically transmit medication orders (prescriptions) for patients in accordance with the standards specified in Table 2A row 3. No Associated Proposed Meaningful Use Stage 1 Objective. Maintain active medication list Enable a user to electronically record, modify, and retrieve a patient's active medication list as well as medication history for longitudinal care ( i.e., over multiple office visits) in accordance with the applicable standard specified in Table 2A row 1. Maintain active medication allergy list Enable a user to electronically record, modify, and retrieve a patient's active medication allergy list as well as medication allergy history for longitudinal care ( i.e., over multiple office visits). Record demographics 4 5 Enable a user to electronically record, modify, and retrieve patient demographic data including preferred language, insurance type, gender, race, ethnicity, and date of birth. Enable a user to electronically record, modify, and retrieve patient demographic data including preferred language, insurance type, gender, race, ethnicity, date of birth, and date and cause of death in the event of mortality. Record and chart changes in vital signs: • Height • Weight • Blood pressure • Calculate and display: BMI • Plot and display growth charts for children 2-20 years, including BMI 1. Enable a user to electronically record, modify, and retrieve a patient's vital signs including, at a minimum, the height, weight, blood pressure, temperature, and pulse. 2. Automatically calculate and display body mass index (BMI) based on a patient's height and weight. 3. Plot and electronically display, upon request, growth charts (height, weight, and BMI) for patients 2-20 years old. Record smoking status for patients 13 years old or older Enable a user to electronically record, modify, and retrieve the smoking status of a patient to: current smoker, former smoker, or never smoked. Incorporate clinical lab-test results into EHR as structured data 1. Electronically receive clinical laboratory test results in a structured format and display such results in human readable format. 2. Electronically display in human readable format any clinical laboratory tests that have been received with LOINC® codes. 3. Electronically display all the information for a test report specified at 42 CFR 493.1291(c)(1) through (7). 6 4. Enable a user to electronically update a patient's record based upon received laboratory test results. Generate lists of patients by specific conditions to use for quality improvement, reduction of disparities, and outreach Enable a user to electronically select, sort, retrieve, and output a list of patients and patients' clinical information, based on user-defined demographic data, medication list, and specific conditions. Report quality measures to CMS or the States 7 8 1. Calculate and electronically display quality measure results as specified by CMS or states. 2. Enable a user to electronically submit calculated quality measures in accordance with the standard specified in Table 2A row 5. Send reminders to patients per patient preference for preventive/follow up care Electronically generate, upon request, a patient reminder list for preventive or follow-up care according to patient preferences based on demographic data, specific conditions, and/or medication list. No Associated Proposed Meaningful Use Stage 1 Objective. Implement 5 clinical decision support rules 9 10 1. Implement automated, electronic clinical decision support rules (in addition to drug-drug and drug-allergy contraindication checking) according to specialty or clinical priorities that use demographic data, specific patient diagnoses, conditions, diagnostic test results and/or patient medication list. 1. Implement automated, electronic clinical decision support rules (in addition to drug-drug and drug-allergy contraindication checking) according to a high priority hospital condition that use demographic data, specific patient diagnoses, conditions, diagnostic test results and/or patient medication list. 2. Automatically and electronically generate and indicate ( e.g., pop-up message or sound) in real-time, alerts and care suggestions based upon clinical decision support rules and evidence grade. 2. Automatically and electronically generate and indicate ( e.g., pop-up message or sound) in real-time, alerts and care suggestions based upon clinical decision support rules and evidence grade. 3. Automatically and electronically track, record, and generate reports on the number of alerts responded to by a user. 3. Automatically and electronically track, record, and generate reports on the number of alerts responded to by a user. Check insurance eligibility electronically from public and private payers Enable a user to electronically record and display patients' insurance eligibility, and submit insurance eligibility queries to public or private payers and receive an eligibility response in accordance with the applicable standards specified in Table 2A row 4. Submit claims electronically to public and private payers Enable a user to electronically submit claims to public or private payers in accordance with the applicable standards specified in Table 2A row 4. Provide patients with an electronic copy of their health information upon request 11 12 Enable a user to create an electronic copy of a patient's clinical information, including, at a minimum, diagnostic test results, problem list, medication list, medication allergy list, immunizations, and procedures in: (1) Human readable format; and (2) accordance with the standards % specified in Table 2A row 1 to provide to a patient on electronic media, or through some other electronic means. Enable a user to create an electronic copy of a patient's clinical information, including, at a minimum, diagnostic test results, problem list, medication list, medication allergy list, immunizations, discharge summary, and procedures in: (1) Human readable format; and (2) accordance with the standards % specified in Table 2A row 1 to provide to a patient on electronic media, or through some other electronic means. Provide patients with an electronic copy of their discharge instructions and procedures at time of discharge, upon request No Associated Proposed Meaningful Use Stage 1 Objective. Enable a user to create an electronic copy of the discharge instructions and procedures for a patient, in human readable format, at the time of discharge to provide to a patient on electronic media, or through some other electronic means. Provide patients with timely electronic access to their health information (including lab results, problem list, medication lists, allergies) within 96 hours of the information being available to the eligible professional Enable a user to provide patients with online access to their clinical information, including, at a minimum, lab test results, problem list, medication list, medication allergy list, immunizations, and procedures. No Associated Proposed Meaningful Use Stage 1 Objective. Provide clinical summaries for patients for each office visit 1. Enable a user to provide clinical summaries to patients (in paper or electronic form) for each office visit that include, at a minimum, diagnostic test results, medication list, medication allergy list, procedures, problem list, and immunizations. No Associated Proposed Meaningful Use Stage 1 Objective. 2. If the clinical summary is provided electronically ( i.e., not printed), it must be provided in: (1) Human readable format; and (2) accordance with the standards % specified in Table 2A row 1 to provide to a patient on electronic media, or through some other electronic means. Capability to exchange key clinical information among providers of care and patient authorized entities electronically 13 14 Provide summary care record for each transition of care and referral 1. Electronically receive a patient summary record, from other providers and organizations including, at a minimum, diagnostic test results, problem list, medication list, medication allergy list, immunizations, and procedures and upon receipt of a patient summary record formatted in an alternative standard specified in Table 2A row 1, displaying it in human readable format. 2. Enable a user to electronically transmit a patient summary record to other providers and organizations including, at a minimum, diagnostic test results, problem list, medication list, medication allergy list, immunizations, and procedures in accordance with the standards % specified in Table 2A row 1. 1. Electronically receive a patient summary record, from other providers and organizations including, at a minimum, discharge summary, diagnostic test results, problem list, medication list, medication allergy list, immunizations, and procedures and upon receipt of a patient summary record formatted in an alternative standard specified in Table 2A row 1, displaying it in human readable format. 2. Enable a user to electronically transmit a patient summary record, to other providers and organizations including, at a minimum, discharge summary, diagnostic test results, problem list, medication list, medication allergy list, immunizations, and procedures in accordance with the standards % specified in Table 2A row 1. Perform medication reconciliation at relevant encounters and each transition of care Electronically complete medication reconciliation of two or more medication lists (compare and merge) into a single medication list that can be electronically displayed in real-time. Capability to submit electronic data to immunization registries and actual submission where required and accepted Electronically record, retrieve, and transmit immunization information to immunization registries in accordance with the standards % specified in Table 2A row 8 or in accordance with the applicable state-designated standard format. Capability to provide electronic submission of reportable lab results (as required by state or local law) to public health agencies and actual submission where it can be received No Associated Proposed Meaningful Use Stage 1 Objective. Electronically record, retrieve, and transmit reportable clinical lab results to public health agencies in accordance with the standards % specified in Table 2A row 6. Capability to provide electronic syndromic surveillance data to public health agencies and actual transmission according to applicable law and practice Electronically record, retrieve, and transmit syndrome-based ( e.g., influenza like illness) public health surveillance information to public health agencies in accordance with the standards specified in Table 2A row 7. Protect electronic health information created or maintained by the certified EHR technology through the implementation of appropriate technical capabilities 1. Assign a unique name and/or number for identifying and tracking user identity and establish controls that permit only authorized users to access electronic health information. 2. Permit authorized users (who are authorized for emergency situations) to access electronic health information during an emergency. 3. Terminate an electronic session after a predetermined time of inactivity. 4. Encrypt and decrypt electronic health information according to user-defined preferences ( e.g., backups, removable media, at log-on/off) in accordance with the standard specified in Table 2B row 1. 5. Encrypt and decrypt electronic health information when exchanged in accordance with the standard specified in Table 2B row 2. 6. Record actions ( e.g., deletion) related to electronic health information in accordance with the standard specified in Table 2B row 3 ( i.e., audit log), provide alerts based on user-defined events, and electronically display and print all or a specified set of recorded information upon request or at a set period of time. 7. Verify that electronic health information has not been altered in transit and detect the alteration and deletion of electronic health information and audit logs in accordance with the standard specified in Table 2B row 4. 8. Verify that a person or entity seeking access to electronic health information is the one claimed and is authorized to access such information. 9. Verify that a person or entity seeking access to electronic health information across a network is the one claimed and is authorized to access such information in accordance with the standard specified in Table 2B row 5. 10. Record disclosures made for treatment, payment, and health care operations in accordance with the standard specified in Table 2B row 6. We reiterate that adopted certification criteria identify the required capabilities for a Complete EHR or EHR Module to be certified. Adopted certification criteria do not apply to, or require actions by, eligible professionals or eligible hospitals. For example, to be certified, a Complete EHR or EHR Module must be capable of plotting and displaying growth charts for patients. By being tested and certified, a Complete EHR or EHR Module will have demonstrated that this capability is available for an eligible professional or eligible hospital to use. 3 For eligible hospitals the full proposed meaningful use Stage 1 objective is: “Use CPOE for orders (any type) directly entered by authorizing provider (for example, MD, DO, RN, PA, NP).” 4 For eligible professionals the full proposed meaningful use Stage 1 objective is: “record demographics: preferred language, insurance type, gender, race, ethnicity, date of birth.” 5 For eligible hospitals the full proposed meaningful use Stage 1 objective is: “record demographics: preferred language, insurance type, gender, race, ethnicity, date of birth, date and cause of death in the event of mortality.” 6 42 CFR 493.1291(b) specifies that “[t]he test report information maintained as part of the patient's chart or medical record must be readily available to the laboratory and to CMS or a CMS agent upon request.” 42 CFR 493.1291(c) specifies the required test report information. 7 For eligible professionals the full proposed meaningful use Stage 1 objective is “Report ambulatory quality measures to CMS or the States.” 8 For eligible hospitals the full proposed meaningful use Stage 1 objective is “Report hospital quality measures to CMS or the States.” 9 For eligible professionals the full proposed meaningful use Stage 1 objective is “Implement 5 clinical decision support rules relevant to specialty or high clinical priority, including diagnostic test ordering, along with the ability to track compliance with those rules” 10 For eligible hospitals the full proposed meaningful use Stage 1 objective is “Implement 5 clinical decision support rules related to a high priority hospital condition, including diagnostic test ordering, along with the ability to track compliance with those rules” 11 For eligible professionals the full proposed meaningful use Stage 1 objective is “Provide patients with an electronic copy of their health information (including diagnostic test results, problem list, medication lists, allergies), upon request” 12 For eligible hospitals the full proposed meaningful use Stage 1 objective is “Provide patients with an electronic copy of their health information (including diagnostic test results, problem list, medication lists, allergies, discharge summary, procedures), upon request” 13 For eligible professionals the full proposed meaningful use Stage 1 objective is “Capability to exchange key clinical information (for example problem list, medication list, allergies, diagnostic test results) among providers of care and patient authorized entities electronically.” 14 For eligible hospitals the full proposed meaningful use Stage 1 objective is “Capability to exchange key clinical information (for example discharge summary, procedures, problem list, medication list, allergies, diagnostic test results) among providers of care and patient authorized entities electronically.” In adopting these certification criteria, we attempted to balance specificity with flexibility and the opportunity for innovation. However, in taking this approach we recognize that certain tradeoffs exist. On one hand, we anticipate that flexibility will allow Complete EHRs and EHR Modules to evolve over time to meet these criteria in increasingly efficient, useable, and innovative ways. On the other hand, any lack of specificity concerning the capabilities Complete EHRs or EHR Modules must include risks the possibility that Certified EHR Technology may inadequately support an eligible professional or eligible hospital's attempt to achieve meaningful use Stage 1, once finalized. Therefore, we request public comment on whether any of the adopted certification criteria above are insufficiently specific to be used to test and certify Complete EHRs or EHR Modules with reasonable assurance that the technology will effectively support the delivery of health care as well as the achievement of meaningful use Stage 1, once finalized. 2. Adopted Standards In fulfilling the Secretary's responsibility under section 3004(b)(1), the following initial set of standards and implementation specifications have been adopted 15 for use in Certified EHR Technology to support proposed meaningful use Stage 1 and to enable increased interoperability and privacy and security. We have organized adopted standards into the same four categories recommended by the HIT Standards Committee. 15 Per section 3004(b)(1), we believe the standards adopted address all applicable “areas required for consideration” under section 3002(b)(2)(B)—the HIT Policy Committee required areas described above in Section I of this interim final rule. • Vocabulary Standards ( i.e., standardized nomenclatures and code sets used to describe clinical problems and procedures, medications, and allergies); • Content Exchange Standards ( i.e., standards used to share clinical information such as clinical summaries, prescriptions, and structured electronic documents); • Transport Standards ( i.e., standards used to establish a common, predictable, secure communication protocol between systems); and • Privacy and Security Standards ( e.g., authentication, access control, transmission security) which relate to and span across all of the other types of standards. As demonstrated by the adopted certification criteria, we expect Certified EHR Technology to be tested and certified as being capable of complying with adopted standards. We note that there are not standards required for every certification criterion adopted by this interim final rule. However, we have required standards as part of certain certification criteria when their adoption could lead to increased interoperability and privacy and security. We agree with the HIT Policy Committee's recommendation to focus on these two areas and believe they are the most important to emphasize for this initial set of standards. We discuss the adopted interoperability standards directly below and the adopted privacy and security standards in section III.C.2.c. With respect to interoperability standards we have, after considering the recommendations of the HIT Standards Committee, chosen to adopt alternative standards for certain purposes. Also, at the recommendation of the HIT Standards Committee, we have limited the adoption of specific vocabulary standards in this initial set to a few, important instances. Presently, we have only adopted a limited number of certification criteria that require Certified EHR Technology to be capable of using a specific vocabulary or code set. In certain instances, because of other HHS regulatory requirements, we have adopted those vocabularies and code sets with which the regulated community is already required to comply. We expect future stages of meaningful use will require Certified EHR Technology to provide additional capabilities as well as an increased capacity to exchange electronic health information according to specific vocabularies and code sets. To enhance interoperability, we believe it will be essential to adopt specific standards, vocabularies, and code sets in the future. We look forward to receiving recommendations from the HIT Standards Committee related to specific vocabularies and code sets to support future stages of meaningful use. The initial set of standards and implementation specifications in this interim final rule was adopted to support the proposed requirements for meaningful use Stage 1. We have added a column in Table 2A to illustrate the standards that we believe Certified EHR Technology should most likely be capable of to support meaningful use Stage 2 (although as explained in the Medicare and Medicaid EHR Incentives Program proposed rule, CMS intends to engage in rulemaking to adopt Stage 2 criteria for meaningful use and ONC would adopt standards consistent with this effort). We developed this list of candidate Stage 2 standards by considering the recommendations made by the HIT Standards Committee related to standards to support meaningful use Stage 2 and developing our own estimates of what it would take to advance interoperability. We have added a column in Table 2A to illustrate the standards that we believe should be included in Certified EHR Technology to support meaningful use Stage 2. With the exception of standards that are tied to other HHS regulatory requirements, this additional column represents our best estimate and does not in any way imply the Secretary's adoption of these standards or limit the Secretary's discretion to adopt different standards in the future. We look forward to receiving recommendations from the HIT Standards Committee to advance interoperability in line with these estimates and welcome comments on the industry's ability to implement these candidate standards in time to support meaningful use Stage 2 (which is proposed to begin in 2013). As an example of our future expectations, currently adopted certification criteria do not require the use of the vocabulary standard, RxNorm. However, RxNorm maintains links from the RxNorm concept unique identifier (CUI) to the corresponding drug codes in other vocabularies. While we have not adopted RxNorm as a standard in this initial set, we have adopted as a standard for medication information the use of a vocabulary the National Library of Medicine has identified as an RxNorm drug data source provider with a complete data set integrated within RxNorm (additional detail regarding this standard is provided below). We believe this standard will establish an important bridge to full RxNorm adoption and will help facilitate this transition over time. We anticipate adopting certification criteria that requires Certified EHR Technology be capable of using the RxNorm superset in its entirety to support meaningful use Stage 2 and look forward to HIT Standards Committee recommendations in this regard. As another example, we have adopted a certification criterion that requires Certified EHR Technology to be capable of receiving a message with Logical Observation Identifiers Names and Codes (LOINC®) codes from a laboratory, retaining those LOINC® codes, and using LOINC® codes to populate a patient summary record. We do not require Certified EHR Technology to be capable of mapping all laboratory orders or tests to LOINC® codes. Rather, we require that Certified EHR Technology be capable of using LOINC® codes that are received and retained to populate a patient summary record. Moreover, having LOINC® codes used internally for meaningful use Stage 1 will prepare Certified EHR Technology for any future potential meaningful use Stage 2 requirements. We believe the use of LOINC®, Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT®), and other vocabulary standards will accelerate the adoption and use of clinical decision support. Requiring LOINC® as a vocabulary standard that Certified EHR Technology must have the capability to support for meaningful use Stage 1 provides an incremental approach to achieving these future goals. A final example would be, if an eligible professional uses Certified EHR Technology that has implemented the continuity of care document (CCD) standard for the exchange of a patient summary record and receives a patient summary record formatted in the continuity of care record (CCR) standard, their Certified EHR Technology must be capable of interpreting the information within the CCR message and displaying it in human readable format. We do not expressly state how this should be accomplished or in what format human readable information should be displayed ( e.g., information in a CCR message could be converted to a text file or PDF). We only require that Certified EHR Technology must be capable of performing this function. We believe this requirement is critical and have included it to allow flexibility in the marketplace during meaningful use Stage 1 and to prevent good faith efforts to exchange information from going to waste ( i.e., information is exchanged, but is unreadable to both Certified EHR Technology (machine readable) and humans). We discuss in more detail below the four categories identified above and the standards adopted for each. At the end of this section we provide in Table 2A the standards adopted for certain exchange purposes to support meaningful use Stage 1, as proposed in the Medicare and Medicaid EHR Incentive Programs proposed rule, as well as those candidate standards we believe should be adopted and required in certification criteria to support meaningful use Stage 2. Finally, and consistent with the National Technology Transfer and Advancement Act of 1995 (NTTAA) (15 U.S.C. 3701 et seq. ) and OMB Circular A-119 16 (the circular), we have adopted voluntary consensus standards wherever practical. We have noted with a superscript “+” (plus sign) those standards that are not voluntary consensus standards. Both the NTTAA and the Circular require Federal agencies to use technical standards that are developed or adopted by voluntary consensus standards bodies, using such technical standards as a means to carry out policy objectives or activities. Federal agencies, however, are not required to use such standards if doing so would be “inconsistent with applicable law or otherwise impractical.” In those instances in which we have not used voluntary consensus standards, we determined that to do so would be impractical for two principal reasons. First, in most cases a voluntary consensus standard that could meet the requisite technical goals was simply unavailable. Second, to the extent that a potentially equivalent voluntary consensus standard was available, the standard was too limiting and did not meet our policy goals, including allowing for greater innovation by the marketplace. We solicit comment on our approach and the availability of voluntary consensus standards that may be viable alternatives to any of the non-voluntary consensus standards we have adopted. 16 http://www.whitehouse.gov/omb/circulars_a119. a. Transport Standards With respect to transport standards, we have adopted Simple Object Access Protocol (SOAP) version 1.2 and Representational state transfer (REST) to provide standard ways for systems to interact with each other. SOAP and REST are discussed in more detail below. These standards are widely used and implemented by the HIT industry and were also recommended by the HIT Standards Committee. We understand that the industry is already exploring other standards beyond SOAP and REST, and we look forward to receiving recommendations from the HIT Standards Committee in this regard to help enable innovation in the marketplace rather than constrain it. We recognize, out of the four categories of standards identified above, that the term “transport standard” may be used by others to refer to what we have called a “content exchange standard.” In the interest of retaining the categories recommended by the HIT Standards Committee and to avoid further confusion, we have chosen this categorization and believe the following distinction can be made to clarify the meaning of the two terms in this interim final rule. Transport standards are not domain specific while content exchange standards are. That is, SOAP and REST can be used by other industries to exchange information while the CCD, for example, is specifically designed for the exchange of health information. SOAP, originally defined as “Simple Object Access Protocol”, is a protocol specification for exchanging structured information in the implementation of Web Services in computer networks. It relies on Extensible Markup Language (XML) as its message format, and usually relies on other Application Layer protocols (most notably Remote Procedure Call (RPC) and HyperText Transfer Protocol (HTTP)) for message negotiation and transmission. SOAP can form the foundation layer of a web services protocol stack, providing a basic messaging framework upon which web services can be built. The SOAP architecture consists of several layers of specifications for message format, message exchange patterns (MEP), underlying transport protocol bindings, message processing models, and protocol extensibility. SOAP was adopted because it is widely used and versatile enough to allow for the use of different transport protocols, is platform independent, and is language independent. REST is a style of software architecture for distributed hypermedia systems such as the Internet. Systems which follow REST principles are often referred to as “RESTful”. An important concept in REST is the existence of Web resources (sources of specific information), each of which is referenced with a global identifier ( e.g., a Uniform Resource Identifier or URI in HTTP). In order to manipulate these resources, “components” of the network (user agents and origin servers) communicate via a standardized interface ( e.g., HTTP) and exchange “representations” of these resources (the actual documents conveying the information). A RESTful web service is a simple web service implemented using HTTP and the principles of REST. b. Content Exchange and Vocabulary Standards i. Patient Summary Record With respect to meaningful use Stage 1, Certified EHR Technology will be required to be certified as being capable of (1) using the Health Level Seven (HL7) Clinical Document Architecture (CDA) Release 2 (R2) Level 2 CCD or ASTM CCR to electronically exchange a patient summary record; and 2) upon receipt of a patient summary record formatted in an alternative standard, displaying it in human readable format. An HL7 CCD Level 2 allows the body of the CCD to be either structured XML text, or unstructured text, and provides backward compatibility to CCD Level 1 documents as well as a migration path to the more complex HL7 Version 3 reference information model (RIM) based information found in CCD Level 3. For the purposes of industry readiness and to further interoperability in a stepwise fashion, we have decided to adopt these two content exchange standards as alternatives. We firmly believe one patient summary record standard should be adopted to support meaningful use Stage 2 and beyond. We believe that this is necessary to improve patient care and access to health information as well as interoperability in general. We expect the industry to move toward a single standard for patient summary records in the near future and potentially in time to support meaningful use Stage 2. We welcome public comments regarding these alternatives and specifically comments that can address the HIT industry's readiness to move to a single standard. We also look forward to receiving recommendations from the HIT Standards Committee in this regard. With respect to the vocabulary standards for use within a patient summary record, and in support of [Text truncated at 120,000 characters. The full text is on the page linked above.] --- Source: Frix Law Library, https://www.frixlaw.com/law-library/documents/fr%3AE9-31216. Public record. Not legal advice.