E9-31216. 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.”

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]

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.

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.

• 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.

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 proposed meaningful Stage 1 objectives, we expect the following fields to be populated: problem list; medication list; medication allergy list; procedures; vital signs; units of measure; lab orders and results; and, where appropriate, discharge summary. At this time, the Secretary has only adopted standards related to the use of International Classification of Diseases, 9th Revision, Clinical Modifications (ICD-9-CM) or SNOMED CT® to populate a problem list and ICD-9-CM or American Medical Association (AMA) Current Procedural Terminology (CPT®) Fourth Edition (CPT-4) to populate information related to procedures. For medication lists, we have adopted a standard that requires the use of codes from a drug vocabulary the National Library of Medicine has identified as an RxNorm drug data source provider with a complete data set integrated within RxNorm.^[17] For lab results, we have adopted a standard that requires the use of LOINC® to populate information in a patient summary record related to lab orders and results when LOINC® codes have been received from a laboratory and are retained and subsequently available to Certified EHR Technology. In instances where LOINC® codes have not been received from a laboratory, the use of any local or proprietary code is permitted (i.e., we do not require these local or proprietary codes to be converted to LOINC® codes in order to populate a patient summary record). Apart from the standards specified above, we do not specify the types of vocabularies or code sets that could potentially be used to populate the remaining fields of a patient summary record. As shown in Table 2A, we anticipate adopting vocabulary standards for many of the fields above to support meaningful use Stage 2. For example, we have not identified any code sets for medication allergies, but we believe there is value to integrating both medication and non-medication related allergies using a common standard, and in providing ingredient-based medication allergies. These requirements would be satisfied through the use of the UNII standard (referenced as a candidate Stage 2 standard in Table 2A). We request public comment on the standard we have adopted to populate medication list information.

ii. Drug Formulary Check

For the purposes of performing a drug formulary check, Certified EHR Technology must be capable of using NCPDP Formulary & Benefits Standard 1.0 adopted by HHS (73 FR 18918) in order to ensure in circumstances where an eligible professional or eligible hospital electronically prescribes a Part D drug for a Medicare Part D eligible individual, he/she can maintain compliance with applicable law. We are adopting this standard also to meet one of the proposed meaningful use Stage 1 objectives, which seeks to have an automated formulary check as a capability provided by Certified EHR Technology so that formulary and benefit information can be readily provided to advise an eligible professional or eligible hospital's decisions in prescribing drugs to a patient.

iii. Electronic Prescribing

For the purposes of electronic prescribing, Certified EHR Technology must be capable of using NCPDP SCRIPT 8.1 or NCPDP SCRIPT 8.1 and 10.6. SCRIPT 8.1 is the current standard adopted by HHS for specified transactions involving the communication of a prescription or prescription-related information between prescribers and dispensers in the Medicare Part D electronic prescribing drug program. While it is not recognized as such at this time, we expect that SCRIPT 10.6 will be a permitted backwards compatible alternative by the start of meaningful use Stage 1. Moreover, if SCRIPT 10.6 is permitted, prior to any modification of the provisions of this interim final rule in response to public comment, we would expect to change our requirement to simply permit either SCRIPT 8.1 or SCRIPT 10.6. Again, with respect to a vocabulary standard, we have adopted a standard that requires the use of codes from a drug vocabulary currently integrated into the RxNorm (see detailed description above). We believe that adopting RxNorm in the future will lead to improved interoperability and look forward to receiving recommendations from the HIT Standards Committee in this regard.

iv. Administrative Transactions

For the purposes of conducting certain administrative transactions, Certified EHR Technology must be capable of using applicable HIPAA transaction standards and Medicare Part D standards adopted by the Secretary. This includes at least the following Accredited Standards Committee (ASC) X12N Subcommittee standards or NCPDP standards for the relevant covered transactions. Because the HIPAA transactions standards regulations reference the transaction standards together with the “implementation guides,” which are comprised of implementation specifications, we have chosen to identify the adopted standards and implementation specifications associated with these HIPAA transaction standards together rather than separately in section III.C.3 below. In adopting these standards and the implementation specifications, we have referenced the CFR locations where they have been adopted for the relevant HIPAA transactions, and as a result the certification criteria will track the adopted HIPAA transactions standards requirements. Consequently, as the HIPAA transaction standards are updated or modified, Complete EHRs or EHR Modules will be certified consistently with the current HIPAA transaction standards requirements. We intend, to the extent possible, to assure that Certified EHR Technology will enable covered entities to conduct HIPAA covered transactions as “standard transactions,” as that term is defined in 45 CFR 162.103.

However, in pursuing this approach we note that in accordance with 45 CFR 162.1102 and 45 CFR 162.1202, the Secretary currently permits the use of two versions of ASC X12N and NCPDP standards (Versions 4010/4010A and 5010 and Versions 5.1 and D.0, respectively) until December 31, 2011, at which point only the most recently adopted HIPAA transaction standards will be permitted (74 FR 3296). Unlike the effective date for ICD-10-CM and ICD-10-PCS which is set for October 1, 2013, placing compliance within meaningful use Stage 2, the 5010 and D.0 HIPAA transaction standards are required to be used in the second year of meaningful use Stage 1. Consequently, in order for eligible professionals and eligible hospitals that adopt Certified EHR Technology to remain in compliance with the law for conducting certain administrative transactions, Certified EHR Technology must be capable of using both versions of applicable adopted HIPAA transaction standards.

• For retail pharmacy drugs and dental, professional, and institutional health care eligibility benefit inquiry and response transactions (as defined at 45 CFR 162.1201) Certified EHR must be capable of using the following standards:

○ NCPDP Telecommunications Standards Implementation Guide, Version 5, Release 1 (Version 5.1), and Version D, Release 0 (Version D.0) equivalent NCPDP Batch Standards Batch Implementation Guide, Versions 1.1 and 1.2; and

○ ASC X12N 270/271—Health Care Eligibility Benefit Inquiry and Response, Version 4010 (004010X092) and Addenda to Health Care Eligibility Benefit Inquiry and Response (004010X092A1) as well as ASC X12 Standards for Electronic Data Interchange Technical Report Type 3, Version 5010 (ASC X12N/005010X279).

• For retail pharmacy drugs and dental, professional, and institutional health care claims or equivalent encounter information transaction (as defined at 45 CFR 162.1101):

○ NCPDP Telecommunications Standards Implementation Guide, Version 5, Release 1 (Version 5.1), and Version D, Release 0 (Version D.0) equivalent NCPDP Batch Standards Batch Implementation Guide, Versions 1.1 and 1.2; and

○ ASC X12N 837—Health Care Claim: Dental—Version 4010 (004010X097) and Addenda to Health Care Claim: Dental, Version 4010 (004010X097A1) as well as ASC X12 Standards for Electronic Data Interchange Technical Report Type 3—Health Care Claim: Dental (837), (ASC X12N/005010X224), and Type 1 Errata to Health Care Claim: Dental (837) ASC X12 Standards for Electronic Data Interchange Technical Report Type 3, (ASC X12N/005010X224A1); and

○ ASC X12N 837—Health Care Claims: Professional, Volumes 1 and 2, Version 4010 (004010X098) and Addenda to Health Care Claims: Professional, Volumes 1 and 2, Version 4010, (004010x098A1), as well as ASC X12 Standards for Electronic Data Interchange Technical Report Type 3—Health Care Claim: Professional (837), (ASC X12N/005010X222); and

○ The ASC X12N 837—Health Care Claim: Institutional, Volumes 1 and 2, Version 4010, (004010X096) and Addenda to Health Care Claim: Institutional, Volumes 1 and 2, Version 4010, (004010X096A1) as well as ASC X12 Standards for Electronic Data Interchange Technical Report Type 3—Health Care Claim: Institutional (837), (ASC X12N/005010X223), and Type 1 Errata to Health Care Claim: Institutional (837) ASC X12 Standards for Electronic Data Interchange Technical Report Type 3 (ASC X12N/005010X223A1).

• To perform eligibility inquiry and response transactions between dispensers and Part D sponsors for Part D prescription drugs.

○ NCPDP Telecommunications Standards Implementation Guide, Version, 5, Release 1 (Version 5.1), and equivalent NCPDP Batch Standards Batch Implementation Guide, Version 1.1.

v. Quality Reporting

For the purposes of electronically submitting calculated quality measures required by CMS or by States, Certified EHR Technology must be capable of using the CMS PQRI 2008 Registry XML Specification. We recognize that CMS has discussed in the Medicare and Medicaid EHR Incentive Programs proposed rule potential approaches to quality reporting requirements for future years of meaningful use and we anticipate adopting standards as necessary and in consultation with CMS to support future quality reporting requirements. We also understand that for the purposes of electronically submitting quality measures an upcoming standard for Complete EHRs and EHR modules may be the HL7 Quality Reporting Document Architecture (QRDA) Implementation Guide based on HL7 CDA Release 2 and we request public comment on whether this standard is mature enough to be used in Complete EHRs and EHR Modules during meaningful use Stage 1.

vi. Submission of Lab Results to Public Health Agencies

For the purposes of submitting lab results to public health agencies, Certified EHR Technology must be capable of using HL7 2.5.1. With respect to vocabulary standards for the submission of lab results to public health agencies, we have adopted the same standard for populating lab results as we do for the patient summary record above. We believe that enabling the use of UCUM and SNOMED CT® for this exchange in the future would lead to improved interoperability.

vii. Submission to Public Health Agencies for Surveillance or Reporting

For the purposes of electronically submitting information to public health agencies for surveillance and reporting, Certified EHR Technology must be capable of using HL7 2.3.1 or HL7 2.5.1 as a content exchange standard. This requirement is not meant to include adverse event reporting. At this time, we have not adopted a specific vocabulary standard for submitting information to public health agencies for surveillance and reporting, and believe that such standards will be determined in large part by the applicable public health agency receiving such information. We look forward to receiving recommendations from the HIT Standards Committee regarding additional standards that should be adopted to facilitate the electronic submission of information to public health agencies for surveillance and reporting purposes.

viii. Submission to Immunization Registries

For the purposes of electronically submitting information to immunization registries Certified EHR Technology must be capable of using HL7 2.3.1 or HL7 2.5.1 as a content exchange standard and the CDC maintained HL7 standard code set CVX—Vaccines Administered ^[18] as the vocabulary standard.

ix. Table 2A

Table 2A below displays the applicable adopted standards for each exchange purpose specified. We have used “Cx” and “V” as shorthand for “content exchange” and “vocabulary,” respectively, to identify which standard category applies to the exchange purpose. Where a cell in table 2A includes the reference “no standard adopted at this time” it means that a Complete EHR or EHR Module would not be required to be tested and certified as including a particular standard. As a result, any local or proprietary standard could be used as well as the standard(s) listed as candidate meaningful use Stage 2 standards. Unless marked with the following superscripts, all of the adopted standards are from the ONC process that took place prior to the enactment of the HITECH Act or are required by other HHS regulations.

• A number sign “#” indicates that the HIT Standards Committee recommended this standard to the National Coordinator but it was not part of the prior ONC process.
• An asterisk “*” indicates that the standard was neither recommended by the HIT Standards Committee nor part of the prior ONC process.
• A plus sign “+” as mentioned above indicates a standard that is not a voluntary consensus standard.

Table 2A—Adopted Content Exchange and Vocabulary Standards

Row No.	Purpose	Category	Adopted standard(s) to support meaningful use stage 1	Candidate standard(s) to support meaningful use stage 2
1	Patient Summary Record	Cx	HL7 CDA R2 CCD Level 2 or ASTM CCR	Alternatives expected to be narrowed based on HIT Standards Committee recommendations.
	• Problem List	V	Applicable HIPAA code set required by law (i.e., ICD-9-CM); or SNOMED CT®	Applicable HIPAA code set required by law (e.g., ICD-10-CM) or SNOMED CT®.
	• Medication List	V	Any code set by an RxNorm drug data source provider that is identified by the United States National Library of Medicine as being a complete data set integrated within RxNorm+	RxNorm.
	• Medication Allergy List	V	No standard adopted at this time	UNII.
	• Procedures	V	Applicable HIPAA code sets required by law (i.e., ICD-9-CM or CPT-4®)	Applicable HIPAA code sets required by law (i.e., ICD-10-PCS or CPT-4®).
	• Vital Signs	V	No standard adopted at this time	CDA template.
	• Units of Measure	V	No standard adopted at this time	UCUM.
	• Lab Orders and Results	V	LOINC® when LOINC® codes have been received from a laboratory	LOINC®.
2	Drug Formulary Check	Cx	Applicable Part D standard required by law (i.e., NCPDP Formulary & Benefits Standard 1.0)	Applicable Part D standard required by law.
3	Electronic Prescribing	Cx	Applicable Part D standard required by law (e.g., NCPDP SCRIPT 8.1) or NCPDP SCRIPT 8.1 and NCPDP SCRIPT 10.6	NCPDP SCRIPT 10.6.
		V	Any code set by an RxNorm drug data source provider that is identified by the United States National Library of Medicine as being a complete data set integrated within RxNorm+	RxNorm.
4	Administrative Transactions	Cx	Applicable HIPAA transaction standards required by law	Applicable HIPAA transaction standards required by law.
5	Quality Reporting	Cx	CMS PQRI 2008 Registry XML Specification #,+	Potentially newer version(s) or standards based on HIT Standards Committee Input.
6	Submission of Lab Results to Public Health Agencies	Cx	HL7 2.5.1	Potentially newer version(s) or standards based on HIT Standards Committee Recommendations.
		V	LOINC® when LOINC® codes have been received from a laboratory	LOINC®, UCUM, and SNOMED CT® or Applicable Public Health Agency Requirements.
7	Submission to Public Health Agencies for Surveillance or Reporting (excluding adverse event reporting)	Cx	HL7 2.3.1 or HL7 2.5.1	Potentially newer version(s) or standards based on HIT Standards Committee Input.
		V	According to Applicable Public Health Agency Requirements	GIPSE or According to Applicable Public Health Agency Requirements.
8	Submission to Immunization Registries	Cx	HL7 2.3.1 or HL7 2.5.1	Potentially newer version(s) or standards based on HIT Standards Committee Recommendations.
		V	CVX*,+	CVX.

c. Privacy and Security Standards

We believe it is necessary for Certified EHR Technology to provide certain privacy and security capabilities. In that regard, we have aligned adopted certification criteria to applicable HIPAA Security Rule requirements and believe that in doing so, such capabilities may assist eligible professionals and eligible hospitals to improve their overall approach to privacy and security. In addition, some may find that the capabilities provided by Certified EHR Technology may facilitate and streamline compliance with Federal and state privacy and security laws. We believe that the HIPAA Security Rule serves as an appropriate starting point for establishing the capabilities for Certified EHR Technology. That being said, the HITECH Act directs the HIT Policy Committee, the HIT Standards Committee, and ONC to look at capabilities beyond those explicitly specified in the HIPAA Security Rule. We intend to work with both of these Committees to explore these areas and where possible to adopt new certification criteria and standards in the future to improve the capabilities Certified EHR Technology can provide to protect health information.

The adopted certification criteria in Table 1 assure that Certified EHR Technology is capable of supporting eligible professionals and eligible hospitals comply with HIPAA requirements to protect electronic health information residing within Certified EHR Technology and, where appropriate, when such information is exchanged. For certain capabilities, we have adopted, after considering the recommendations of the HIT Standards Committee, specific standards to be used in Certified EHR Technology. These standards and their purposes are displayed in Table 2B. For other capabilities, we have not adopted specific standards because such capabilities can be appropriately addressed through different approaches, and we did not want to preclude innovation. For example, while we have adopted a certification criterion related to access control, we have not adopted a specific standard for access control because we believe that the industry will continue to innovate at a rapid pace in this area and better methods to implement this capability will be available faster than we would be able to adopt them via regulation. On the other hand, we have adopted certification criteria and standards for encryption because specific industry best practices and requirements exist with respect to encryption and the strength of encryption algorithms. HHS previously articulated in guidance entitled “Guidance Specifying the Technologies and Methodologies That Render Protected Health Information Unusable, Unreadable, or Indecipherable to Unauthorized Individuals” (74 FR 42741) that encryption is an effective method to “render protected health information unusable, unreadable, or indecipherable to unauthorized individuals,” and one that can exempt a HIPAA covered entity from having to report a breach. To further support this determination, we believe a logical and practical next step and one that will provide eligible professionals and eligible hospitals with a capability they may not have had in the past is to require Certified EHR Technology to be capable of encryption.

It is important to note, under 45 CFR 164.312(a)(2)(iv) and (e)(2)(ii), a HIPAA covered entity must assess whether encryption as a method for safeguarding electronic protected health information is a reasonable and appropriate safeguard in its environment. Consequently, a HIPAA covered entity could be in compliance with the HIPAA Security Rule if it determines that encryption is not reasonable and appropriate in its environment and it documents its rationale and implements an equivalent alternative measure if reasonable and appropriate. We hope that by requiring Certified EHR Technology to include this capability, that the use of encryption will become more prevalent. Of the certification criteria and associated standards we have adopted related to encryption, the first is for encryption in general while the second is specific to when electronic health information is exchanged. The first certification criterion and standard will assure that Certified EHR Technology is capable of using encryption according to user-defined preferences. There are several industry best practices in this regard and we expect that with the availability of the capability to perform encryption, eligible professionals and hospitals will follow suit and enhance how they protect electronic health information. We anticipate that this capability could be used by eligible professionals and eligible hospitals to encrypt backup hard drives or tapes, removable media, or portable devices. Finally, we expect other functions or services such as domain name service, directory access, and consistent time (e.g., for audit logs) to support and further enable some of the standards in Table 2B. However, due to the fact these functions or services may be part of an overall implementation of Certified EHR Technology (e.g., operating system, network time server) rather than a specific capability Certified EHR Technology should be tested and certified as including, we chose not to adopt certification criteria or standards. We request public comment on whether the previously mentioned functions or services or any other function or service should be considered for adoption by the Secretary as a necessary capability for Certified EHR Technology to include.

After considering the written and oral public comments provided to both the HIT Policy and HIT Standards Committees, we would like to clarify the applicability of the privacy and security certification criteria and standards adopted in this interim final rule. This interim final rule strictly focuses on the capabilities of Certified EHR Technology and does not change existing HIPAA Privacy Rule or Security Rule requirements, guarantee compliance with those requirements, or absolve an eligible professional, eligible hospital, or other health care provider who adopts Certified EHR Technology from having to comply with any applicable provision of the HIPAA Privacy or Security Rules. While the capabilities provided by Certified EHR Technology may assist an eligible professional or eligible hospital in improving their technical safeguards in order to meet some or all of the HIPAA Security Rule's requirements or influence their risk analysis, the use of Certified EHR Technology alone does not equate to compliance with the HIPAA Privacy or Security Rules. The capabilities provided by Certified EHR Technology do not affect in any way the analysis a HIPAA covered entity is responsible for performing specified at 45 CFR 164.306(b) and (d). Unless there are specific meaningful use measures for privacy and security that require the use of a particular capability, an eligible professional or eligible hospital may find that its security practices exceed these capabilities and nothing in this rule precludes the use or implementation of more protective privacy and security measures.

Table 2B—Adopted Privacy and Security Standards

Row No.	Purpose	Adopted standard
1	General Encryption and Decryption of Electronic Health Information	A symmetric 128 bit fixed-block cipher algorithm capable of using a 128, 192, or 256 bit encryption key must be used (e.g., FIPS 197 Advanced Encryption Standard, (AES), Nov 2001).+
2	Encryption and Decryption of Electronic Health Information for Exchange	An encrypted and integrity protected link must be implemented (e.g., TLS, IPv6, IPv4 with IPsec).+
3	Record Actions Related to Electronic Health Information (i.e., audit log)	The date, time, patient identification (name or number), and user identification (name or number) must be recorded when electronic health information is created, modified, deleted, or printed. An indication of which action(s) occurred must also be recorded (e.g., modification).+
4	Verification that Electronic Health Information has not been Altered in Transit	A secure hashing algorithm must be used to verify that electronic health information has not been altered in transit. The secure hash algorithm used must be SHA-1 or higher (e.g., Federal Information Processing Standards (FIPS) Publication (PUB) Secure Hash Standard (SHS) FIPS PUB 180-3).+
5	Cross-Enterprise Authentication	Use of a cross-enterprise secure transaction that contains sufficient identity information such that the receiver can make access control decisions and produce detailed and accurate security audit trails (e.g., IHE Cross Enterprise User Assertion (XUA) with SAML identity assertions).+
6	Record Treatment, Payment, and Health Care Operations Disclosures	The date, time, patient identification (name or number), user identification (name or number), and a description of the disclosure must be recorded.+

3. Adopted Implementation Specifications

Pursuant to section 3004 of the PHSA, the Secretary is required to adopt implementation specifications in addition to standards and certification criteria. Implementation specifications, which for HIPAA covered transaction standards are found in implementation guides, provide specific configuration instructions and constraints for implementing a particular standard or set of standards. Because some standards can be implemented in several different ways, these specifications are critical in some cases to make interoperability a reality—simply using a standard does not necessarily guarantee interoperability.

Standards Development Organizations (SDOs), HITSP, and others have developed implementation specifications with varying degrees of specificity, which in turn have resulted in varying degrees of interoperability. In some cases, the standards used in the NHIN, for example, have been constrained even further and resulted in a narrow and unique set of implementation specifications, designed for a specific architecture and well-defined exchange. Based on input from HIT Standards Committee, we understand that very few implementation specifications are widely used and most are immature or too architecturally specific for adoption by large segments of the HIT industry before meaningful use Stage 2.

Given the importance of implementation specifications and the analyses and field testing necessary to refine them, we do not believe, with the exception of the few mentioned below, that there are mature implementation specifications ready to adopt to support meaningful use Stage 1. We seek public comment on whether there are in fact implementation specifications that are industry-tested and would not present a significant burden if they were adopted. We believe that certain exchange purposes such as electronic prescribing and laboratory test results, already have available some of the most mature implementation specifications. We will consider adopting implementation specifications, though, for any or all adopted standards provided that there is convincing evidence submitted in public comment of the specifications' maturity and widespread usage.

We have adopted a certification criterion requiring that Certified EHR Technology be capable of using the standard, CMS PQRI 2008 Registry XML Specification, for quality reporting. We have also adopted as the implementation specifications for this standard, the Physician Quality Reporting Initiative Measure Specifications Manual for Claims and Registry. Additionally, as we noted above we have adopted standards that require Certified EHR Technology to be capable of using applicable HIPAA transaction standards adopted by HHS for eligibility for health plan transactions and for health care claims or equivalent encounter information transactions. In so doing, the specific HIPAA standards and “implementation specifications” associated with these covered transactions have also been adopted. As a supporting implementation specification for the eligibility for health plan transactions HIPAA transaction standard we have also adopted the requirements of Phase 1 of the Council for Affordable Quality Healthcare (CAQH) Committee on Operating Rules for Information Exchange (CORE). We request public comment on the HIT industry's experience using CAQH CORE Phase 1 with adopted HIPAA transactions standards.

Finally, in preparing to adopt future implementation specifications to support meaningful use Stage 2, ONC plans to work with the HIT industry and solicit input from relevant Federal advisory committees to obtain further specificity in the area of implementation specifications. We also encourage SDOs to make widely available implementation specifications that can be tested and adopted by the Secretary in the future.

4. Additional Considerations, Clarifications, and Requests for Public Comments

a. Relationship to Other Federal Laws

Nothing required by this interim final rule should be construed as affecting existing legal requirements under other Federal laws. While the capabilities provided by Certified EHR Technology may assist in the compliance with certain legal requirements, they do not in any way remove or alter those requirements. For example, Certified EHR Technology may be able to assist health care providers required to comply with the Confidentiality of Alcohol and Drug Abuse Patient Records Regulation, 42 CFR Part 2, but it may not provide, from a technical perspective, all of the capabilities necessary to comply with these regulations. As another example, in providing patients with access to their online health information, it is important to note that the accessibility requirements of the Americans with Disabilities Act of 1990 and Section 504 of the Rehabilitation Act of 1973 still apply to entities covered by these Federal civil rights laws. Additionally, Title VI of the Civil Rights Act of 1964 and its implementing regulations protect persons from unlawful discrimination on the basis of race, color and national origin. Under Title VI and its implementing regulations, recipients of Federal financial assistance must take reasonable steps to ensure meaningful access to their programs, services, and activities by eligible limited English proficient persons.

b. Human Readable Format

As acknowledged in prior sections of this interim final rule, the initial set of adopted standards, implementation specifications, and certification criteria are only the beginning of what we expect will be an incremental approach to enhance the interoperability, functionality, and utility of health information technology. We believe that in order to recognize the enormous potential of HIT, greater standardization in future years is necessary. In that regard, we recognize that more advanced interoperability requires health information to be represented by specific vocabularies and code sets that can be interpreted by EHR technology as well as converted and presented in a readable format to the users of such technology. At the present time we recognize that implementing certain vocabularies and code sets in EHR technology is a difficult, technical undertaking. For that reason, we have not adopted specific vocabularies and code sets for a number of the exchange purposes identified above in Table 2A. We have, however, as a transitional step, adopted certification criteria that require Certified EHR Technology to be capable of presenting health information received in human readable format. By human readable format, we mean a format that enables a human to read and easily comprehend the information presented to them regardless of the method of presentation (e.g., computer screen, handheld device, electronic document). This would likely require information in coded or machine readable format to be converted to, for example, its narrative English language description. In an effort to further the transition to, and prevalence of, more specific vocabularies and code sets, we are interested in public comment regarding industry readiness if we were to adopt certification criteria requiring the use of additional vocabularies and code sets in parallel with meaningful use Stage 2. Such certification criteria could include not only that Certified EHR Technology be capable of presenting information in human readable format but also that it be capable of automatically incorporating certain vocabulary or code sets (i.e., machine readable information).

c. Certification Criterion and Standard Regarding Accounting of Disclosures

Section 3004(b)(1) of the PHSA requires the Secretary to adopt a standard and certification criterion in this interim final rule that are consistent with section 3002(b)(2)(B)(iv) (pertaining to technologies that, as part of a Qualified EHR, allow for an accounting of disclosures made by a HIPAA covered entity for purposes of treatment, payment, and health care operations). This requirement is parallel to section 13405(c) of the HITECH Act, which requires the Secretary 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 now 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. In promulgating these regulations, the Secretary is instructed to “only require such information to be collected through an electronic health record in a manner that takes into account the interests of the individuals in learning the circumstances under which their protected health information is being disclosed and takes into account the administrative burden of accounting for such disclosures.” Unless modified by the Secretary, the effective date ^[19] for HIPAA covered entities that have acquired an electronic health record after January 1, 2009, is January 1, 2011, or anytime after this date when they acquire an electronic health record.

We intend for our adoption of a basic certification criterion and standard to account for disclosures (§ 170.302(v) and § 170.210(e), respectively) to provide a technical foundation for the information that the Secretary will subsequently determine should be collected for treatment, payment and health care operations disclosures. We have adopted a basic certification criterion that requires the capability to record disclosures (as defined by the HIPAA Privacy Rule) made for treatment, payment, and health care operations in accordance with the standard we have adopted. The standard specified in Table 2B above stipulates a functional requirement that a recorded disclosure for treatment, payment, or health care operations must include: The date, time, patient identification (name or number), user identification (name or number), and a description of the disclosure. We believe date, time, patient identification, and user identification are all readily available data because it is the same information required in the standard for an audit log. We have also included the requirement that a “description of the disclosure” must be recorded; however, we have not required any additional specificity for what should be included in the “description,” because the Secretary has not yet weighed the interests of individuals with the administrative burden associated with accounting for such disclosures to determine what information shall be collected. The certification criterion and standard in this interim final rule are limited to disclosures for treatment, payment, and health care operations, as those terms are defined at 45 CFR 164.501. This interim final rule does not address the capability of Certified EHR Technology to account for other types of disclosures. We note that a HIPAA covered entity using Certified EHR Technology must continue to account for disclosures in accordance with 45 CFR 164.528, which may require the collection of additional information for disclosures that are not for treatment, payment, or health care operations.

We do not propose additional requirements at this time because we believe that several significant technical challenges will need to be addressed before it is possible to record additional information about disclosures in an efficient manner. For example, we are unaware of any particular technology solution that is capable of automatically recognizing the difference between a “use” and a “disclosure,” as the HIPAA regulations define these terms. Additionally, we are concerned about the amount of electronic storage that will be necessary to record three years worth of information related to treatment, payment, and health care operations disclosures. We welcome public comment, particularly from the HIT developer community, as to these concerns as well as about the technical feasibility of recording other elements of information about a disclosure. We are specifically interested in comments as to the technical feasibility of recording the purpose or reason for the disclosure, to whom the disclosure was made (i.e., recipient), and any other elements that may be beneficial for a patient to know about with respect to their health information.

It is important to note, as discussed above, that the Secretary has the discretion to modify the compliance date for the revised accounting-for-disclosure regulations to as late as 2013 for HIPAA covered entities that acquire electronic health records after January 1, 2009. The Secretary will address the compliance date for accounting for treatment, payment, and health care operations disclosures in a later rulemaking. In the interim, we again note that the standards and certification requirements adopted do not affect a HIPAA covered entity's compliance with the HIPAA Privacy or Security Rules.

As the use of Certified EHR Technology becomes more widespread and technology advances, we believe the ability to account for disclosures will continue to evolve. Accordingly, this first certification criterion and standard for accounting of disclosures is intended as an incremental step, which will be refined as the technology develops and regulatory requirements are issued. We plan to work with the HIT Policy Committee and HIT Standards Committee to receive recommendations regarding the policies that should be established to address these standards and certification criteria requirements and with the HHS Office for Civil Rights to appropriately coordinate the adoption of policies for the accounting of treatment, payment, and health care operations disclosures with the capabilities that Certified EHR Technology must include in the future.

d. Additional Requests for Public Comment

• We are interested in public comments to inform future deliberations on whether specific certification criteria could be adopted to further promote the capabilities Certified EHR Technology should provide with respect to meeting the accessibility needs of individuals with disabilities.
• We are also interested in public comments to inform future deliberations on whether specific certification criteria could be adopted to further promote the capabilities Certified EHR Technology should provide with respect to the prevention and detection of potential fraud, waste, and abuse.
• We are interested in public comment regarding the “candidate standards to support meaningful use Stage 2” listed in Table 2A. We are specifically interested in feedback regarding implementation feasibility, maturity, and prevalence in the industry.

IV. Collection of Information Requirements

This interim final rule contains no new information collection requirements subject to review by the OMB under the Paperwork Reduction Act (PRA). The HITECH Act establishes new information collection requirements, but those information collection requirements are addressed by other regulatory and programmatic activities (e.g., the Medicare and Medicaid EHR Incentive Programs Proposed Rule).

The HITECH Act applies through Section 13111(b) to “federal information collection activities.” The HITECH Act states that “with respect to a standard or implementation specification adopted under section 3004 of the Public Health Service Act, as added by section 13101, the President shall take measures to ensure that Federal activities involving the broad collection and submission of health information are consistent with such standard or implementation specification, respectively, within three years after the date of such adoption.” Standards adopted in this interim final rule may affect how Federal agencies collect information in the future; however, the potential implications of this requirement will largely depend on actions taken by the Executive Office of the President, including how it interprets the terms “consistent,” “broad,” and “health information.” We welcome comments on the potential for standards and implementation specifications adopted in this regulation to change the way information is collected by Federal agencies. We will share such comments with the OMB.

V. Regulatory Impact Analysis

A. Introduction

We have examined the impacts of this rule as required by Executive Order 12866 on Regulatory Planning and Review (September 30, 1993, as further amended), the Regulatory Flexibility Act (RFA) (5 U.S.C. 601 et seq.), section 202 of the Unfunded Mandates Reform Act of 1995 (2 U.S.C. 1532) (UMRA), Executive Order 13132 on Federalism (August 4, 1999), and the Congressional Review Act (5 U.S.C. 804(2)).

Executive Order 12866 directs agencies to assess all costs and benefits of available regulatory alternatives and, if regulation is necessary, to select regulatory approaches that maximize net benefits (including potential economic, environmental, public health and safety effects, distributive impacts, and equity). A regulatory impact analysis (RIA) must be prepared for major rules with economically significant effects ($100 million or more in any one year). We have determined that this interim final rule is not an economically significant rule because we estimate that the costs to prepare Complete EHRs and EHR Modules to be tested and certified will be less than $100 million per year. Nevertheless, because of the public interest in this interim final rule, we have prepared an RIA that to the best of our ability presents the costs and benefits of the interim final rule. We request comments on the economic analysis provided in this interim final rule with comment.

The RFA requires agencies to analyze options for regulatory relief of small businesses if a rule has a significant impact on a substantial number of small entities. For more information on Small Business Administration's (SBA's) size standards, see the SBA's Web site.^[20] Although the RFA only requires an initial regulatory flexibility analysis (IRFA) when an agency issues a proposed rule, HHS has a policy of voluntarily conducting an IRFA for interim final regulations. We examine the burden of the interim final regulation in Section V.D below.

Section 202 of the UMRA also requires that agencies assess anticipated costs and benefits before issuing any rule whose mandates require spending in any one year of $100 million in 1995 dollars, updated annually for inflation. In 2009, that threshold is approximately $133 million. This rule will not impose an unfunded mandate on States, tribal government or the private sector of more than $133 million annually.

Executive Order 13132 establishes certain requirements that an agency must meet when it promulgates a proposed rule (and subsequent final rule) that imposes substantial direct costs of compliance on State and local governments, preempts State law, or otherwise has Federalism implications. We do not believe that our interim final rule imposes substantial direct compliance costs on State and local governments, preempts State law, or otherwise has Federalism implications.

B. Why Is This Rule Needed?

Section 3004(b)(1) of the PHSA requires the Secretary to adopt an initial set of standards, implementation specifications, and certification criteria by December 31, 2009. Certification criteria and associated standards and implementation specifications will be used to test and certify Complete EHRs and EHR Modules in order to make it possible for eligible professionals and eligible hospitals to adopt and implement Certified EHR Technology. The use of Certified EHR Technology is one of the requirements an eligible professional or eligible hospital needs to meet in order to qualify for an incentive payment under the Medicare and Medicaid EHR Incentive Programs.

C. Costs and Benefits

Throughout the following analysis we invite comments on specific portions of our analysis. The public, however, is invited to offer comments on any and all elements of the analysis and the assumption underlying the analysis.

1. Costs

This interim final rule is one of three coordinated rulemakings (the other two being the Medicare and Medicaid EHR Incentive Programs proposed rule and the HIT Certification Programs proposed rule) undertaken to implement the goals and objectives of the HITECH Act related to the adoption and meaningful use of Certified EHR Technology. Each rule's preamble contains a RIA section. While there is no bright line that divides the effects of this interim final rule and the other two noted above, we believe that each analysis properly focuses on the direct effects of the provisions it creates. This interim final rule estimates the costs commercial vendors, open source developers, and relevant Federal agencies ^[21] will incur to prepare Complete EHRs and EHR Modules to be tested and certified to adopted standards, implementation specifications, and certification criteria. The Medicare and Medicaid EHR Incentive Programs proposed rule estimates the impacts related to the actions taken by eligible professionals or eligible hospitals to become meaningful users, including purchasing or self-developing Complete EHRs or EHR Modules. The HIT Certification Programs proposed rule estimates the testing and certification costs for Complete EHRs and EHR Modules.

This interim final rule adopts standards, implementation specifications, and certification criteria and consequently establishes the capabilities that Complete EHRs or EHR Modules will need to demonstrate in order to be certified. Due to the fact that the Medicare and Medicaid EHR Incentive Programs require (among other things) that eligible professionals and eligible hospitals use Certified EHR Technology in order to receive incentive payments, we anticipate that commercial vendors and open source developers of Complete EHRs and EHR Modules will respond by preparing such technology to meet the certification criteria adopted in this interim final rule. We expect this to occur because commercial vendors and open source developers who do not prepare Complete EHRs or EHR Modules to be tested and certified risk losing market share (i.e., eligible professionals and eligible hospitals seeking to achieve meaningful use will not buy Complete EHRs or EHR Modules that cannot outright or when combined with other EHR Modules meet the definition of Certified EHR Technology). It is important to note, however, as discussed in section 3001(c)(5)(A) of the PHSA, that Congress intended for the act of preparing for and subsequently seeking the certification of a Complete EHR or EHR Module to be voluntary.

As we discuss above, our analysis only focuses on the direct effects of the provisions created by this interim final rule. As a result, we only include estimates for the costs commercial vendors, open source developers, and relevant Federal agencies may incur to prepare Complete EHRs or EHR Modules to be tested and certified. We do not include in this analysis the costs to eligible professionals and eligible hospitals that choose to: (1) Purchase new Certified EHR Technology, or (2) self-develop or modify their current, HIT to become meaningful users. These costs are addressed in the Medicare and Medicaid EHR Incentive Programs proposed rule because they are directly related to the actions taken by eligible professionals or eligible hospitals to become meaningful users. Additionally, the cost for Complete EHRs and EHR Modules to be tested and certified is addressed in the HIT Certification Programs proposed rule and not in this interim final rule.

In conducting research to inform the estimates we make below we found several websites that listed, in an aggregate format, different types of Complete EHRs and EHR Modules designed for various types of health care providers as well as those that were designed primarily for specialists. Based on our research, we believe it is reasonable to assume that a few hundred unique Complete EHRs and EHR Modules make up the available universe of HIT for health care providers, including eligible professionals and eligible hospitals. This estimate includes within it specialty and other niche HIT that are not the intended focus of this interim final rule. While certain certification criteria may be applicable to these other types of HIT, the Secretary has not adopted a specific or complete set of certification criteria for them at this time. Therefore, our estimates for the impacts of this interim final rule solely focus on what we believe will be the likely amount of Complete EHRs and EHR Modules that are prepared to be tested and certified and how much that preparation will cost.

We have analyzed previously developed CCHIT ambulatory and inpatient certification criteria and believe that many, but not all, require the exact same capabilities required by the respective certification criteria adopted by the Secretary at 45 CFR 170.302, 45 CFR 170.304, and 45 CFR 170.306. Generally speaking, we believe this overlap includes most of the clinically oriented capabilities required by the certification criteria adopted by the Secretary. Accordingly, with respect to this impact analysis, we believe that a significant number of previously CCHIT-certified-EHRs will only incur moderate costs to prepare for certification. We assume, for the purposes of creating reasonable estimates, that previously CCHIT-certified-EHRs are similar to our definition of a Complete EHR. As a result, we have based our estimates in Table 3 with the expectation that these previously CCHIT-certified-EHRs will again be prepared for certification as Complete EHRs. To add further specificity to our estimates, we understand, according to CCHIT's Web site, there are 74 CCHIT-certified-EHRs that have been certified to its 2008 ambulatory certification criteria and 17 CCHIT-certified-EHRs, that have been certified to its 2007 or 2008 inpatient certification criteria.^{[22 23 24]} Of these 74 and 17 previously CCHIT-certified-EHRs we expect that 90% will be prepared for certification to the certification criteria adopted by the Secretary. We do not believe that it is realistic to assume that 100% of previously CCHIT-certified-EHRs will be prepared for certification for a number of reasons. These reasons include: (1) A recognition that mergers and acquisitions within the marketplace have reduced the number of previously CCHIT-certified-EHRs; (2) that the subsequent resources needed to market and promote Certified EHR Technology may not be available at the present time; and (3) that some previously CCHIT-certified-EHRs will be tested and certified as EHR Modules rather than Complete EHRs. Given these assumptions we have estimated the number of previously CCHIT-certified-EHRs that will be prepared to be tested and certified will be 65 and 15, ambulatory and inpatient, respectively. We also believe it is reasonable to assume that of these 65 and 15, some will require more preparation than others (i.e., we assume that some previously CCHIT-certified-EHRs include more capabilities than what CCHIT tested and certified and may be able to more easily meet the certification criteria adopted by the Secretary). Given this assumption we have created low and high ranges for the cost to prepare previously CCHIT-certified ambulatory and inpatient EHRs.

In creating our low and high ranges for the tables below we assumed based on our analysis of previously developed and required CCHIT certification criteria that certain capabilities (e.g., the capability to maintain a medication list) have been implemented and deployed in HIT to such a large degree that there would be little or no modification required to prepare Complete EHRs or EHR Modules for testing and certification to certain certification criteria. We also assumed that the certification criteria adopted by the Secretary range from relatively simple capabilities (e.g., recording a patient's smoking status) to more sophisticated capabilities (e.g., clinical decision support). As a result, we have made a general assumption that the costs to prepare Complete EHRs and EHR Modules to be tested and certified will vary depending on a number of factors including, but not limited to, whether the Complete EHR or EHR Module: (1) Already includes the capability; (2) includes some aspect of the capability which would need to be updated; (3) does not currently include the capability at all. We believe it is reasonable to estimate that it will cost somewhere between $10,000 and $250,000 per certification criterion to prepare a Complete EHR or EHR Module for testing and certification taking into account the factors identified directly above. We have used this per certification criteria range as the basis for our low and high cost range estimates and for the ease of our calculations assume that the Secretary has adopted approximately 40 certification criteria.

For Table 3 we have made the following assumptions: (1) In general, previously CCHIT-certified-EHRs will need additional preparation to be tested and certified to 25% of the certification criteria adopted by the Secretary; (2) the average low and high per certification criterion cost for previously CCHIT-certified ambulatory EHRs to be prepared to be tested and certified will be $50,000 and $150,000, respectively; and (3) the average low and high per certification criterion cost for previously CCHIT-certified inpatient EHRs to be prepared to be tested and certified will be $75,000 and $200,000, respectively.

Table 3—Estimated One-Time Costs for Previously CCHIT-Certified-EHRs To Be Prepared To Be Tested and Certified as Complete EHRs (3-Year Period)—Totals Rounded

Type	Number prepared for certification	One time cost per EHR ($M)			Total cost for all EHRs over 3-year period ($M)
		Low	High	Mid-point	Low	High	Mid-point
2008 Ambulatory CCHIT-Certified-EHR	65	$0.50	$1.5	$1.0	$32.5	$97.5	$65.0
2007/2008 Inpatient CCHIT-Certified-EHR	15	0.75	2.0	1.38	11.25	30.0	20.63
Total	80				43.75	127.50	85.63

The second type of cost we estimate includes the costs that we expect for CCHIT-certified ambulatory EHRs certified prior to 2008 (“out-of-date CCHIT-Certified-EHRs”) and never previously CCHIT-certified-EHRs to be prepared to be tested and certified as Complete EHRs rather than being prepared to be tested and certified as an EHR Module.^[25] We assume the EHR technology that falls into this category may require more extensive changes than previously CCHIT-certified-EHRs identified in Table 3. Again, we have estimated low and high preparation cost ranges. We assume that there will be very little growth in the Complete EHR market due to the market share ^[26] represented by the previously CCHIT-certified-EHRs included in Table 3 and the upfront costs required to bring a Complete EHR to market. As a result, we expect there to be 8 and 5 Complete EHRs (for use by eligible professionals and eligible hospitals, respectively) prepared to be tested and certified to all of the applicable certification criteria adopted by the Secretary.^[27]

Again, using our general assumptions discussed above (40 certification criteria and a low and high range of $10,000 to $250,000 per certification criterion) we have made the following assumptions in our Table 4 calculations: (1) In general, out-of-date CCHIT-Certified-EHRs and never previously CCHIT-certified-EHRs will need additional preparation to be tested and certified to 60% of the certification criteria adopted by the Secretary; (2) the average low and high per certification criterion cost for Complete EHRs for eligible professionals to be prepared to be tested and certified will be $50,000 and $150,000, respectively; and (3) the average low and high per certification criterion cost for Complete EHRs for eligible hospitals to be prepared to be tested and certified will be $75,000 and $200,000, respectively.

Table 4—Estimated One-Time Costs for Never CCHIT-Certified-EHRs and Out-of-Date CCHIT-Certified-EHRs To Be Prepared To Be Tested and Certified as Complete EHRs (3-Year Period)—Totals Rounded

Type	Number prepared for certification	One time cost per EHR ($M)			Total cost for all EHRs over 3-year period ($M)
		Low	High	Mid-point	Low	High	Mid-point
Complete EHRs for Eligible Professionals	8	$1.2	$3.6	$2.4	$9.6	$28.8	$19.2
Complete EHRs for Eligible Hospitals	5	1.8	4.8	3.3	9.0	24.0	16.5
Total	13				18.60	52.80	35.70

Finally, the third type of cost we estimate relates to the number of EHR Modules we expect to be prepared to be tested and certified and the costs associated with that preparation. As discussed above, we believe over time that EHR Modules will play an increasingly important role in improving the capabilities available to eligible professionals and eligible hospitals. It is also our belief that EHR Modules will lead to a more innovative and competitive marketplace. We believe that during meaningful use Stage 1, approximately seven types of EHR Modules will be practical given the current state of the HIT marketplace. We assume that EHR Modules will most likely be prepared to be tested and certified to provide the following types of capabilities: Electronic prescribing; administrative transactions; core clinical capabilities; computerized provider order entry; quality reporting; online patient portals; and interfacing with a health information organization to enable the electronic exchange of health information.

Generally speaking, of the available universe of HIT developers we assume that a small percentage will prepare the previously mentioned types of EHR Modules for certification prior to the beginning of meaningful use Stage 2 (i.e., between 2010 and 2012). Furthermore, we assume during meaningful use Stage 1 there will be on average 7 EHR Modules prepared to be tested and certified for each type of EHR Module described above. As a result we estimate that there will be approximately 50 EHR Modules (number of modules X types of modules) prepared to be tested and certified. Again, we have provided low and high preparation cost estimates in Table 5 below. We assume that some of EHR Modules prepared for certification will be capable of meeting applicable certification criteria with little modification while other EHR Modules may not. Given the potential differences in preparation costs and combinations of certification criteria to create EHR Modules we believe it is reasonable to estimate a wide range for the costs to prepare these types of EHR modules for testing and certification.

Table 5—Estimated One-Time Costs to Prepare EHR Modules for Certification to Applicable Adopted Certification Criteria (3-Year Period)—Totals Rounded

Type	Number prepared	One time cost per EHR module ($M)			Total cost all EHR modules over 3-year period
		Low	High	Mid-point	Low	High	Mid-point
EHR Modules	50	$0.1	$0.5	$0.3	$5.0	$25.0	$15.0
Total	50				5.0	25.0	15.0

We invite comments on the number of commercial vendors and open source developers of Complete EHRs or EHR Modules that make up the marketplace and the number of Complete or EHR Modules that will be prepared for testing and certification. Because many of the adopted standards and implementation specifications are already in widespread use and because many of the adopted certification criteria require core capabilities that already exist in the marketplace today we believe that the costs incurred as a result of voluntary actions by the private sector to prepare for certification will be modest. We welcome comments on our estimates above.

In total, if we were to distribute the costs to prepare Complete EHRs and EHR Modules between 2010 and 2012 evenly per year we believe they would likely be in the range of $67.35 to $205.3 million or $22.45 to $68.43 million per year with an annual cost mid-point of approximately about $45.44 million. However, we do not believe that the costs will be spread evenly over these three years due to market pressures and the fact that higher upfront incentive payments are available under the Medicare and Medicaid EHR Incentive Programs. We assume this factor will motivate a greater ratio of commercial vendors and open source developers of Complete EHRs and EHR Modules to prepare such technology for testing and certification in 2010 and 2011 rather than 2012. We also assume that it will generally take 6 to 18 months for commercial vendors and open source developers of Complete EHRs and EHR Modules to prepare for testing and certification. As a result, we believe as represented in Table 6 that the costs attributable to this interim final rule will be distributed as follows: 45% for 2010, 40% for 2011 and 15% for 2012.

Table 6—Distributed Total Preparation Costs (3-Year Period)—Totals Rounded

Year	Ratio (percent)	Total low cost estimate ($M)	Total high cost estimate ($M)	Total average cost estimate ($M)
2010	45	$30.31	$92.39	$61.35
2011	40	26.94	82.12	54.53
2012	15	10.10	30.80	20.45
3-Year Totals		67.35	205.3	136.33

Note that these cost estimates do not include additional costs to prepare for testing and certification that will likely be incurred when we adopt additional standards, implementation specifications, and certification criteria to support meaningful use Stages 2 and 3. We will account for costs associated with these additional standards, implementation specifications, and certification criteria in future rulemaking.

2. Benefits

We believe that there will be several benefits from this interim final rule. By adopting this initial set, the Secretary will set in motion what we believe will be an iterative process to further enhance the interoperability, functionality, utility, and security of health information technology and to support its meaningful use. The capabilities required by adopted certification criteria will help arm health care providers with tools to improve patient care, reduce medical errors and unnecessary tests. The standards adopted will aid in fostering greater interoperability. We also believe that this interim final rule will be a catalyst for a more competitive and innovative marketplace. Finally, adopted certification criteria can be used by commercial vendors and open source developers of Complete EHRs and EHR Modules as technical requirements to ensure that their HIT can be tested and certified and subsequently adopted and implemented as Certified EHR Technology by eligible professionals and eligible hospitals to help them qualify for incentive payments under Medicare and Medicaid EHR Incentive Programs.

D. Regulatory Flexibility Act Analysis

The RFA requires agencies to analyze options for regulatory relief of small businesses if a rule has a significant impact on a substantial number of small entities. As noted above, although the RFA only requires an initial regulatory flexibility analysis when an agency issues a proposed rule, HHS has a policy of voluntarily conducting an initial regulatory flexibility analysis for interim final regulations.

We are implementing this interim final rule as required by section 3004(b)(1) of the PHSA. The objective of the interim final rule is for the Secretary to adopt an initial set of standards, implementation specifications, and certification criteria for HIT.

While commercial vendors and open source developers of Complete EHRs and EHR Modules represent a small segment of the overall information technology industry, we believe that the entities impacted by this interim final rule most likely fall under the North American Industry Classification System (NAICS) code 541511 “Custom Computer Programming Services” specified at 13 CFR 121.201 where the SBA publishes “Small Business Size Standards by NAICS Industry.” The size standard associated with this NAICS code is set at $25 million in annual receipts ^[28] which “indicates the maximum allowed for a concern and its affiliates to be considered small entities.”

Based on our analysis, we believe that a handful of multinational corporations and many national or regional businesses represent a significant majority of the potential Complete EHR and EHR Module developers and that many, if not all, exceed the specified SBA size standard. We make this assumption based on our understanding of the upfront investments necessary to develop and market HIT in a competitive marketplace as well as the upgrade and product modification costs that these businesses incur to stay competitive. However, we note, and request public comment on, the following constraint encountered during our analysis. With the exception of aggregate business information available through the U.S. Census Bureau and the SBA related to NAICS code 541511, it appears that many commercial vendors and open source developers of Complete EHRs and EHR Modules are privately held or owned and do not regularly, if at all, make their specific annual receipts publicly available. As a result, it is difficult at the present time to locate empirical data related to many of the commercial vendors and open source developers of Complete EHRs and EHR Modules to correlate to the SBA size standard. We therefore request public comment on any additional information regarding the business size of commercial vendors and open source developers of Complete EHRs and EHR Modules in the HIT marketplace to help inform our analysis.

Given the discussion above, we estimate that this interim final rule will have effects on commercial vendors and open source developers of Complete EHRs and EHR Modules, some of which may be small entities. However, we do not believe that the interim final rule will create a significant economic impact on a substantial number of these entities, regardless of size. The Secretary certifies that this interim final rule will not have a significant impact on a substantial number of small entities.

E. Executive Order 13132—Federalism

Executive Order 13132 establishes certain requirements that an agency must meet when it promulgates a proposed rule (and subsequent final rule) that imposes substantial direct requirement costs on State and local governments, preempts State law, or otherwise has federalism implications.

Nothing in this interim final rule imposes substantial direct requirement costs on State and local governments, preempts State law or otherwise has federalism implications. We are not aware of any State laws or regulations that are contradicted or impeded by any of the standards, implementation specifications, or certification criteria that have been adopted. This interim final rule with comment period affords all States an opportunity to identify any problems that our standards, implementation specifications, and certification criteria would create, and to propose constructive alternatives. We welcome comments from State and local governments.

F. Unfunded Mandates Reform Act of 1995

Title II of the Unfunded Mandates Reform Act of 1995 (Pub. L. 104-4) requires cost-benefit and other analyses before any rulemaking if the rule includes a “Federal mandate that may result in the expenditure by State, local, and tribal governments, in the aggregate, or by the private sector, of $100,000,000 or more (adjusted annually for inflation) in any 1 year.” The current inflation-adjusted statutory threshold is approximately $130 million. The Department has determined that this rule would not constitute a significant rule under the Unfunded Mandates Reform Act, because it would impose no mandates.

The Office of Management and Budget reviewed this interim final rule with comment period.

List of Subjects in 45 CFR Part 170

• Computer technology
• Electronic health record
• Electronic information system
• Electronic transactions
• Health
• Health care
• Health information technology
• Health insurance
• Health records
• Hospitals
• Incorporation by reference
• Laboratories
• Medicaid
• Medicare
• Privacy
• Reporting and recordkeeping requirements
• Public health
• Security

For the reasons set forth in the preamble, the Department amends 45 CFR subtitle A to add subchapter D as follows:

SUBCHAPTER D—HEALTH INFORMATION TECHNOLOGY

PART 170—HEALTH INFORMATION TECHNOLOGY STANDARDS, IMPLEMENTATION SPECIFICATIONS, AND CERTIFICATION CRITERIA AND CERTIFICATION PROGRAMS FOR HEALTH INFORMATION TECHNOLOGY

Subpart A—General Provisions

170.100

Statutory basis and purpose.

170.101

Applicability.

170.102

Definitions.

Subpart B—Standards and Implementation Specifications for Health Information Technology

170.200

Applicability.

170.202

Transport standards for exchanging electronic health information.

170.205

Content exchange and vocabulary standards for exchanging electronic health information.

170.210

Standards for health information technology to protect electronic health information created, maintained, and exchanged.

170.299

Incorporation by reference.

Subpart C—Certification Criteria for Health Information Technology

170.300

Applicability.

170.302

General certification criteria for Complete EHRs or EHR Modules.

170.304

Specific certification criteria for Complete EHRs or EHR Modules designed for an ambulatory setting.

170.306

Specific certification criteria for Complete EHRs or EHR Modules designed for an inpatient setting.

Authority: 42 U.S.C 300jj-14; 5 U.S.C. 552.

Subpart A—General Provisions

§ 170.100

Statutory basis and purpose.

The provisions of this subchapter implement section 3004 of the Public Health Service Act.

§ 170.101

Applicability.

The standards, implementation specifications, and certification criteria adopted in this part apply to Complete EHRs and EHR Modules and the testing and certification of such Complete EHRs and EHR Modules.

§ 170.102

Definitions.

For the purposes of this part:

Certification criteria means 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.

Certified EHR Technology means 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.

Complete EHR means EHR technology that has been developed to meet all applicable certification criteria adopted by the Secretary.

Disclosure means the release, transfer, provision of access to, or divulging in any other manner of information outside the entity holding the information.

EHR Module means any service, component, or combination thereof that can meet the requirements of at least one certification criterion adopted by the Secretary.

Implementation specification means specific requirements or instructions for implementing a standard.

Qualified EHR means an electronic record of health-related information on an individual that:

(1) Includes patient demographic and clinical health information, such as medical history and problem lists; and

(2) 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.

Standard means a technical, functional, or performance-based rule, condition, requirement, or specification that stipulates instructions, fields, codes, data, materials, characteristics, or actions.

Subpart B—Standards and Implementation Specifications for Health Information Technology

§ 170.200

Applicability.

The standards and implementation specifications adopted in this part apply with respect to Complete EHRs and EHR Modules. When a section of this part includes adoption of both a standard and at least one alternative standard, use of the specified standard or alternatives will be considered compliant.

§ 170.202

Transport standards for exchanging electronic health information.

The Secretary adopts the following standards to define the common transport methods that must be used to electronically exchange health information formatted in accordance with the standards adopted under § 170.205.

(a) Standard. The Organization for the Advancement of Structured Information Standards (OASIS) Simple Object Access Protocol (SOAP) Version 1.2 (incorporated by reference in § 170.299).

(b) Alternative standard. A stateless, client-server, cacheable communications protocol that adheres to the principles of Representational State Transfer (REST) must be used.

§ 170.205

Content exchange and vocabulary standards for exchanging electronic health information.

(a) Patient summary record.

(1) The Secretary adopts the following content exchange standards for the purposes of electronically exchanging a patient summary record or to use in creating an electronic copy of a patient summary record:

(i) Standard. Health Level Seven Clinical Document Architecture (CDA) Release 2, Level 2 Continuity of Care Document (CCD) (incorporated by reference in § 170.299).

(ii) Alternative standard. ASTM E2369 Standard Specification for Continuity of Care Record and Adjunct to ASTM E2369 (incorporated by reference in § 170.299).

(2) The Secretary adopts the following vocabulary standards for the purposes of specifying the code set, terminology, or nomenclature to use to represent health information included in a patient summary record:

(i) Problem list.

(A) Standard. The code set specified for the conditions specified at 45 CFR 162.1002(a)(1).

(B) Alternative standard. International Health Terminology Standards Development Organization (IHTSDO) Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT®) July 2009 version (incorporated by reference in § 170.299).

(ii) Procedures.

(A) Standard. The code set specified at 45 CFR 162.1002(a)(2).

(B) Alternative standard. The code set specified at 45 CFR 162.1002(a)(5).

(iii) Laboratory orders and results.

(A) Standard. Logical Observation Identifiers Names and Codes (LOINC®) version 2.27, when such codes were received within an electronic transaction from a laboratory (incorporated by reference in § 170.299).

(B) [Reserved]

(iv) Medication list.

(A) Standard. Any code set by an RxNorm drug data source provider that is identified by the United States National Library of Medicine as being a complete data set integrated within RxNorm.

(B) [Reserved]

(b) Drug formulary check. The Secretary adopts the following content exchange standard for transmitting formulary and benefits information between prescribers and Medicare Part D sponsors.

(1) Standard. Drug formulary and benefits information must be transmitted in accordance with 42 CFR 423.160(b)(5).

(2) [ Reserved]

(c) Electronically transmitting prescription information.

(1) The Secretary adopts the following content exchange standard to provide for the transmission of a prescription or prescription-related information.

(i) Standard. An electronic prescription for a Medicare Part D covered drug that is prescribed for a Medicare Part D eligible individual must be transmitted in accordance with 42 CFR 423.160(b)(2)(ii), in all other circumstances, if consistent with applicable state and other Federal law, electronic prescriptions may be transmitted in accordance with 42 CFR 423.160(b)(2)(ii) or using the NCPDP SCRIPT Standard, Implementation Guide, Version 10.6 (incorporated by reference in § 170.299).

(ii) [ Reserved]

(2) The Secretary adopts the following vocabulary standard for the purposes of specifying the code set to use to represent health information included in electronic prescriptions.

(i) Standard. Any code set by an RxNorm drug data source provider that is identified by the United States National Library of Medicine as being a complete data set integrated within RxNorm.

(ii) [ Reserved]

(d) Electronically exchange administrative transactions. The Secretary adopts the following content exchange standards and associated implementation specifications for the following electronic transactions.

(1) Standard and implementation specifications. An eligibility for a health plan transaction as defined at 45 CFR 162.1201 must be conducted in accordance with:

(i) 45 CFR 162.1202(b) or for the period on and after January 1, 2012, in accordance with 45 CFR 162.1202(c); and

(ii) The operating rules specified in Phase 1 of the Council for Affordable Quality Healthcare (CAQH) Committee on Operating Rules for Information Exchange (CORE) (incorporated by reference in § 170.299).

(2) Standard and implementation specifications. Eligibility inquiry and response transactions between dispensers and Part D sponsors for Part D prescription drugs must be conducted in accordance with 42 CFR 423.160(b)(3)(ii).

(3) Standard and implementation specifications. A health care claims or equivalent encounter information transaction as defined at 45 CFR 162.1101 must be conducted in accordance with 45 CFR 162.1102(b) or for the period on and after January 1, 2012, in accordance with 45 CFR 162.1102(c).

(e) Electronically exchange quality reporting information. The Secretary adopts the following content exchange standard and implementation specification for quality reporting.

(1) Standard. The CMS Physician Quality Reporting Initiative (PQRI) 2008 Registry XML Specification (incorporated by reference in § 170.299).

(2) Implementation specification. Physician Quality Reporting Initiative Measure Specifications Manual for Claims and Registry (incorporated by reference in § 170.299).

(f) Electronic submission of lab results to public health agencies.

(1) The Secretary adopts the following content exchange standard for the electronic submission of lab results to public health agencies.

(i) Standard. HL7 2.5.1(incorporated by reference in § 170.299).

(ii) [ Reserved]

(2) The Secretary adopts the following vocabulary standard for the purposes of representing lab results in an electronic submission to public health authorities.

(i) Standard. Logical Observation Identifiers Names and Codes (LOINC®), version 2.27, when such codes were received within an electronic transaction from a laboratory (incorporated by reference in § 170.299).

(ii) [ Reserved]

(g) Electronic submission to public health agencies for surveillance or reporting. The Secretary adopts the following content exchange standards for electronic submission to public health agencies for surveillance or reporting:

(1) Standard. HL7 2.3.1 (incorporated by reference in § 170.299).

(2) Alternative standard. HL7 2.5.1 (incorporated by reference in § 170.299).

(h) Electronic submission to immunization registries.

(1) The Secretary adopts the following content exchange standards for electronic submission to immunization registries:

(i) Standard. HL7 2.3.1 (incorporated by reference in § 170.299).

(ii) Alternative standard. HL7 2.5.1 (incorporated by reference in § 170.299).

(2) The Secretary adopts the following vocabulary standard for electronic submissions to immunization registries.

(i) Standard. HL7 Standard Code Set CVX—Vaccines Administered, July 30, 2009 version (incorporated by reference in § 170.299).

(ii) [Reserved]

§ 170.210

Standards for health information technology to protect electronic health information created, maintained, and exchanged.

The Secretary adopts the following standards to protect electronic health information created, maintained, and exchanged:

(a) Encryption and decryption of electronic health information.

(1) General. A symmetric 128 bit fixed-block cipher algorithm capable of using a 128, 192, or 256 bit encryption key must be used.

(2) Exchange. An encrypted and integrity protected link must be implemented.

(b) Record actions related to electronic health information. The date, time, patient identification, and user identification must be recorded when electronic health information is created, modified, deleted, or printed; and an indication of which action(s) occurred must also be recorded.

(c) Verification that electronic health information has not been altered in transit. Standard. A secure hashing algorithm must be used to verify that electronic health information has not been altered in transit. The secure hash algorithm (SHA) used must be SHA-1 or higher.

(d) Cross-enterprise authentication. A cross-enterprise secure transaction that contains sufficient identity information such that the receiver can make access control decisions and produce detailed and accurate security audit trails must be used.

(e) Record treatment, payment, and health care operations disclosures. The date, time, patient identification, user identification, and a description of the disclosure must be recorded for disclosures for treatment, payment, and health care operations, as these terms are defined at 45 CFR 164.501.

§ 170.299

Incorporation by reference.

(a) Certain material is incorporated by reference into this part with the approval of the Director of the Federal Register under 5 U.S.C. 552(a) and 1 CFR part 51. To enforce any edition other than that specified in this section, the Department of Health and Human Services must publish notice of change in the Federal Register and the material must be available to the public. All approved material is available for inspection at the National Archives and Records Administration (NARA). For information on the availability of this material at NARA, call 202-741-6030 or go to http://www.archives.gov/​federal_​register/​code_​of_​federal_​regulations/​ibr_​locations.html. Also, it is available for inspection at 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 arrange for inspection at 202-690-7151, and is available from the sources listed below.

(b) Organization for the Advancement of Structured Information Standards (OASIS), Post Office Box 455, Billerica, MA 01821, http://www.oasis-open.org/​home/​index.php,, Telephone: [phone].

(1) Simple Object Access Protocol (SOAP), Version 1.2 (Second Edition), parts 0-2, W3C Recommendation April 27, 2007 (SOAP version 1.2), IBR approved for § 170.202.

(i) SOAP version 1.2 PART 0: Primer;

(ii) SOAP version 1.2 PART 1: Messaging Framework; and

(iii) SOAP version 1.2 PART 2: Adjuncts.

(2) [Reserved]

(c) Health Level Seven, 3300 Washtenaw Avenue, Suite 227, Ann Arbor, MI 48104; Telephone [phone] or http://www.hl7.org/​.

(1) Health Level Seven Standard Version 2.3.1 (HL7 2.3.1), An Application Protocol for Electronic Data Exchange in Healthcare Environments, April 14, 1999, IBR approved for § 170.205.

(2) Health Level Seven Messaging Standard Version 2.5.1 (HL7 2.5.1), An Application Protocol for Electronic Data Exchange in Healthcare Environments, February 21, 2007, IBR approved for § 170.205.

(3) Health Level Seven Implementation Guide: Clinical Document Architecture (CDA) Release 2—Level 2 Continuity of Care Document (CCD), April 01, 2007, IBR approved for § 170.205.

(d) ASTM International, 100 Barr Harbor Drive, PO Box C700, West Conshohocken, PA, 19428-2959 USA; Telephone [phone] or http://www.astm.org/​.

(1) ASTM E2369-05: Standard Specification for Continuity of Care Record (CCR), year of adoption 2005, ASTM approved July 17, 2006, IBR approved for § 170.205.

(2) ASTM E2369-05 (Adjunct to E2369): Standard Specification Continuity of Care Record—Final Version 1.0 (V1.0), November 7, 2005, IBR approved for § 170.205.

(e) National Council for Prescription Drug Programs, Incorporated, 9240 E. Raintree Drive, Scottsdale, AZ 85260- 7518; Telephone [phone]; and Facsimile [phone] or http://www.ncpdp.org.

(1) SCRIPT Standard, Implementation Guide, Version 10.6, October, 2008, (Approval date for ANSI: November 12, 2008), IBR approved for § 170.205.

(2) [Reserved]

(f) Council for Affordable Quality Healthcare (CAQH), 601 Pennsylvania Avenue, NW., South Building, Suite 500, Washington, DC 20004; Telephone [phone] or http://www.caqh.org/​CORE_​phase1.php.

(1) Committee on Operating Rules for Information Exchange (CORE) Phase I Eligibility and Benefits Operating Rules Manual, April, 2006, IBR approved for § 170.205.

(2) [Reserved]

(g) Regenstrief Institute, Inc., LOINC® c/o Medical Informatics The Regenstrief Institute, Inc 410 West 10th Street, Suite 2000 Indianapolis, IN 46202-3012; Telephone [phone] or http://loinc.org/​.

(1) Logical Observation Identifiers Names and Codes (LOINC®) version 2.27, June 15, 2009, IBR approved for § 170.205.

(2) [Reserved]

(h) U.S. National Library of Medicine, 8600 Rockville Pike, Bethesda, MD 20894; Telephone [phone] or http://www.nlm.nih.gov/​.

(1) International Health Terminology Standards Development Organization Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT®), International Release, July 2009, IBR approved for § 170.205.

(2) [Reserved]

(i) Centers for Disease Control and Prevention, National Centers for Immunization and Respiratory Diseases Immunization Information System Support Branch—Informatics 1600 Clifton Road Mailstop: E-62 Atlanta, GA 30333.

(1) HL7 Standard Code Set CVX—Vaccines Administered, July 30, 2009, IBR approved for § 170.205.

(2) [Reserved]

(j) Centers for Medicare & Medicaid Services, Office of Clinical Standards and Quality, 7500 Security Boulevard, Baltimore, Maryland 21244; Telephone [phone].

(1) CMS PQRI 2008 Registry XML Specification, December 10, 2008 IBR approved for § 170.205.

(2) 2009 Physician Quality Reporting Initiative Measure Specifications Manual for Claims and Registry, Version 3.0, December 8, 2008 IBR approved for § 170.205.

Subpart C—Certification Criteria for Health Information Technology

§ 170.300

Applicability.

The certification criteria adopted in this subpart apply to the testing and certification of Complete EHRs and EHR Modules.

§ 170.302

General certification criteria for Complete EHRs or EHR Modules.

The Secretary adopts the following general certification criteria for Complete EHRs or EHR Modules. Complete EHRs or EHR Modules must include the capability to perform the following functions electronically and in accordance with all applicable standards and implementation specifications adopted in this part:

(a) Drug-drug, drug-allergy, drug-formulary checks.

(1) Alerts. Automatically and electronically generate and indicate 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 computerized provider order entry (CPOE).

(2) Formulary checks. Enable a user to electronically check if drugs are in a formulary or preferred drug list in accordance with the standard specified in § 170.205(b).

(3) Customization. Provide certain users with administrator rights to deactivate, modify, and add rules for drug-drug and drug-allergy checking.

(4) Alert statistics. Automatically and electronically track, record, and generate reports on the number of alerts responded to by a user.

(b) Maintain up-to-date problem list. Enable a user to electronically record, modify, and retrieve a patient's problem list for longitudinal care in accordance with:

(1) The standard specified in § 170.205(a)(2)(i)(A); or

(2) At a minimum, the version of the standard specified in § 170.205(a)(2)(i)(B).

(c) 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 in accordance with the standard specified in § 170.205(a)(2)(iv).

(d) 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.

(e) Record and chart vital signs.

(1) Vital signs. 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) Calculate body mass index. Automatically calculate and display body mass index (BMI) based on a patient's height and weight.

(3) Plot and display growth charts. Plot and electronically display, upon request, growth charts for patients 2-20 years old.

(f) Smoking status. Enable a user to electronically record, modify, and retrieve the smoking status of a patient. Smoking status types must include: current smoker, former smoker, or never smoked.

(g) Incorporate laboratory test results.

(1) Receive results. Electronically receive clinical laboratory test results in a structured format and display such results in human readable format.

(2) Display codes in readable format. Electronically display in human readable format any clinical laboratory tests that have been received with LOINC® codes.

(3) Display test report information. Electronically display all the information for a test report specified at 42 CFR 493.1291(c)(1) through (7).

(4) Update. Enable a user to electronically update a patient's record based upon received laboratory test results.

(h) Generate patient lists. 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.

(i) Report quality measures.

(1) Display. Calculate and electronically display quality measures as specified by CMS or states.

(2) Submission. Enable a user to electronically submit calculated quality measures in accordance with the standard and implementation specifications specified in § 170.205(e).

(j) Check insurance eligibility. 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 and implementation specifications specified in § 170.205(d)(1) or (2).

(k) Submit claims. Enable a user to electronically submit claims to public or private payers in accordance with the standard and implementation specifications specified in § 170.205(d)(3).

(l) Medication reconciliation. Electronically complete medication reconciliation of two or more medication lists by comparing and merging into a single medication list that can be electronically displayed in real-time.

(m) Submission to immunization registries. Electronically record, retrieve, and transmit immunization information to immunization registries in accordance with:

(1) One of the standards specified in § 170.205(h)(1) and, at a minimum, the version of the standard specified in § 170.205(h)(2); or

(2) The applicable state-designated standard format.

(n) Public health surveillance. Electronically record, retrieve, and transmit syndrome-based public health surveillance information to public health agencies in accordance with one of the standards specified in § 170.205(g).

(o) Access control. 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.

(p) Emergency access. Permit authorized users (who are authorized for emergency situations) to access electronic health information during an emergency.

(q) Automatic log-off. Terminate an electronic session after a predetermined time of inactivity.

(r) Audit log.

(1) Record actions. Record actions related to electronic health information in accordance with the standard specified in § 170.210(b).

(2) Alerts. Provide alerts based on user-defined events.

(3) Display and print. Electronically display and print all or a specified set of recorded information upon request or at a set period of time.

(s) Integrity.

(1) In transit. Verify that electronic health information has not been altered in transit in accordance with the standard specified in § 170.210(c).

(2) Detection. Detect the alteration and deletion of electronic health information and audit logs, in accordance with the standard specified in § 170.210(c).

(t) Authentication.

(1) Local. Verify that a person or entity seeking access to electronic health information is the one claimed and is authorized to access such information.

(2) Cross network. 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 § 170.210(d).

(u) Encryption.

(1) General. Encrypt and decrypt electronic health information according to user-defined preferences in accordance with the standard specified in § 170.210(a)(1).

(2) Exchange. Encrypt and decrypt electronic health information when exchanged in accordance with the standard specified in § 170.210(a)(2).

(v) Accounting of disclosures. Record disclosures made for treatment, payment, and health care operations in accordance with the standard specified in § 170.210(e).

§ 170.304

Specific certification criteria for Complete EHRs or EHR Modules designed for an ambulatory setting.

The Secretary adopts the following certification criteria for Complete EHRs or EHR Modules designed to be used in an ambulatory setting. Complete EHRs or EHR Modules must include the capability to perform the following functions electronically and in accordance with all applicable standards and implementation specifications adopted in this part:

(a) Computerized provider order entry. Enable a user to electronically record, store, retrieve, and manage, at a minimum, the following order types:

(1) Medications;

(2) Laboratory;

(3) Radiology/imaging; and

(4) Provider referrals.

(b) Electronically exchange prescription information. Enable a user to electronically transmit medication orders (prescriptions) for patients in accordance with the standards specified in § 170.205(c).

(c) Record demographics. Enable a user to electronically record, modify, and retrieve patient demographic data including preferred language, insurance type, gender, race, ethnicity, and date of birth.

(d) Generate patient reminder list. 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.

(e) Clinical decision support.

(1) Implement rules. 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.

(2) Alerts. Automatically and electronically generate and indicate in real-time, alerts and care suggestions based upon clinical decision support rules and evidence grade.

(3) Alert statistics. Automatically and electronically track, record, and generate reports on the number of alerts responded to by a user.

(f) Electronic copy of health information. 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) On electronic media or through some other electronic means in accordance with:

(i) One of the standards specified in § 170.205(a)(1);

(ii) The standard specified in § 170.205(a)(2)(i)(A), or, at a minimum, the version of the standard specified in § 170.205(a)(2)(i)(B);

(iii) One of the standards specified in § 170.205(a)(2)(ii);

(iv) At a minimum, the version of the standard specified in § 170.205(a)(2)(iii); and

(v) The standard specified in § 170.205(a)(2)(iv).

(g) Timely access. 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.

(h) Clinical summaries.

(1) Provision. Enable a user to provide clinical summaries to patients for each office visit that include, at a minimum, diagnostic test results, problem list, medication list, medication allergy list, immunizations and procedures.

(2) Provided electronically. If the clinical summary is provided electronically it must be:

(i) Provided in human readable format; and

(ii) On electronic media or through some other electronic means in accordance with:

(A) One of the standards specified in § 170.205(a)(1);

(B) The standard specified in § 170.205(a)(2)(i)(A), or, at a minimum, the version of the standard specified in § 170.205(a)(2)(i)(B);

(C) One of the standards specified in § 170.205(a)(2)(ii);

(D) At a minimum, the version of the standard specified in § 170.205(a)(2)(iii); and

(E) The standard specified in § 170.205(a)(2)(iv).

(i) Exchange clinical information and patient summary record.

(1) Electronically receive and display. Electronically receive a patient's summary record, from other providers and organizations including, at a minimum, diagnostic tests results, problem list, medication list, medication allergy list, immunizations, and procedures in accordance with § 170.205(a) and upon receipt of a patient summary record formatted in an alternate standard specified in § 170.205(a)(1), display it in human readable format.

(2) Electronically transmit. 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:

(i) One of the standards specified in § 170.205(a)(1);

(ii) The standard specified in § 170.205(a)(2)(i)(A), or, at a minimum, the version of the standard specified in § 170.205(a)(2)(i)(B);

(iii) One of the standards specified in § 170.205(a)(2)(ii);

(iv) At a minimum, the version of the standard specified in § 170.205(a)(2)(iii); and

(v) The standard specified in § 170.205(a)(2)(iv).

§ 170.306

Specific certification criteria for Complete EHRs or EHR Modules designed for an inpatient setting.

The Secretary adopts the following certification criteria for Complete EHRs or EHR Modules designed to be used in an inpatient setting. Complete EHRs or EHR Modules must include the capability to perform the following functions electronically and in accordance with all applicable standards and implementation specifications adopted in this part:

(a) Computerized provider order entry. Enable a user to electronically record, store, retrieve, and manage, at a minimum, the following order types:

(1) Medications;

(2) Laboratory;

(3) Radiology/imaging;

(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.

(b) Record demographics. 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.

(c) Clinical decision support.

(1) Implement rules. 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) Alerts. Automatically and electronically generate and indicate in real-time, alerts and care suggestions based upon clinical decision support rules and evidence grade.

(3) Alert statistics. Automatically and electronically track, record, and generate reports on the number of alerts responded to by a user.

(d) Electronic copy of health information. 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, procedures, and discharge summary in:

(1) Human readable format; and

(2) On electronic media or through some other electronic means in accordance with:

(i) One of the standards specified in § 170.205(a)(1);

(ii) The standard specified in § 170.205(a)(2)(i)(A), or, at a minimum, the version of the standard specified in § 170.205(a)(2)(i)(B);

(iii) One of the standards specified in § 170.205(a)(2)(ii);

(iv) At a minimum, the version of the standard specified in § 170.205(a)(2)(iii); and

(v) The standard specified in § 170.205(a)(2)(iv).

(e) Electronic copy of discharge information. 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 on electronic media or through some other electronic means.

(f) Exchange clinical information and summary record.

(1) Electronically receive and display. Electronically receive a patient's summary record from other providers and organizations including, at a minimum, diagnostic test results, problem list, medication list, medication allergy list, immunizations, procedures, and discharge summary in accordance with § 170.205(a) and upon receipt of a patient summary record formatted in an alternate standard specified in § 170.205(a)(1), display it in human readable format.

(2) Electronically transmit. Enable a user to electronically transmit a patient's summary record to other providers and organizations including, at a minimum, diagnostic results, problem list, medication list, medication allergy list, immunizations, procedures, and discharge summary in accordance with:

(i) One of the standards specified in § 170.205(a)(1);

(ii) The standard specified in § 170.205(a)(2)(i)(A), or, at a minimum, the version of the standard specified in § 170.205(a)(2)(i)(B);

(iii) One of the standards specified in § 170.205(a)(2)(ii);

(iv) At a minimum, the version of the standard specified in § 170.205(a)(2)(iii); and

(v) The standard specified in § 170.205(a)(2)(iv).

(g) Reportable lab results. Electronically record, retrieve, and transmit reportable clinical lab results to public health agencies in accordance with the standard specified in § 170.205(f)(1) and, at a minimum, the version of the standard specified in § 170.205(f)(2).

Dated: December 28, 2009.

Kathleen Sebelius,

Secretary.

Footnotes

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.”

2.  This last definition is referenced in Federal Information Processing Standards 201.

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.”

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.

16.  http://www.whitehouse.gov/​omb/​circulars_​a119.

17.  According to the most recent RxNorm Release Documentation File Full Release (11/2/09) published by the National Library of Medicine, the following RxNorm drug data source providers with a complete data set integrated within RxNorm are identified at the end of section 11.1 located at http://www.nlm.nih.gov/​research/​umls/​rxnorm/​docs/​2009/​rxnorm_​doco_​full11022009.html GS—10/01/2009 (Gold Standard Alchemy); MDDB—10/07/2009 (Master Drug Data Base. Medi-Span, a division of Wolters Kluwer Health); MMSL—10/01/2009 (Multum MediSource Lexicon); MMX—09/28/2009 (Micromedex DRUGDEX); MSH—08/17/2009 (Medical Subject Headings (MeSH)); MTHFDA—8/28/2009 (FDA National Drug Code Directory); MTHSPL—10/28/2009 (FDA Structured Product Labels); NDDF—10/02/2009 (First DataBank NDDF Plus Source Vocabulary); SNOMED CT—07/31/2009 (SNOMED Clinical Terms (drug information) SNOMED International); VANDF—10/07/2009 (Veterans Health Administration National Drug File). We note that FDA Unique Ingredient Identifiers (UNII) are a component of RxNorm.

18.  The CDC's National Center of Immunization and Respiratory Diseases (NCIRD) maintains the HL7 external code set CVX http://www.cdc.gov/​vaccines/​programs/​iis/​stds/​cvx.htm.

19.  See HITECH Act section 13405(c)(4), which also provides that the effective date for HIPAA covered entities that are current users of EHRs (i.e., acquired EHRs as of January 1, 2009) January 1, 2014, unless modified by the Secretary.

20.  http://sba.gov/​idc/​groups/​public/​documents/​sba_​homepage/​serv_​sstd_​tablepdf.pdf.

21.  All Indian Health Service (IHS) facilities and the vast majority of Tribally-operated facilities funded by IHS utilize the Resource and Patient Management System (RPMS), the IHS health information and EHR system that is centrally developed and distributed by the IHS Office of Information Technology. It is our understanding that IHS provides information technology support to over 40 IHS and Tribal hospitals as well as health care providers at approximately 300 ambulatory facilities. The RPMS EHR is designed for both inpatient and ambulatory implementations and it is IHS's goal to remain consistent with the certification criteria adopted by the Secretary. As a result, we expect IHS will the RPMS EHR for testing and certification to applicable adopted certification criteria.

22.  Some are marked with a conditional certification either “Pre-Market: These are conditionally certified EHRs which are new products that are fully certified once their operational use at a physician office site has been verified.” or “eRx Conditional: These are conditionally certified pending advanced ePrescribing EHRs that are in the process of verifying their ability to conduct medication history, formulary and eligibility checking through a national network for electronic-prescribing transactions.” We do not believe that these caveats have any effect on our estimates.

23.  http://www.cchit.org/​products/​Ambulatory—when certification years 2006 and 2007 are unchecked.

24.  http://www.cchit.org/​products/​Inpatient.

25.  CCHIT began testing and certifying inpatient EHRs in 2007 and we assume that all of those EHRs are included in Table 3 which is why they are not included in this discussion.

26.  http://www.cchit.org/​about—“* * * EHR products certified by mid-2009, representing over 75% of the marketplace.”

27.  This estimate includes the fact that IHS's RPMS EHR was not included in Table 1 and that it will be preparing the RPMS EHR as a Complete EHR to meet the applicable certification criteria adopted by the Secretary for both ambulatory and inpatient settings.

28.  The SBA references that annual receipts means “total income” (or in the case of a sole proprietorship, “gross income”) plus “cost of goods sold” as these terms are defined and reported on Internal Revenue Service tax return forms. http://www.sba.gov/​idc/​groups/​public/​documents/​sba_​homepage/​guide_​to_​size_​standards.pdf.