2010-17210

8/13/2019 2010-17210

http://slidepdf.com/reader/full/2010-17210 1/66

Wednesday,

July 28, 2010

Part III

Department ofHealth and HumanServices45 CFR Part 170

Health Information Technology: Initial Setof Standards, ImplementationSpecifications, and Certification Criteriafor Electronic Health Record Technology;Final Rule

VerDate Mar<15>2010 19:21 Jul 27, 2010 Jkt 220001 PO 00000 Frm 00001 Fmt 4717 Sfmt 4717 E:\FR\FM\28JYR3.SGM 28JYR3

8/13/2019 2010-17210


44590 Federal Register / Vol. 75, No. 144 / Wednesday, July 28, 2010 / Rules and Regulations

DEPARTMENT OF HEALTH ANDHUMAN SERVICES

Office of the Secretary

45 CFR Part 170

RIN 0991–AB58

Health Information Technology: Initial

Set of Standards, ImplementationSpecifications, and CertificationCriteria for Electronic Health RecordTechnology

AGENCY: Office of the NationalCoordinator for Health InformationTechnology (ONC), Department ofHealth and Human Services.ACTION: Final rule.

SUMMARY: The Department of Health andHuman Services (HHS) is issuing thisfinal rule to complete the adoption of aninitial set of standards, implementationspecifications, and certification criteria,

and to more closely align suchstandards, implementationspecifications, and certification criteriawith final meaningful use Stage 1objectives and measures. Adoptedcertification criteria establish therequired capabilities and specify therelated standards and implementationspecifications that certified electronichealth record (EHR) technology willneed to include to, at a minimum,support the achievement of meaningfuluse Stage 1 by eligible professionals,eligible hospitals, and/or critical accesshospitals (hereafter, references to‘‘eligible hospitals

’’in this final ruleshall mean ‘‘eligible hospitals and/or

critical access hospitals’’) under theMedicare and Medicaid EHR IncentivePrograms. Complete EHRs and EHRModules will be tested and certifiedaccording to adopted certificationcriteria to ensure that they haveproperly implemented adoptedstandards and implementationspecifications and otherwise complywith the adopted certification criteria.DATES: Effective Date: This final rule iseffective August 27, 2010. Theincorporation by reference of certain

publications listed in the rule isapproved by the Director of the FederalRegister as of August 27, 2010.FOR FURTHER INFORMATION CONTACT:Steven Posnack, Director, Federal PolicyDivision, Office of Policy and Planning,Office of the National Coordinator forHealth Information Technology, 202–690–7151.SUPPLEMENTARY INFORMATION:

Acronyms

ANSI American National StandardsInstitute

CAH Critical Access HospitalCCD Continuity of Care DocumentCCHIT Certification Commission for Health

Information TechnologyCCR Continuity of Care RecordCDA Clinical Document ArchitectureCDC Centers for Disease Control and

PreventionCFR Code of Federal RegulationsCGD Certification Guidance Document

CMS Centers for Medicare & MedicaidServicesCPOE Computerized Provider Order EntryEHR Electronic Health RecordFIPS Federal Information Processing

StandardsHHS Department of Health and Human

ServicesHIPAA Health Insurance Portability and

Accountability Act of 1996HIT Health Information TechnologyHITECH Health Information Technology for

Economic and Clinical HealthHITSP Healthcare Information Technology

Standards PanelHL7 Health Level SevenICD International Classification of Diseases

ICD–9–CM International Classification ofDiseases, 9th Revision, ClinicalModification

ICD–10–PCS International Classification ofDiseases, 10th Revision, Procedure CodingSystem

ICD–10–CM International Classification ofDiseases, 10th Revision, ClinicalModification

IHS Indian Health ServiceLOINC Logical Observation Identifiers

Names and CodesNCPDP National Council for Prescription

Drug ProgramsNLM National Library of MedicineOCR Office for Civil RightsOMB Office of Management and BudgetONC Office of the National Coordinator for

Health Information TechnologyPHSA Public Health Service ActPQRI Physician Quality Reporting InitiativeREST Representational state transferRFA Regulatory Flexibility ActSNOMED–CT Systematized Nomenclature

of Medicine Clinical TermsSOAP Simple Object Access ProtocolUCUM Unified Code for Units of MeasureUMLS Unified Medical Language SystemXML eXtensible Markup Language

Table of Contents

I. BackgroundA. Legislative HistoryB. Regulatory History1. Initial Set of Standards, Implementation

Specifications, and Certification Criteriafor EHR Technology Interim Final Rule

2. Interdependencies With Other HITECHProvisions and Relationship to OtherRegulatory Requirements

II. Overview of the Final RuleIII. Section-by-Section Discussion of the

Final Rule and Response to CommentsA. IntroductionB. General CommentsC. Definitions—§170.1021. Definition of Disclosure2. Definition of Standard3. Definition of Implementation

Specification

4. Definition of Certification Criteria5. Definition of Qualified EHR6. Definition of Complete EHR7. Definition of EHR Module8. Definition of Certified EHR Technology9. Definition of Human Readable Format10. Definition of UserD. Final Rule Amendments to Adopted

Standards, ImplementationSpecifications, and Certification Criteria

§§ 170.202, 170.205, 170.207, 170.210,170.302, 170.304, 170.306

1. Flexibility and Innovation2. Transport Standards3. Certification Criteria and Associated

Standards and ImplementationSpecifications

a. General Certification for Complete EHRsor EHR Modules—§170.302

b. Specific Certification for Complete EHRsor EHR Modules Designed for anAmbulatory Setting—§170.304

c. Specific Certification for Complete EHRsor EHR Modules Designed for anInpatient Setting—§170.306

d. Adoption and Realignment ofCertification Criteria to Support the Final

Requirements for Meaningful Use Stage1.E. Additional CommentsF. Comments Beyond the Scope of This

Final RuleIV. Collection of Information RequirementsV. Regulatory Impact Analysis

A. IntroductionB. Why is this rule needed?C. Executive Order 12866—Regulatory

Planning and Review Analysis1. Comment and Response2. Executive Order 12866 Final Analysisa. Costs

b. BenefitsD. Regulatory Flexibility Act Analysis1. Comment and Response

2. Final RFA AnalysisE. Executive Order 13132—FederalismRegulation Text

I. Background

A. Legislative History

The Health Information Technologyfor Economic and Clinical Health(HITECH) Act, Title XIII of Division Aand Title IV of Division B of theAmerican Recovery and ReinvestmentAct of 2009 (ARRA) (Pub. L. 111–5), wasenacted on February 17, 2009. TheHITECH Act amended the Public HealthService Act (PHSA) and established‘‘

Title XXX—Health InformationTechnology and Quality’’ to improvehealth care quality, safety, andefficiency through the promotion ofhealth information technology (HIT) andthe electronic exchange of healthinformation. Section 3004(b)(1) of thePHSA requires the Secretary of Healthand Human Services (the Secretary) toadopt an initial set of standards,implementation specifications, andcertification criteria by December 31,2009 to enhance the interoperability,functionality, utility, and security of


8/13/2019 2010-17210


44591Federal Register / Vol. 75, No. 144 / Wednesday, July 28, 2010 / Rules and Regulations

health information technology. Section3004(b)(1) of the PHSA also permits theSecretary to adopt the initial set ofstandards, implementationspecifications, and certification criteriaon an interim, final basis.

B. Regulatory History

1. Initial Set of Standards,

Implementation Specifications, andCertification Criteria for EHRTechnology Interim Final Rule

On December 30, 2009, the FederalRegister made available for publicinspection, an interim final rule (theInterim Final Rule) with a request forcomments, which adopted an initial setof standards, implementationspecifications, and certification criteria.As noted in this rulemaking (75 FR2014), we described how Congressfundamentally tied the adoptedstandards, implementationspecifications, and certification criteria

to the incentives available under theMedicare and Medicaid EHR IncentivePrograms by requiring the meaningfuluse of Certified EHR Technology.Congress outlined several goals formeaningful use, one of which includedthe ‘‘use of certified EHR technology ina meaningful manner.’’ This means thatto qualify for incentives, an eligibleprofessional or eligible hospital must

both adopt Certified EHR Technologyand demonstrate meaningful use of thistechnology.

The initial set of standards,implementation specifications, andcertification criteria adopted in theInterim Final Rule established thecapabilities that Certified EHRTechnology would need to include to, ata minimum, support eligibleprofessionals’ and eligible hospitals’efforts to achieve what had beenproposed for meaningful use Stage 1under the Medicare and Medicaid EHRIncentive Programs proposed rule.

2. Interdependencies With OtherHITECH Provisions and Relationship toOther Regulatory Requirements

In addition to our discussion of howthe standards, implementation

specifications, and certification criteriaadopted in the Interim Final Rulecorrelated with the Medicare andMedicaid EHR Incentive Programsproposed rule, we also discussed ourapproach to align adopted standards,implementation specifications, andcertification criteria with new andpending HITECH Act regulatory actions

and with other already establishedregulatory requirements. We alsoexplained our approach for aligningthese standards, implementationspecifications, and certification criteriawith: the adopted standard andcertification criterion related to theHealth Insurance Portability andAccountability Act of 1996 (HIPAA)Privacy Rule Accounting of DisclosuresRegulation under the HITECH Act;alignment with the HIPAA Privacy andSecurity Regulations; the Medicare PartD Electronic Prescribing Regulations;and the HIPAA Transactions and Code

Sets Standards Regulations.II. Overview of the Final Rule

We are amending part 170 of title 45of the Code of Federal Regulations (CFR)to complete the adoption of the initialset of standards, implementationspecifications, and certification criteriaas required by section 3004(b)(1) of thePHSA and realign them with the finalobjectives and measures established formeaningful use Stage 1. After reviewingand considering public comments onour adopted standards, implementationspecifications, and certification criteria,

we have made several revisions tosupport the final meaningful useobjectives and measures, clarify certaincertification criteria to resolve identifiedtechnical challenges related to some ofthe standards and implementationspecifications we adopted, and toprovide for additional flexibility.

III. Section-by-Section Discussion of theFinal Rule and Response to Comments

A. Introduction

This section summarizes the nearly400 timely comments received by ONCrelated to the Interim Final Rule. In

some cases, due to the simultaneouspublication and topical similarity of thenotice of proposed rulemaking formeaningful use Stage 1, commentersinadvertently submitted comments toour regulation docket on regulations.govinstead of the Centers for Medicare &Medicaid Services (CMS) regulationdocket, and vice versa. Recognizing thisoversight, CMS and ONC sharedmisplaced comments between theoffices and we included within ourreview all comments that could bereasonably identified as comments onthe Interim Final Rule.

We have organized the preamble ofthis final rule along the following lines.First, we respond to general comments,including those related to the scope andapplicability of the final rule that we

believe are necessary to clarify upfront.Next, we respond to commentsregarding the definitions of certain

defined terms. We then respond topublic comments on each certificationcriterion, and where an adoptedcertification criterion also referencesstandards and implementationspecifications, we include our responseto public comments on the relatedstandards and implementationspecifications. These concepts wereseparately discussed in the InterimFinal Rule and we believe thatdiscussing the certification criteriatogether with associated standards andimplementation specifications willimprove the clarity of the final rule andwill allow us to more fully addresspublic comments in a broader context.We include the following table at the

beginning of the discussion of eachcertification criterion section toillustrate the final meaningful use Stage1 objectives for eligible professionalsand eligible hospitals and to show howwe have revised adopted certificationcriteria in response to the revisedmeaningful use objectives and measuresand public comments.

Meaningful use Stage 1 objective Meaningful use Stage 1 measure Certification criterion

Eligible Professional and/or EligibleHospital & Critical Access Hos-pital Objective.

Eligible Professional and/or Eligi-ble Hospital & Critical AccessHospital Measure.

Interim Final Rule Text: Certification Criterion.Final Rule Text: Certification Criterion.

Finally, in considering publiccomments on the Interim Final Rule, weanalyzed whether we had structured theregulation text in an optimal andunderstandable manner. For several

provisions, we received commentsrequesting additional clarification andwe felt that the original regulatorystructure contributed to thecommenters’ confusion. Because of

those comments and in an effort to better structure the regulation text forfuture revisions, we have revised thestructure conceptually to group contentexchange standards and associated


8/13/2019 2010-17210



implementation specifications andvocabulary standards, and separatedthem into different sections. In line withthis ‘‘conceptual’’ restructuring, we havedetermined that specifying how aComplete EHR or EHR Module mustcomply with an adopted standardshould be solely reflected in thecertification criteria. As a result, several

certification criteria have been revisedto more clearly reflect how a CompleteEHR or EHR Module must comply withadopted standards and, whereapplicable, the relevant adoptedimplementation specifications.

B. General Comments

Some commenters appear to havemisinterpreted or misunderstood thescope of the Interim Final Rule and theapplicability of the adopted standards,implementation specifications, andcertification criteria. We wouldtherefore like to clarify these concepts atthe beginning of this final rule and areproviding the following responses to therelevant comments.

Comments. Some commenters seem tohave construed the adoption ofstandards, implementationspecifications, and certification criteriaas including requirements that apply tothe health care providers that will usethe Certified EHR Technology, ratherthan as required capabilities of theCertified EHR Technology itself. Thesecommenters, for instance, questionedwhether entities using Certified EHRTechnology must comply with adoptedstandards and implementation

specifications when electronically usingor transmitting health informationwithin or among components of thelegal entity or alternatively whether thestandards apply solely to transmissions

between legal entities. Othercommenters specifically requestedclarification regarding the adoptedstandards that are required to be usedinternally within each provider’s office,institution, or closed system and whichstandards are required for purposes ofelectronically exchanging healthinformation among such entities. Somecomments implied that the Interim

Final Rule should have specified whenan eligible professional or eligiblehospital would be required to useadopted standards. One commenterspecifically requested that the adoptedstandards apply only to the electronicexchange of health information betweenlegal entities.

Response. As stated in §170.101, wespecify that ‘‘[t]he standards,implementation specifications, andcertification criteria adopted in this partapply to Complete EHRs and EHRModules and the testing and

certification of such Complete EHRs andEHR Modules.’’ In §§ 170.200 and170.300, we further specify that ‘‘[t]hestandards and implementationspecifications adopted in this part applywith respect to Complete EHRs and EHRModules’’ and that ‘‘[t]he certificationcriteria adopted in this subpart apply tothe testing and certification of Complete

EHRs and EHR Modules.’’The purpose of this final rule,

therefore, is to adopt standards,implementation specifications, andcertification criteria to test and certifythat a Complete EHR or EHR Moduleprovides certain capabilities, and whereapplicable, to require that thosecapabilities be implemented inaccordance with adopted standards andimplementation specifications. Theadopted standards, implementationspecifications, and certification criteriawere not intended to imposeindependent requirements on the

entities using Certified EHRTechnology. Unlike certain otherregulatory requirements to whicheligible professionals or eligiblehospitals may be subject, it is not withinthe intended scope of this final rule tospecify the requirements for entitiesusing Certified EHR Technology.

We understand the commenters’ pointthough that an adopted standard andimplementation specification couldapply equally to electronic transactions

between legal entities as well as totransmissions within an entity. Thisfinal rule, however, is not intended tospecify the conditions under which

adopted standards and implementationspecifications must be used, only that aComplete EHR or EHR Module, in orderto be certified, must include specifiedcapabilities that are implemented inaccordance with those standards,implementation specifications, andcertification criteria. We anticipate thatother regulations, as well as the clinicaland business needs of HIT users,anticipated efficiencies and desiredquality improvements, and technical,architectural, and enterprise limitationswill determine when entities will utilizethe capabilities required of Certified

EHR Technology. Additionally, wewould note that Complete EHRs andEHR Modules will, in many cases, betested and certified independent of theenvironment within which they will beimplemented. Consequently, specifyingwhen an entity that implementsCertified EHR Technology must utilize aparticular capability in its operatingenvironment exceeds the scope of thisrule.

To further demonstrate this point,Certified EHR Technology implemented

by an eligible professional will need to

possess the capability to generate anelectronic prescription according to oneof the standards we have adopted. Tospecify the contexts in which anelectronic prescription (generatedaccording to the adopted standard) must

be transmitted would go beyond thescope of certification. Moreover, itwould raise a more serious and practical

consideration. Attempting to specifywhen entities must utilize thecapabilities of Certified EHRTechnology would add an unnecessarylevel of complexity to this rule andcreate the potential for conflicts withother regulations promulgated by theHHS. For instance, HHS has alreadypromulgated at least two sets ofregulations identifying when health careproviders need to use specific standardsand the contexts in which thosestandards must be used. Under theHIPAA Transactions and Code SetsStandards regulations, HHS specifies at

45 CFR 162.923(a) that‘‘[e]xcept asotherwise provided in this part, if a

covered entity conducts with anothercovered entity (or within the samecovered entity ), using electronic media,a transaction for which the Secretaryhas adopted a standard under this part,the covered entity must conduct thetransaction as a standard transaction.’’(Emphasis added.) Consequently, in theHIPAA context, covered entities mustuse adopted transaction standards forcovered transactions both within thecovered entities and with outsideentities. The Medicare Part D electronic-

prescribing (e-prescribing) regulationsimplement a different approach forcertain e-prescribing transactions.Health care providers that electronicallyprescribe Part D drugs for Part D eligibleindividuals under 42 CFR423.160(a)(3)(iii), ‘‘may use either HL7messages or the NCPDP SCRIPTStandard to transmit prescriptions orprescription-related informationinternally when the sender and therecipient are part of the same legalentity. If an entity sends prescriptionsoutside the entity (for example, from anHMO to a non-HMO pharmacy), it mustuse the adopted NCPDP SCRIPTStandard or other applicable adoptedstandards.’’ Therefore, we believe that itis unnecessary and outside of theintended scope of this rule to specifythe contexts or circumstances underwhich adopted standards andimplementation specifications must beutilized.

Moreover, we anticipate that futuremeaningful use objectives and measureswill specify, as necessary andappropriate, the conditions under whichcertain health care providers will need


8/13/2019 2010-17210



1 http://www.whitehouse.gov/omb/ circulars _a119.

to use adopted standards andimplementation specifications. Thecontext, for instance, governing when astandard must be used will, in somecases, be directly related to whether andhow an eligible professional or eligiblehospital must meaningfully useCertified EHR Technology. For example,a final meaningful use Stage 1 objective

requires that eligible professionals andeligible hospitals use Certified EHRTechnology to record demographicsincluding, among other fields, race andethnicity. While we have adopted therace and ethnicity codes published bythe Office of Management and Budget(OMB), in the context Medicare andMedicaid EHR incentive programs, themeaningful use of Certified EHRTechnology will dictate whether suchcodes must be used ‘‘inside’’ anorganization. Another example of whena meaningful use objective establishesthe context in which a standard must be

used is the objective that requireseligible professionals and eligiblehospitals to use Certified EHRTechnology to maintain an up-to-dateproblem list of current and activediagnoses. The measure associated withthis objective requires that entries berecorded in ‘‘structured data’’ and in thiscontext we adopted ICD–9 or SNOMED–CT® to provide that structure. As aresult, Certified EHR Technology must

be capable of using ICD–9 or SNOMED–CT® when an eligible professional oreligible hospital seeks to maintain anup-to-date problem list.

In other instances, the Department

does not specify explicitly in regulationthe context for certain meaningful useobjectives and whether meaningful useof Certified EHR Technology wouldrequire the use of a standard forelectronic transactions solely betweentwo different legal entities, or for alltransactions, or for most transactionswith certain exemptions.

Comments. Several commentersrequested that we provide moreinformation about the standards weexpect the Secretary to adopt in order tosupport future stages of meaningful use.These commenters noted, along with

referencing the timelines for makingchanges to HIT, that it would benefit theHIT industry if we could provide aroadmap, framework, or moredescriptive ‘‘glide path’’ for futurestandards adoption activities.

Response. We anticipate that futurestages of meaningful use will require usto adopt additional standards,implementation specifications, andcertification criteria. We also expect thatstandards we have adopted willcontinue to be revised and updated overtime, to reflect current technology,

changing medical practice andregulatory requirements. We willtherefore need to continue to harmonizethose adopted standards with otherstandards to support interoperability.We anticipate that the standardsrequired to support future stages ofmeaningful use will need a frameworkthat supports harmonization across

different meaningful use scenarios andthat supports early real world testing.We plan to work closely with the HITStandards Committee to develop aforward looking agenda and to makeknown in advance the types ofstandards, implementationspecifications, and certification criteriaon which we will seekrecommendations from the HITStandards Committee. We believe thiswill benefit the HIT industry byproviding greater transparency of thestandards adoption activities and willserve as an early indication for the

public of candidate standards that are being identified for possible adoption.

C. Definitions—§170.102

In this section, we respond to publiccomment on the definitions adopted inthe Interim Final Rule. We address thedefinition of Certified EHR Technologylast after we provide clarificationsrelated to the definitions of CompleteEHR and EHR Module.

1. Definition of Disclosure

Comments. A few commenters notedthat the definition of disclosure was too

broad or asked that we refine theadopted definition to be more limitedand to only apply in certaincircumstances. One commenter notedthat this was a new definition.

Response. As we explained in thepreamble of the Interim Final Rule, thisdefinition repeated the text specified at45 CFR 160.103 (the General Provisionssection for the HIPAA regulations).Because the Interim Final Rule createda new part in Title 45 of the CFR, thedefinition of disclosure as it is used inthe HIPAA regulations would notnecessarily have applied to our use ofthe term in this rule. Therefore, toprevent unnecessary ambiguity for theregulated community, we adopted thedefinition of the term as it is defined at45 CFR 160.103.

In light of public comment and toprevent any future regulatoryinconsistency that would requirerulemaking to correct, we have revisitedour approach of repeating the text of thedefinition of disclosure from 45 CFR160.103 and have decided to crossreference 45 CFR 160.103 in thedefinition of disclosure. The final

definition will read: disclosure isdefined as it is in 45 CFR 160.103.

2. Definition of Standard

Comment. A commenter stated thatour definition of standard wascomprehensive from a technicalperspective, but believed the definitionwas incomplete from a policy

perspective. The commenter argued thatfor interoperability to be successful, itwas essential that standards be createdthrough collaborative, consensus-basedprocesses that take into considerationthe needs and concerns of all interestedstakeholders. For that reason, thecommenter suggested, in order for thedefinition to be whole from both atechnical and policy perspective, weshould add to the definition the phrase‘‘developed through the use of open,collaborative, consensus-basedprocesses.’’

Response. While we appreciate thecommenter’s point, we believe that theproposed language is unnecessary andpotentially problematic. Federalagencies are already required under theNational Technology Transfer andAdvancement Act of 1995 (NTTAA) (15U.S.C. 3701 et seq.) and OMB CircularA–119 1 to use, wherever practical,technical standards that are developedor adopted by voluntary consensusstandards bodies to carry out policyobjectives or activities, with certainexceptions. In drafting the Interim FinalRule, we briefly discussed relevantprovisions of the NTTAA and OMBCircular A–119, our compliance with

the statute and the Circular, and werequested comments on our approach tothe selection of standards. We alsoexplained that both the NTTAA andOMB Circular A–119 provide for certainexceptions to selecting only standardsdeveloped or adopted by voluntaryconsensus standards bodies, namelywhen doing so would be ‘‘inconsistentwith applicable law or otherwiseimpractical.’’ In the Interim Final Rule,we identified those instances in whichwe had and had not adopted voluntaryconsensus standards. In the instances inwhich we had not adopted voluntary

consensus standards, we provided twoprincipal reasons: first, that in mostcases a voluntary consensus standardthat could meet the requisite technicalgoals was simply unavailable; andsecond, that to the extent a potentiallyequivalent voluntary consensusstandard was available, the standardwas too limiting and did not meet ourpolicy goals, including allowing forgreater innovation by the industry. In


http://www.whitehouse.gov/omb/circulars_a119






8/13/2019 2010-17210



this final rule, we have adopted onlyvoluntary consensus standards, exceptfor two government-unique standards(CMS Physician Quality ReportingInitiative (PQRI) 2009 Registry XMLSpecification and the Office ofManagement and Budget Standards forMaintaining, Collecting, and PresentingFederal Data on Race and Ethnicity), a

functional standard relating tovocabularies included in RxNorm, andthe specified standards to protectelectronic health information. We areaware of no voluntary consensusstandards that would serve asalternatives to these standards for thepurposes that we have identified. Weencourage the HIT Standards Committeeto obtain public input, hold hearings on,and recommend to the NationalCoordinator standards that have beendeveloped or adopted by voluntaryconsensus standards bodies.

3. Definition of Implementation

SpecificationWe did not receive any comments

applicable to the definition ofimplementation specification andconsequently did not make any changesto the definition.

4. Definition of Certification Criteria

Comments. One commenter expresslystated its support for our definition ofcertification criteria.

Response. We appreciate thecommenter’s support for our definitionof certification criteria and have notmade any changes to the definition in

this final rule.5. Definition of Qualified EHR

Comments. A couple of commentersasserted that there is uncertainty in theindustry with respect to whatconstitutes an EHR due both to theseemingly inconsistent definitions ofterms in the HITECH Act and to thealternative definitions published bydifferent organizations and associations.The commenters made specificreference to the definition of ‘‘QualifiedElectronic Health Record’’ (‘‘QualifiedEHR’’) at section 3000 of the PHSA and

to the term‘‘

EHR’’

found in the HITECHAct at section 13400 of Subtitle D. Thelatter defines EHR as ‘‘an electronicrecord of health-related information onan individual that is created, gathered,managed, and consulted by authorizedclinicians and staff.’’ The former definesQualified EHR as ‘‘an electronic recordof health-related information on anindividual that: (1) Includes patientdemographic and clinical healthinformation, such as medical historyand problem lists; and (2) has thecapacity: (i) to provide clinical decision

support; (ii) to support physician orderentry; (iii) to capture and queryinformation relevant to health carequality; and (iv) to exchange electronichealth information with, and integratesuch information from other sources.’’Both commenters recommended that thedefinition of Qualified EHR be clarifiedwith one commenter suggesting that the

definition should follow the definitionof EHR as it relates to health careproviders.

Response. We appreciate thesecomments and recognize that theexistence of multiple terms that includethe word ‘‘EHR’’ can be confusing.However, we believe that Congressintended for HHS to apply thedefinition of a Qualified EHR found insection 3000 of the PHSA to thisregulation for specific reasons thatcannot be overlooked. As a result, wehave decided not to adopt therecommendation to follow the

definition of the term EHR that is foundin Subtitle D of the HITECH Act. Wediscuss additional responses tocomments on the definition of QualifiedEHR below.

Comments. A few commentersrequested that we expand the definitionof Qualified EHR to include a variety ofadditional functionality and that aQualified EHR be able to comply with

business or legal requirements. Thesecomments requested that we addrequired elements for an EHR toconstitute a Qualified EHR, includingthat the EHR: Have a record-keeping

capability for legal purposes; includecertain requirements for usability;enable health care providers to performseveral other actions not specified in thedefinition; and that certain elements ofpatient demographic information bespecified.

Response. We understand therationale behind these commenters’suggestions, but we do not believe thatit is necessary to add more prerequisitecapabilities to the definition ofQualified EHR. We believe Congressdefined Qualified EHR to include aminimum level of capabilities.Furthermore, to meet the definition ofCertified EHR Technology, a QualifiedEHR must be certified in accordancewith a certification program established

by the National Coordinator. As a result,we believe that any additionalcapabilities a Qualified EHR wouldneed to possess to allow an eligibleprofessional or eligible hospital to be ina position to qualify for incentivepayments under the Medicare andMedicaid EHR incentive programs will

be more appropriately addressedthrough the Secretary’s adoption of

additional standards, implementationspecifications, and certification criteria.

Comments. Some commentersrequested that we clarify some of theterms in the definition of Qualified EHRsuch as ‘‘capture,’’ ‘‘query,’’ ‘‘othersources,’’ and ‘‘relevant to health carequality’’ with respect to how theyrelated to Certified EHR Technology.

Another commenter expressly statedthat if we only intended to repeat thestatutory definition of Qualified EHRwithout modification, we should at leastclarify the meaning of demographicinformation.

Response. We do not believe thatadditional clarity is needed or desirablefor such terms because the meanings arecontext specific. The intended meaningsof these terms will depend significantlyon the contexts in which the terms areused and the associated capabilities ofthe Certified EHR Technology. Theterms’ meanings may also be affected byany standards and implementationspecifications that are associated withthose capabilities and adopted. Incertain circumstances, for instance, themeaning of the phrase ‘‘other sources’’ asused in the definition of Qualified EHRwill depend on the specific context inwhich electronic health information is

being integrated or exchanged, andperhaps on whether the source isexternal to or internal within theComplete EHR or the EHR Module.Similarly, the meanings of the terms orphrases ‘‘capture,’’ ‘‘query,’’ ‘‘relevant tohealth care quality’’ and ‘‘demographic’’

information may vary according the

context of the required capabilities ofthe EHR technology. In each of theseinstances, we believe that the adoptedcertification criteria and meaningful useobjectives and measures will providethese contexts, identify the associatedrequired capabilities, and consequentlyclarify the intended meanings of theseterms.

6. Definition of Complete EHR

Comments. Some commenterssupported our definition of CompleteEHR and believed that it wasunderstandable, sufficient, andreasonable. Other commenters,however, suggested that the definitionof Complete EHR was too narrow,

because the term is tied to only thosecertification criteria adopted by theSecretary. These commenters arguedthat the Complete EHR and the adoptedcertification criteria should be morecomprehensive and should includefunctionality that is not presentlyrequired for a Complete EHR to achievecertification. Many of these commentersreferenced the Health Level Seven (HL7)EHR System Functional Model (EHR–S


8/13/2019 2010-17210



FM) and contended that what we haddefined as a Complete EHR did not alignwith or include all of the functionalityspecified in the EHR–S FM. Onecommenter requested that we clarifywhat we meant by ‘‘we fully expectsome EHRs to have capabilities beyondthose addressed by certification criteria’’

when we made this point during our

discussion of the definition of CompleteEHR in the preamble of the InterimFinal Rule. Other commentersrecommended specific wording changesto the definition.

Response. In the Interim Final Rulewe defined Complete EHR to mean‘‘EHR technology that has beendeveloped to meet all applicablecertification criteria adopted by theSecretary.’’ We clarified that the termComplete EHR is ‘‘meant to encompassEHR technology that can perform all ofthe applicable capabilities required bycertification criteria adopted by the

Secretary and distinguish it from EHRtechnology that cannot perform thosecapabilities.’’ We believe thatcommenters misunderstood the scopeand purpose of the regulatory definitionand believe that the definitioneffectively fulfills its regulatorypurpose. We intend for the definition ofComplete EHR to be used to clearlyidentify EHR technology as being able toperform, at a minimum, all of theapplicable capabilities required bycertification criteria adopted by theSecretary, and thereby, as providingeligible professionals or eligiblehospitals with the technical capabilities

they need to support their achievementof meaningful use of Certified EHRTechnology. It is in this context that weview such EHR technology as‘‘complete.’’

We recognize that many commentersrecommended a definition of ‘‘CompleteEHR’’ that would be morecomprehensive than the definition weprovided. Many commenters contendedthat HIT exists and is available foreligible professionals and eligiblehospitals to implement, and much of itincludes a myriad of capabilities farsurpassing the capabilities required to

meet the definition of Complete EHR.We do not dispute that point. We alsounderstand that the capabilitiesincluded in a Complete EHR, as definedfor the purposes of this regulation, maynot encompass all of the capabilities aspecific eligible professional or eligiblehospital or for that matter any healthcare provider, may deem essential tomeet their unique business needs anduse cases.

This definition, however, does not inany way preclude any additionalcapabilities from being included in a

Complete EHR or implemented in acomplementary fashion. The definitionsets forth a floor, not a ceiling, andserves to signify that once tested andcertified to all applicable certificationcriteria, a Complete EHR meets thedefinition of Certified EHR Technology.For this reason, we did not seek to craftthis definition in a way that signified

that a Complete EHR would be able toprovide all of the capabilities a healthcare provider desired or deemednecessary, or that the entity’s EHR couldonly include the capabilities for whichthe Secretary has adopted certificationcriteria. Nor did we define CompleteEHR according to a particular functionalmodel, because doing so would have

been inconsistent with the regulatorypurpose of the definition.

In light of public comment and tofurther clarify the regulatory purpose ofthe definition of Complete EHR as wellas make clear that a Complete EHR

should not be misinterpreted to meanEHR technology that is any morecomprehensive than the certificationcriteria to which it was tested andcertified, we have added the phrase ‘‘ata minimum’’ to the definition. The finaldefinition of Complete EHR willtherefore read ‘‘EHR technology that has

been developed to meet, at a minimum,all applicable certification criteriaadopted by the Secretary.’’

As a related point, we would also notethat an eligible professional or eligiblehospital would need to use a capabilitythat is included among the adoptedcertification criteria to meet the

associated meaningful use objective ormeasure. The eligible professional oreligible hospital therefore could notattempt to use a capability that issuperfluous to certification todemonstrate the meaningful use of‘‘Certified EHR Technology.’’ Weunderstand that the Medicare andMedicaid EHR Incentive Programs finalrule discusses this issue more fully inseveral places, and we defer to thosediscussions concerning therequirements for achieving meaningfuluse of Certified EHR Technology.

Comment. In the context of the

definition of Complete EHR, onecommenter asked for clarificationregarding how many certificationcriteria a Complete EHR must bedeveloped to meet.

Response. For the purposes ofmeeting the definition of Complete EHR,EHR technology designed for anambulatory setting (to be used byeligible professionals) must be certifiedto all of the certification criteria adoptedat 45 CFR 170.302 and 45 CFR 170.304,and EHR technology designed for aninpatient setting (to be used by eligible

hospitals) must be certified to all of thecertification criteria adopted at 45 CFR170.302 and 45 CFR 170.306.

7. Definition of EHR Module

Comments. Numerous commentersstrongly supported our inclusion of amodular approach to meet the definitionof Certified EHR Technology. Many of

these commenters saw this approach asa way to spur greater innovation in theHIT marketplace, provide more choicesfor health care providers, and generally

broaden the appeal of HIT and expediteits adoption. Some commenters noted,however, that they believed thedefinition needed further clarificationwith respect to what would constitutean EHR Module. In most cases, thesecommenters provided examples oftechnologies that they believed shouldmeet the definition of EHR Module andthey sought confirmation that thesetechnologies would meet the definition.Included among these technologies wereradiology information systems (RIS),picture archiving and communicationsystems (PACS), PHRs, speechrecognition software, electrocardiogramsystems, remote patient monitoring(RPM) devices, and other electronicdevices including non-health caredevices.

Response. In the Interim Final Rule,we defined an EHR Module to mean‘‘any service, component, orcombination thereof that can meet therequirements of at least one certificationcriterion adopted by the Secretary.’’Consequently, EHR Modules, by

definition, must provide a capabilitythat can be tested and certified inaccordance with at least onecertification criterion adopted by theSecretary. Therefore, if an EHR Moduledoes not provide a capability that can betested and certified at the present time,it is not HIT that would meet thedefinition of EHR Module. We stress ‘‘atthe present time,’’ because as newcertification criteria are adopted by theSecretary, other HIT could be developedand then tested and certified inaccordance with the new certificationcriteria as EHR Modules.

We encourage eligible professionalsand eligible hospitals to use any and allHIT they believe will help make thehealth care they deliver more effectiveand efficient. However, unless the HITis tested and certified to at least onecertification criterion for use as part ofCertified EHR Technology, it does notconstitute an EHR Module for thepurposes of this regulation. Eligibleprofessionals and eligible hospitals arenot prohibited from using orimplementing this HIT, but again, at thepresent time, such HIT cannot


8/13/2019 2010-17210



constitute an EHR Module and serve asa necessary component of Certified EHRTechnology for eligible professionals oreligible hospitals to use when seeking toachieve meaningful use as defined inthe Medicare and Medicaid EHRIncentive Programs final rule.

In response to these comments, wewould also like to clarify our

conceptualization of an EHR Module.An EHR Module could provide a singlecapability required by one certificationcriterion or it could provide allcapabilities but one, required by thecertification criteria for a CompleteEHR. In other words, we would call HITtested and certified to one certificationcriterion an ‘‘EHR Module’’ and HITtested and certified to nine certificationcriteria an ‘‘EHR Module,’’ where tencertification criteria are required for aComplete EHR. We have not made anychanges to the definition of EHRModule as a result of these comments or

the comments addressed below.Comment. One commenter asked

whether we meant to include in thedefinition of EHR Module ‘‘interfaces’’

that perform data mapping ortransformation. The commenter raisedthis question while noting that someorganizations use multiple interfaces tointerconnect their HIT systems and thatit would be an arduous task for theseorganizations to ensure that allindividual interfaces are certified.Another commenter sought clarificationregarding what we meant when westated as an example in the Interim

Final Rule that EHR Modules could be‘‘an interface or other software programthat provides the capability to exchangeelectronic health information.’’

Response. As discussed above, tomeet the definition of EHR Module, HITwould need to provide a capability thatcould be tested and certified to at leastone certification criterion. If acertification criterion has therefore beenadopted that requires a particularcapability for exchanging electronichealth information, an interface or othersoftware program that provides thatcapability could be tested and certified

as an EHR Module. In manycircumstances, an interface or programmay provide valuable functionality, butnot a capability for which a certificationcriterion has been adopted. Forexample, software implemented by aneligible professional that performs datatranslation or mapping between twodatabases or data sets may providecritical functionality, yet that softwarewould not constitute an EHR Module.Similarly, interfaces between ‘‘HITsystems’’ may be critical to thefunctionality of the separate systems,

but they themselves would not be EHRModules.

In those circumstances in which aninterface or other software program is anintegral component of an EHR Modulewithout which it would not be able to

be tested and certified, then suchinterface or other software program,though not itself an EHR Module, would

function as a critical piece of the overallEHR Module presented for testing andcertification. For example, a softwareprogram that would permit an eligibleprofessional or eligible hospital toelectronically exchange healthinformation with other eligibleprofessionals or eligible hospitals could

be tested and certified as an EHRModule, if it provides the capability toelectronically exchange healthinformation according to standardsadopted by the Secretary. In thisexample, whatever comprises thesoftware program would be considered

part of the EHR Module that is testedand certified.Finally, in situations where an

eligible professional or eligible hospital believes that it has multiple HITsystems that would each meet thedefinition of EHR Module, we suggestthat the eligible professional or eligiblehospital evaluate whether these systemscould be combined with other systemsto constitute a Complete EHR. If they arecapable of being combined to form aComplete EHR, it may be moreexpeditious and beneficial for aneligible professional or eligible hospitalto simply seek Complete EHR testing

and certification.Comments. A few commenters

requested that we clarify how EHRModules would be tested and certifiedto adopted privacy and securitycertification criteria. Other commentersasked whether we meant to allow forthere to be EHR Modules that providedonly privacy and security capabilities.

Response. These comments pertain tothe certification programs rule, and areoutside of the scope of this rule. Wetherefore respond to these comments inthe Temporary Certification Programfinal rule (75 FR 36158).

8. Definition of Certified EHRTechnology

Comments. Multiple commenterscommended ONC for recognizing theneed to certify EHR Modules andenabling certified EHR Modules to beused in combination to meet thedefinition of Certified EHR Technology.These commenters noted that thisapproach makes it clear that eligibleprofessionals and eligible hospitals willhave the flexibility to select certifiedEHR modules that are the most useful to

them, and can achieve meaningful useeither with combinations of certifiedHIT or a single EHR system. However,some commenters mentioned that thedefinition is unnecessarily ambiguous,and subject to possible alternativeinterpretations. Some commenters alsocommented on certain statements in thepreamble regarding EHR Modules and

queried how a proper combination ofEHR Modules could be used to meet thedefinition of Certified EHR Technology.Other commenters, whileacknowledging that adoptedcertification criteria will determine inpart what constitutes Certified EHRTechnology, urged ONC to revise thedefinition to include only patient carefunctionality. Finally, a few commentersoffered specific word changes for thedefinition to improve its clarity.

Response. In the Interim Final Rule,we defined Certified EHR Technology tomean ‘‘a Complete EHR or a

combination of EHR Modules, each ofwhich: (1) Meets the requirementsincluded in the definition of a QualifiedEHR; and (2) Has been tested andcertified in accordance with thecertification program established by theNational Coordinator as having met allapplicable certification criteria adopted

by the Secretary.’’ With respect to acombination of EHR Modules, weclarified in the preamble of the InterimFinal Rule that:

As long as each EHR Module has beenseparately tested and certified in accordancewith the certification program established by

the National Coordinator * * * to all of theapplicable certification criteria adopted bythe Secretary, a proper combination ofcertified EHR Modules could meet thedefinition of Certified EHR Technology. Toclarify, we are not requiring the certificationof combinations of certified EHR Modules,just that the individual EHR Modulescombined have each been certified to allapplicable certification criteria in order forsuch a ‘‘combination’’ to meet the definitionof Certified EHR Technology.

Many commenters appeared to beconfused by the inclusion of ‘‘each ofwhich’’ in the definition of CertifiedEHR Technology. Other commenters

also stated that‘‘

each of which’’

wasawkwardly placed, making it difficult tointerpret how the combination of EHRModules must satisfy the subsequentrequirements of the definition. Thisconfusion also made it difficult tounderstand the clarifying remarksreiterated above regarding our intentionto avoid implying that a combination ofcertified EHR Modules had to becertified a second time when a propercombination had been created. Wegenerally agree with these commentsand are revising the definition slightly


8/13/2019 2010-17210



to avoid this ambiguity and to clarifythat the definition of Certified EHRTechnology can be met in either of twoways.

The first way that the definition ofCertified EHR Technology can be met isfor a Complete EHR to: (1) Meet therequirements included in the definitionof a Qualified EHR, and (2) be tested

and certified in accordance with thecertification program established by theNational Coordinator as having met allapplicable certification criteria adopted

by the Secretary. The second way thatthe definition of Certified EHRTechnology can be met is if eachconstituent EHR Module of acombination of EHR Modules has beentested and certified in accordance withthe certification program established bythe National Coordinator as having metall applicable certification criteriaadopted by the Secretary and theresultant combination also meets the

requirements included in the definitionof a Qualified EHR.As previously written, it was unclear

to many commenters that the commapreceding ‘‘each of which’’ was meant toseparately apply a Complete EHR and‘‘combination of EHR Modules’’ to thesubsequent requirements. Our intentionwas that a combination of EHR Moduleswould have to provide the capabilitiesnecessary to meet the definition of aQualified EHR and that the EHRModules combined would have each

been tested and certified in accordancewith the certification criteria applicableto each EHR Module.

In response to commenters, we havedecided to revise the definition ofCertified EHR Technology to stateexplicitly the two distinct ways thedefinition can be met. The reviseddefinition will read as follows. CertifiedEHR Technology means:

(1) A Complete EHR that meets therequirements included in the definitionof a Qualified EHR and has been testedand certified in accordance with thecertification program established by theNational Coordinator as having met allapplicable certification criteria adopted

by the Secretary; or

(2) A combination of EHR Modules inwhich each constituent EHR Module ofthe combination has been tested andcertified in accordance with thecertification program established by theNational Coordinator as having met allapplicable certification criteria adopted

by the Secretary, and the resultantcombination also meets therequirements included in the definitionof a Qualified EHR.

As discussed in the TemporaryCertification Program final rule, a pre-coordinated integrated bundle of EHR

Modules would fall under the seconddefinition of Certified EHR Technology,although each EHR Module of the

bundle would be tested and certified atthe same time rather than separately.Therefore, provided that a propercombination of EHR Modules has beencreated, combinations of EHR Modulescould be tested and certified either at

the same time or at separate times, tomeet the definition of Certified EHRTechnology.

Finally, we believe that commentersuggestions to revise the definition ofCertified EHR Technology to referencespecific certification criteria aremisguided. The definition, regardless ofthe certification criteria that must beincluded in a Complete EHR orcombination of EHR Modules, must beable to accommodate changes incertification criteria over time.Accordingly we believe that the finaldefinition meets this intended goal and

conveys a clear meaning.Comments. Some commentersappeared to interpret our definition asproviding that EHR Modules must beused to meet the definition of CertifiedEHR Technology. Of these commenters,some requested that we clarify whetherhealth care providers would be requiredto obtain certification of EHR Modulesthat no vendors support. Othercommenters asked whether non-certified ‘‘EHR modules’’ could be usedin combination with a Complete EHR orin combination with EHR Modules thatare used to meet the definition ofCertified EHR Technology.

Response. We would like to makeclear that eligible professionals andeligible hospitals are not required to useEHR Modules in order to meet thedefinition of Certified EHR Technology.The use of EHR Modules is completelyvoluntary and provides an alternateavenue for eligible professionals andeligible hospitals who seek toimplement more customized HITsolutions while still meeting thedefinition of Certified EHR Technology.Commenters who expressed concernsabout their responsibility for seekingcertification for EHR Modules for which

no vendor supports did not providespecific examples, and we are uncertainas to the basis for their concerns.Regardless, we reiterate that the use ofEHR Modules is voluntary and we

believe that most eligible professionalsand eligible hospitals that are adoptingHIT for the first time will have a varietyof Complete EHRs available from whichto choose.

We also clarify that only those EHRModules that provide capabilitiesnecessary to meet the definition ofCertified EHR Technology will need to

be tested and certified. That being said,eligible professionals and eligiblehospitals are free to utilize any othertype of HIT to complement or incombination with Certified EHRTechnology, including HIT thatprovides capabilities for other purposesnot related to meaningful use.

Comments. Some commenters

suggested that our definition was too broad. Most of these commenters arguedthat we should permit eligibleprofessionals to adopt only CompleteEHRs and EHR Modules that werecertified as including only thosecapabilities applicable to their specialtyor practice. In other words, thesecommenters sought for the definition ofCertified EHR Technology to beinterpreted in such a way as to permitdifferent specialty-oriented variations ofCertified EHR Technology to exist.

Response. At the present time, we believe that the definition of CertifiedEHR Technology already includes someof the flexibility these commentersrequest. We permit, for example, aComplete EHR designed for anambulatory setting and a Complete EHRdesigned for an inpatient setting both tomeet the definition of Certified EHRTechnology, even though each iscompliant with a slightly different set ofapplicable certification criteria. In thatregard, we believe we have integrated a

balanced and appropriate amount offlexibility into the definition of CertifiedEHR Technology, which will also allowus to make additional refinements overtime. We believe that it is possible based

on industry need for us to specify in afuture rulemaking sets of applicablecertification criteria for Complete EHRsand EHR Modules designed forparticular clinical settings.

9. Definition of Human Readable Format

Comments. A number of commentersacross several certification criteriarequested that we clarify the meaning of‘‘human readable format.’’ Thesecommenters questioned what humanreadable format meant when it was usedin the certification criteria and offeredexamples of what they thought wouldconstitute human readable format suchas, style sheets and PDFs. A couple ofcommenters suggested that humanreadable format should considerpatients’ linguistic needs. A commenterrequested we discuss the compliancerequirements associated with theAmericans with Disabilities Act and therelevant sections of the RehabilitationAct of 1973 to ensure human readableformat was meant to include anobligation to provide people withdisabilities alternative formats such aslarge print or Braille.


8/13/2019 2010-17210



Response. In the Interim Final Rule,we discussed the meaning of humanreadable format and provided examplesof what we believe would constitutehuman readable format. We reiteratethat discussion below.

We believe that in order to recognize theenormous potential of HIT, greaterstandardization in future years is necessary.

In that regard, we recognize that moreadvanced interoperability requires healthinformation to be represented by specificvocabularies and code sets that can beinterpreted by EHR technology as well asconverted and presented in a readable formatto the users of such technology. At thepresent time we recognize that implementingcertain vocabularies and code sets in EHRtechnology is a difficult, technicalundertaking. For that reason, we have notadopted specific vocabularies and code setsfor a number of the exchange purposes * * *We have, however, as a transitional step,adopted certification criteria that requireCertified EHR Technology to be capable ofpresenting health information received in

human readable format. By human readableformat, we mean a format that enables ahuman to read and easily comprehend theinformation presented to them regardless ofthe method of presentation (e.g., computerscreen, handheld device, electronicdocument). This would likely requireinformation in coded or machine readableformat to be converted to, for example, itsnarrative English language description. In aneffort to further the transition to, andprevalence of, more specific vocabularies andcode sets, we are interested in publiccomment regarding industry readiness if wewere to adopt certification criteria requiringthe use of additional vocabularies and codesets in parallel with meaningful use Stage 2.

Such certification criteria could include notonly that Certified EHR Technology becapable of presenting information in humanreadable format but also that it be capable ofautomatically incorporating certainvocabulary or code sets (i.e., machinereadable information).

The term human readable format isused in two contexts, when codedhealth information should be displayedto an eligible professional or (to a healthcare professional within) an eligiblehospital using Certified EHRTechnology and in the circumstanceswhere Certified EHR Technology must

be capable of generating an electroniccopy of health information forindividuals. Each context may dictate adifferent human readable format. Forexample, the use of a style sheet may beappropriate for both health careprofessionals that are interacting withCertified EHR Technology as well asindividuals who receive an electroniccopy of their health information toaccess at a later time. In othercircumstances it may be moreappropriate for a health careprofessional to view health information

in human readable format on theirhandheld device while an individualmay seek an electronic document, suchas a PDF. Given the requests foradditional clarity regarding the meaningof human readable format, we havedecided to define the term in this finalrule as follows: Human readable formatmeans a format that enables a human to

read and easily comprehend theinformation presented to him or herregardless of the method of presentation(e.g., computer screen, handheld device,electronic document).

We noted in the Interim Final Rulethat the standards, implementationspecifications, and certification criteriaadopted by the Secretary applied toComplete EHRs and EHR Modules, notto persons or entities. We also statedthat nothing required by the InterimFinal Rule should be construed asaffecting existing legal requirementsunder other Federal laws. Accordingly,

this final rule does not affect an eligibleprofessional or eligible hospital’srequirements to comply with otherFederal laws in the event healthinformation is provided in humanreadable format and persons withdisabilities require reasonableaccommodations.

10. Definition of User

Comments. A number of commenterscommenting on several certificationcriteria requested that we clarify themeaning of the term ‘‘user.’’

Response. We recognize that the termuser is referenced in the certificationcriteria and at times could beinterpreted differently. We believe thisflexibility is necessary because a usermay be different depending on thecertification criterion and the contextwithin which the capability it specifiesis used. Accordingly, we believe a usercould be a health care professional oroffice staff, someone who might interactdirectly with Certified EHR Technologyor that it could also be software programor service.

D. Final Rule Amendments to AdoptedStandards, Implementation

Specifications, and Certification Criteria§§ 170.202, 170.205, 170.207, 170.210,170.302, 170.304, 170.306

1. Flexibility and Innovation

Comments. Many commentersrequested that we provide moreflexibility in the final rule toaccommodate new developments inHIT. These commenters agreed with ourapproach to identify minimumstandards for certain code sets and theyrecommended a similar approach forother standards. Some commenters

suggested alternative approaches toadopting standards, such as adoptingstandards at a higher level of abstraction(e.g., HL7 2.x, where ‘‘x’’ could be anyversion within the version 2 family) andaccompanying the adopted standardswith detailed implementationspecifications or guidance outside of therulemaking process.

Response. We appreciate commenters’support for the ‘‘minimum standard’’

approach that we established in theInterim Final Rule. We believe that codesets are an appropriate type of standardto set as a ‘‘minimum.’’ In the TemporaryCertification Program final rule, wediscuss the approaches available to theSecretary to identify and accept newerversions of adopted minimum code setstandards. Below, we discuss how wehave added flexibility into this final ruleand how we can add flexibility in futurerulemakings.

In many cases, however, ourflexibility may be limited due to legalrequirements to adopt substantiverequirements through following theprocedures of the AdministrativeProcedure Act (APA). Depending uponthe circumstances and subject matter,we may not be able to alter thesubstantive standards that apply toCertified EHR Technology solelythrough guidance. In addition, a realand practical need to ensure consistencyamong various standards regulationsconstrains the amount of flexibility wecan incorporate into the standards weadopt.

In addition, in accordance with Office

of the Federal Register regulationsrelated to ‘‘incorporation by reference,’’which we follow for this final rule, thepublications we reference are ‘‘limited tothe edition of the publication that isapproved’’ and do not include ‘‘[f]utureamendments or revisions of thepublication.’’ Consequently, we do notinclude regulatory language that refers,for instance, to ‘‘Version 1.X’’ when ‘‘X’’

remains a variable.We do believe, however, that

additional flexibility can be added intothis and future rulemakings through atleast one of four currently identified

means:• Alternative Standards. In theInterim Final Rule and in this final rule,we have adopted ‘‘alternative’’ standards(and applicable implementationspecifications) for several certificationcriteria. As a general rule, when anadopted certification criterion refers totwo or more standards as alternatives,use of at least one of the alternativestandards will be considered compliantwith the certification criterion. For thecertification criterion at §170.302(k)(1),for instance, we have adopted HL7 2.3.1


8/13/2019 2010-17210



and HL7 2.5.1 as alternatives, and theuse of either standard (and theapplicable implementationspecifications) would be sufficient tocomply with the certification criterion.In each of these instances, we have triedto balance the need for flexibility withthe goal of advancing interoperability,while also taking into account that the

HIT industry has not yet migrated to asingle specific standard for certainpurposes. In some cases, this balancinghas required the adoption ofcertification criteria that requires certainEHR technology to be capable ofreceiving electronic health informationformatted according to a standard that itis not natively capable of generating. Forexample, with respect to patientsummary records, we have adopted theContinuity of Care Document andContinuity of Care Record standards asalternatives. As a condition ofcertification, section 170.304(i)(1)

provides as an additional requirementthat upon receipt of a patient summaryrecord formatted in the alternativestandard, the EHR technology must becapable of displaying the patientsummary record in human readableformat. We believe this final rulecorrectly balances at this stage of EHRadoption our goal of promotinginteroperability with the HIT industry’sability to comply with the certificationcriteria and its need for flexibility.Consistent with our long-term goals forinteroperability, we anticipate that this

balance will need to change as the HITindustry migrates to single specificstandards for particular purposes.• Minimum Code Set Standards. As

previously discussed in the InterimFinal Rule, we adopted severalminimum code set standards. It isimportant to note that these code setstandards set the floor, not the ceiling,for testing and certification. If, andwhen, the Secretary accepts a newerversion of an adopted minimumstandard code set, the Secretary will, ineffect, raise the ceiling for what ispermitted for testing and certification aswell as whether Certified EHRTechnology can be upgraded to that

newer version without adverselyaffecting the Certified EHR Technology’scertified status. For context purposes werepeat a portion of the Interim FinalRule’s preamble that discussed ourapproach to minimum code setstandards.

We have implemented this approach bypreceding references to specific adoptedstandards with the phrase, ‘at a minimum.’In those instances, the certification criterionrequires compliance with the version of thecode set that has been adopted throughincorporation by reference, or any

subsequently released version of the code set.This approach will permit Complete EHRsand EHR Modules to be tested and certified,to, ‘at a minimum,’ the version of thestandard that has been adopted or a morecurrent or subsequently released version.

We would note that consistent withthis approach the Secretary hasproactively identified and deemed

acceptable newer versions of thefollowing adopted ‘‘minimum standard’’

code sets:(1) LOINC version 2.3, released on

February 26, 2010; and(2) CVX—Vaccines Administered,

March 17, 2010.We are consequently using this

opportunity to inform Complete EHRand EHR Module developers,prospective ONC-Authorized Testingand Certification Bodies, and the rest ofthe public of the Secretary’s recognitionof these newer versions of certainadopted ‘‘minimum standard’’ code sets.We reiterate that use of these newer

versions is voluntary. We also note inaccordance with 45 CFR 170.455(b)(2)that Certified EHR Technology may beupgraded to comply with these newerversions at any time without adverselyaffecting the certification status of theCertified EHR Technology.

• Optional Standards,Implementation Specifications, andCertification Criteria. We believe thatadditional flexibility and specificity can

be introduced into this and future cyclesof rulemaking through the adoption anddesignation of ‘‘optional’’ standards,implementation specifications, and

certification criteria. Optionalstandards, implementationspecifications, and certification criteriawould be voluntary and would not berequired for testing and certifying aComplete EHR or EHR Module. We

believe that optional standards,implementation specifications, andcertification criteria will also help betterprepare the HIT industry for futuremandatory certification requirements.

• Standards and BackwardsCompatibility. In previous rulemakings,specifically the Secretary’s adoption ofelectronic prescribing (e-prescribing)

standards (70 FR 67579) related to theMedicare Part D prescription drugprogram, HHS discussed a process toimprove flexibility in regulatoryrequirements which involves‘‘ backwards compatibility.’’ HHSdescribed backwards compatibility asmeaning that a newer version of astandard retains at a minimum the fullfunctionality of the version previouslyadopted in regulation, and that thenewer version would permit thesuccessful completion of the applicabletransaction(s) with entities that continue

to use the older version(s). HHSdiscussed that if a newer version of astandard were backward compatiblewith an adopted standard, it would bepossible to pursue a more expeditedapproach to permit the utilization of thenewer version while still remaining incompliance with the law. We believethat the approach established in the

e-prescribing rulemaking could beleveraged in many situations for thestandards and implementationspecifications adopted for HITcertification. However, we note that thisapproach can only be implementedwhen a newer version of a standard istechnically capable of fully functioningwith the adopted version of the standardto conduct the specified transaction.

Much like minimum code setstandards, we could foresee possiblyadopting a backward compatible versionof a previously adopted standard andallowing entities to voluntarily use the

newer version for a period of time. Insuch cases, much like a minimum codeset standard, Complete EHR and EHRModule developers would be permittedto have their Complete EHR or EHRModule certified according to theadopted backward compatible version,and eligible professionals and eligiblehospitals in possession of Certified EHRTechnology would be permitted toupgrade voluntarily their Certified EHRTechnology to include the adopted

backwards compatible version. Giventhat we anticipate adopting new ormodified standards, implementationspecifications, and certification criteria

every two years in sync with theinitiation of a new meaningful use stage,we believe that the Secretary’s adoptionof backward compatible versions ofstandards would generally be limited tointermediate years (i.e., 2012 and 2014).To accomplish the adoption of a

backwards compatible version, wewould take an approach very similar tothe approach described in the finale-prescribing regulation.

We would first review whether thenew version of an adopted standardretains at a minimum the fullfunctionality of the adopted version of

the standard as well as whether itenables the successful completion of theapplicable transaction(s) with entitiesthat continue to use the older version(s).We would then review whether astandard should be updated with a newversion and whether use of either thenew version or the older version would

be considered compliant as well aswhether use of the new version wouldconflict with any already existingregulatory requirements. If we believethat the Secretary’s adoption of a newerversion of a standard on a voluntary


8/13/2019 2010-17210



basis would be appropriate, we wouldthen seek the advice of the HITStandards Committee to evaluate thenewer version of the standard and tosolicit relevant public input. TheSecretary would then recognize or adoptfor voluntary use the new version of thestandard in a Federal Registerpublication. At that point, use of either

the new or old version would beconsidered compliant. Entities thatwould voluntarily adopt the later

backward compatible version of thestandard would remain obligated toaccommodate the earlier adoptedversion without modification. Prior tothe Department formally retiring theolder version of the standard andmandating the use of the later version,the Department would engage in noticeand comment rulemaking.

2. Transport Standards

Comments. Generally, commenters

echoed one of two responses: Someurged for the complete removal of SOAPand REST and others requested that weprovide detailed implementationspecifications for SOAP and REST alongwith the identification of thetransactions to which SOAP and RESTwere applicable. Some commenters alsostated that neither standard wassufficiently specified in order to ensureinteroperability, while others pointedout that it appeared that we had globallyapplied the usage of SOAP or REST to

all adopted standards, which, if true,would cause conflicts with severaladopted standards (e.g., it was notedthat the HL7 standards we adoptedutilize Minimum Lower Layer Protocol(MLLP) as the transport standard andnot SOAP or REST).

Response. We have considered the

public comments received on thismatter and we are convinced that it isprudent to remove the adoptedstandards, SOAP and REST. We did notintend for the significant potentialconflicts identified by commenters tooccur as a result of our adoption ofSOAP and REST. We have determinedthat it would be more appropriate andreasonable for us not to require at thepresent time specific transportstandards as a condition of certification.We hope that this will reduce some ofthe burden on Complete EHR and EHRModule developers and provide greater

opportunities for innovation. With thatsaid, we plan to carefully watch theimpact of this decision and its affect oninteroperability. We encourageComplete EHR and EHR Moduledevelopers to utilize transport standardsthat will help the industry coalescearound common methods for electronichealth information exchange, and weplan to examine this decision in futurerulemakings.

3. Certification Criteria and AssociatedStandards and ImplementationSpecifications

We have organized our discussion ofthe final certification criteria accordingto the order in which they are currentlyspecified at 45 CFR 170 subpart C. Wenote that the final regulatory citations

will have changed for many certificationcriteria and encourage the public toreview, in full, the final regulatory textspecified in subpart C of part 170 in theregulation text of this final rule. We

begin with the certification criteria at 45CFR 170.302 (general certificationcriteria for Complete EHRs and EHRModules), move on to 45 CFR 170.304(specific certification criteria forComplete EHRs and EHR Modulesdesigned for an ambulatory setting) andend with 45 CFR 170.306 (specificcertification criteria for Complete EHRsor EHR Modules designed for aninpatient setting). We also include,where appropriate, a discussion of theadopted standard(s) andimplementation specificationsassociated with each certificationcriterion. For each final certificationcriterion, we start with an overview ofthe final version and then discuss andrespond to public comments.

a. General Certification for CompleteEHRs or EHR Modules—§ 170.302

Section 170.302(a)—Drug-Drug, Drug-Allergy, Drug-Formulary Checks

Meaningful use Stage 1 objectiveMeaningful use

Stage 1 measure

Certification criterion

Implement drug-drug and drug-al-lergy interaction checks.

The EP/eligible hospital/CAH hasenabled this functionality for theentire EHR reporting period.

Interim Final Rule Text:(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, medicationallergy list, age, and computerized provider order entry(CPOE).

(3) Customization. Provide certain users with administrator rightsto deactivate, modify, and add rules for drug-drug and drug-al-lergy checking.

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

Final Rule Text: §170.302(a).(1) Notifications. Automatically and electronically generate and

indicate in real-time, notifications at the point of care for drug-

drug and drug-allergy contraindications based on medicationlist, medication allergy list, and computerized provider orderentry (CPOE).

(2) Adjustments. Provide certain users with the ability to adjustnotifications provided for drug-drug and drug-allergy interactionchecks.


8/13/2019 2010-17210



Meaningful use Stage 1 objective Meaningful useStage 1 measure

Certification criterion

Implement drug-formulary checks ... The EP/eligible hospital/CAH hasenabled this functionality andhas access to at least one inter-nal or external drug formularyfor the entire EHR reporting pe-riod.

Interim Final Rule Text:(2) Formulary checks. Enable a user to electronically check if

drugs are in a formulary or preferred drug list in accordancewith the standard specified in §170.205(b).

Final Rule Text: §170.302(b).Drug-formulary checks. Enable a user to electronically check if

drugs are in a formulary or preferred drug list.

Comments. Based on the examplegiven in the preamble of the InterimFinal Rule, several commenters believedthat we required real-time alerts toutilize a pop-up message or sound.Commenters stated that the method ofdelivering real-time alerts should not beincluded in the regulation as it wouldrestrain innovation. One commenterexpressed concern that the requirementsof this certification criterion were overlyspecific with respect to how theCertified EHR Technology needed to

perform the tasks rather than focusingon the desired result. The commenterrecommended the certification criterion

be modified to ensure that such alertsare clearly visible to the physicians atthe point-of-care. Some commentersrecommended that the term‘‘notification’’ should replace the term‘‘alert’’ for this and other certificationcriterion because the term alert implieda particular implementation whereasnotification was more neutral.

Response. Unfortunately, many of thecommenters who reacted to our examplealso believed that it was a requirement.

We simply added the example of a pop-up message or sound in the preamble ofthe Interim Final Rule to make therequirement clear. The use of a pop-upmessage or sound was not a specifiedrequirement in the regulation text. Weagree with the commenters whoexplained that there may be better waysto provide alerts. For the purposes oftesting and certification, we leave itentirely up to Complete EHR and EHRModule developers to innovate in thisarea and provide capabilities that are

both easy to use and prevent medicalerrors. Additionally, we agree with the

commenters who suggested that wereplace ‘‘alert’’ with ‘‘notification,’’ andwe have made that change globallyacross all certification criteria that usedthe term alert.

Comments. A few commentersrequested clarification of therequirement to track and report on thenumber of alerts responded to by a user.A commenter requested clarification onwhy the number of alerts is captured butnot what the user did with the alert andif this data is going to be used to rateproviders based upon the number of

alerts they received. Two commentersrequested that ‘‘responded to by a user’’

be clarified and asked whether it meantthat a user had taken a different actionas a result of the alert. One commenterrecommended removing the alertrequirement unless it is more clearlyspecified. One commenterrecommended deleting the requirementon alert statistics because it could leadto alert fatigue. A few commentersexpressed concern about the ability todeactivate, modify, and add rules for

drug-drug and drug-allergy checking.These commenters recommended thatthis capability be removed because ofthe risk to patient safety. A commenternoted that treating physicians shouldhave the ability to ignore alerts in lightof other clinical facts about the patientand felt that providing the ability todelete or modify alerts in a way thatwould be inconsistent with currentmedical standards would beirresponsible and contrary to themeaningful use goal of preserving thehealth and safety of patients. Othercommenters requested clarification as to

whether the ability to‘‘deactivate

’’rulesimplied the ability to remove specific

rules or drug pairs as they exist incommercially-available clinical decisionsupport (CDS) databases; the ability to‘‘modify’’ rules implied that anadministrator would be able to changethe rules as they exist in thesecommercially-available CDS databases;and the ability to ‘‘add’’ new rulesimplied that the administrator couldcreate new rules incommercially-available CDS databases.The commenters interpreted ‘‘modify’’ tomean, for example, the ability to

override or change severity setting; and‘‘add’’ to mean activating a category ofCDS, such as drug-drug interactions, butnot individual rules; and ‘‘deactivate’’ asthe ability to ‘‘turn off ’’ specific types ofrules. Another commenter requestedclarification as to whether therequirement for customization would bemet if a system administrator were to setthe selected severity level to reflect thecollective decision of a practice or ifalerts must be tailored on an EP-by-EP

basis. A commenter requestedclarification on what qualifies as a

‘‘response’’ to an alert. One commenterrecommended that the rule clarify that‘‘responded to by a user’’ means in a waywhich meaningfully addresses thealerts. A couple of commenters statedthat centrally hosted services wouldhave problems complying with thecustomization requirements because thehosting vendor takes responsibility forthe administration, maintenance andupdating of the clinical decisionsupport rules including alerts for druginteractions alerts, including drug-drug,

drug-allergy and drug-problem. Thesecommenters were concerned thatallowing each of their clients to createlocal drug-interaction rules would slowtheir ability to provide importantupdates to their client base, since thiswould require navigation of a complexhierarchy of preferred local rules. Theselocal rules would also introduce clinicalrisk if old local rules could create aconflict with a clinically appropriateglobal, updated rule.

Response. Based on the significantnumber of comments presenting diverseinterpretations of these provisions, we

determined that this certificationcriterion needed further clarificationand have revised it accordingly. Ourintention related to the alert statisticscapability had been to mirror theclinical decision support capability.With respect to customization, wesought to provide users of Certified EHRTechnology with a way to adjust theseverity level for which alerts arepresented. In response to publiccomment, and to clarify what we believeCertified EHR Technology must includeas a condition of certification, we haveremoved the ‘‘alert statistics’’ part of the

certification criterion altogether andrevised the ‘‘customization’’ part of thecertification criterion to more clearlyspecify this capability. Our revisionsfocus on Certified EHR Technology’scapability to allow certain users (e.g.,those with administrator rights) with theability to adjust notifications providedfor drug-drug and drug-allergy checks(e.g., set the level of severity for whichnotifications are presented).

Comment. A commenter stated thatuse of age as a required data element inthis certification criterion is a problem


8/13/2019 2010-17210



because drug databases handle age innon-standard ways. It was also statedthat for geriatric patients weight is alsoconsidered along with age.

Response. We agree with thiscommenter. After considering thiscomment, particularly in light of thepotentially divergent interpretations ofthis certification criterion we noted

above, we have removed ‘‘age’’ from thecertification criterion. It was never ourintention, as could have beenanticipated, to require that CertifiedEHR Technology be capable ofperforming checks that relate type ordosage of drugs to the patient’s age, or‘‘drug-age checks.’’

Comment. A commenter encouragedONC to add adverse drug events to thecertification criterion and to identifycandidate standards for its inclusion tosupport meaningful use Stage 2.

Response. We appreciate thesuggestion and believe that identifyingadverse drug events is important.Because the final meaningful use Stage1 requirements under the Medicare andMedicaid EHR incentive programs donot include such a requirement, though,we do not believe that it would beappropriate at the present time to addsuch a requirement as a condition ofcertification. This does not precludeComplete EHR or EHR Moduledevelopers from including suchfunctionality.

Comment. A couple of commentersrequested clarification on what CPOEmeans in the certification criterion. Acommenter requested that ONC clarify

that this certification criterion appliesonly to the order-entry workflow and isnot applicable to other office processesor workflows which might involve thesame clinical data but which would notnecessarily generate these alerts.

Response. We clarify for commentersthat our inclusion of CPOE in thecertification criterion is meant toindicate that notifications should occur

based on new medication orders, inaddition to a patient’s currentmedications and medication allergies, asthey are being entered. In response tothe other commenter’s request for

clarification, we believe thatnotifications will occur during theorder-entry workflow.

Comment. A commenter requestedthat the rule be clarified to explicitlyrequire that drug-drug, drug-allergy, anddrug formulary checks occur based oninformation and medication lists in anindividual’s complete medical recordderived from all relevant providers, notonly the drug list of the specificprovider.

Response. We clarify that we expectCertified EHR Technology to perform

drug-drug and drug-allergy checks basedon medication list and medicationallergy list information included withinCertified EHR Technology as structureddata. We recognize that Certified EHRTechnology may also store healthinformation in scanned documents,images, and other non-interoperablenon-computable formats and,

consequently, do not expect CertifiedEHR Technology to be capable ofreading or accessing the information inthese other formats for the purposes ofperforming drug-drug and drug-allergychecks.

Comment. A commenter requestedthat ONC clarify that EHR vendors willnot be required to remove the option todisable drug-drug and drug-allergychecks.

Response. While we do not requirethat the option to disable drug-drug anddrug-allergy checks be removed as acondition of certification, we note thatin order for an eligible professional oreligible hospital to become a meaningfuluser of Certified EHR Technology thiscapability must be enabled.

Comments. Several commenters notedthat the NCPDP Formulary and Benefitsstandard is not used in an inpatientsetting. The commenters consequentlyrequested clarification as to how thestandard can be used in an inpatientsetting. Some of the commenters notedthat for inpatient settings, hospitalstypically relied on their ownformularies for performing the types ofchecks specified. Another commenterrequested clarification whether the

correct content exchange standard wasNational Council for Prescription DrugPrograms (NCPDP) Formulary andBenefits Standard version 1.0 and that ifit was, the commenter recommended itsadoption. Another commenter notedthat some State Medicaid formulariesare not yet available via nationwide e-prescribing networks and recommendedthat ONC encourage the implementationof State Medicaid formularies within theNCPDP Formulary and BenefitsStandard via a nationwide e-prescribingnetwork.

Response. We agree with those

commenters who identified theinconsistency of applying the Formularyand Benefits standard to the inpatientsetting. Because the CMS proposedmeaningful use objectives applied to

both eligible professionals and eligiblehospitals, we did not make thedistinction as to when a Complete EHRor EHR Module would need to includethe Formulary and Benefits standard.However, in light of these commentsand to support the final meaningful usemeasure, we have determined that itwould be appropriate to adopt a more

general certification criterion that would be applicable to both Complete EHRsand EHR Modules designed forambulatory and inpatient settings.Accordingly, we have removed anyreference to a particular standard

because an eligible professional oreligible hospital that does not haveexternal access to a drug formulary

would be able to satisfy this meaningfuluse measure by checking an internallymanaged drug formulary. Although theFormulary and Benefits standard is nolonger required as a condition ofcertification, we note that eligibleprofessionals who seek to comply withthe electronic prescribing requirementsassociated with Medicare Part D eligibleindividuals will need to use thisstandard as they do today. Additionally,we do not agree that it is within thescope of this rulemaking to addressState Medicaid Agencies’ participationin nationwide e-prescribing networks.

Comments. Many commenters notedthat the drug-formulary requirementshould not apply to Complete EHRs andEHR Modules designed for an inpatientsetting because there was no proposedrequirement for meaningful use Stage 1for eligible hospitals to electronicallyprescribe. Many of the commentersrecommended removing this as arequirement for eligible hospitals whileretaining it with the criteria for eligibleprofessionals. A few commentersspecifically recommended adding it tothe criterion for electronic prescribing.Several commenters recommended thatif the requirement were kept for

hospitals it should be written as aseparate criterion to address the queryof a hospital’s drug formulary during theorder entry process and not the NCPDPFormulary and Benefits standard. Acommenter stated that current industrypractice among vendors of EHRtechnology is to provide a ‘‘generic’’

national formulary rather than theformulary for a particular plan. Thecommenter recommended that thefunctionality require that a user actuallyperform an eligibility check beforeaccess is provided and, in response tothat check, the functionality show the

correct formulary and benefitsinformation, rather than just genericdata.

Response. We believe that ourdiscussion above regarding the removalof the standard associated with thiscertification criterion addresses many ofthe concerns raised by commenters.However, we disagree with thesuggestion that Complete EHRs and EHRModules designed for an inpatientsetting should not be required toinclude this capability. This capabilityis required to be enabled for the


8/13/2019 2010-17210



purposes of meeting the meaningful useStage 1 measure. Consistent with thefinal meaningful use Stage 1 objectiveswhich separated drug-drug and drug-allergy checks from drug-formularychecks, we have separated out thesecapabilities into two differentcertification criteria.

Comments. A commenter stated aconcern that this criterion, combinedwith future meaningful userequirements, will shift providers’ focusfrom prescribing the best drug for thepatient to prescribing what is covered

by the patient’s insurance plan orgeneric brands. Another commenterstated that adding formulary checks tothe workload of physicians willdecrease physicians’ efficiency andincrease their costs.

Response. In this rule, the Secretary iscompleting the adoption of the initialset of standards, implementationspecifications, and certification criteriafor the certification of Complete EHRsand EHR modules. The certificationcriteria ensure that Certified EHRTechnology includes certaincapabilities. The extent to which health

care providers must use thosecapabilities and how they integrate EHRtechnology into their practice fallsoutside the scope of this rule. Wetherefore do not believe that theseconcerns are within the scope of thisrulemaking.

Comment. A commenterrecommended that ‘‘drug-test checks’’

should be added. The commenter statedthat many drugs require some form of

laboratory testing to ensure that drugsare prescribed appropriately. Thecommenter stated, for example, that ananticoagulant medication should not beprescribed unless there is a test resulton record that shows that giving thisdrug would not cause harm.

Response. Presently, drug-testchecking is not a required capability for

eligible professionals and eligiblehospitals to use in order to successfullymeet the requirements of meaningfuluse Stage 1. Accordingly, we do not

believe that it would be appropriate torequire Certified EHR Technology to becapable of performing drug-test checksas a condition of certification at thepresent time.

Section 170.302(b)—Maintain Up-To-Date Problem List

Meaningful use stage 1 objective Meaningful use stage 1 measure Certification criterion

Maintain an up-to-date problem listof current and active diagnoses.

More than 80% of all unique pa-tients seen by the EP or admit-ted to the eligible hospital’s orCAH’s inpatient or emergencydepartment (POS 21 or 23)have at least one entry or an in-dication that no problems areknown for the patient recordedas structured data.

Interim Final Rule Text:Maintain up-to-date problem list. Enable a user to electronically

record, modify, and retrieve a patient’s problem list for longitu-dinal 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).Final Rule Text: §170.302(c).

Final rule text remains the same as Interim Final Rule text, ex-cept for references to adopted standards, which have beenchanged.

Comments. Several commentersexpressed concerns about the use of

ICD–9–CM because it is primarily usedfor billing and administrative purposesand may not accurately represent thetrue clinical meaning of a problem orcondition when it is documented at thepoint of care. One commenter stated aconcern that the problem list standardsdo not allow for capturing of free textthat health care providers use when anappropriate code is in neitherSNOMED–CT® nor ICD–9–CM.

Response. The comments are correctin that ICD–9–CM is primarily used for

billing and administrative purposes.SNOMED–CT® is offered as an

alternative standard that will supportmore clinical descriptions of patientproblems or conditions. We believe thatwith the adoption of both SNOMED–CT® and ICD–9–CM, healthcareproviders should have adequatecoverage for patient diagnoses andconditions. We are discouraging the useof free text for documenting problemlists since this will limit the usefulnessof problem lists for clinical reminders,decision support and other patientsafety and quality reporting.

Comments. Several commentersrecommended that only SNOMED–CT®

be adopted, or alternatively, that weexpressly indicate an intention to moveaway from ICD–9CM and ICD–10 in thefuture. Another commenterrecommended against the adoption ofSNOMED–CT® because the commenterfelt that our adoption of SNOMED–CT® would require eligible professionals andeligible hospitals to use both ICD–9–CMand SNOMED–CT®. One commenterrecommended that a publicly vetted andHHS approved standard mapping

between ICD–9–CM and SNOMED CT® should be made available at the public’sexpense.

Response. We agree conceptually thata single standard for clinicalinformation would be desirable in thelong term. However, presently bothICD–9–CM and SNOMED–CT® are used

by EHR technology to code clinicalinformation, and adopting both wouldprovide users with additional flexibility.Moreover, we anticipate that asmeaningful use objectives and measuresevolve over time, we will receiveadditional public input and experiencerelated to these standards and may

eventually be able to adopt only onestandard.

Comments. A few commenters askedfor clarification as to whetherSNOMED–CT® or ICD–9CM codesneeded to be included within CertifiedEHR Technology or if these standardswere only necessary when electronichealth information is exchanged. Someof these commenters also requested thatwe permit any coding system to be usedas long as it can be mapped to theappropriate format when electronichealth information is to be exchanged.

Response. As previously discussed,meaningful use requirements willtypically specify whether an adoptedstandard will have to be used amongcomponents of a business organizationor solely for the electronic exchange ofhealth information with other legalentities. The measure for this finalmeaningful use objective provides thatentries be recorded as structured data.The certification criterion specifies thatICD–9CM or SNOMED–CT® are thecode sets which must be included inCertified EHR Technology, and aretherefore the code sets that would beused to record entries as structured data.


8/13/2019 2010-17210



Comments. A few commentersrecommended the removal of‘‘longitudinal care’’ in the certificationcriterion. These commenters cited ourclarification in the preamble that bylongitudinal care we meant ‘‘overmultiple office visits.’’ Thesecommenters questioned how thislanguage would be applicable to an

inpatient setting since patients aretypically treated for acute episodes andnot over multiple office visits.

Response. The reference tolongitudinal care is intended to conveythat the problem list must becomprehensive in the sense that it must

be capable of including entries providedover an extended period of time.Consequently, for Complete EHRs andEHR Modules to be certified for anambulatory setting, they will need to bedesigned to enable the user toelectronically record, modify, andretrieve a patient’s problem list overmultiple encounters. For an inpatientsetting, they will need to enable the userto electronically record, modify, andretrieve a patient’s problem list for theduration of an entire hospitalization.This clarification was also requested inrelation to the medication list andmedication allergy list certification

criteria and we have not repeated ourresponse. As a result, we have retained‘‘longitudinal care’’ in each certificationcriterion where the term is referencedand only make this clarification once.

Comment. A commenter suggestedthat we include a reasonableexpectation of what constitutes ‘‘up-to-date’’ in the reference to ‘‘up-to-date’’

problem list.Response. We referred this comment

to CMS, and it is addressed in the finalrule on the Medicare and Medicaid EHRIncentive Programs.

Section 170.302(c)—Maintain ActiveMedication List


Maintain active medication list ........ More than 80% of all unique pa-tients seen by the EP or admit-ted to the eligible hospital’s orCAH’s inpatient or emergencydepartment (POS 21 or 23)have at least one entry (or anindication that the patient is notcurrently prescribed any medica-tion) recorded as structured data.

Interim Final Rule Text:Maintain active medication list. Enable a user to electronically

record, modify, and retrieve a patient’s active medication listas well as medication history for longitudinal care in accord-ance with the standard specified in § 170.205(a)(2)(iv).

Final Rule Text: §170.302(d).Maintain active medication list. Enable a user to electronically

record, modify, and retrieve a patient’s active medication listas well as medication history for longitudinal care.

Comments. A few commenters agreedwith the certification criterion. Onecommenter requested that we providemore clarity on the use of term‘‘retrieve.’’ The commenter questionedwhether we intended to use the word‘‘retrieve’’ in the certification criterion tomean solely the retrieval of informationavailable to Certified EHR Technologyor if we intended for it to also includethe interactive retrieval of medicationlist information from external sources.The commenter suggested we clarifythat ‘‘retrieve’’ meant retrieval of onlyinformation internally available toCertified EHR Technology. Othercommenters, similar to their commentson the problem list certificationcriterion, stated that there needed to bemore clarity with respect to how thereference to ‘‘longitudinal care’’ appliedto a Complete EHR or EHR Module used

by an eligible hospital.

Response. We clarify that for thiscertification criterion, and all othercertification criteria, the term ‘‘retrieve’’

means the retrieval of informationdirectly stored and managed byCertified EHR Technology and that itdoes not mean the retrieval ofinformation from external sources,unless explicitly stated otherwise. Wealso take this opportunity, in the contextof our response regarding ‘‘longitudinalcare’’ above, to clarify that ‘‘medicationhistory’’ is intended to include a recordof prior modifications to a patient’smedications.

Comment. A commenter stated thatthere needs to be more clarity withrespect to whether an EHR Module mustmaintain a list of all active medicationsor if a specialty system, such as acardiology system, could maintain a listof medications specific to its specialtyuse and provide the list to the enterpriseEHR.

Response. If an EHR Module

developer seeks to have its ‘‘medicationlist EHR Module’’ certified, the EHRModule must provide the capabilitiesspecified by the certification criterion.We do not intend to limit how the EHRModule could appropriately providethese capabilities (i.e., whether the EHRModule must itself enable the user toelectronically record, modify, andretrieve a patient’s active medication listfor longitudinal care, or whether theEHR Module could be designed toprovide those capabilities through itsinteraction with a device or devices atthe enterprise level).

Comment. One comment stated thatthis criterion should include a provisionto include the ability to transmit thisinformation to public health entities asrequired by law.

Response. Nothing we adopt in thisfinal rule precludes such a capabilityfrom being included in a Complete EHRor EHR Module. That is not, however,currently a necessary requirement forcertification.

Comments. One commenter statedthat it would need to perform extensivereprogramming to accommodate the

standard we adopted if it meantmodifying underlying medicationdatabases. This commenter suggestedthat this standard as it applied to themaintenance of medication lists bedeferred. Along those lines, a couple ofcommenters stated that moreclarification was needed with respect towhether RxNorm identifiers needed to

be stored internally within Certified

EHR Technology or only needed to beused upon the electronic exchange ofhealth information. Other commentersexpressly stated that the mapping of thevocabulary be limited to instanceswhere the electronic exchange of healthinformation would take place.

Response. We understand thesecommenters’ concerns and agree that itwould be premature to require the useof the adopted standard in this context.In that regard, we seek to clarify forcommenters our intention, which wassolely to associate this adopted standard(as some commenters suggested) with

the certification criteria that require thecapability to electronically exchangehealth information. We recognize thatcontinuing to associate this standardwith the adopted certification criterioncould potentially impose a significant

burden on the industry, which we didnot intend. Accordingly, we haveremoved from this certification criterionthe requirement to use this standard. Wediscuss our response to comments onthe standard itself in the context of thepatient summary record certificationcriterion.


8/13/2019 2010-17210



Section 170.302(d)—Maintain ActiveMedication Allergy List


Maintain active medication allergylist.

More than 80% of all unique pa-tients seen by the EP or admit-ted to the eligible hospital’s orCAH’s inpatient or emergencydepartment (POS 21 or 23)have at least one entry (or anindication that the patient has noknown medication allergies) re-corded as structured data.

Interim Final Rule Text:Maintain active medication allergy list. Enable a user to electroni-

cally record, modify, and retrieve a patient’s active medicationallergy list as well as medication allergy history for longitudinalcare.

Final Rule Text: UnchangedNow § 170.302(e).

Comments. Much like the priorcertification criterion, manycommenters signaled their support forthis certification criterion. Othercommenters raised the same pointsrelated to this certification criterion asthey did for the medication listcertification criterion.

Response. We believe our responsesto the problem list and medication listcertification criteria are applicable tothese repeated comments.

Comments. Many commenterssuggested that non-medication allergies

be added to this certification criterion.A few commenters stated that it couldjeopardize patient safety if not allallergens were included in CertifiedEHR Technology.

Response. Patient safety is one ofHHS’s top priorities. At the present

time, the final meaningful use objectiveand measure focus on medicationallergies. Accordingly, we have adopteda certification criterion to support this

objective and measure. We would like toreiterate, however, that a certificationcriterion sets the floor not the ceiling forthe capabilities Certified EHRTechnology must include. Weencourage Complete EHR and EHRModule developers to provide morecomprehensive capabilities than thosecurrently required for achieving

certification.

Section 170.302(e)—Record and ChartVital Signs


Record and chart changes in vitalsigns:

• Height• Weight• Blood pressure• Calculate and display BMI

• Plot and display growthcharts for children 2–20years, including BMI.

For more than 50% of all uniquepatients age 2 and over seen bythe EP or admitted to eligiblehospital’s or CAH’s inpatient oremergency department (POS 21or 23), height, weight and bloodpressure are recorded as struc-tured data.

Interim Final Rule Text:(1)Vital signs. Enable a user to electronically record, modify, and

retrieve a patient’s vital signs including, at a minimum, theheight, weight, blood pressure, temperature, and pulse.

(2)Calculate body mass index. Automatically calculate and dis-play body mass index (BMI) based on a patient’s height andweight.

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

Final Rule Text: §170.302(f).

(1)Vital signs. Enable a user to electronically record, modify, andretrieve a patient’s vital signs including, at a minimum, height,weight, and blood pressure.

(2) Unchanged(3) Unchanged

Comment. One commenter noted thatthe units of measurement should bespecified in the EHR with regards tovital signs. For example that heightshould be specified in inches orcentimeters.

Response. We do not believe that thislevel of specificity is necessary. We

expect that Complete EHR and EHRModule developers will include theunits of measure that their customers

believe are necessary to meet theirneeds, which in many cases willinclude those that patients routinelyrequest. We also expect that manyComplete EHR and EHR Moduledevelopers will offer both metric unitsand U.S. units of measurement, as astandard business practice.

Comments. In what appeared to be areaction to the proposed meaningful useobjective and measure, some

commenters requested that we removeBMI as part of the certification criterionfor Complete EHR or EHR Modulesdesigned for an inpatient setting. Therationale provided was that acute careproviders would not be required to trackBMI.

Response. While we can understand

these commenters’ concern, we believethat BMI is a simple mathematicalcalculation that Certified EHRTechnology should be capable ofperforming regardless of the setting forwhich it is designed.

Comment. One commenterrecommended that BMI and agecomponents should be used to create analert when an unhealthy BMI isindicated for a patient and that CertifiedEHR Technology should record whetherthe patient was informed of theunhealthy BMI status.

Response. We believe that thisrecommendation is overly specific, ismore germane to meaningful use, andexceeds the type of capability we

believe should be specified as acondition of certification.

Comments. A few commenters notedthis certification criterion applies more

directly to specialties thatpredominantly treat children. For otherspecialties, this criterion would addunnecessary cost and complexity tomany HIT products that they would use.Many commenters suggested that agrowth chart component should not berequired for EHR technology designedfor an inpatient setting, as it is notfeasible to track this data in ameaningful way over a long enoughperiod of time in an inpatient setting(which is typically of a short and


8/13/2019 2010-17210



2Smoking status recodes: http://www.cdc.gov/ nchs/nhis/tobacco/tobacco _recodes.htm.

infrequent duration). A couple ofcommenters suggested that non-traditional forms of growth chartsshould be accepted. One commentersuggested that the certification criterionestablish a baseline, but should not limitthe expansion of this capability to otherages. Other commenters made specificsuggestions for different age ranges,

such as including children under theage of two and lowering the upper ageto ages less than 20 years old (e.g., 18).

Response. As we stated above withrespect to the calculation of BMI, we

believe that Certified EHR Technologyshould be capable of performing thiscapability regardless of the setting forwhich it is designed. Moreover, withrespect to whether growth charts should

be applicable to Complete EHRs andEHR Modules designed for an inpatientsetting, we remind commenters thatchildren’s hospitals qualify as eligiblehospitals under the Medicaid EHRincentive program and will also need todemonstrate meaningful use of CertifiedEHR Technology. We do not precludeComplete EHR and EHR Moduledevelopers from designing novelapproaches to displaying growth charts.Finally, we concur with the commenterthat suggested this certification criterionshould be a baseline. We reiterate that

this certification criterion establishes afloor, not a ceiling, and we encourageComplete EHR and EHR Moduledevelopers to include additionalfunctionality where it will enhance thequality of care that eligible professionalsand eligible hospitals can provide.

Comments. Similar to the commentsabove, many commenters suggested the

growth chart requirement shouldinclude children under age 2. Thecharting would then include: weight,length, pulse oximetry, headcircumference, and blood pressure (withpercentiles based on age and weight).

Response. For Stage 1, the relatedmeaningful use objective addresses ages2–20. In order to remain consistent withand support this objective, we do not

believe that it is necessary at this timeto require a capability for charting anyadditional ages as a condition ofcertification.

Comment. One commenter requestedthat we clarify whether ‘‘plot andelectronically display’’ means to plotheight, weight, and BMI over time oragainst national norms.

Response. We clarify that we expect agrowth chart to plot the height, weight,and BMI over time, as compared tonational norms. While the regulationtext does not specifically requirecomparison to national norms, we

understand that this type of informationis typically provided along with thegrowth chart itself to provide greaterrelevance and meaning for the growthcharts. We encourage Complete EHRand EHR Module developers to includethis feature.

Comment. A commenter suggestedthat SNOMED–CT® be used for

designation of BMI.Response. Although we agree that

SNOMED–CT® could be used to codeBMI, we only require that Certified EHRTechnology be capable of calculatingBMI. We do not believe that it isnecessary, as a condition ofcertification, to specify how BMI should

be coded. That being said, we do notpreclude the use of SNOMED–CT® tocode BMI.

Comment. One commenter suggestedthat the certification criterion should be

better aligned with the final meaningfuluse objective and measure. The

commenter noted that the criterionincludes temperature and pulse, whichis not included in the meaningful useobjective and measure.

Response. We agree with thecomment and have removedtemperature and pulse from thecertification criterion.

Section 170.302(f)—Smoking Status


Record smoking status for patients13 years old or older.

More than 50% of all unique pa-tients 13 years old or older seenby the EP or admitted to the eli-gible hospital’s or CAH’s inpa-tient or emergency department(POS 21 or 23) have smokingstatus recorded as structureddata.

Interim Final Rule Text:Smoking status. Enable a user to electronically record, modify,

and retrieve the smoking status of a patient. Smoking statustypes must include: current smoker, former smoker, or neversmoked.

Final Rule Text: §170.302(g).Smoking status. Enable a user to electronically record, modify,

and retrieve the smoking status of a patient. Smoking statustypes must include: current every day smoker; current someday smoker; former smoker; never smoker; smoker, currentstatus unknown; and unknown if ever smoked.

Comments. Several commentersstated that the smoking statuscertification criterion was overlyprescriptive because it specified certainstatus variables. These commentersagreed that recording smoking status is

crucial to health improvement efforts, but contended that mandating certainfields was the wrong approach. Many ofthese commenters stated that they wereunaware of defined industry standardvalue set for smoking terminology andother suggested that our reference tospecific types of smokers be removed.Others asked whether these variableswere examples or the only responsesallowed. A few commenters agreed withthis certification criterion as reasonableand appropriate because it would

provide value for both clinical care andpublic health. Commentersrecommended that besides what we hadspecified, the certification criterionshould also reference packs per dayhistory information, secondhand smoke

exposure, and alcohol consumptioninformation. Other commentersrecommended that the certificationcriterion be changed to reflect tobaccouse rather than smoking.

Response. We have adopted thiscertification criterion to fully supportthe final meaningful use objective andmeasure, which in response tocomments has been revised to furtherclarify the purpose of the objective andmeasure. We therefore disagree withthose commenters who stated that thiscertification criterion is too prescriptive.

Concurring with CMS, we believe thatthe fields associated with this measureshould mirror those expressed in theCenters for Disease Control andPrevention, National Center for HealthStatistics, National Health Interview

Survey related to smoking statusrecodes.2 Accordingly, the finalcertification criterion further specifiesand slightly broadens the smokingstatuses we expect Certified EHRTechnology to be capable of recording.Generally speaking, we understand thata ‘‘current every day smoker’’ or ‘‘currentsome day smoker’’ is an individual whohas smoked at least 100 cigarettesduring his/her lifetime and still


http://www.cdc.gov/nchs/nhis/tobacco/tobacco_recodes.htm






8/13/2019 2010-17210



3 ftp://ftp.cdc.gov/pub/Health _Statistics/NCHS/datasets/DATA2010/Focusarea27/O2701a.pdf.

regularly smokes everyday orperiodically, yet consistently; a ‘‘formersmoker’’ would be an individual whohas smoked at least 100 cigarettesduring his/her lifetime but does notcurrently smoke; and a ‘‘never smoker’’would be an individual who has notsmoked 100 or more cigarettes during

his/her lifetime.3 The other two statuses(smoker, current status unknown; andunknown if ever smoked) would beavailable if an individual’s smokingstatus is ambiguous. The status ‘‘smoker,current status unknown’’ would apply toindividuals who were known to havesmoked at least 100 cigarettes in the

past, but their whether they currentlystill smoke is unknown. The last statusof ‘‘unknown if ever smoked’’ is self-explanatory.

Section 170.302(g)—IncorporateLaboratory Test Results


Incorporate clinical lab-test resultsinto certified EHR technology asstructured data.

More than 40% of all clinical labtests results ordered by the EPor by an authorized provider ofthe eligible hospital or CAH forpatients admitted to its inpatientor emergency department (POS21 or 23) during the EHR report-ing period whose results are ei-ther in a positive/negative or nu-merical format are incorporatedin certified EHR technology asstructured data.

Interim Final Rule Text:(1) Receive results. Electronically receive clinical laboratory test

results in a structured format and display such results inhuman readable format.

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

(3) Display test report information. Electronically display all theinformation for a test report specified at 42 CFR493.1291(c)(1) through (7).

(4) Update. Enable a user to electronically update a patient’srecord based upon received laboratory test results.

Final Rule Text: §170.302(h).(1) Unchanged.(2) Display test report information. Electronically display all the

information for a test report specified at 42 CFR493.1291(c)(1) through (7).

(3) Incorporate results. Electronically attribute, associate, or linka laboratory test result to a laboratory order or patient record.

Comments on 170.302(g)(1)

Comments. A few commenterssuggested that we specify in theregulation that the reference to receivingclinical laboratory test results in a‘‘structured format’’ means in HL7version 2.3.1 format. These commentersfurther recommended that we refer toHL7 version 2.3.1 within the

certification criterion. Thesecommenters stated that many CompleteEHR and EHR Module developersalready use HL7 2.3.1 and that adoptingit as a standard would spur industry-wide adoption and also set the stage fordriving adoption of future HL7standards, like HL7 2.5.1, in the laterstages of meaningful use. A commenterin support of including HL7 2.3.1 statedthat it was concerned that if we did notspecify a standard for this requirementthat there could be confusion regardingwhich version of the standard should beused, and that laboratories would have

to continue to support multiplestandards. Another commenter alsonoted that we did not specify a standardformat for the laboratory results thatCertified EHR Technology must becapable of receiving. This commenter,however, stated that many EHRs arecompliant with HL7 2.5.1 for thepurposes of receiving laboratory results.The commenter also recommended thatwe apply this certification criterion

differently for ambulatory and inpatientsettings by requiring that CompleteEHRs and EHR Modules designed for anambulatory setting be required toreceive HL7 2.5.1 formatted laboratorytest results and those designed for aninpatient setting be required to receiveHL7 2.3.1 formatted laboratory testresults. One commenter suggested that

our objectives could be better supportedif we stated that in this certificationcriterion a requirement that laboratoryresults must be received electronicallyusing HL7 transactions withimplementation guidance.

Response. While we understand theintent of these commenters’ suggestions,we do not believe that it is within thescope of this rule to dictate the standard

by which laboratories transmit testresults. The scope of this rule is theadoption of certification criteria thatspecify required capabilities of CertifiedEHR Technology (in this case, receiving

laboratory information in structuredformat) and not, in this instance,specifying the standard by whichlaboratories must transmit test results.

Comment. A commenter requestedthat we clarify how this certificationcriterion is applicable to hospitalsettings. The commenter asked whetherwe intended for the capability ofreceiving laboratory test results toinclude results obtained during a

patient’s stay at the hospital or if wemeant to also include the receipt oflaboratory test results from other timeperiods. They suggested requiring onlythose laboratory test results obtainedduring the patient stay.

Response. For the purposes ofdemonstrating compliance with thiscertification criterion, we do not specify

the contexts (e.g., a patient stay) underwhich laboratory test results arereceived. Rather, consistent with themeaningful use objective and measureand the capabilities required by thiscertification criterion, we specify thatwhen laboratory test results are receivedin structured format by Certified EHRTechnology, that the results can beincorporated.

Comment. One commenter requestedthat we clarify whether the structureddata requirement applies to alllaboratories (including reference labs,

hospital labs, physician office labs, andphysicians performing their own labtests).

Response. This certification criterionrequires Complete EHRs and EHRModules to provide the capability toreceive clinical laboratory test results ina structured format as a condition ofcertification. It does not speak to howlaboratories must send the test results.


8/13/2019 2010-17210




Comments. Some commentersrequested clarification on this specificcapability within the certificationcriterion regarding what needed to bedisplayed in the context of LOINCcodes. These commenters suggested thatwe not require the display of the actual

LOINC code, but the descriptionassociated with the LOINC code. Acommenter suggested that we identify asubset of common LOINC codes insteadof requiring that tens of thousands ofLOINC codes be supported for thepurposes of certification. Othercommenters suggested that we offerguidance in the form of a ‘‘starter set’’ ofLOINC codes to encourage the use of thestandard. One commenter requested thatwe confirm its understanding of thisspecific part of the certificationcriterion, which is that Certified EHRTechnology must demonstrate the

capability to import LOINC codedresults from an external source. Finally,one commenter noted that the headingfor the standard at § 170.205(a)(2)(iii)should just refer to ‘‘laboratory testresults’’ and not ‘‘laboratory orders andresults.’’

Response. We clarify that we do notexpect Certified EHR Technology tonatively (or internally) support LOINCin its entirety, which is why we do not

believe that it is necessary to specify asubset of common LOINC codes. Giventhe diverse comments and requests forclarification on this specific aspect of

the certification criterion, we agree withcommenters that we should not requirea LOINC code that has been received, tothen be displayed. Accordingly, wehave decided to remove thisrequirement from the certificationcriterion. We do, however, wish tofurther clarify our current approach toCertified EHR Technology’s use ofLOINC codes. Presently, we expectCertified EHR Technology to be able toreuse a LOINC code once it has beenreceived and is accessible to CertifiedEHR Technology. We do not expect, aswe mention above, that Certified EHR

Technology will have to crosswalk ormap internal or local codes to LOINCcodes. This clarification is applicable tothe standard that we have adoptedregarding LOINC codes now specified at§ 170.207. This response is applicable tosimilar comments we received on othercertification criteria that also referencedthe use of LOINC codes. Finally, weagree with the commenter whosuggested that we revise the heading ofthe standard at § 170.205(a)(2)(iii). Wehave done this as part of the overallrestructuring of the regulation text.


Comments. Some commenters agreedwith the capability specified in170.302(g)(3). One noted a concern thatmodifications to either a certifiedComplete EHR or certified EHR Modulecould potentially result in the failure ofCertified EHR Technology to display thetest report information as required bythe regulations and, thereby, put thelaboratory in technical violation of theCLIA regulations. These commentersreasoned that because a Complete EHRor EHR Module must be tested andcertified to be in compliance with 42CFR 493.1291(c)(1) through (7) thatcertification should replace anyrequirement for the laboratory toconfirm that the information has beenproperly transmitted and meets theCLIA requirements. These commentersalso asserted that a laboratory should berelieved of any further regulatoryresponsibility under 42 CFR

493.1291(c)(1) through (7) for thedisplay of the required reportinformation to the physician orsubsequent viewers of the information ifthe Certified EHR Technology has beenimplemented by an eligible professionalor eligible hospital. One commenterreiterated the point by stating that

because Certified EHR Technologywould be required to display therequired CLIA report elements,laboratories should not be unfairly heldaccountable for any elements that may

be removed or altered by other partiesfrom the test report before received by

the physician.Response. While we can understand

the concern expressed by thesecommenters, we reiterate that the scopeof our authority under this final ruleonly applies to capabilities thatCertified EHR Technology must include.As a result, we cannot provide theregulatory relief that these commentersseek.


Comments. A couple of commentersquestioned whether we intended for the‘‘updates’’ to be manual updates ofelectronic records. If that were true,some commenters were concerned thatwould create workflow problems andreduce the availability of results. Othercommenters suggested that either theuser be able to create an additionalrecord, rather than be permitted tochange the ‘‘official’’ record or that anadequate audit trail be preserved of theexisting data and any updates, since anupdate may result in disparities withthe official record of test results. Thesecommenters wanted to ensure that thelaboratory’s record would be the same

as the record maintained in the EHR.One commenter stated that paragraph(g)(4) could imply process and system

behavior that we did not intend torequire. The commenter stated that it iscommon practice in a hospital settingfor lab results to be transmitted in highvolume from a lab system to an EHR andmade available for review to the

clinician through the EHR, without aneed for a user to review eachtransaction before updating the EHR tomake the results available. Anothercommenter made a similar point andquestioned whether an ‘‘update’’ meantmanual intervention, which they statedwould be impracticable in a hospitalsetting. One commenter stated that mostEHR technology already links orders tolab results in an established way. Thecommenter also indicated that thecertification criterion we adoptedrequires changes to a process that mostEHR developers have already

implemented and introducesinefficiencies for both EHR developersand health care providers.

Response. We appreciate the issuesraised by commenters on this specificcapability and have revised this part ofthe certification criterion to more clearlyexpress our expectation for CertifiedEHR Technology and to be responsive toand consistent with commenters’suggestions. We intended for an updateto mean, as indicated by the meaningfuluse objective and measures, that alaboratory test result would beincorporated in Certified EHRTechnology with the originating

laboratory order or with a patient’srecord in any one of the methodsspecified. Accordingly we have revisedthis specific capability to more clearlyreflect our intent. We believe thisaddresses commenters’ concerns andrequests for clarification and wouldpermit batches of laboratory test resultsto be electronically linked to laboratoryorders or patient records withoutmanual intervention.

Comments. Some commenters notedthat small and medium size practiceshave had a difficult time working withcommercial laboratory vendors to

provide interfaces from which they canreceive lab test results. Thesecommenters noted that laboratoryvendors typically charge too much fortheir services and do not prioritizeestablishing connections with small andmedium size practices because they donot have the same volume of laboratoryreferrals as large practices.

Response. This certification criterionrequires as a condition of certificationthat Certified EHR Technology becapable of supporting electroniclaboratory interfaces. We understand the


8/13/2019 2010-17210



concerns raised by commenterspertaining to the difficulty of certainpractices being able to obtain laboratoryinterfaces and note that the meaningfuluse Stage 1 measure associated with thiscertification criterion is included in the‘‘menu set’’ specified by CMS which we

believe should help assuage somecommenters’ concerns. We do not

believe that the ability of a practice(regardless of size) to obtain an interfaceor other type of connection is an issuethat is within the scope of this final ruleto address.

Comment. One commenterrecommended that we revise thiscertification criterion to require thatlaboratory domain expertise beexhibited when laboratory informationis displayed. The commenter furtherelaborated by stating that laboratoryresults are not homogeneous, and thatspecific laboratory domain expertise is

necessary to design the ways in whichthe data associated with certainlaboratory results (e.g., microbiology,molecular pathology) are displayed inEHR systems to ensure appropriatepresentation and interpretation.

Response. With the exception ofdisplaying the required elementsspecified at 42 CFR 493.1291(c)(1)

through (7), we do not require as acondition of certification any additionaldisplay requirements. Accordingly, wedo not preclude Complete EHR and EHRModule developers from designing morespecific displays of laboratory resultsthat may need to be displayed in a morecomplex fashion.

Comment. One commenter requestedthat we clarify that Certified EHRTechnology did not need to enable theEHR Technology user to receivevoluminous raw or pre-final-report labdata, and further, that not providing this

capability would not disqualify aComplete EHR or EHR Module from

becoming certified.Response. Enabling a Complete EHR

or EHR Module to receive ‘‘raw or pre-final-report lab data’’ is not requiredunder this or any other adoptedcertification criterion.

Comment. One commenter suggestedthat we modify this certificationcriterion to require transmission ofcancer related lab tests and results tocancer registries as required by law.

Response. Because this certificationcriterion is about incorporating lab testresults in Complete EHRs and EHRModules and does not require anyelectronic transmissions, we do not

believe that this is an appropriaterequirement to consider.

Section 170.302(h)—Generate PatientLists


Generate lists of patients by spe-cific conditions to use for qualityimprovement, reduction of dis-parities, research or outreach.

Generate at least one report listingpatients of the EP, eligible hos-pital or CAH with a specific con-dition.

Interim Final Rule Text:Generate patient lists. Enable a user to electronically select, sort,

retrieve, and output a list of patients and patients’ clinical infor-mation, based on user-defined demographic data, medicationlist, and specific conditions.

Final Rule Text: §170.302(i).Generate patient lists. Enable a user to electronically select, sort,

retrieve, and generate lists of patients according to, at a min-imum, the data elements included in:

(1) Problem list;(2) Medication list;(3) Demographics; and(4) Laboratory test results.

Comments. Several commentersrequested clarification regarding the setof variables that should be included inthe demographic information for thepatient lists. Some of these commenterssuggested that the gender, race,ethnicity and preferred language of thepatient should be included in this dataset. One commenter suggested that thefinal rule should explicitly adopt andincorporate the recommendations of areport published by the Institute ofMedicine in mid-2009 entitled, ‘‘Race,Ethnicity and Language Data:Standardization for Health Care Quality

Improvement.’’

Response. We appreciate thecommenters’ suggestions, and we haveused them to clarify this certificationcriterion. It was our intention thatCertified EHR Technology would beable to leverage the information,specifically the structured data it hasavailable to it, to assist eligibleprofessionals and eligible hospitals togenerate patient lists. We have clarifiedthis certification criterion to express thisintent. Accordingly, we expect that

Certified EHR Technology will be ableto generate patient lists according tocertain data elements for whichstructured data will be available:Medical problems; medications;demographics; and laboratory testresults. While we respect the workcompleted by the Institute of Medicine,we do not believe that the public hashad an adequate opportunity to considerits recommendations related todemographics in the context ofcertification, and we are therefore notincluding them as a condition ofcertification at this time. We encourage

the HIT Standards Committee toconsider this report as it recommendsstandards to the National Coordinator.

Comments. Several commentersrequested further clarification regardingthe meaning of ‘‘patient’s clinicalinformation.’’ Other commenters statedthat this phrase was too vague and wasnot included as part of the proposedmeaningful use objective or measureand should therefore be removed. Somecommenters requested further definitionof the term ‘‘specific conditions,’’

particularly to clarify whether this termrefers to problems and diagnoses.Clarification was also requestedregarding whether this informationincludes: a patient summary; thepatient’s entire medical history; andpatient encounter notes. Onecommenter recommended that weclarify how the lists must be structuredand suggested that we specify timeperiods for patient histories. Onecommenter requested clarification of theterm ‘‘output,’’ and suggested that itshould mean to produce a list forinternal use and that it does not refer to

exporting the patient list to a system ordestination external to the office of aneligible professional.

Response. We appreciate the concernsraised by these commenters and afterfurther consideration agree that theterms referenced by commenters could

be interpreted in multiple ways.Accordingly we have removed ‘‘patient’sclinical information’’ and ‘‘specificconditions’’ from the certificationcriterion, and have reframed thecertification criterion to more directly


8/13/2019 2010-17210



align with the meaningful use measure by changing ‘‘output’’ to ‘‘generate.’’ Wesought to clarify that we intended thatCertified EHR technology would becapable of electronically producing or‘‘generating’’ patient lists for an eligibleprofessional or eligible hospital’s

subsequent use. We do not require as acondition of certification that timeperiods be associated with a patient list,

but presumably time (i.e., the age of theinformation) could be one factor aneligible professional or eligible hospitalcould also use to sort their lists (e.g.,

patients with XYZ problem recorded inthe past 3 months). We believe thatthese revisions make this certificationcriterion clearer while addressing thesecommenters’ concerns.

Section 170.302(i)—Report QualityMeasures


Eligible Professionals: Report am-bulatory clinical quality measuresto CMS or the States.

For 2011, provide aggregate nu-merator, denominator, and ex-clusions through attestation asdiscussed in section II(A)(3) of[the Medicare and MedicaidEHR Incentive Programs finalrule].

Interim Final Rule Text:(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 imple-mentation specifications specified in § 170.205(e).

Eligible Hospitals and CAHs: Re-port hospital clinical qualitymeasures to CMS or the States.

For 2012, electronically submit theclinical quality measures as dis-cussed in section II(A)(3) of [theMedicare and Medicaid EHR In-centive Programs final rule].

Final Rule Text: §170.304(j).(1) Calculate.

(i) Electronically calculate all of the core clinical measuresspecified by CMS for eligible professionals.

(ii) Electronically calculate, at a minimum, three clinical qual-ity measures specified by CMS for eligible professionals,in addition to those clinical quality measures specified inparagraph (1)(i).

(2) Submission. Enable a user to electronically submit calculatedclinical quality measures in accordance with the standard andimplementation specifications specified in § 170.205(f).

§ 170.306(i).(1) Calculate. Electronically calculate all of the clinical quality

measures specified by CMS for eligible hospitals and criticalaccess hospitals.

(2) Submission. Enable a user to electronically submit calculatedclinical quality measures in accordance with the standard andimplementation specifications specified in § 170.205(f).

Comments. Many commenters statedthat the Physician Quality ReportingInitiative (PQRI) 2008 Registry XMLspecifications apply only in the context

of eligible professionals. Some of thesecommenters went on to state thathospitals are not familiar with PQRI andhave been submitting qualitymeasurement data to CMS under aseparate program. A few commentersrecommended that this standardrequirement be removed while severalothers stated we should adopt bothQuality Reporting DocumentArchitecture (QRDA) and the PQRI XMLRegistry specification in this rulemakingand move to a single standard in thenext rulemaking. Other commentersrecommended that QRDA not be

adopted in this rulemaking. Severalcommenters suggested that animplementation specification foreligible hospitals be created if we intendto continue to require that qualitymeasure be reported in the PQRIRegistry XML format. One commenterexpressed a concern that if the PQRI2008 Registry XML standard ismaintained as the adopted standard thatthere is a danger that the certificationComplete EHR and EHR Moduledevelopers obtain may become obsolete

before Stage 1 has run its course.

Finally, a couple of commenterssuggested that ONC consider deferringthe naming of a standard for submissionof clinical quality measures until Stage

2 and instead only require what isnecessary to support clinical qualitymeasure submission in Stage 1.

Response. Many commentersmisinterpreted our intent with respectto the adoption of the PQRI 2008Registry XML specification as thestandard for electronically submittingquality reporting data to CMS.Presently, CMS requires the submissionof aggregate, summary level data for thepurposes of meaningful use and not dataat the patient-specific level. It is ourunderstanding that the PQRI 2008Registry XML specification is capable of

serving as the‘‘

envelope’’

for aggregate,summary level data. Accordingly, we donot believe that, as some commenterssuggested, an eligible hospital’sfamiliarity with the PQRI program isrelevant to the adoption of this standardfor this specified purpose. Nor do we

believe that a specific implementationof this standard is necessary for hospitalsettings as the standard’s purpose andthe type of data it will transmit to CMSwill be the same—aggregate, summarylevel data. Through recent discussionswith CMS since the publication of the

Interim Final Rule we have determinedthat the PQRI 2009 Registry XMLspecification, a more recent version ofthe standards we adopted in the Interim

Final Rule is a suitable replacement for2008 version, and accordingly, we haveadopted the 2009 version in its place.We believe this revision should assuagesome commenters’ concerns about theobsolescence of the adopted standardand reduce concerns that a whollydifferent standard would be adopted inthe near future. If adopting a differentstandard for Certified EHR Technology

becomes necessary, we would do soonly after engaging in subsequentrulemaking.

Comments. A few commenters statedthat many of the clinical qualitymeasures proposed by CMS do not haveelectronic specifications and contendedthat it would be difficult for any vendorto have embedded these measures intheir EHR products in a timely manner.But, these same commenters stated thatwhen the specifications becomeavailable, that HHS should ensurethrough the certification process that theproducts are capable of generatingaccurate data. Many commentersexpressed concerns that the certificationcriterion was too vague or too broad(because it implicitly referenced all of


8/13/2019 2010-17210



the quality measures CMS hadproposed). Some of the commentersrecommended that this certificationcriterion be removed, while othersrecommended that it focus on a subsetof measures in order to constrain theamount of electronic measurespecifications a Complete EHR or EHRModule developer would need to

address in order to be certified. At leastone of these latter commenters indicatedthat our adopted certification criteriacreated uncertainty for Complete EHRand EHR Module Developers. Thiscommenter asked that we clarify whatclinical quality measures would need to

be tested in order to satisfy thiscertification criterion and if there would

be a baseline for eligible hospitalmeasures as well as some identified coreset of measures for eligibleprofessionals. Along these same lines,another commenter recommended thatEHR technology should be tested and

certified only to the clinical qualitymeasures applicable to the medicalspecialties of the eligible professionalsthat the EHR technology is intended tosupport and to whom it is marketed.Other commenters expressed concernsabout timing and that a significantamount of effort would be required toreprogram Complete EHRs and EHRModules to capture, calculate, andreport the final meaningful use Stage 1measures. Many commenters also statedthat the proposed quality measures arenot yet ready for automated reporting,that a significant amount of work is still

required by the measure developercommunity, and that the value sets forthese quality measures have not beenvalidated. Several commenters objectedto the reference to ‘‘States’’ in thecertification criterion and recommendedthat it be removed. These commenterscontended that the certification criterionshould be limited to the ‘‘federalrequirements’’ and further that it wasunrealistic to expect Complete EHR andEHR Module developers to also complywith 50 separate State requirements asa condition of certification.

Response. We understand that CMS

has worked to significantly increase theavailability of a number of electronicmeasure specifications that areassociated with specific clinical qualitymeasures. In light of the final approachCMS has taken with respect to clinicalquality measures for meaningful useStage 1, we have revised thiscertification to better align it with theMedicare and Medicaid EHR IncentivePrograms final rule requirements. Wealso agree with those commenters thatrequested we explicitly focus the reportof clinical quality measures certification

criterion, and the certification criteria ingeneral, on Federal requirements andhave removed the reference to ‘‘orStates’’ in this certification criterion.

To better align this certificationcriterion with the final approach toclinical quality measures in theMedicare and Medicaid EHR IncentivePrograms final rule, we have determined

that it is no longer sufficient to specifyone general certification criterion for

both Complete EHRs and EHR Modulesdesigned for either an ambulatory orinpatient setting. Accordingly, the finalrule in §§170.304 and 170.306 willinclude a specific certification criterionfor each setting. Complete EHRs andEHR Modules designed for anambulatory setting will be required to betested and certified as being compliantwith all 6 of the core (3 core and 3alternate core) clinical quality measuresspecified by CMS for eligibleprofessionals (Section II(A)(3) of the

Medicare and Medicaid EHR IncentivePrograms final rule). Complete EHRsand EHR Modules designed for anambulatory setting will also be requiredto be tested and certified as beingcompliant with, at a minimum, 3 of theadditional clinical quality measuresCMS has identified for eligibleprofessionals (Section II(A)(3)of theMedicare and Medicaid EHR IncentivePrograms final rule). We believe thisrevision provides clarity and flexibilityand reduces the potential burden forComplete EHR and EHR Moduledevelopers (who may have beenunfamiliar with certain clinical quality

measures because of the type of eligibleprofessional they serve) to becomecompliant with this certificationcriterion. As a result, Complete EHR andEHR Module developers for theambulatory setting may provideCertified EHR Technology with a certainlevel of variability in terms of clinicalquality measure capabilities. To providefurther transparency for potentialeligible professionals regarding theclinical quality measures to which aComplete EHR or EHR Module has beentested and certified, we specified that anONC–Authorized Testing and

Certification Body would need to reportsuch information to the NationalCoordinator, and further, that theComplete EHR or EHR Moduledeveloper would need to make sure thisinformation is available andcommunicated to prospectivepurchasers as part of the Complete EHRor EHR Module’s certification.

Complete EHRs and EHR Modulesdesigned for an inpatient setting will berequired to be tested and certified as

being compliant with all of the clinicalquality measures specified by CMS

(Section II(A)(3) of the Medicare andMedicaid EHR Incentive Programs finalrule) for eligible hospitals. Again, we

believe this revision provides greaterclarity and reduces the potential burdenfor Complete EHR and EHR Moduledevelopers.

Comments. One commenter suggestedthat we separate the calculation and the

submission parts of this certificationcriterion into two separate certificationcriteria.

Response. We disagree. We see no basis for separating these two parts ofthis certification criterion into twoseparate certification criteria. However,we believe that it is necessary to specifytwo different certification criteria toaccount for the different clinical qualitymeasures that eligible professionals andeligible hospitals will need to report.Accordingly, we have adopted separatecertification criteria for Complete EHRsand EHR Modules designed forambulatory and inpatient settings andreferenced the respective qualitymeasures for each in the appropriatecertification criterion.

Comments. One commenter suggestedthat all approved PQRI registries beautomatically certified as an EHRModule.

Response. We do not believe that it isprudent or appropriate to automaticallydeem certain HIT as certified. That

being said, if a PQRI registry canadequately perform the capabilityspecified by the certification criterion, itcould be certified as an EHR Module.

Comments. Several commenters

stated that Certified EHR Technologyshould be capable of collecting qualitymeasurement data and calculatingresults for reporting to avoid havingeligible professionals and eligiblehospitals perform these processesmanually. These commenters also statedthat Certified EHR Technology should

be capable of accurately and reliablyreporting quality measurement data.Some commenters recommended that aComplete EHR or EHR Module only berequired to be certified to existing e-measure specifications.

Response. We agree that the collectionof clinical quality measurement dataand the calculation of results forsubmission to CMS should beperformed by Certified EHRTechnology. We also agree thatComplete EHRs or EHR Modules shouldonly be required to be tested andcertified to developed electronicmeasure specifications. This is whyCMS has only specified clinical qualitymeasures for eligible professionals andeligible hospitals in the Medicare andMedicaid EHR Incentive Programs finalrule for which electronic measure


8/13/2019 2010-17210



specifications have been developed.Complete EHR and EHR Moduledevelopers should follow theseelectronic measure specifications inorder to accurately calculate clinicalquality measures.

Comments. Several commentersrecommended that the certificationcriterion should be revised to includethe word ‘‘accurately.’’

Response. We expect that clinicalquality measures would be accurately

calculated and do not see a need tospecifically include the word in thecertification criterion.

Section 170.302(j)—Check InsuranceEligibility and § 170.302(k)—SubmitClaims


Removed from final rule .................. Removed from final rule ................ Interim Final Rule Text:Enable a user to electronically record and display patients’ insur-

ance eligibility, and submit insurance eligibility queries to pub-lic or private payers and receive an eligibility response in ac-cordance with the applicable standards and implementationspecifications specified in §170.205(d)(1) or (2).

Final Rule Text:Removed.


Removed from final rule .................. Removed from final rule ................ Interim Final Rule Text:Enable a user to electronically submit claims to public or private

payers in accordance with the standard and implementationspecifications specified in §170.205(d)(3).

Final Rule Text:

Removed.

Comments. Many commentersrecommended that the certificationcriteria for administrative transactions

be removed because they considered theadministrative capabilities that werequired to be outside of the scope of anelectronic health record and statedfurther that their inclusion did not alignwith the HIT industry’s common viewof what constituted EHR technology. Alarge number of commenters conveyedspecific challenges including: These

functions are usually handled bypractice management systems whichgenerally are separate from an EHR,although on occasion some vendorsinclude these functionalities in theirEHRs; practice management systemsadoption is already very high andrequiring certification for these productswould be unnecessary and burdensome,given the wide variety and number ofvendors and significant potential forincreasing costs for providers; providersinterested in achieving meaningful usewould have to abandon a workingpractice management system if their

practice management vendors wereunwilling or unable to get certified; andmany providers currently useclearinghouses to convert paper claimsinto electronic claims to submit to CMSand other payers. Several commentersrecommended retaining theadministrative transactions certificationcriteria because it would eventuallyreduce administrative costs across thehealth care system. Many commentersrequested that we clarify several aspectsof these certification criteria while someother commenters noted that significant

progress has been made in usingelectronic eligibility inquires and claimstransactions outside of an EHR context.Those commenters expressed concernthat the inclusion of administrativetransaction capability in this rule wouldcreate confusion, ambiguity, andpotentially duplicate efforts. A couple ofcommenters noted that some payers donot accept electronic claims andeligibility checks. One commenterexpressly noted that including the

administrative functionalities woulddecrease innovation by creating a large

barrier to entry for EHR innovators.Finally, a couple of commenters notedthat health care providers would facesignificant challenges in the transitionto ASC X12N 5010 and ICD–10 and lostproductivity.

Response. In concert with CMS, wehave considered commenters’ rationalefor and against the inclusion of thesecertification criteria. We have tried tosummarize above several technical andprogrammatic challenges commentersidentified if administrative transaction

capability were included within thecertification requirements. Due to theremoval of these objectives from themeaningful use Stage 1 requirements,we do not believe that it would beappropriate to continue to require, as acondition of certification, that CompleteEHRs and EHR Modules include thesecapabilities. Accordingly, we haveremoved the adopted standards,implementation specifications, andcertification criteria related to theseadministrative transactions from thisfinal rule.

As CMS explains in more detail in theMedicare and Medicaid EHR IncentivePrograms final rule, the subsequentinclusion of administrativesimplification requirements as part ofmeaningful use Stage 2 is an importantlong-term policy goal. Administrativesimplification can improve theefficiency and reduce unnecessary costsin the health care system as a whole; thesmall percentage of paper claimssubmitted represents a

disproportionately high administrativecost for health plans; the reconciliationof billing charges for services noteligible for payment creates a significant

burden for providers, health plans, andmost significantly, for patients.Moreover, we believe that theintegration of administrative andclinical information systems isnecessary to support effectivemanagement and coordinated care inphysician practices. For example, theability to: leverage clinicaldocumentation in support ofappropriate charge capture (e.g., for

preventive counseling, orimmunizations provided); link lists ofpatients needing clinical reminders withpatient contact information; stratifyquality measures by patientdemographic factors (e.g., race/ethnicity) and insurer status (e.g.,Medicare beneficiaries).

Additionally, we believe thatimportant benefits can be recognizedthrough the future adoption ofadministrative transactions standardsand certification criteria for CompleteEHRs and EHR Modules. Through the


8/13/2019 2010-17210



use of EHR Modules, eligibleprofessionals and eligible hospitals havethe opportunity to use practicemanagement systems or clearinghousesthat provide the capability to conductadministrative transactions ascomponents of Certified EHRTechnology. In that regard, we recognizethe concerns expressed by some

commenters that the developers of somepractice management systems may not

be prepared to seek certification forthese legacy systems in 2010 or 2011.We also acknowledge that the requiredcompliance date of January 1, 2012 forASC X12N version 5010 transactionswould further complicate thecertification process associated withmeaningful use Stage 1. However, we

believe that after the ASC X12N version5010 transition has occurred, and weapproach the October 1, 2013compliance date for HIPAA coveredentities to use ICD–10, our decision to

delay the adoption of administrativetransactions certification criteria willprove beneficial for the adoption ofCertified EHR Technology.

In order to meet upcomingadministrative simplification deadlines,most health care providers will have toupgrade their practice managementsystems or implement new ones. Thiswill provide an important opportunity

to align EHR technology capabilities andstandards for administrativetransactions with the administrativesimplification provisions that theAffordable Care Act provides for healthplans and clearinghouses. Therefore, weintend to include for adoption,administrative transactions standardsand certification criteria to support

meaningful use Stage 2 rulemaking, andexpect health care providers andComplete EHR and EHR Moduledevelopers to take this intoconsideration leading up to 2013.

Comments. Many commentersrecommended that we remove theimplementation specification, COREPhase 1 (CORE), which we previouslyadopted. Several commenters noted thatCORE is only useful if it has also beenadopted by health plans, and theyexplained that not all health plans hadadopted CORE. A few commentersexpressed concern with CORE stating

that it adds requirements to the HIPAAStandard Transactions and did notfollow the work of the standardsdevelopment organization thatmaintains administrative transactions. Afew commenters also believed thatfollowing CORE results in non-compliant ASC X12N 4010 transactions.Other commenters noted that itappeared that we had required CORE for

both ASC X12N 4010 and 5010 standardtransactions, but that CORE Phase 1 isonly applicable to ASC X12N 4010standard transactions and cannot beused with ASC X12N 5010 standardtransactions. A few commentersrequested that we clarify whetherproviders and vendors will be requiredto receive CORE certification. Severalcommenters recommended ONC retainCORE Phase 1. A few commenters notedthat CORE promotes uniformity and canprovide significant reduction intransaction costs. A couple commentersrecommended that ONC adoptsubsequent CORE standards in futurestages.

Response. As previously mentioned,we have decided to align our revisionswith the changes made in the Medicareand Medicaid EHR Incentive Programsfinal rule and to remove, as noted above,the standards, implementation

specifications, and certification criteriaassociated with administrativetransactions. Consistent with thatapproach, we are removing the COREPhase 1 implementation specificationfor the reasons submitted in comments.

Section 170.302(l)—MedicationReconciliation


The EP, eligible hospital or CAHwho receives a patient from an-other setting of care or providerof care or believes an encounteris relevant should perform medi-cation reconciliation.

The EP, eligible hospital or CAHperforms medication reconcili-ation for more than 50% of tran-sitions of care in which the pa-tient is transitioned into the careof the EP or admitted to the eli-gible hospital’s or CAH’s inpa-tient or emergency department(POS 21 or 23).

Interim Final Rule Text:Medication reconciliation. Electronically complete medication rec-

onciliation of two or more medication lists by comparing andmerging into a single medication list that can be electronicallydisplayed in real-time.

Final Rule Text: §170.302(j)Medication reconciliation. Enable a user to electronically com-

pare two or more medication lists.

Comments. Many commenterssuggested that for this certificationcriterion we clarify whether weintended for the process of medicationreconciliation to be automatic or tosupport an eligible professional oreligible hospital in performing this task.Many saw the former as a potential risk

to patient safety. Although severaldifferent reasons were given, manycommenters recommended that werevise the certification criterion toindicate that two or more medicationlists be simultaneously displayed inorder to permit an eligible professionalor eligible hospital to then reconcile themedication lists.

Response. We have reviewedcommenters’ concerns and intend toclarify the language in this certificationcriterion. We recognize that the

technical foundation and safety checksare not currently in place for automatedmedication reconciliation. We did notintend to imply that automatedreconciliation needed to occur throughour use of the word ‘‘electronically.’’ Weused the term ‘‘electronically’’ to expressour expectation that eligible

professionals and eligible hospitalswould be able to use Certified EHRTechnology to complete this task.Accordingly, we have revised thiscertification criterion to require thatCertified EHR Technology be capable ofproviding a user with the ability toelectronically compare two or moremedication lists (e.g., between anexternally provided medication list andthe current medication list in CertifiedEHR Technology). We expect that thiscould be done in a number of ways and

we do not want to preclude CompleteEHR and EHR Module developers frominnovating, provided that the desiredoutcome is reached. For example, a usercould be presented with two electroniclists side-by-side and move medicationsfrom one list to the other and then selectthe final current list. Alternatively, a

user could view one list and two PDFsof other medications and use thiscapability to update the currentmedication list. We do, however, seegreat promise in making this capabilitymore comprehensive and anticipateexploring ways to improve the utility ofthis capability before we adopt asubsequent round of certificationcriteria.

Comments. Several commenterssupported this certification criterion,

but wanted clarification regarding how


8/13/2019 2010-17210



4http://www.cdc.gov/vaccines/programs/iis/stds/ cpt.htm.

we expected testing and certification to be accomplished, especially if only onemedication list was in use.

Response. We believe that theclarifications and revisions to thecertification criterion and the discussionabove clarify how we intend for thiscertification criterion to be tested.

Comments. Several commentersrequested that we clarify the meaningsof ‘‘medication reconciliation,’’‘‘transitions of care,’’ and ‘‘relevantencounter.’’

Response. These terms are not used inthe certification criterion. We encouragecommenters to review the Medicare and

Medicaid EHR Incentive Programs finalrule to see how these terms have beenclarified in response to publiccomments.

Section 170.302(m)—Submission toImmunization Registries


Capability to submit electronic datato immunization registries or Im-munization Information Systemsand actual submission in accord-ance with applicable law andpractice.

Performed at least one test of cer-tified EHR technology’s capacityto submit electronic data to im-munization registries and followup submission if the test is suc-cessful (unless none of the im-munization registries to whichthe EP, eligible hospital or CAHsubmits such information havethe capacity to receive the infor-mation electronically).

Interim Final Rule Text:Submission to immunization registries . Electronically record, re-

trieve, and transmit immunization information to immunizationregistries in accordance with:

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

(2) The applicable state-designated standard format.Final Rule Text: §170.302(k).

Submission to immunization registries. Electronically record,modify, retrieve, and submit immunization information in ac-cordance with:

(1) The standard (and applicable implementation specifications)specified in §170.205(e)(1) or §170.205(e)(2); and

(2) At a minimum, the version of the standard specified in

§ 170.207(e).

Comments. A significant majority ofcommenters recommended that weremove paragraph (m)(2) related to theapplicable state-designated format.These commenters contended that sucha requirement was vague, could beproblematic from an interoperabilityperspective, and would makecertification impracticable.

Response. We agree with thosecommenters that requested we explicitlyfocus the certification criterion andcertification in general on Federalrequirements. We have thereforeremoved the reference to ‘‘applicablestated-designated standard format’’ inthe certification criterion. Additionally,we have reviewed this certificationcriterion and have determined that ourreference to ‘‘immunization registries’’ isunnecessary. We are primarilyconcerned with Certified EHRTechnology’s ability to transmit theimmunization information in astandardized format, and do not believethat it is necessary to specify aparticular recipient in the certification

criterion.Comments. Many commenters

supported our adoption of both HL72.3.1 and HL7 2.5.1. Some commentersacknowledged that HL7 2.3.1 was morecommonly used for the purpose ofsubmitting information to immunizationregistries while other commenterssuggested that we only adopt HL7 2.5.1.Some commenters recommended thatwe keep our adopted standards the waythey are. Others recommended that weonly adopt HL7 2.3.1 because most

immunization registries cannot complywith HL7 2.5.1.

Response. We appreciate thatcommenters support our adoption of

both HL7 2.3.1 and HL7 2.5.1. Weunderstand that both standards arecurrently in use and for that reason wehave permitted either to be used forpurposes of certification. We alsounderstand that eligible professionalsand eligible hospitals will have to usethe standard that the immunizationregistry or Immunization InformationSystem in their jurisdiction can receiveand, as a result, we have adopted thetwo most common standards utilized forthe transmission of immunizationinformation.

Comment. One commenter noted thatit would be very helpful to provide asource for mapping from the NDC codeon the vaccine packaging to the CVX/MVX codes used for interoperability, inanticipation of supporting barcodescanning of vaccines. Anothercommenter noted that while somemapping has occurred between CPT andCVX, they were not aware of atranslation map from NDC to CVX. Theyalso stated that even though a list ofCVX codes is available, they were notaware of a downloadable immunizationdatabase using CVX codes. Theyconsidered this lack of a database asignificant burden and impediment tocompliance. The commenter concluded

by suggesting that CPT codes be usedinstead of CVX codes, because CPTcodes are used for billing purposes andwould be readily available.

Response. The CDC maintains anopenly available list of updated CVXcodes as well as a mapping of CVXcodes to CPT codes on their Web site.4 Moreover, we believe that CVX codesare more appropriate than CPT codes

because as the commenter referenced,CPT codes are used for billing purposes.In that regard, we believe that becausethere is a publicly available mapping

between CVX and CPT, it would not bedifficult or burdensome to map CPT

codes to CVX codes. NDC codes werenot adopted as a standard to representimmunizations and we do not believethat requiring their use for the purposesof demonstrating compliance with thiscertification criterion would beappropriate.

Comment. One commenterrecommended that we revise thecertification criterion combined withassociated standards to state, ‘‘For thepurposes of electronically submittinginformation to immunization registriesCertified EHR Technology must becapable of using a certified EHR module

or portal provided by a stateimmunization registry which is capableof submitting and retrieving codedimmunization information or capable ofusing HL7 2.3.1 or HL7 2.5.1 as acontent exchange standard and the CDCmaintained HL7 standard code setCVX—Vaccines Administered as thevocabulary standard.’’ The basis for thiscommenter’s suggestion was thatproviders in its state link to the state’s


http://www.cdc.gov/vaccines/programs/iis/stds/cpt.htm




8/13/2019 2010-17210



immunization module through EHRsand that all immunization data arestored immediately in the state’sregistry. The commenter furtherclarified that since the data resides inthe state registry natively, there is noneed to transmit this information.

Response. In light of this commenter’ssuggestion, we have revised the

certification criterion to replace theword ‘‘transmit’’ with ‘‘submit’’ to betteralign this certification criterion with themeaningful use objective and measure.We believe that submission ofimmunization data would encompassthis commenter’s existing method.

Comment. One commenter stated thatthey believed the use of CVX is neithermature nor widespread.

Response. We disagree. Ourinformation indicates that CVX codesare widely used for reporting toimmunization registries.

Comment. Some commentersidentified implementationspecifications that are available for thestandards we had adopted fortransmitting immunization information.A couple of these commentersspecifically recommended usingimplementation specifications thatwould identify message types necessaryfor transmissions to immunizationregistries. Commenters also suggestedusing the CDC’s implementation guides,and explicitly recommended that weadopt the CDC public healthinformation network (PHIN)implementation guide version 2.2associated with HL7 2.3.1 for the

transmission of immunizationinformation and the CDCimplementation guide as well as theimplementation guide associated withHL7 2.5.1.

Response. In the Interim Final Rule,we expressed our interest in receiving

public comment on whether there wereadditional implementationspecifications that we should adopt. Wealso noted that we would consideradopting implementation specificationsfor any or all of the standards adoptedin the Interim Final Rule. After furtherconsideration of commenters’recommendations and consultation with

the CDC, we agree with thesecommenters and believe that adoptingimplementation specifications for thetransmission of immunizationinformation would benefit EHRtechnology developers and users.Moreover, given commenters’ generalrequests for greater specificity and ourstated goal of greater interoperability,we believe that it would be appropriateto adopt the following implementationspecifications for the submission ofimmunization data. For HL7 2.3.1 wehave adopted the ‘‘ImplementationGuide for Immunization Data

Transactions using Version 2.3.1 of theHealth Level Seven (HL7) StandardProtocol, Implementation Guide Version2.2.’’ We are aware that thisimplementation specification has beensuccessfully adopted numerous times invarious contexts since its publicationfour years ago and do not believe thatit will be burdensome for Complete EHRand EHR Module developers toimplement these specifications. For HL72.5.1, we have adopted the‘‘Implementation Guide forImmunization Messaging Release 1.0.’’This implementation specification

represents the collaborative effort of theAmerican Immunization RegistryAssociation (AIRA) and the CDC. Wehave also consulted with CDC, and theCDC confirms the appropriateness andsupports the usage of theseimplementation specifications in this

context. We encourage migration to thisnewer implementation specification and

believe that it will likely advanceinteroperability across the country andimprove query capabilities.

Comment. A commenterrecommended that we clarify that thecertification criterion should be limitedto verifying the ability of the system to

record, retrieve, and transmitimmunization information.

Response. The purpose of testing andcertifying a Complete EHR or EHRModule to this certification criterion isto verify that it can perform thecapabilities included in the certificationcriterion.

Comment. A couple of commentersstrongly supported the transmission ofimmunization data to state and localimmunization registries but requestedthat the data requirements be expandedto include the transmission ofinformation regarding diseases such as

cystic fibrosis to pediatric registries.Response. Presently, we do not

believe that it is necessary orappropriate to expand this certificationcriterion in this manner. We emphasize,though, that this should not precludeeligible professionals or eligiblehospitals from using Certified EHRTechnology to submit other types ofinformation as medically appropriateand if the recipient of the informationis capable of receiving the data.

Comment. A commenterrecommended including the term‘‘modify’’ in the certification criterion.

Response. We agree, and consistentwith our other certification criteria thatinclude the term ‘‘modify,’’ we haveadded this term.

Section 170.302(n)—Public HealthSurveillance

Meaningful use Stage 1objective

Meaningful use Stage 1 measure Certification criterion

Capability to submit electronicsyndromic surveillance data topublic health agencies and actualsubmission in accordance withapplicable law and practice.

Performed at least one test of cer-tified EHR technology’s capacityto provide electronic syndromicsurveillance data to publichealth agencies and follow-upsubmission if the test is suc-cessful (unless none of the pub-lic health agencies to which anEP, eligible hospital or CAHsubmits such information havethe capacity to receive the infor-mation electronically).

Interim Final Rule Text:Public health surveillance. Electronically record, retrieve, and

transmit syndrome-based public health surveillance informationto public health agencies in accordance with one of the stand-ards specified in §170.205(g).

Final Rule Text: §170.302(l).Public health surveillance. Electronically record, modify, retrieve,

and submit syndrome-based public health surveillance infor-mation in accordance with the standard (and applicable imple-mentation specifications) specified in §170.205(d)(1) or§ 170.205(d)(2).

Comments. A couple of commenterssupported the adoption of certificationcriteria related to public healthreporting. One commenter believed that

this certification criterion should beimplemented as adopted.

Response. We appreciate commenters’support of this certification criterion.

Comment. One commenterrecommended that we defer anyvocabulary standard for public healthreporting and surveillance until a laterdate. Another commenter expressed


8/13/2019 2010-17210



concern that we would adopt as astandard, ‘‘according to applicablepublic health agency requirements,’’

because they thought it could beproblematic for hospital systems withfacilities in two or more states, as theirEHR technology would have to meetwhatever standards each state elected touse.

Response. We clarify for commentersthat we adopted two content exchangestandards for electronic submission topublic health agencies for surveillanceand reporting. We did not adopt aspecific vocabulary standard, nor didwe include the phrase one commenterstated that we included. However, wehave, consistent with our rationale inthe immunization submissioncertification criterion, removed ourreference to ‘‘public health agencies’’ asthe recipient of information. Also,consistent with the certificationcriterion above, we have replaced the

term‘‘transmit

’’with

‘‘submit.

’’

Comments. A couple of commentersstated that compliance with HL7 2.5.1not be included in this adopted set ofstandards. One commenter suggestedHL7 2.5.1 should be adopted in a futurerulemaking. Another commentersuggested that HL7 2.3.1 be required forthe purposes of certification. Anothercommenter recommended that thestandard be HL7 2.3.1, because in itsopinion many public health agenciescannot comply with HL7 2.5.1 whileanother commenter took the oppositeposition and recommended HL7 2.5.1.

Response. Given the diversity in

implementations and public healthagencies’ ability to receive informationin a given standard, we believe that theflexibility included in this criterion isnecessary for the foreseeable future.However, relative to the generalcomments we received regarding theadoption of implementationspecifications for adopted standards, wehave adopted the followingimplementation specifications for HL72.5.1: Public Health InformationNetwork HL7 Version 2.5 MessageStructure Specification for NationalCondition Reporting Final Version 1.0

and the Errata and ClarificationsNational Notification MessageStructural Specification. We believe thatthese implementation specificationsprovide the additional claritycommenters were seeking and willenable Complete EHR and EHR Moduledevelopers to focus their efforts on amore specific implementation of theHL7 2.5.1 standard. We do not believethat a suitable implementationspecification for HL7 2.3.1 exists for the

purpose of public health surveillanceand reporting.

Comments. Multiple commentersstated concerns that the Federalgovernment and state governments, aswell as other public health agencies, donot have the capability to receiveinformation electronically in astandardized format. One commenterstated that while they supported usingthe HL7 standards, some agencies areonly able to accept public healthsubmissions if they have an HL7-basedfeed. Several commenters suggested thatthe public health reporting requirement

be delayed until a single, nationalstandard exists. One commenter statedthat requiring EHRs to ‘‘electronicallyrecord, retrieve, and transmit syndrome-

based public health surveillanceinformation to public health agencies’’ isa worthwhile future goal, but theystrongly questioned the likelihood thatit could be accomplished within the

2011–2012 timeframe. The commenteralso noted that the certification criteriondid not specify which agencies (local,state, Federal) are included, and thatmost of those agencies are not preparedto receive biosurveillance dataelectronically in the format specified.The commenter concluded that it would

be difficult for any EHR to provecompliance with the certificationcriterion as written and recommendedthe following alternative: ‘‘Electronicallyrecord, retrieve, and be capable ofproducing an electronic messagecontaining syndrome-based public

health surveillance information inaccordance with one of the standardsspecified in § 170.205(g).’’

Response. We recognize that somepublic health agencies do not yet havethe capability of electronically receivinginformation. We do not believe that thisshould serve as a limiting factor,however, or preclude Certified EHRTechnology from having the capabilityto transmit information in a standardformat.

Comment. One commentercommented that if a public healthagency is unable to accept the data,

separate reports could be filed with thepublic health agency to ensurecompliance with the standards.

Response. The commenter’s point isunclear, as is its proposal. We thereforereiterate that Certified EHR Technologymust be capable of transmitting healthinformation in accordance with thestandards adopted by the Secretary,regardless of whether a specific publichealth agency can accept or receive theinformation.

Comment. One commenter suggestedthat if current interfaces comply withpublic health surveillance data usingolder versions of HL7, the organizationsshould be allowed to keep theseversions and not be required to upgradeto a newer version.

Response. We permit a Complete EHRor EHR Module to be tested and

certified to either HL7 2.3.1 or HL72.5.1. No other versions will beconsidered compliant with the adoptedstandards or certification criterion.

Comment. One commenterrecommended that we specifyacceptable testing methods. Thecommenter also recommended that thetesting methods should include anevaluation of HL7 conformance,completeness, and accuracy of testmessages sent to a state public healthagency with a demonstrated capabilityfor electronic laboratory reporting.

Response. We do not specify the

testing methods applicable to thecertification criterion, because thatinformation is outside the scope of thisfinal rule.

Comment. One commenter suggestedthat adverse events be reported to publichealth agencies.

Response. Our certification criteriondoes not preclude other types ofreportable events from occurring.Presently, we do not believe that it isappropriate to modify the certificationcriterion to explicitly refer to adverseevents.

Comment. One commenter

recommended that because some publichealth agencies do not have the abilityto receive public health surveillanceinformation in electronic format, weshould clarify that this certificationcriterion is limited to verifying theability of the system to record, modify,retrieve, and submit such information

based on at least one test of thesecapabilities.

Response. We reiterate, that thepurpose of certification is to verify thata Complete EHR or EHR Module canperform these capabilities. That shouldnot be construed to mean that aneligible professional or eligible hospitalis exempt from using Certified EHRTechnology to meet the meaningful useobjective and measure.

Comment. A commenterrecommended including the word‘‘modify’’ in the certification criterion.

Response. Consistent with ourrationale above, we have added theword modify to the certificationcriterion.

Section 170.302(o)—Access Control


8/13/2019 2010-17210




Protect electronic health informationcreated or maintained by the cer-tified EHR technology throughthe implementation of appropriatetechnical capabilities.

Conduct or review a security riskanalysis per 45 CFR 164.308(a)(1) and implement securityupdates as necessary and cor-rect identified security defi-ciencies as part of its risk man-agement process.

Interim Final Rule Text:Access control. Assign a unique name and/or number for identi-

fying and tracking user identity and establish controls that per-mit only authorized users to access electronic health informa-tion.

Final Rule Text: §170.302(o).Unchanged.

Comment. One commenter explicitlynoted its support for this certificationcriterion. We received other commentsthat included some mention of ‘‘access’’

but did not expressly focus on the

certification criterion or provide anyrelated suggestions orrecommendations.

Response. We appreciate thecomment supporting this certification

criterion. This certification criterionremains unchanged from thecertification criterion adopted in theInterim Final Rule.

Section 170.302(p)—Emergency Access



Conduct or review a security riskanalysis per 45 CFR 164.308(a)(1) and implement securityupdates as necessary and cor-rect identified security defi-ciencies as part of its risk man-

agement process.

Interim Final Rule Text:Emergency access. Permit authorized users (who are authorized

for emergency situations) to access electronic health informa-tion during an emergency.

Final Rule Text: §170.302(p).Unchanged.

Comment. One commenter asked thatwe clarify the circumstances that wouldqualify as an ‘‘emergency’’ and furtherclarify whether compliance with thiscertification criterion is intended to pre-empt conflicting or stricter state lawsthat may limit this type of access orrequire patient consent. Further, thecommenter questioned whether we wereimplying that some authorized users ofCertified EHR Technology would not beauthorized for emergency situations or

whether we intended for any authorizeduser to be entitled to access in anemergency situation. Finally, anothercommenter requested clarification as towhether emergency access is driven byorganizational policies and whethercapturing such access in an audit log isappropriate.

Response. We have adoptedcertification criteria to ensure thatCertified EHR Technology includescertain capabilities, in this case thatCertified EHR Technology be capable ofpermitting authorized users to accesselectronic health information during anemergency. The criterion is notintended to specify what constitutes anemergency or who would be authorized

to access electronic health informationin an emergency. In a medicalemergency, those determinations would

be made under specific factualcircumstances and in accordance withapplicable state and federal laws,organizational policies and procedures,and the relevant standard of care.

With respect to emergency access, wenote that HHS stated in the HIPAASecurity Final Rule (68 FR 8355):

We believe that emergency access is a

necessary part of access controls and,therefore, is properly a requiredimplementation specification of the ‘‘Accesscontrols’’ standard. Access controls will still

be necessary under emergency conditions,although they may be very different fromthose used in normal operationalcircumstances. For example, in a situationwhen normal environmental systems,including electrical power, have beenseverely damaged or rendered inoperativedue to a natural or manmade disaster,procedures should be established beforehandto provide guidance on possible ways to gainaccess to needed electronic protected healthinformation.

We believe that this certificationcriterion is consistent with the HIPAASecurity Rule.

Some commenters appeared tointerpret our reference to ‘‘emergency’’

in ‘‘emergency access’’ as solelyconstituting a clinical or life threateningemergency related to a patient for whichaccess would be required. We believethat emergency could encompass thatscenario, as well as a broader range ofpossibilities, including normal patientcare when timely access to electronichealth information becomes critical.Therefore, we have not sought to limit

the development of emergency accesscapabilities for Certified EHRTechnology to a particular scenario.

Comment. One commenter suggestedthat we require automated notificationof user activity to system administratorswhen emergency access is invoked.

Response. We appreciate thissuggestion. However, at the presenttime, we do not believe that thisrequirement should be a condition ofcertification because a person or entity’sorganizational policies and proceduresmay ensure timely notification of

appropriate personnel.Section 170.302(q)—Automatic Log-Off




Interim Final Rule Text:Automatic log-off. Terminate an electronic session after a pre-

determined time of inactivity.Final Rule Text: §170.302(q).

Unchanged.


8/13/2019 2010-17210



Comments. One commentersupported this requirement. Anothercommenter concurred with the purposeof the certification criterion, but notedthat it may be difficult in somecircumstances for eligible professionalsor eligible hospitals to implement thiscapability if the Certified EHRTechnology is offered as a service and

multiple individuals are using theCertified EHR Technology at the sametime.

Response. We appreciate thecommenters’ support for the adoption ofthis certification criterion. We believethat automatic logoff capabilities arecommonplace and that this certificationcriterion can be met by any Complete

EHR or EHR Module developer. We areaware that many Web services todaylogoff customers after a period ofinactivity and do not believe thisrequirement is unduly burdensome forany Complete EHR or EHR Moduledeveloper.

Section 170.302(r)—Audit Log




Interim Final Rule Text:(1) Record actions. Record actions related to electronic health in-

formation 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 setperiod of time.

Final Rule Text: §170.302(r).(1) Record actions. Record actions related to electronic health in-

formation in accordance with the standard specified in§ 170.210(b).

(2) Generate audit log. Enable a user to generate an audit logfor a specific time period and to sort entries in the audit log ac-

cording to any of the elements specified in the standard at170.210(b).

Comments. Several commentersrecommended that we add to thestandard specified at §170.210(b)‘‘access,’’ ‘‘reading,’’ or ‘‘viewing’’ astriggers for when actions needed to berecorded as part of an audit log. Onecommenter recommended expandingthe audit content to include maintainingthe before-access content of theinformation accessed as well as theafter-access content. Some commenters

requested clarification of the intendedmeaning of the reference to recordingthe action of ‘‘printing.’’ Commentersrecommended expanding or replacing‘‘print’’ in the standard with other typesof output methods such as extraction,copy, exchange, report, and export.Some commenter stated that the printfunction in many operating systems andsoftware products is a multiple stepprocess that is difficult for any systemto audit. Other commenters expressedconcerns that the requirement to auditall printing would be difficult becausethere were numerous ways to

circumvent the specific action ofprinting, such as using the print screenfunction and printing out the image ofthe screen shot. One commenter statedthat auditing of the print functionwould be possible, but completeauditing of all possible ways of printingwould be impracticable.

Response. We appreciate thethoughtfulness and thoroughness of thecomments provided on this standard.We agree with commenters that auditingthe action of printing, as it wasoriginally envisioned, could be

circumvented in such ways as to makethe burden of trying to accurately auditsuch occurrences outweigh the benefit.Accordingly, we have removed‘‘printed’’ from the standard. We alsoagree with commenters that ouromission of ‘‘access’’ should be correctedand we have added ‘‘accessed’’ to thestandard. We view the action of ‘‘access’’

to encompass ‘‘reading’’ or ‘‘viewing’’

and consequently have not included

those terms as well. Finally, we believethat the action of ‘‘accessed’’ is asuperset of actions which may include‘‘export’’ and for that reason have notincluded, per some commenters’suggestions, the word ‘‘exported’’ in thestandard. Additionally, to providegreater clarity, we have added in ‘‘and

by whom’’ toward the end of thestandard in order to more clearly specifythat the actions recorded should beassociated with the user identificationthat is recorded.

The final standard will read asfollows: ‘‘The date, time, patient

identification, and user identificationmust be recorded when electronichealth information is created, modified,accessed, or deleted; and an indicationof which action(s) occurred and bywhom must also be recorded.’’

Comments. Some commentersrequested that we clarify the term ‘‘useridentification’’ in the standard specifiedat § 170.210(b) and recommended theuse of existing standards-baseddefinitions, such as HL7’s definition ofauthor which includes person,organization, or device.

Response. We specified in thestandard that the date, time, patientidentification, and user identificationmust be recorded when certain actionstake place. The HL7’s definition ofauthor is consistent with ourexpectation. While we believe that inmost cases a user will be a health careprofessional performing an action usingCertified EHR Technology, it is alsopossible that a device or another

software process or program couldperform any one of these actions. We donot intend to preclude Complete EHRand EHR Module developers fromincluding these and other types ofspecific features.

Comment. One commenter stated thatthe audit alert criterion exceedsreasonable expectations for CertifiedEHR Technology to provide automaticalerts, and recommended that the auditcriteria focus on record access ratherthan electronic alerts. Severalcommenters suggested that alerts are notwell defined and should be removedfrom the criteria. Several commentersexpressed concern that the auditalerting criterion goes beyond what isrequired by HITECH and HIPAA andexceeds the current capabilities ofproducts in the market, andrecommends that the alerting criterion

be eliminated from the final rule. Somecommenters recommended against theadoption of certification criterion thatrequires EHR systems to create anunlimited and open-ended series ofrules to produce user-defined alerts, andsuggested that we should clearly define


8/13/2019 2010-17210



which actions should be recorded andwhat alerts should be defined andprovided in an audit log. Severalcommenters stated that the use of thephrase ‘‘ based on user-defined events’’

in the criterion could be easilymisinterpreted or misunderstood toextend beyond ‘‘entity-defined’’ eventsto include individual patient

preferences. Some of the commentersthat expressed concerns also contendedthat it would be difficult to test andcertify this portion of the certificationcriterion.

Response. Again, we appreciate thethoroughness of the commenters’suggestions. With respect to alerts basedon user-defined events, we hadintended for Complete EHRs or EHRModules designed to provide thiscapability to be capable of beingconfigured by a specific user of CertifiedEHR Technology or based onorganizational policy to generate alerts

when certain actions (defined in thestandard) had taken place. For example,a user-defined event could be when apatient’s health information is accessedoutside of normal business hours. Inthis case, it was our expectation thatCertified EHR Technology would alert aspecific user of the Certified EHRTechnology or the organization’sinformation security staff. Weunderstand the point that commentersraise, however, about the potential formisinterpretation of this certificationcriterion and the consequent potential

burden.Our overall intent for the third

paragraph of this certification criterionwas to ensure that Certified EHRTechnology provided the capability foreligible professionals and eligiblehospitals to gain access to a specifiedportion, or a complete representation, ofthe Certified EHR Technology’s auditlog. We believe that this capability isessential for eligible professionals andeligible hospitals for risk analysis andother purposes. Therefore, in concertwith the feedback commenters providedon the second paragraph, we analyzedwhether combining the third paragraphwith the second paragraph into a single

paragraph would express a clearerrequirement. Accordingly, we havemerged the two paragraphs and haveadopted in the final rule a requirementthat we believe more clearly expressesour intent for this certification criterion.We also note for clarification that thephrase ‘‘any of the elements specified by170.210(b)’’ would also include, forexample, ‘‘date’’ or that information has

been ‘‘deleted.’’Finally, we believe that it is important

for our privacy and security certificationcriteria to remain consistent with the

HIPAA Security Rule to the degree thatCertified EHR Technology includestechnical capabilities that are associatedwith assisting HIPAA covered entitiescomply with applicable legalrequirements. We disagree, however,with those commenters who stated thatwe did not have a sufficient legal basisto adopt this certification criterion the

way we did because it went beyond theHIPAA Security Rule. What a HIPAAcovered entity must do to remain incompliance with the HIPAA SecurityRule is separate and distinct from thecapabilities that a Complete EHR or EHRModule must include in order to becertified. We do not believe that we areprecluded by the HITECH Act fromadopting certification criteria that go

beyond the requirements specified bythe HIPAA Security Rule. We believethat the HITECH Act, while directingthat standards, implementationspecifications, and certification criteria

be consistent with the HIPAA standards,authorizes the Secretary to adoptcertification criteria more broadly forthe electronic use and exchange ofhealth information. Section 3004(b)(1)of the PHSA, as added by the HITECHAct, requires the Secretary, for instance,to adopt an initial set of standards,implementation specifications, andcertification criteria to enhance theinteroperability, functionality, utility,and security of health informationtechnology.

With respect to the concern expressedthat this certification criterion requirescapabilities that exceed the current

capabilities of products in the market,we disagree. Based on ourunderstanding of the current EHRtechnology in the market, we believethat the capabilities we have specifiedin the criterion and the embeddedstandard are already common industrypractice, and further, that the industryhas expanded the functionality availablein audit logs.

Comment. One commenter suggestedwe defer our adoption of the standarduntil the next rulemaking related tomeaningful use.

Response. We disagree. As stated

above, we believe that audit logcapabilities are an essential componentof Certified EHR Technology. As wementioned above, we believe that theactions we have specified in thestandard, in response to publiccomment, are already common industrypractice. Moreover, audit logs willprovide valuable information to eligibleprofessionals and eligible hospitals inthe event of a security incident.

Comments. Several commentersacknowledged the importance of theaudit log, but emphasized that the audit

log requirements should address theavailability of the audit log and itssecurity. Several commentersrecommended that additionalrequirements be added, including thatthe audit log always be on duringnormal production for the minimumelements specified in 170.210(b), bemaintained in a secure manner, be

produced in a human readable format,and be retained in conjunction with theretention period of the record.

Response. We agree with thesecommenters on the merits of theirsuggestions. In particular, we note thataudit logs provide an importantresource for eligible professionals andeligible hospitals. Audit logs can assistin the identification of securityincidents, such as unauthorized access,as well as serve to deter users fromconducting fraudulent or abusiveactivities and detect such activities. Thepurpose of adopted certification criteria

is to specify the capabilities CompleteEHRs and EHR Modules must include inorder to be certified, not when suchcapabilities must be used. Accordingly,we do not believe that it would beappropriate to specify in thiscertification criterion the time period forwhich an audit log should be ‘‘on.’’ Weagree with commenters that audit logsshould be maintained in a securemanner. For this reason, we havepreserved the capability we adopted inthe Interim Final Rule as part of theintegrity certification criterion thatspecified that Certified EHR Technologymust be capable of detecting alterations

to audit logs. We encourage the HITStandards Committee to consideradditional capabilities that could bespecified related to audit logs.

Comment. One commenterrecommended that the IHE Audit Trailand Node Authentication (ATNA)Integration Profile be used, but that itsuse be constrained to the electronictransactions among organizations, ratherthan electronic transmissions within anorganization.

Response. We decided to defer ouradoption of the ATNA standard becauseit can be configured in multiple ways

and we did not believe that it would beappropriate at this time to require aspecific implementation as a conditionof certification. Our deferral does notpreclude Complete EHR and EHRModule developers from using thestandard, however.

Comment. One commenter requestedclarification between ‘‘read’’ audits and‘‘write’’ audits, and how each is to beused. The commenter suggested that notrequiring the capability of ‘‘read’’ auditswill significantly reduce the ability ofauditors to identify and investigate


8/13/2019 2010-17210



5http://csrc.nist.gov/publications/fips/fips180-3/ fips180-3 _ final.pdf.

6http://csrc.nist.gov/publications/nistpubs/800- 107/NIST-SP-800-107.pdf .

inappropriate use of health informationwhen records are accessed but notmanipulated. The commenter noted thatauditing all read operations for all dataelements within an EHR is infeasible.The commenter further suggested that‘‘read’’ operations should be auditedonly when certain demographic health

information needed to identify a patient(e.g., name, record number, date of

birth, address) is presented to or can beknown by the user.

Response. As discussed above, wehave adopted in the standard the actionof ‘‘accessed’’ which would encompassthe action of ‘‘read.’’ At the present time,

we only identify certain data elementsin the adopted standard that must berecorded and believe that thisspecificity will help reduce anypotential burden associated withrecording the action of ‘‘accessed.’’

Section 170.302(s)—Integrity




Interim Final Rule Text:(1) In transit. Verify that electronic health information has not

been altered in transit in accordance with the standard speci-fied in § 170.210(c).

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

Final Rule Text: §170.302(s).(1) Create a message digest in accordance with the standard

specified in 170.210(c).(2) Verify in accordance with the standard specified in 170.210(c)

upon receipt of electronically exchanged health informationthat such information has not been altered.

(3) Detection. Detect the alteration of audit logs.

Comments. Several commentersrequested a definition of ‘‘in transit.’’Other commenters suggested thathashing of messages in transit be limitedto circumstances of transmission overpublic networks only. Thesecommenters suggested that messagestransmitted over private networks beexempt from complying with thisstandard. One commenter suggested thatin addition to message hashing, digitalsignatures should be required onmessages in transit. Another commenterstated that requiring hashing of

messages in transit is overly burdensome. One commenter requestedthat we clarify whether we intended§ 170.302(s)(1) to require that thereceiver of a message always verifymessages received rather than simplydemonstrate the capability to usehashing.

Response. We intend for thiscertification criterion to support, at aminimum, the HIPAA Security Ruleimplementation specification providedat 45 CFR 164.312(e)(2)(i) ‘‘[i]mplementsecurity measures to ensure thatelectronically transmitted electronic

protected health information is notimproperly modified without detectionuntil disposed of.’’ Because thiscertification criterion specifies acapability that Certified EHRTechnology must include, we do not

believe that it is necessary orappropriate for us to address whetherhashing is applicable to public andprivate networks. Additionally, weclarify that Certified EHR Technologymust include the capability to check theintegrity of health information that has

been received through electronic

exchange. However, similar to ourapproach to many adopted certificationcriteria, we do not specify the instancesin which this capability needs to beexecuted. Nevertheless, in response topublic comments we have attempted toclarify this certification criterion. Weclarify that we expect Certified EHRTechnology to be capable of creating amessage digest and when in receipt ofa message digest, to use the messagedigest to verify that the contents of themessage have not been altered. We haverevised the certification criterion toclarify our intent.

Additionally, based on these revisionsin the certification criterion, we wish toclarify the wording of the integritystandard specified at 170.210(c). Thestandard currently includes the words‘‘or higher’’ at the end of the standard.To provide more certainty to theindustry of our intended meaning, weare replacing those words with moreaccurate terminology. We have modifiedthe standard to read as follows: ‘‘Ahashing algorithm with a securitystrength equal to or greater than

SHA–1 must be used to verify thatelectronic health information has not been altered.’’ More information onSHA–1 and other secure hashalgorithms can be found in FIPS 180–3 5 while more information on the securitystrength of certain hashing algorithmscan be found in NIST SpecialPublication 800–107.6

Comments. Some commenters notedthat § 170.302(s)(2) refers to the use ofthe adopted standard which specifiesthe use of hashing to detect audit logalteration or deletion and that such arequirement is inappropriate. Othercommenters recommended that hashingshould not, at the present time, be usedfor detecting alterations to data at rest.

Response. We have considered thesecomments and agree with thesecommenters that this requirementrequires further clarification. We notethat part of this requirement as adopted

in the Interim Final Rule (‘‘detect * * *deletion of electronic healthinformation’’) is redundant with thestandard we specify for audit logs whichrequires that deletions of electronichealth information be recorded. For thisreason, we have removed the referenceto the detection of deleted electronichealth information and have opted for amore concise requirement thatalterations to audit logs be detected. Inresponse to public comment, we havechosen not to specify a standard fordetecting alterations to audit logs at thistime.

Comment. One commenter requestedclarification as to how message hashingshould work when messages are part ofa multi-part transmission process, e.g.,through switches, clearinghouses, andother brokers.

Response. We expect Certified EHRTechnology to be capable of generatinga hash of electronic health informationand upon receipt of such information,verifying that it has not been alteredwhen it has been electronicallyexchanged. We recognize that certainsituations may not be conducive to the


http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf




http://csrc.nist.gov/publications/nistpubs/800-107/NIST-SP-800-107.pdf







8/13/2019 2010-17210



use of hashes, which is why, as wenoted above, we do not specify theinstances in which hashing must beused, just that Certified EHRTechnology include these capabilities.

Comment. One commenter stated thatsecure transmission requirements are‘‘inappropriate’’ because they do not

support any meaningful userequirements.

Response. We disagree. Meaningfuluse requires the electronic exchange ofhealth information and the protection ofsuch information. We believe that theonly practical and effective way thatelectronic health information can be

exchanged in a meaningful manner is ifthe integrity of the information can bemaintained. Information ‘‘integrity’’ isalso one of the three pillars of securingor ‘‘protecting’’ electronic information.

Section 170.302(t)—Authentication




Interim Final Rule Text:(1) Local. Verify that a person or entity seeking access to elec-

tronic health information is the one claimed and is authorizedto access such information.

(2) Cross network. Verify that a person or entity seeking accessto electronic health information across a network is the oneclaimed and is authorized to access such information in ac-cordance with the standard specified in §170.210(d).

Final Rule Text: § 170.302(t) .Authentication. Verify that a person or entity seeking access to

electronic health information is the one claimed and is author-ized to access such information.

Comments. One commenter expresslysupported this certification criterion. Amajority of commenters expressedconcerns related to §170.302(t) and thecross-enterprise authentication standardspecified at §170.210(d). Somecommenters misinterpreted our exampleand stated that Security AssertionMarkup Language (SAML) should not berequired or be a named standard. Onecommenter suggested expanding the setof examples we provided. Othercommenters requested that the standardand the related portion of thecertification criterion be removed

because it was too burdensome to

implement at the present time, wasoverly broad, and could be subject tomultiple interpretations. Othercommenters contended that there is aninsufficient infrastructure to supportcross-enterprise authentication. Onecommenter stated that cross-enterpriseauthentication would not reside in anEHR application, but rather in thenetwork infrastructure.

Response. We have considered theconcerns issued by commenters andagree that the burden associated withcross enterprise authentication isunnecessarily high and cross-networkauthentication should not be a

condition of certification at the presenttime. As a result, we have removed thisspecific part of the certification criterionand the associated standard.

Comment. A commenter requestedclarification as to whether ‘‘user nameand password’’ would be sufficient toauthorize a user or whether biometricswould be required.

Response. We do not believe that it isappropriate to specify, as a condition ofcertification, the types of factors thatusers could utilize to authenticatethemselves.

Section 170.302(u)—Encryption




Interim Final Rule Text:(1) General. Encrypt and decrypt electronic health information

according to user-defined preferences in accordance with thestandard specified in §170.210(a)(1).

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

Final Rule Text: §170.302(u).General encryption. Encrypt and decrypt electronic health infor-

mation in accordance with the standard specified in§ 170.210(a)(1), unless the Secretary determines that the useof such algorithm would pose a significant security risk for Cer-tified EHR Technology.

§ 170.302(v).

Encryption when exchanging electronic health information.Encrypt and decrypt electronic health information when ex-changed in accordance with the standard specified in§ 170.210(a)(2).

Comments. A number of commentersstated that transmissions of healthinformation over leased or privatenetwork lines should not be subject tothe encryption of data in transitrequirement.

Response. Certified EHR Technologymust include the capability to encryptand decrypt information regardless ofthe transmission method used. Thiscertification criterion and relatedstandard do not specify thecircumstances under which encryption

and decryption must be performed; theysimply require the capability. If aneligible professional or eligible hospitaldetermines that encryption is anappropriate and necessary safeguard, we

believe that Certified EHR Technologyshould provide the capability to


8/13/2019 2010-17210



implement encryption. Overall, we wantto ensure that Certified EHR Technologyis capable of assisting eligibleprofessionals and eligible hospitals toimplement more secure technicalsolutions if they determine, based ontheir risk analysis, that technicalsafeguards such as encryption arereasonable and appropriate, or required.

Comment. One commenter requestedfurther clarification of the phrase‘‘encrypted and integrity protected link.’’Several commenters recommended thatTransport Layer Security (TLS) ought to

be specifically named as a requiredprotocol. Other commenters alsoexpressed concern that unless TLS isexplicitly named, all example protocolswould be required to be supported.

Response. The example list ofprotocols that would meet thecertification criterion is not intended to

be exhaustive or suggest that CompleteEHRs or EHR Modules must be capableof using all of the listed protocols to becertified. The example list of protocolsin the Interim Final Rule was includedsolely for illustrative purposes. Wehave, however, consistent with the waywe have restructured the regulatory textfor some standards (to better associatethem with the adopted certificationcriterion that reference them), modifiedthis standard to simply express that thestandard is any encrypted and integrityprotected link.

Comments. Several commenterssuggested replacing the functionaldescription of the encryption standardwith a specific reference to FIPS 140–2.

These commenters also noted that HHShad included such a reference in anupdate to its guidance specifying thetechnologies and methodologies thatrender protected health informationunusable, unreadable, or indecipherablethat was included in the BreachNotification for Unsecured ProtectedHealth Information Interim Final Rule,published on August 24, 2009 (74 FR42740), and further, requested that wemake our standard consistent with thisguidance. Some commenters explicitlyrecommended that AES be specified asthe encryption algorithm standard.

Response. We have considered thesecommenters’ points and have decided torevise our adopted standard to be moreflexible regarding the encryptionalgorithms we permit EHR Technologyto implement to be certified. We havealso sought to clarify how our adoptedstandard relates to the guidanceincluded in the breach notificationinterim final rule. We have revised thegeneral encryption standard to read asfollows: ‘‘Any encryption algorithmidentified by the National Institute ofStandards and Technology (NIST) as an

approved security function in Annex Aof the Federal Information ProcessingStandards (FIPS) Publication 140–2.’’

The National Institute of Standardsand Technology (NIST) publishedFederal Information ProcessingStandards (FIPS) Publication 140–2 tospecify the security requirements forcryptographic modules. As part of FIPS

140–X conformance, NIST publishes‘‘annexes’’ of different ‘‘approved’’

security protocols. For purposes ofencryption, NIST maintains ‘‘Annex A’’

which identifies ‘‘approved securityfunctions.’’ Annex A identifies bothsymmetric and asymmetric keyencryption algorithms that NIST hasidentified for use in accordance withFIPS 140–2. In response to commenters’concerns, we believe that leveragingNIST’s work in this area provides for aclearer requirement for compliance andprovides Complete EHR and EHRModule developers with the ability to

use one or more secure encryptionalgorithms for the purposes ofdemonstrating compliance with thiscertification criterion. We believe thisflexibility will benefit eligibleprofessionals and eligible hospitals

because they may be able to leverage a broader suite of secure encryptionalgorithms. As noted in SpecialPublication 800–111, which is specifiedin the guidance included in the breachnotification interim final rule for theencryption of data at rest, ‘‘[w]heneverpossible, AES should be used for theencryption algorithm because of itsstrength and speed.’’

We point out that the adoptedcertification criterion identifies certaindiscretionary authority that theSecretary is retaining with respect toacceptable encryption algorithms. Wehave adopted the list of approvedencryption algorithms that NIST hasidentified and referenced in FIPS 140–2 Annex A, which is being incorporated

by reference. While the list is intendedto be current, we anticipate that NISTwill on an as-needed basis revise andupdate the list, based on thedevelopment of new technologies orperhaps on identified vulnerabilities

associated with a particular algorithm.Regardless of any revisions to this list by NIST, this version of Annex A thatis incorporated by reference will remaineffective for purposes of serving as theadopted encryption standard. With thatsaid, if the Secretary determines thatone of the listed encryption algorithmsposes a significant security risk forCertified EHR Technology, the Secretarywill notify the public on theDepartment’s Web site (and perhapswith some time delay in the FederalRegister), and will direct ONC–ATCBs

or ONC–ACBs not to test and certifyComplete EHRs and EHR Modulesaccording to the specified compromisedalgorithm. The Department would thenfollow-up with rulemaking as necessaryand appropriate to update the adoptedlist of acceptable encryption algorithms.

Comments. Many commentersexpressed concerns that the rule would

require the encryption of data at rest.One commenter recommended thatencryption not be a requiredfunctionality of EHR systems, butdefined as limited to devices. Somecommenters stated that requiring EHRsystems to be capable of encryptionwould hinder adoption.

Response. We require that CertifiedEHR Technology must be capable ofencrypting electronic healthinformation. We do not specify thepolicies surrounding the use ofencryption by an eligible professional oreligible hospital nor do we specify thatit should only apply to devices. Ratherwe intend for Certified EHR Technologyto be technologically capable ofencryption, thereby allowing, if desiredor required, an eligible professional oreligible hospital who adopts CertifiedEHR Technology to use this capability.We disagree that requiring CertifiedEHR Technology be capable ofencryption would hinder adoption. Tothe contrary, we believe that CertifiedEHR Technology capable of encryptingelectronic health information will bedesired, especially in light of the new

breach notification requirementsestablished by the HITECH Act and the

Breach Notification for UnsecuredProtected Health Information InterimFinal Rule. We also take thisopportunity to make a technicalcorrection to this certification criterion.We inadvertently combined bothencryption capabilities under the sameparagraph and per our reaffirmedinterpretation expressed in theTemporary Certification Program, we

believe that the scope of onecertification criterion starts at the firstparagraph level and includes allsubparagraphs. As a result, we viewthese as two distinct capabilities and

have created a separate certificationcriterion for each.Comments. One commenter stated

that the security requirements,particularly for encryption, are lowerthan the security standards it alreadymeets. This commenter consequently

believes that our adoption of thisstandard would require it to reduce thesecurity of its products. Anothercommenter stated that encryptiontechnology should not be integrated intoan EHR product, but should instead beimplemented through other means as


8/13/2019 2010-17210



part of the system on which an EHRmay be installed.

Response. We believe that CertifiedEHR Technology must be capable ofperforming encryption. Because of theflexibility in the adopted standard,however, how encryption is technicallyimplemented is up to the Complete EHR

or EHR Module developer to determinewithin the parameters of Annex A ofFIPS 140–2. Given the changes we havemade to the general encryptionstandard, we believe that the full rangeof the most secure encryption

algorithms are available for CompleteEHR and EHR Module developers toimplement.

Comments. A few commenters statedthat the term ‘‘user-defined preferences’’

in the certification criteria was toovague and allowed too much latitude fordivergent interpretations of therequirement. Other commenters noted

that users do not always get to definesuch preferences as they would conflictwith overarching organizationalpolicies.

Response. We intended the phrase,‘‘according to user-defined preferences’’

in the Interim Final Rule, to mean thatusers would have the ability to electwhen they wanted encryption to occur,for example, at log-off. We recognizethat organizational policies, software asservice models and other architecturesin which Certified EHR Technology may

be implemented, could lead toencryption being instituted insignificantly different ways and, as aresult, we have removed the reference to‘‘user-defined preferences.’’

Section 170.302(v)—Accounting ofDisclosures




Interim Final Rule Text:Record disclosures made for treatment, payment, and health

care operations in accordance with the standard specified in§ 170.210(e).

Final Rule Text: §170.302(w).Certification criterion made optional, while the text of this certifi-

cation criterion remains unchanged.

Comments. Many commentersasserted that the certification criterionand accompanying standard foraccounting of disclosures for treatment,payment, and health care operations (asthese terms are defined at 45 CFR164.501) would be a resource intensiveprocess and too administratively,technically, and financially

burdensome. A large portion ofcommenters further conveyed specificchallenges including: The ability todifferentiate between a ‘‘use’’ and a‘‘disclosure

’’(as these terms are definedat 45 CFR 160.103); storing three years

worth of disclosures, which many notedcould be voluminous; that health careproviders, especially hospitals, havedecentralized systems, which today aremanually accessed to create anaccounting of disclosures; thedevelopment time for such a capabilitywould take more time than is available

before the meaningful use Stage 1effective date; that it would be difficultto account for these types of disclosuresin real-time without a code set fordisclosures; that this requirement could

affect workflow; and the scope ofelectronic exchanges that the term‘‘disclosure’’ would encompass isunclear. A majority of commenters alsoechoed that the Secretary should usediscretion provided by the HITECH Actto delay the compliance date foraccounting of disclosures for treatment,payment, and health care operations.Commenters supported this suggestion

by pointing out that the Secretary hasnot yet formally established the policiesfor accounting of disclosures. Theyexplained that the HITECH Act requires

the Secretary to promulgate a rule nolater than six months after the Secretaryhas adopted a standard for accounting ofdisclosures, which has not yet occurred.Many of these commenters suggestedthat the certification criterion andstandard should be removed or theiradoption delayed until after thetechnical specifications for accountingof disclosures can be harmonized withthe Secretary’s forthcomingpromulgation of a regulation on thisissue. Other commenters noted that the

HIT Policy Committee includedaccounting of disclosures in itssuggestions as a meaningful use Stage 3objective. In response to the questionswe posed, several commenters notedthat to whom the disclosure was made(recipient) should be an importantelement included in an accounting ofdisclosures. One commenter noted thatthe standard should be the same as whatis currently applicable to disclosuresthat are not for treatment, payment, andhealth care operations and cited therequirements at 45 CFR 164.528(b)(2).Other commenters stated that theadopted certification criterion should bean audit log.

Response. We appreciate thethoroughness, specificity, and detailprovided by many of those whocommented on this certificationcriterion. We recognize that significanttechnical and policy challenges remainunresolved. Accordingly, we do not

believe that the capability to account fordisclosures should be a condition ofcertification at the present time. Asdiscussed in the beginning of thepreamble of this final rule, we have

decided to make this certificationcriterion ‘‘optional’’ instead of removingit. Additionally, the standard willremain unchanged as currently wordedand as applicable to the certificationcriterion to provide guidance toComplete EHR and EHR Moduledevelopers that choose to adopt thiscapability at this time. As an optionalcertification criterion, though, CompleteEHR or EHR Module will not berequired to possess the capability forcertification. As we stated previously in

the Interim Final Rule, we plan to workcollaboratively with the Office for CivilRights (OCR) as it develops theregulatory policy related to thisrequirement. We anticipate updatingthis certification criterion and therelated standard in a future rulemakingto reflect OCR’s final policies regardingaccounting of disclosures.

Comment. Several commentersrequested that we clarify what is meant

by a ‘‘description of the disclosure.’’Some commenters noted that it wouldnot be possible to include thesedescriptions in an accounting withoutcode sets for the various types ofdisclosures. These commenters alsoindicated that this requirement couldhave serious workflow implicationsunless it can be fully automated.

Response. We recognize thetechnological challenges associated witheffectively and efficiently addressingthis aspect of the standard which somecommenters mentioned. We alsorecognize that the regulated communityis awaiting the proposed rule andsubsequent final rule that willimplement important privacy provisions


8/13/2019 2010-17210



of the HITECH Act. As we discussed inthe Interim Final Rule, we intended toleave Complete EHR and EHR Moduledevelopers with the flexibility toinnovate in this area and to developnew solutions to address the needs oftheir customers. We anticipated that a‘‘description of the disclosure’’ would, atthe present time, be a free text field that

would have included any informationthat could be readily and electronicallyassociated with the disclosure. Forexample, we envisioned that some

descriptive information could beincluded such as the words ‘‘treatment,’’‘‘payment,’’ or ‘‘health care operations’’

separately or together as a generalcategory. We also assumed thatComplete EHR and EHR Moduledevelopers could find innovative waysto associate certain electronicallyavailable information with the

disclosures, such as, to whom thedisclosure was made. Again, for thetime being, we have made thiscertification criterion optional, and will

wait for OCR to promulgate finalregulations for accounting ofdisclosures, before revisiting whetherthis certification criterion should berequired.

b. Specific Certification for CompleteEHRs or EHR Modules Designed for anAmbulatory Setting—§ 170.304

Section 170.304(a)—ComputerizedProvider Order Entry


Use CPOE for medication ordersdirectly entered by any licensedhealthcare professional who canenter orders into the medicalrecord per state, local and pro-fessional guidelines.

More than 30% of unique patientswith at least one medication intheir medication list seen by theEP or admitted to the eligiblehospital’s or CAH’s inpatient oremergency department (POS 21or 23) have at least one medica-tion order entered using CPOE.

Interim Final Rule Text:Enable a user to electronically record, store, retrieve, and man-

age, at a minimum, the following order types:(1) Medications;(2) Laboratory;(3) Radiology/imaging; and(4) Provider referrals.

Final Rule Text: §170.304(a).Computerized provider order entry. Enable a user to electroni-

cally record, store, retrieve, and modify, at a minimum, the fol-lowing order types:

(1) Medications;(2) Laboratory; and(3) Radiology/imaging.

Comments. A couple of commentersnoted that within the confines of manyhospitals, just about any ‘‘order’’ can beentered, so the process of order entry isdefined. For providers, the commenternoted that the ability to perform ordersvaries. The commenter inquiredwhether a specific meaning for orderentry was intended for this certificationcriterion. A few commenters supportedthe certification criterion. Onecommenter recommended that referralsto dieticians, speech therapists, childlife and social services be added to theorder types, as well as durable medicalequipment, orthotics, and prosthetics.Another commenter recommended thatCPOE include a Patient Plan of Care(PPOC) because, according to thecommenter, PPOC requires the contentnecessary for electronic datainteroperability. The commenter feltthat PPOC within an EHR would help toachieve the integration goals thatpromote the appropriate exchange ofmedical information for the optimalcoordination of patient care in differenthealthcare settings. Another commentersuggested that we narrow the CPOErequirements to focus on medications,laboratory tests, and imaging tests. Onecommenter stated that based on thediscussions of CPOE in the InterimFinal Rule and the Medicare andMedicaid EHR Incentive Programsproposed rule, we should consider arequest for a consultation or a provider

referral made by an eligible professionalin a private practice to constitute anorder that should be handledfunctionally through CPOE.

Response. We agree with thecommenter that suggested that wenarrow our focus, in order to reduce the

burden associated with this certificationcriterion. Accordingly, we have

removed ‘‘provider referrals’’ from thecertification criterion. Complete EHRand EHR Module developers mayinclude additional orders as they see fitand as recommended by somecommenters, however in order to becertified they must include at aminimum the three order types(medications, laboratory, and radiology/imaging) specified in the certificationcriterion. Many commenters generallysupported these three specified ordertypes and we note that while the finalmeaningful use Stage 1 objective focuseson medication orders, we believe that

for the purposes of certification and toequip eligible professionals with a basicset of ordering capabilities, it isappropriate to continue to maintainthese three order types. (This responsealso applies to the change we made inthe CPOE certification criterion forComplete EHRs or EHR Modulesdesigned for an inpatient setting).Finally, in further reviewing thiscertification criterion in light ofcomments received, we have alsodetermined that it would be appropriateand clearer to replace the term ‘‘manage’’

with ‘‘modify’’ to be more consistentwith the terminology used in othercertification criteria. We have also madethis change in the CPOE certificationcriterion for Complete EHRs and EHRModules designed for an inpatientsetting.

Comment. A commenter stated thatthe lab industry does not have any

standards for order entry, and evenamong lab providers, their operatingunits utilize different standards. Thecommenter contended that this lack ofconsistency in order entry wouldrequire EHRs to build custom interfacesto every lab. They recommended thatwe require that Certified EHRTechnology provide the ability to linkthe results to the original order. Anothercommenter recommended that thecertification criterion include therequirement for standardized bi-directional laboratory interfaces,including functionality pertinent to all

the laboratory order data needed for thelaboratory to conduct proper testing,patient matching and billing (includinglimited coverage rules and printing ofAdvance Beneficiary Notices (ABNs)).

Response. In the certification criteriondiscussed above regarding incorporatinglaboratory test results, we have requiredthat Certified EHR Technology becapable of electronically attributing,associating, or linking a laboratory testresult to a laboratory order or patientrecord. Bidirectional exchange(including electronic transmission of


8/13/2019 2010-17210



laboratory orders) is not a requirementof meaningful use Stage 1 and is beyondthe scope of this rule.

Comments. Several commentersrecommended we clarify that the user ofCPOE includes the eligible professionaland any authorized user in the office ofthe eligible professional (EP). They alsorecommended that CPOE be deemed to

include the scenario in which only theactual orders are entered by the EP, withthe additional billing and demographicinformation entered by authorized usersin the EP’s office or even by thirdparties (e.g. laboratory personnel in thepatient service center of a laboratorythat collects specimens from thepatient).

Response. As we stated in an earlierresponse, the standards, implementationspecifications, and certification criteriaadopted in this final rule apply toComplete EHRs and EHR Modules. Wehave focused on whether Certified EHR

Technology must include a capabilityand how it must perform the capability.As a result, it is not within the scope ofthis rulemaking to specify the personswho would need to use CPOE.

Comment. A commenter suggestedthat we not create controlledvocabularies or value sets in the

regulation but rather refer to and adoptexisting controlled vocabularies orsubsets. The commenter also stated thatthe regulation introduces a requirementto record, store, retrieve and manageorders, though no vocabularies arespecified and further pointed out thatthere are no vocabularies or standardsfor orders, images, or referrals in any

part of the Interim Final Rule. Thecommenter recommended that theDepartment focus its efforts onidentifying and adopting standards forcomputable and interoperablerepresentations of these elements andprocesses before directing eligibleprofessionals to implement ‘‘CPOE.’’

Response. We appreciate thecommenter’s concern. This is an initialset of standards, implementationspecifications, and certification criteriaand we expect to adopt more standards,implementation specifications, andcertification criteria in the future as

necessary to improve thecomprehensiveness of certaincapabilities.

Comment. A commenter requestedthat we clarify whether only imagingand radiology reports were intended to

be included in this capability, or, if weintended to include the images

themselves in addition to the imagingreports as part of the certificationcriteria. The commenter recommendedthat we further clarify the criterion andmoreover, adopt the DICOM standard inthe initial set of standards, as anessential step in meeting the CPOEcapability.

Response. We clarify that the adopted

certification criteria related to CPOEpertain only to the ordering, and not tothe delivery of results (reports orimages). As a result, we do not believethat this commenter’s recommendationis applicable to this certificationcriterion.

Comment. A commenterrecommended that the CPOEcertification criterion should include aprompt for an authorized user of theCPOE to include diagnosis codes atorder entry.

Response. We do not believe that itwould be appropriate to specify this

type of capability as a condition ofcertification because it is not central tothe meaningful use objective andmeasure this certification criterion isintended to support.

Section 170.304(b)—ElectronicallyExchange Prescription Information


Generate and transmit permissibleprescriptions electronically (eRx).

More than 40% of all permissibleprescriptions written by the EPare transmitted electronicallyusing certified EHR technology.

Interim Final Rule Text:Enable a user to electronically transmit medication orders (pre-

scriptions) for patients in accordance with the standards speci-fied in § 170.205(c).

Final Rule Text: §170.304(b).

Electronic prescribing. Enable a user to electronically generateand transmit prescriptions and prescription-related informationin accordance with:

(1) The standard specified in §170.205(b)(1) or §170.205(b)(2);and

(2) The standard specified in 170.207(d).

Comments. Many commenterssupported the adoption of NCPDPSCRIPT 8.1 and the inclusion of NCPDPSCRIPT 10.6. These commenters alsoencouraged the exclusive adoption ofNCPDP 10.6 for meaningful use Stage 2.One commenter stated that moreclarification was needed as to which

NCPDP SCRIPT standard was requiredfor certification.

Response. In the Interim Final Rule,we stated that we expected that CMSwould identify as a backwardscompatible standard NCPDP SCRIPT10.6 and permit its use as an alternativeto NCPDP SCRIPT 8.1 for the electronictransmission of prescription and certainother prescription-related informationfor Medicare Part D covered drugsprescribed for Part D eligibleindividuals (75 FR 38026). Further, we

stated that ‘‘if SCRIPT 10.6 is permitted,prior to any modification of theprovisions of this interim final rule inresponse to public comment, we wouldexpect to change our requirement tosimply permit either SCRIPT 8.1 orSCRIPT 10.6.’’ Accordingly, we havemodified this certification criterion to

specify that Complete EHR and EHRModule developers may seek to havetheir Complete EHR or EHR Moduletested and certified to either solelyNCPDP SCRIPT 8.1 or 10.6.Additionally, we have also replaced thestandard adopted in the Interim FinalRule and have adopted both NCPDPSCRIPT 8.1 and NCPDP SCRIPT 10.6.As discussed in the beginning of thepreamble, we have revised our approachto specifying the certification criteria tomore clearly focus on the capabilities

with which they must be associated.Therefore, we have modified thiscertification criterion to specify that aComplete EHR or EHR Module would becompliant with this certificationcriterion if it has the capability ofgenerating and transmitting prescriptionand prescription-related information

according to NCPDP SCRIPT 8.1 whilealso using the adopted vocabularystandard, or if it is capable of generatingand transmitting prescriptions andprescription-related informationaccording to NCPDP SCRIPT 10.6 whilealso using the adopted vocabularystandard.

Comments. Several commenterssupported the adoption of RxNorm andthe use of RxNorm code sets as avocabulary standard. One commenterrecommended that RxNorm be adopted


8/13/2019 2010-17210



7http://www.nlm.nih.gov/research/umls/rxnorm/ docs/2010/rxnorm _doco _ full _2010–3.html.

in Stage 1 while one commenter statedthat Stage 2 is likely the earliesttimeframe practicable forimplementation. Others suggested thatmore testing was needed before RxNormcould be adopted in full. Somecommenters stated that RxNorm is notcomplete and requested guidance onhow gaps in RxNorm will be addressed.

A couple commenters stated a concernthat current drug databases do not mapto RxNorm and that in order to developinterfaces for electronic prescribingservices, pharmacies and developerswill need to expend significant effort.Other commenters stated that moreclarification was needed with respect tothe description of the adopted standardand one of those commentersrecommended that the description bechanged to ‘‘a drug data source providerthat demonstrates group domaincomprehensiveness.’’

Response. We have consolidated and

addressed our adopted vocabularystandard for medications under thiscertification criterion. However, ourresponse and subsequent clarificationsare applicable to all certification criteriathat reference this vocabulary standard.

As we explained in the Interim FinalRule, we determined that the HITindustry would benefit from a certaindegree of flexibility with respect to thecoding of medications. To provide thisflexibility while also establishing a glidepath to full adoption of RxNorm, weadopted a standard that permits the useof one of many different vocabularystandards. We specified that a Complete

EHR or EHR Module would becompliant with the adopted vocabularystandard if it utilized ‘‘[a]ny code set byan RxNorm drug data source providerthat is identified by the United StatesNational Library of Medicine as being acomplete data set integrated withinRxNorm.’’ We specified the standardthis way in order to establish what we

believe is an important bridge to fullRxNorm adoption and will helpfacilitate this transition over time. Ouradoption of this standard stems fromour belief that Complete EHRs and EHRModules should be capable of

classifying and categorizing medicationsfor the purpose of clinical qualitymeasurement and clinical decisionsupport. The National Library ofMedicine (NLM) maintains the UnifiedMedical Language System® (UMLS®),which contains the mapping betweenRxNorm and commonly utilized drugvocabularies.

At the time we published the InterimFinal Rule, we noted that NLM,according to the most recent RxNormrelease, listed a number of RxNorm drugdata source providers with complete

data sets integrated within RxNorm.After the Interim Final Rule waspublished, NLM subsequently releasedseveral more RxNorm versions. NLMhas also reorganized the RxNormdocumentation in a way that we believemore clearly specifies the intent of ourstandard. Accordingly, we believe thatthis standard, particularly in response to

public comments, can be furtherclarified. In addition, to permit thedevelopment or mapping and use ofother vocabularies independent of NLM,we have dropped the requirement thatNLM explicitly identify the acceptabledata sources. Instead, the standard nowpermits the use of codes from any drugvocabulary successfully included inRxNorm. To provide guidance andclarification to the industry, we willrecognize any source vocabulary that isidentified by NLM’s RxNormDocumentation as a source vocabularyincluded in RxNorm. We are therefore

revising the standard to state:‘‘Anysource vocabulary that is included in

RxNorm, a standardized nomenclaturefor clinical drugs produced by theUnited States National Library ofMedicine.’’ We note that in section 3.1,of the most recent release of the‘‘RxNorm Documentation (06/07/10,Version 2010–3) 7,’’ NLM has identifiedthe following source vocabularies as

being included in RxNorm.• GS—Gold Standard Alchemy.• MDDB—Medi-Span Master Drug

Data Base.• MMSL—Multum MediSource

Lexicon.

• MMX—Micromedex DRUGDEX.• MSH—Medical Subject Headings(MeSH).

• MTHFDA—FDA National DrugCode Directory.

• MTHSPL—FDA Structured ProductLabels.

• NDDF—First DataBank NDDF PlusSource Vocabulary.

• NDFRT—Veterans HealthAdministration National Drug File—Reference Terminology.

• SNOMED CT—SNOMED ClinicalTerms (drug information).

• VANDF—Veterans HealthAdministration National Drug File.

We clarify for commenters that thestandard we have adopted is afunctional standard that enables the useof any source vocabulary that isincluded within RxNorm. Consequently,any one of these ‘‘source vocabularies’’

identified by NLM may be used, or anyother source vocabulary successfullyincluded within RxNorm.

Comments. A few commenters statedconcerns about this certification

criterion causing two differentworkflows because of the restrictionsplaced on the electronic prescribing ofcontrolled substances.

Response. The Drug EnforcementAgency has since published an interimfinal rule (75 FR 16236) on therequirements related to the electronicprescribing of controlled substances. At

the present time, we do not require asa condition of certification for CompleteEHRs and EHR Modules that they becapable of enabling compliance with thecurrent DEA provisions for theelectronic prescribing of controlledsubstances.

Comments. A couple of commentersstated that the prescribing capabilitiesmust allow for weight-based dosingcalculation with intelligent roundingand that without this, e-prescribing willnot be helpful to pediatricians.

Response. We recognize that this is animportant capability for pediatricians;however, we do not believe that itnecessary to require it as a condition ofcertification at the present time. Again,this does not preclude Complete EHRand EHR Module developers fromincluding this capability.

Comments. A few commentersexpressed concerns about somepharmacies not being capable ofreceiving electronic prescriptions whichthey stated could cause a negativeimpact on the workflow. Onecommenter suggested that we add a‘‘where possible’’ to the certificationcriterion.

Response. While we recognize that

some pharmacies may be unable toreceive electronic prescriptions at thepresent time, we do not believe thislimitation should affect the capabilitythat Certified EHR Technology mustprovide. Further, we do not believe thatinserting ‘‘where applicable’’ would be

beneficial because it would make thecriterion unnecessarily ambiguous. Thisphrase would relate to when electronicprescribing should be conducted, nothow it should be done, which is thefocus of this certification criterion.

Comment. A commenter stated thatthe electronic prescribing process

should be linked to the contraindicationand formulary conflict process andshould provide automatic alerts.Another commenter recommended thatinformation relating to the language thepatient speaks should be required aspart of the electronic prescribingprocess, so that pharmacy is notified ofa patient’s need for language assistance.

Response. We do not believe that itwould be appropriate to expand thecertification criterion as suggested atthis time. This does not preclude aComplete EHR or EHR Module


http://www.nlm.nih.gov/research/umls/rxnorm/docs/2010/rxnorm_doco_full_2010-3.html










8/13/2019 2010-17210



developer from pursuing other ways tooptimize how a Complete EHR or EHRModule may function.

Section 170.304(c)—RecordDemographics


Record demographics:• preferred language• gender• race• ethnicity• date of birth

More than 50% of all unique pa-tients seen by the EP or admit-ted to the eligible hospital’s orCAH’s inpatient or emergencydepartment (POS 21 or 23)have demographics recorded asstructured data

Interim Final Rule Text:Enable a user to electronically record, modify, and retrieve pa-

tient demographic data including preferred language, insur-ance type, gender, race, ethnicity, and date of birth.

Final Rule Text: §170.304(c).Record demographics. Enable a user to electronically record,

modify, and retrieve patient demographic data including pre-ferred language, gender, race, ethnicity, and date of birth. En-able race and ethnicity to be recorded in accordance with thestandard specified at 170.207(f).

Comments. Several commentersrecommended that we adopt the OMBrace and ethnicity codes.

Response. We agree with thesecommenters and have adopted the OMBrace and ethnicity codes. In theMedicare and Medicaid EHR Incentive

Programs proposed rule (75 FR 1855),CMS stated that race and ethnicitycodes should follow current Federalstandards. We note that the OMB raceand ethnicity codes constitute agovernment-unique standard for thepurposes of the National TechnologyTransfer and Advancement Act of 1995(NTTAA). We have adopted thisstandard because it provides an easilyunderstood structure and format forelectronically transmitting the dataelements identified in the meaningfuluse Stage 1 objective, the standard isreadily available, in general it providesthe best standard to use to support ourpolicies goals. Moreover, we are

unaware of any alternative voluntaryconsensus standard that accomplishesthe same purpose.

Comments. Several commentersrecommended additional elements forthe certification criterion for us toconsider adding. One commenter

recommended that we include moredemographic data items to allowsuccessful matching with prioradmissions and further that we considerrequiring the inclusion of social securitynumber, birthplace, and years ofeducation, if available. A couplecommenters requested that we addoccupation and industry status as well

because they are already required forcancer registries. Another commentersuggested that we add family history todemographics that should be capturedand reported. One commenter suggestedthat we also include a patient’sfunctional status. Many commenterssuggested that we encourage self-

reporting of demographics and indicatewhether information was self-reported.Finally, one commenter stated thatEHRs are not appropriate source of legaldocumentation for births and deaths.

Response. While we understandcommenters’ intentions, we do not

believe that it would be appropriate toexpand this certification criterion

beyond what is required to supportmeaningful use. Again, as we havepreviously stated, this does not precludea Complete EHR or EHR Moduledeveloper from including the capabilityto record additional demographicinformation. Finally, consistent with theMedicare and Medicaid EHR IncentivePrograms final rule, we have removedthe capability to record insurance typefrom the certification criterion.

Section 170.304(d)—Generate Patient

Reminder List


Send reminders to patients per pa-tient preference for preventive/follow up care

More than 20% of all unique pa-tients 65 years or older or 5years old or younger were sentan appropriate reminder duringthe EHR reporting period

Interim Final Rule Text:Electronically generate, upon request, a patient reminder list for

preventive or follow-up care according to patient preferencesbased on demographic data, specific conditions, and/or medi-cation list.

Final Rule Text: §170.304(d).Patient reminders. Enable a user to electronically generate a pa-

tient reminder list for preventive or follow-up care according topatient preferences based on, at a minimum, the data ele-ments included in:

(1) Problem list;(2) Medication list;(3) Medication allergy list;(4) Demographics; and(5) Laboratory test results.

Comments. Several commentersstated that they support thiscertification criterion. Othercommenters requested further definitionof the term ‘‘specific conditions,’’particularly whether this term refers todata as contained in the problem list.One commenter suggested that thecriterion text be modified to read:

‘‘Electronically generate, upon request, apatient reminder list for preventive orfollow-up care according to patient orphysician preferences based ondemographic data, specific conditions,and/or medication list.’’ Severalcommenters requested further definitionof the term ‘‘patient preferences.’’Clarification was requested about the

meaning of the term, how thesepreferences would be recorded, how thepreferences would be used, and whetherthe preferences should be automated. Aquestion was raised by two commentersabout how many choices should beallowed for the preferred reminderdelivery method due to additional EHRsystem programming that may be


8/13/2019 2010-17210



needed to support the set of choices.One commenter was concerned aboutwhether there would be a cost tophysician practices to implement thisrequirement and whether the practiceswill have the capacity to accommodatethis requirement. Another commentersuggested that this requirement bemoved to meaningful use stage 2 to

allow more time for EHRs to beenhanced. Several commentersrequested clarification of the term ‘‘uponrequest.’’ One commenter wanted toknow which persons would beauthorized to request the patientreminder list and how often. Anothercommenter suggested that the phrase‘‘upon request’’ be removed, as it

believed that outpatient physicianscould make significant advances in thehealth of their patients by generatingand delivering reminders at everyencounter.

Response. In response to comments,

we have revised this certificationcriterion to more clearly articulate thecapability we expect Certified EHRTechnology to include. CMS discussesand clarifies the intended meaning of‘‘patient preferences’’ in the Medicareand Medicaid EHR Incentive Programsfinal rule and because this term isderived from the meaningful use

objective, we encourage commenters toreview CMS’s responses to theirrequests for clarification. Consistentwith the revisions we made to the‘‘generate patient lists’’ certificationcriterion, we believe that Certified EHRTechnology should be able to leveragethe information, specifically thestructured data it had available to it, to

assist eligible professionals and eligiblehospitals generate a patient reminderlist. We have removed ‘‘upon request’’from the certification criterion, because,after further review, we believe that theaction of requesting a list is implied bythe certification criterion and themeaningful use measure, and therefore,unnecessary to further specify.

Comments. Two commenters statedthat specialists will use patientreminders differently than primary careproviders. These commenters worriedthat some patients’ preferences mayexceed a system’s current capabilities

and one commenter requested that thephrase ‘‘with respect to systemcapability’’ be added after ‘‘patientpreferences.’’

Response. We understand thesecommenters’ points of view, however,we do not believe that this addition isnecessary given the references in thecertification criterion to specified data

elements and CMS’s express desire toconsider patient preferences asdescribed in the Medicare and MedicaidEHR Incentive Programs final rule.

Comments. Two commenters askedwhether this requirement refers to thecreation of a list for the internalpurposes of the eligible professional andhis/her staff only and does not refer toor require electronic communication toa patient.

Response. Yes, we expect CertifiedEHR Technology to be capable ofgenerating a patient reminder list for aneligible professional and his/her staff.The meaningful use measure establishesthe requirement for an eligibleprofessional to take action once thereminder list has been generated.

Comments. Two commenterssuggested that the set of variablescontained in the demographicinformation for the patient lists note the

preferred language of the patient.Response. Preferred language is

included in demographics and we donot believe that it is necessary toexpressly call it out as part of thiscertification criterion.

Section 170.304(e)—Clinical DecisionSupport


Implement one clinical decisionsupport rule relevant to specialtyor high clinical priority along withthe ability to track compliancethat rule.

Implement one clinical decisionsupport rule.

Interim Final Rule Text:(1) Implement rules. Implement automated, electronic clinical de-

cision support rules (in addition to drug-drug and drug-allergycontraindication checking) according to specialty or clinical pri-orities that use demographic data, specific patient diagnoses,conditions, diagnostic test results and/or patient medicationlist.

(2) Alerts. Automatically and electronically generate and indicatein real-time, alerts and care suggestions based upon clinicaldecision support rules and evidence grade.

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

Final Rule Text: §170.304(e).(1) Implement rules. Implement automated, electronic clinical de-

cision support rules (in addition to drug-drug and drug-allergycontraindication checking) based on the data elements in-cluded in: problem list; medication list; demographics; and lab-oratory test results.

(2) Notifications. Automatically and electronically generate andindicate in real-time, notifications and care suggestions basedupon clinical decision support rules.

Comments. Several commenters wereexplicitly supportive of this certificationcriterion, while others offered specificsuggestions and requests forclarification. Several commentersrequested that we specify the decisionssupport rules that should be included.One commenter asked if we couldclarify whether a Complete EHR or EHRModule developer would have to

include specific rules that individualeligible professionals would want orwhether those rules could be addedlater. Another commenter asked forclarification regarding several termsincluding ‘‘diagnostic test results,’’whether a ‘‘condition’’ was equivalent to‘‘problem,’’ as well as whether the ruleswould be associated with qualitymeasures.

Response. In consideration ofcommenters’ request for clarificationand to more closely align thiscertification criterion with themeaningful use measure, we haverevised this certification criterion. Wehave removed the terms that causedsome confusion with commenters and

believe that these revisions will providemore specificity and will make


8/13/2019 2010-17210



compliance with the certificationcriterion easier. Moreover, we clarifythat with respect to notifications, that‘‘real-time’’ means at the point of clinicaldecision making (i.e., notifications must

be provided when an eligibleprofessional is using Certified EHRTechnology and not run overnight andprovided in the morning, for instance).

Comments. A number of commentersasked questions and requestedclarifications regarding ‘‘alerts.’’ Onecommenter requested whether it is thenumber of alerts that is important or thetype of alerts that is important and howwe expect an eligible professional torespond to an alert. The commenter alsoasked if we could clarify what wouldqualify as a ‘‘response.’’ One commenterstated that whether we intended for theexamples (pop-up or sound) to beinclusive of the types of alerts weexpected Certified EHR Technologywould include and whether this was

deemed more valuable than a morepassive notification. The commentersuggested that the word ‘‘alert’’ bereplaced with ‘‘notification’’ while

another suggested the word ‘‘advisory.’’Some commenters requestedclarification regarding ‘‘alerts respondedto by a user’’ and whether there was anexpectation that alerts communicatestructured reasons. These commentersalso asked whether users would enter areason for any overrides or, in the caseof notifications, the user would simply

acknowledge the alert by clicking ‘‘OK.’’The commenters also questionedwhether ignored alerts should betracked? Many of these commentersrecommended removing § 170.304(e)(3).Alternatively, one commenterrecommended that we not only considerthe number of alerts ‘‘responded to’’ butalso the action prompted and whetheror not that action was taken.

Response. We thank commenters forthe thorough feedback on thiscertification criterion. We have alreadyaddressed in our responses above theconcerns raised by commenters and will

not repeat them here. With respect tothe third part of this certificationcriterion, we have considered publiccomment and have decided to remove

the requirement from the certificationcriterion. We also removed thisrequirement to be more consistent withCMS’s expectations for meaningful use,which do not include requiring thetracking of alerts at this time.

Comments. A few commenters askedfor clarification on what we meant by‘‘evidence grade’’ and what standard for

evidence grading will be applied inorder to determine compliance with thisobjective. Other commenters noted that‘‘evidence grade’’ as a part of the rulesto trigger alerts is not widely availablein the marketplace and that usingevidence grade in this manner could be

burdensome and present a significantmaintenance issue.

Response. We have considered publiccomment, and agree that evidence gradeis not as widely available in themarketplace as we had anticipated. Wetherefore remove our reference to‘‘evidence grade’’ in the certificationcriterion.

Section 170.304(f)—Electronic Copy ofHealth Information


Provide patients with an electroniccopy of their health information(including diagnostic test results,problem list, medication lists,medication allergies), upon re-quest.

More than 50% of all patients ofthe EP or the inpatient or emer-gency departments of the eligi-ble hospital or CAH (POS 21 or23) who request an electroniccopy of their health informationare provided it within 3 businessdays.

Interim Final Rule Text: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, immuniza-tions, 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 min-

imum, 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).

Final Rule Text: §170.304(f).Electronic copy of health information. Enable a user to create an

electronic copy of a patient’s clinical information, including, ata minimum, diagnostic test results, problem list, medicationlist, and medication allergy list in:


in accordance with:(i) The standard (and applicable implementation specifications)

specified in §170.205(a)(1) or §170.205(a)(2); and(ii) For the following data elements the applicable standard must

be used:(A) Problems. The standard specified in §170.207(a)(1) or, at a

minimum, the version of the standard specified in§ 170.207(a)(2);

(B)Laboratory test results. At a minimum, the version of thestandard specified in §170.207(c); and

(C) Medications. The standard specified in §170.207(d).

Comment. A commenterrecommended that durable medicalequipment and supplies be added to theminimum list.

Response. In the context of theMeaningful Use Stage 1 objective andmeasure, we do not believe that it isappropriate, at the present time, to add

durable medical equipment in thecertification criterion. However, thatdoes not preclude Complete EHRs and


8/13/2019 2010-17210



EHR Modules from having thatadditional capability.

Comments. A few commentersrequested clarification as to theunderlying intent of the certificationcriterion and whether it was intendedthat a patient be provided with acomplete medical record or simply a‘‘snapshot.’’ Commenters also asked how

longitudinal the copy must be andrequested that we specify a time periodthat the electronic copy must cover. Acommenter stated that eligibleprofessionals should be able to limit theapplicable time period by episode ofcare or other parameters. Thecommenter noted that state law alsospecifies the information that can beprovided to a patient without theprovider serving as an intermediary. Afew commenters requested clarificationthat the medication list is limited to thecurrent medication list. A commenterrecommended that the certification

criterion be limited only to informationreadily available to the provider at theconclusion of a patient encounter.

Response. We expect Certified EHRTechnology to be capable of generatingan electronic copy of health informationthat includes the minimum elementsrequired as a condition of certification.We do not believe that it is appropriateto dictate the timeframe suchinformation must encompass, but wewould expect that it would include, ata minimum, the most currentinformation that is available andaccessible within the Certified EHRTechnology. We do not believe that

limiting this certification criterion tospecify that just the informationavailable at the end of an encounter isconsistent with our policy objectives.

Comments. Many commentersrequested a definition of ‘‘diagnostic testresults.’’ One commenter suggested thatfor Stage 1, the definition of diagnostictest result be made clear and be limitedto, at a minimum, lab results.

Response. This term is derived fromthe Medicare and Medicaid EHRIncentive Programs final rule, and itsmeaning is described there. Weencourage commenters to review theMedicare and Medicaid EHR IncentivePrograms final rule.

Comments. Several commentersrequested that ONC define how relevant

procedures are determined for thecertification criterion. The commenterssuggested that a subset of procedures(e.g., surgeries, catheterizations) bedefined to avoid generating huge lists of‘‘small’’ procedures (e.g., venipunctures).These commenters expressed that it wascritical for the rule to provide a clear,clinically-relevant definition of which

types of procedures are to be included.Response. We appreciate the

comment and have revised thiscertification criterion to remove‘‘procedures’’ as well as‘‘immunizations,’’ to be more consistentwith the final meaningful use objectiveand measure and for greater clarity.

Comment. A commenter requestedclarification on how an electronic copywill be disseminated, and providedexamples such as a web-portal, e-mail,and compact disc.

Response. We do not specify themethod by which an individual mustreceive an electronic copy of thespecified health information, only thatCertified EHR Technology be capable ofelectronically generating an electroniccopy in human readable format and inaccordance with one of the adoptedsummary record standards. WhileCertified EHR Technology must becapable of creating an electronic copy ofa patient’s health information asspecified in this certification criterion,we encourage Complete EHR and EHRModule developers to also include thecapability to generate an electronic copyin a manner that allows eligibleprofessionals (and eligible hospitals as

this capability relates to Complete EHRsand EHR Modules designed for aninpatient setting) to comply withapplicable provisions of the HIPAAPrivacy and Security Rules.

Comment. A commenter requestedthat we add a requirement for alerts toprompt users to ask patients if theywant a copy of their health informationand include the ability to recordwhether the information was actuallyprovided and the patient’s preference onthe format of the information. Thecommenter believed that thisrequirement is necessary because manypatients are not aware that they canmake such a request.

Response. While potentially useful asa reminder, we do not believe that this

capability should be a condition ofcertification. This capability wouldexceed the scope of the relevantmeaningful use Stage 1 objective andmeasure. We also note that CompleteEHR and EHR Module developers arenot precluded from including thiscapability in their EHR technology.

Comment. A commenter noted thatwith our emphasis on the representationof clinical information in the format ofa CCD or CCR, it is unclear whether thecertification criterion is enough to meetpatients’ expectations.

Response. We recognize that thisminimum information may not satisfyevery patient’s interests, however, we

believe that the information specifiedrepresents a core set of information thatmost patients will appreciate is morereadily accessible to them.

Comment. A commenter requested

clarification on the use of the word‘‘and’’ in the certification criterion andquestioned whether it suggested that theCertified EHR Technology must generatetwo outputs to produce an electroniccopy (i.e., a copy in human readableformat and a copy as a CCD or CCR).The commenter made this inquiry

because it believed that the certificationcriterion could be met through theproduction of a CCD or CCR with anappropriate style sheet. Additionally, acommenter stated that it is unclearwhether the electronic copy of thehealth information provided to patients

must be in a CCD or CCR format forStage 1 or if alternative formats areallowed. This commenter recommendedthat we clarify and distinguish betweenthe electronic medium carrying theinformation and the content enclosed.

Response. Yes, in order to meet thiscertification criterion, Certified EHRTechnology must be able to generate anelectronic copy that is in humanreadable format and as a CCD or CCR.If Certified EHR Technology is capableof generating one copy that could meet

both of these requirements, we wouldconsider that to be a compliantimplementation of this capability.

Section 170.304(g)—Timely Access


8/13/2019 2010-17210




Provide patients with timely elec-tronic access to their health infor-mation (including lab results,problem list, medication lists,medication allergies) within fourbusiness days of the informationbeing available to the EP.

More than 10% of all unique pa-tients seen by the EP are pro-vided timely (available to the pa-tient within four business daysof being updated in the certifiedEHR technology) electronic ac-cess to their health informationsubject to the EP’s discretion towithhold certain information.

Interim Final Rule Text:Enable a user to provide patients with online access to their clin-

ical information, including, at a minimum, lab test results, prob-lem list, medication list, medication allergy list, immunizations,and procedures.

Final Rule Text: §170.304(g).Timely access. Enable a user to provide patients with online ac-

cess to their clinical information, including, at a minimum, labtest results, problem list, medication list, and medication al-lergy list.

Comments. Many commenterssuggested that we should replace theword ‘‘online’’ with ‘‘electronic’’ to bemore clearly aligned with meaningfuluse and to not preclude other forms oflegitimate electronic access.

Response. We disagree. The purposeand intent of this certification criterionand its associated meaningful useobjective and measure (as clarified in

the Medicare and Medicaid EHR

Incentive Programs final rule) is toensure that patients have the ability toaccess their health information whenthey see fit to do so. Accordingly,referring to ‘‘electronic’’ in thiscertification criterion would not ensurethat Certified EHR Technology providesthe desired capability.

Comments. A few commenters askedfor clarification on the meaning of‘‘procedures

’’and type of results to be

listed in the electronic copy, forexample, lab test results, problem list,medication lists, or others specified bythe eligible professional.

Response. As discussed above, wehave revised this certification criterionto remove ‘‘procedures’’ as well as‘‘immunizations,’’ to be more consistentwith the final meaningful use objectiveand measure.

Section 170.304(h)—Clinical SummariesMeaningful use Stage 1 objective Meaningful use Stage 1 measure Certification criterion

Provide clinical summaries for pa-tients for each office visit.

Clinical summaries provided to pa-tients for more than 50% of alloffice visits within 3 businessdays.

Interim Final Rule Text:(1) Provision. Enable a user to provide clinical summaries to pa-

tients for each office visit that include, at a minimum, diag-nostic test results, problem list, medication list, medication al-lergy list, immunizations and procedures.

(2) Provided electronically. If the clinical summary is providedelectronically 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 min-

imum, 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).

Final Rule Text: §170.304(h).Clinical summaries. Enable a user to provide clinical summaries

to patients for each office visit that include, at a minimum, di-agnostic test results, problem list, medication list, and medica-tion allergy list. If the clinical summary is provided electroni-cally it must be:

(1) Provided in human readable format; and(2) Provided on electronic media or through some other elec-

tronic means in accordance with:(i) The standard (and applicable implementation specifications)


be used:(A) Problems. The standard specified in §170.207(a)(1) or, at aminimum, the version of the standard specified in§ 170.207(a)(2);

(B)Laboratory test results. At a minimum, the version of thestandard specified in §170.207(c); and


Comments. Several commentersrequested that ‘‘diagnostic test results’’

be further defined, with one commentersuggesting that lab results be theminimum and other commenters

suggesting a more comprehensive list,including diagnostic imaging results.Many commenters requestedclarification on the list of proceduresand asked whether this would include

only procedures in a recenthospitalization or historically allprocedures performed on the patient.One commenter questioned whyimmunization data appeared in the list


8/13/2019 2010-17210



and believed its inclusion wasinconsistency with the other items.

Response. We have made revisions tothis certification criterion consistentwith the changes that we have alreadydiscussed above, including the removalof certain terms.

Comment. One commenter expressedconcern that patient summaries are most

useful when the patient/family literacyand the context of the health andfollow-up care are taken intoconsideration. The commenter notedfurther that as written there is littleflexibility in this certification criterionand that many patients will beoverwhelmed with technical data thatcomes with little context forunderstanding it.

Response. We understand thecommenter’s point; however, we do not

believe that certification (which willvalidate whether a Complete EHR orEHR Module can perform this capabilityin a manner compliant with thestandards adopted by the Secretary) isthe appropriate mechanism to addressthis commenter’s concerns.

Comment. One commenter urged thatpatient summaries be affirmativelyoffered to the patient, without theirrequesting them, and that the offer beprovided in their native language withthe offer documented in the EHR.

Response. We do not believe that it iswithin the scope of this final rule torequire eligible professionals to offerpatient summaries to patients.

Comments. Several commentersrequested that this rule clarify thatproviders would only be responsible forthe completeness and accuracy of theclinical summary to the extent theyprovided or did not provide the relevantdata (e.g. if another provider has notforwarded data, they are notresponsible).

Response. We do not believe that this behavior can be addressed by thecertification criterion, nor do we believethat it is within the scope of this finalrule.

Section 170.304(i)—Exchange ClinicalInformation and Patient SummaryRecord

Meaningful use Stage 1 objectives Meaningful use Stage 1 measures Certification criterion

Capability to exchange key clinicalinformation (for example, problemlist, medication list, medication al-

lergies, diagnostic test results),among providers of care and pa-tient authorized entities electroni-cally.

Performed at least one test of cer-tified EHR technology’s capacityto electronically exchange key

clinical information.

Interim Final Rule Text:(1) Electronically receive and display. Electronically receive a pa-

tient’s summary record, from other providers and organizations

including, at a minimum, diagnostic tests results, problem list,medication list, medication allergy list, immunizations, and pro-cedures in accordance with §170.205(a) and upon receipt of apatient summary record formatted in an alternate standardspecified in §170.205(a)(1), display it in human readable for-mat.

(2) Electronically transmit. Enable a user to electronically trans-mit a patient summary record to other providers and organiza-tions including, at a minimum, diagnostic test results, problemlist, medication list, medication allergy list, immunizations, andprocedures in accordance with:

The EP, eligible hospital or CAHwho transitions their patient toanother setting of care or pro-vider of care or refers their pa-tient to another provider of careshould provide summary of care

record for each transition of careor referral.

The EP, eligible hospital or CAHwho transitions or refers theirpatient to another setting of careor provider of care provides asummary of care record formore than 50% of transitions of

care and referrals.

(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 min-imum, 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


Final Rule Text: §170.304(i)(1) Electronically receive and display. Electronically receive and

display a patient’s summary record, from other providers andorganizations including, at a minimum, diagnostic tests results,problem list, medication list, and medication allergy list in ac-cordance with the standard (and applicable implementationspecifications) specified in §170.205(a)(1) or § 170.205(a)(2).Upon receipt of a patient summary record formatted according

to the alternative standard, display it in human readable for-mat.

(2) Electronically transmit. Enable a user to electronically trans-mit a patient summary record to other providers and organiza-tions including, at a minimum, diagnostic test results, problemlist, medication list, and medication allergy list in accordancewith:

(i) The standard (and applicable implementation specifications)specified in §170.205(a)(1) or §170.205(a)(2); and

(ii) For the following data elements the applicable standard mustbe used:

(A) Problems. The standard specified in §170.207(a)(1) or, at aminimum, the version of the standard specified in§ 170.207(a)(2);

(B) Laboratory test results. At a minimum, the version of thestandard specified in §170.207(c); and


8/13/2019 2010-17210





Comments. A few commenterssupported our adoption of theContinuity of Care Record (CCR)standard for patient summary records; acouple commenters expressed nopreference; while many commenterswere opposed to our adoption of CCR asan alternate standard and did not

believe that it was an appropriateselection. Several commenters did notcomment on the merits of adopting CCDand CCR but rather expressed generalconcern that adopting two standardswould be wasteful, counter-productive,confusing, time-consuming, and reduceinteroperability. Of the commenters thatsupported the adoption of CCR, mostexpressed their appreciation for theflexibility we had provided. Thesecommenters contended that CCR waseasier to implement and would make iteasier for smaller Complete EHR andEHR Module developers to enter themarket and get certified. Onecommenter suggested that if weintended to keep both CCD and CCR asadopted standards that we specify thetransactions for which each standardshould apply. This commenterrecommended that CCD be used forexchanging summary records betweenhealth care providers and that CCR beused for exchanging summary records toPHRs. Of the commenters that opposedour selection of CCR, many of themrecommended that we adopt the CCDstandard as the sole standard forsummary records. These commentersprincipally referenced that the CCD wasa harmonization of CDA and CCR. Somecommenters stated that we did notprovide sufficient rationale for adoptingCCR and we had reopened a debate overthe two standards that was purportedlypreviously settled. Some commenterswere concerned that CCR could notsupport certain information,particularly, in the hospital setting.These commenters contended that CCRcould not support discharge informationand that CCR cannot provide input intoclinical decision support due to the lackof a common definition of how data isstructured. Other commentersreferenced that CCR is not extensibleand questioned its ability to be used forquality reporting. Several commentersrecommended that, short of adoptingsolely CCD, we provide clearer guidanceto the industry regarding what standardwe expect to adopt for future stages ofmeaningful use because CCD and CCR

are not based on a common informationmodel.

Response. We appreciate theconstructive comments andrecommendations provided bycommenters. We address our adoptionof the patient summary record standardsin this certification criterion because we

believe that it is the most applicableplace to do so. Section 3004(b)(1) of thePHSA requires the Secretary to adopt aninitial set of standards, implementationspecifications, and certification criteria.Section 3004(b)(2) of the PHSAprovided the Secretary with additionalflexibility in considering whatstandards, implementationspecifications, and certification criteriato adopt in the initial set. Section

3004(b)(2) states that ‘‘[t]he standards,implementation specifications, andcertification criteria adopted before thedate of the enactment of this titlethrough the process existing through theOffice of the National Coordinator forHealth Information Technology may beapplied towards meeting therequirement of paragraph (1).’’Accordingly, we looked at all of thestandards, implementationspecifications, and certification criteriarecognized by the Secretary at any pointin time prior to the enactment of theHITECH Act to determine whether they

should be included in this initial set.Contrary to some commentersstatements, the CCR patient summaryrecord standard was in fact recognized

by the Secretary in 2008 (73 FR 3976)as part of the HITSP ConsumerEmpowerment InteroperabilitySpecification (HITSP V2.1 2007 IS03).We understand that in January, 2009,the Secretary recognized (74 FR 3604)an updated HITSP IS03 which removedthe CCR standard. We do not believethat section 3004(b)(2) precludes theSecretary from considering all possiblestandards that were part of the ‘‘priorprocess.’’ To the contrary, we believe theHITECH Act provided the Secretarywith the authority and flexibility todetermine which standards would be

best to include in this initial set.Accordingly, we adopted both the CCRand CCD as patient summary recordstandards.

We adopted both standards for a fewreasons. First, we are aware, contrary tosome commenters’ statements, that asignificant segment of the HIT industrystill uses the CCR patient summaryrecord standard and that some health

care providers prefer the CCR over theCCD. For this reason, we did not wantto mandate, at such an early stage, thatall of these early adopters adopt adifferent summary record standard forthe purposes of meaningful use Stage 1,given that electronic health informationexchange is not required. Second, weunderstand that in some circumstancesthe CCR is easier, faster, and requiresfewer resources to implement than theCCD. We have therefore concluded thatit was appropriate to adopt the CCRstandard for patient summary records inthis initial set of standards. Finally, we

believe that at the present time, eachstandard could equally be used tosatisfy the requirements of meaningfuluse Stage 1.

Comments. Numerous commentersquestioned why we did not adopt theHITSP C32 implementationspecification for the CCD. Thesecommenters requested that we adopt theC32 implementation specification. Theynoted that it had been accepted by theindustry, tested and implemented inseveral operating environments, andwas supported by multiple EHRtechnology developers. A fewcommenters requested additionalclarification regarding our adoption of a‘‘level 2’’ CCD as part of this standardand stated that use of a level 2 CCD was

inconsistent with our adoption ofseveral adopted vocabulary standards.These commenters questioned whetherwe intended to adopt a level 3 CCD. Atleast one commenter recommended theremoval of our reference to levels.Another commenter stated that problemlist, medication list, medication allergylist, procedures, etc. are commonlyreferred to as ‘‘sections’’ of the CDA orCCD document, not ‘‘fields.’’ They statedthat sections may contain narrative textusing the CDA XML format for text, andneed not contain level 3 entries;however, they believed that in order touse the specified clinical vocabulariesfound in the Interim Final Rule in aninteroperable fashion, the codes fromthese selected vocabularies must appearin level 3 entries. Some commentersalso noted this and recommended thatwe adopt CCD and specify that thestandard must be implemented inaccordance with the HITSP C32implementation specification, using thevocabulary standards we had adopted inthe Interim Final Rule. One commenternoted that units of measure arecomponents of structured entries (CDA


8/13/2019 2010-17210



level 3) in these sections. Thecommenter supported specified clinicalvocabularies and level 3 CCD becausethe commenter felt that level 3 would benecessary to properly communicate theinformation.

Response. We have considered publiccomments and, in response, have madetwo changes. Both are related to ouradoption of the CCD standard. In theInterim Final Rule we explicitlyincluded a reference to ‘‘level 2’’ toindicate that we expected a CompleteEHR or EHR Module would be capableof generating a level 2 CCD. Afterfurther consideration, we agree thatremoving ‘‘level 2’’ from the adoptedstandard will help clarify therequirements regarding theimplementation of CCD. As somecommenters pointed out, the coded dataelements we expect to populate thefields of the CCD would necessitate‘‘level 3’’ entries. Thus, we have

removed the reference to ‘‘level 2.’’ Wealso agree, that the HITSP C32 (version2.5) implementation specification forCCD would be appropriate to adopt. Weunderstand that a majority of CompleteEHR and EHR Module developers whohave implemented the CCD standard doso according to the HITSP C32implementation specification, andconsequently we do not believe that thiswould be a significant burden. Wefurther clarify that, for the purposes oftesting and certification, a compliantCCD implemented according to theHITSP C32 must include the

information for those entries‘‘required

’’

by the HITSP C32. Additionally, wenote that as specified by thiscertification criterion, we expect thatcertain health information for whichother certification criteria require to berecorded will be used to populatecertain ‘‘optional’’ entries specified bythe HITSP C32 implementationspecification (e.g., problems from aproblem list should in most cases beavailable to populate the ‘‘conditioncontent module’’ section of the HITSPC32). Accordingly, we expect that thetest data used to evaluate whether a

Complete EHR or EHR Module cansuccessfully generate a CCD accordingto the HITSP C32 will include the dataspecified in the certification criterion topopulate the ‘‘optional’’ entries forwhich we have adopted vocabularystandards (e.g., problems). Moreover,from a consistency perspective, weexpect that the same test data referencedabove, which would be used to test andcertify a CCD implemented according tothe HITSP C32 would also be used totest and certify a Complete EHR or EHRModule’s ability to populate a CCR. This

principle is also applicable to CompleteEHRs and EHR Modules designed for aninpatient setting.

Comment. One commenter noted thatalthough CVX is identified as therequired standard for interaction withstate immunization registries, nostandard for ‘‘immunizations’’ isoutlined for the clinical summary. They

presumed that CVX could be used forthis purpose, but stated that CVX doesnot include a dose or date or reaction.

Response. Consistent with thechanges we have made elsewhere in thefinal rule, we have removed‘‘immunizations’’ from this certificationcriterion.

Comment. A commenter suggestedthat ONC strike the following from thecertification criteria ‘‘and upon receiptof a patient summary record formattedin an alternate standard specified in§ 170.205(a)(1), display it in humanreadable format.’’ Another commenterstated that data transport is notaddressed in the standards, and thecriterion instead refers to ‘‘transmit.’’The commenter suggested changing thefirst part of the criterion to ‘‘display’’

instead of ‘‘receive,’’ and the second partof the criterion to ‘‘export’’ instead of‘‘transmit.’’

Response. We disagree and have notmade these changes. We believe thatthis certification criterion expresses thecapabilities we expect Certified EHRTechnology will include. Furthermore,the action of ‘‘exporting’’ a patientsummary record does not indicate orrequire that Certified EHR Technology is

actually capable of transmitting apatient summary record to CertifiedEHR Technology implemented by adifferent eligible professional or eligiblehospital.

Comment. A commenter requestedclarification on how historical data frompaper records should be treated for thepurpose of certification. If historicaldata is on paper, the standards fordisplay are inapplicable.

Response. Data from paper recordswould not be a relevant factor for thepurposes of testing and certification. Weare concerned with whether Complete

EHRs and EHR Modules haveimplemented specific capabilities incompliance with the certificationcriteria adopted by the Secretary.

Comments. A couple of commentersrequested definition of ‘‘diagnostic testresult’’ and ‘‘procedures’’ in the contextof this criterion.

Response. Again, we do not believethat it is appropriate to define‘‘diagnostic test result’’ in this final rulesince the term is derived from theMedicare and Medicaid EHR IncentivePrograms final rule. Consistent with

other revisions we have made in thefinal rule, we have removed‘‘procedures’’ from the certificationcriterion.

Comment. At least one commenterrequested that we clarify what CertifiedEHR Technology needs to be capable ofmeeting this certification criterion. Thecommenter asked whether the

generation of a CCD or CCR wouldconstitute compliance with thiscriterion or would the import andhuman readable display of bothdocument types be required.

Response. We clarify that compliancewith this certification criterion can beachieved by demonstrating that theComplete EHR or EHR Module iscapable of receiving and displayingpatient summary records that complywith either patient summary recordstandard (and if the alternative standardis used, displaying the non-nativelyimplemented patient summary record

standard in human readable format) andgenerating and transmitting a patientsummary record according to one of thepatient summary record standardspopulated with the specified data typesand their applicable standard(s). Forexample, a Complete EHR designed togenerate patient summary records in theCCD standard would need to be capableof generating and transmitting patientsummary records in accordance withCCD. Upon receipt of a patient summaryrecord formatted according to the CCRstandard, the Complete EHR must also

be capable of displaying the CCR-

formatted patient summary record inhuman readable format. We clarify thatwe also expect that the Complete EHRdesigned to natively generate a CCDwould be tested and certified as beingcapable of properly displaying any CCDthat it receives and have added the term‘‘display’’ in the beginning of thecertification criterion. This change isalso applicable to the certificationcriterion for Complete EHRs and EHRModules designed for an inpatientsetting.

Comment. A commenter requestedthat we clarify how we intendedadopted vocabularies to be used. Thecommenter queried whether vocabularystandards that we had adopted apply toEHRs or to transactions that EHRsconduct. The commenter furtherrequested that we clarify whether alocal/proprietary medication vocabularycould be mapped to RxNorm, andwhether a local/proprietary problem listvocabulary could be mapped toSNOMED–CT®. Finally, the commenterasked if mapping is permitted, and if so,requested that we identify the subsets ofthese vocabularies that should be used.


8/13/2019 2010-17210



Response. For purposes ofelectronically exchanging a patientsummary record, we expect the patientsummary record to include healthinformation that is coded, whereapplicable, in accordance with adoptedvocabulary standards. Therefore, unlessotherwise required in the context of ameaningful use objective and measure,

an eligible professional (or eligiblehospital) would be permitted to map orcrosswalk local/proprietary codes to theadopted vocabulary standards prior totransmitting a patient summary record.We do not believe that it would beappropriate to specify subsets ofadopted vocabularies at this time andwould seek additional input from theHIT Standards Committee or publiccomment prior to specifying vocabularysubsets.

Comment. A commenter stated thatthe adopted data exchange standards donot provide for the inclusion of

narrative text results, such as aradiology report, or images of scannedpaper documents. The commenterquestions how meaningful useobjectives will be achieved withoutthese and recommends thatimplementation guidance be issued thatincludes specific references to contentor vocabulary standards.

Response. We have not adoptedstandards for radiology reports orimages; however, both the CCR and CCD

can be used to convey narrative text andobjects such as scanned documents.

Comments. A couple of commentersrequested clarification as to the testingwe expected to occur related to aComplete EHR or EHR Module’scompliance with this certificationcriterion. These commenters questionedwhether the generation of a CCD and

XDS (HITSP/TP13)/FTP/e-mail of adocument would meet the certificationcriterion requirements.

Response. We clarify that because wehave removed the adopted transportstandards, we do not require as acondition of certification that a specifictransport standard be used to transmit agenerated CCD.

Comments. One commenter expresslyagreed with the expectations of thecertification criterion. Anothercommenter stated that this functionalityis crucial to support the patient/family-centered medical home. One commenter

recommended that the Certified EHRTechnology be designed so that theamount of data transmitted could beadjusted by physicians so they do notviolate the HIPAA Privacy Rule’s‘‘minimum necessary’’ requirements.

Response. We appreciate commenters’support for this certification criterionand agree that patient summary recordsserve a valuable purpose. Presently, wedo not believe that it is appropriate torequire as a condition of certification a

capability associated with the HIPAAPrivacy Rule’s minimum necessaryrequirements because suchrequirements are generally contextspecific and determined when a HIPAAcovered entity uses or disclosesprotected health information or when aHIPAA covered entity requestsprotected health information from

another HIPAA covered entity. We donot preclude, however, Complete EHRand EHR Module developers fromincluding additional features to assistHIPAA covered entities comply withthese and other HIPAA Privacy Rulerequirements.

Comment. A commenterrecommended that the summary carerecord should include the durablemedical equipment and supplies used

by the patient.

Response. Presently, the correlatedmeaningful use objective and measuredo not specify that a patient summaryrecord must contain informationregarding durable medical equipment.Accordingly, we do not believe that itwould be appropriate to require this asa condition of certification.

c. Specific Certification for CompleteEHRs or EHR Modules Designed for anInpatient Setting—§ 170.306

Section 170.306(a)—ComputerizedProvider Order Entry


Use CPOE for medication orders

directly entered by any licensedhealthcare professional who canenter orders into the medicalrecord per state, local and pro-fessional guidelines.

More than 30% of unique patients

with at least one medication intheir medication list seen by theEP or admitted to the eligiblehospital’s or CAH’s inpatient oremergency department (POS 21or 23) have at least one medica-tion order entered using CPOE.

Interim Final Rule Text:

Enable a user to electronically record, store, retrieve, and man-age, 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.

Final Rule Text: §170.306(a).Computerized provider order entry. Enable a user to electroni-

cally record, store, retrieve, and modify, at a minimum, the fol-lowing order types:


A commenter recommended that weclarify what is meant by order entry

because the commenter believes thatwithin the confines of many hospitals,just about any ‘‘order’’ can be performed.A few commenters requested that ‘‘dietorders’’ be added to the list of CPOEorder types in order to prevent

inconsistent patient care. Anothercommenter recommended that speech-language pathology and audiology also

be added. Two commenters noted thatthe certification criterion specifies along list of order types. The commentersrecommended that we not attempt tocreate an exhaustive list. One of the

commenters also noted that noinformation is given as to whatconstitutes adequate functionality forany of the orders after the first threeorder types and that some, such as‘‘dialysis’’ may not be appropriate orderfunctionality for a general EHR systemfor hospitals. Both commenters


8/13/2019 2010-17210



recommended that we remove all ordersfrom four through 10 and replace themwith a single provision ‘‘other ordertypes.’’

Response. Consistent with therevisions we made to the CPOEcertification criterion associated withComplete EHRs and EHR Modulesdesigned for an ambulatory setting, we

agree with those commenters whorecommended that we specify aminimum core set of orders as acondition of certification. Accordingly,we identify medication, laboratory, andradiology/imaging as the minimumtypes of orders a Complete EHR or EHRModule designed for inpatient settingsmust include in order to be certified.

While this certification criterion is nowthe same as the certification criterion forComplete EHRs and EHR Modulesdesigned for an ambulatory setting, wehave not combined and moved theCPOE certification criteria to the generalcertification criteria section. Rather, wehave kept the certification criteria forCPOE separate because we anticipate

that these certification criteria could inthe future include differentrequirements, specific to the settings forwhich Complete EHRs and EHRModules are developed.

Comment. A commenter repeated aquestion it raised with respect to CPOEfor eligible professionals. Thecommenter requested that we clarify

whether only imaging and radiologyreports were intended to be included inthis capability, or, if we intended toinclude the images themselves inaddition to the imaging reports as partof the certification criteria. Thecommenter recommended that wefurther clarify the criterion andrequested that the DICOM standard be

adopted in the initial set of standards,as an essential step in meeting the CPOEcapability.

Response. We refer this commenter toour previous response above regardingthis issue.

Section 170.306(b)—RecordDemographics


Record demographics .....................• preferred language• gender• race

• ethnicity• date of birth• date and preliminary cause of

death in the event of mortality inthe eligible hospital or CAH

More than 50% of all unique pa-tients seen by the EP or admit-ted to the eligible hospital’s orCAH’s inpatient or emergency

department (POS 21 or 23)have demographics recorded asstructured data.

Interim Final Rule Text:Enable a user to electronically record, modify, and retrieve pa-

tient demographic data including preferred language, insur-ance type, gender, race, ethnicity, date of birth, and date and

cause of death in the event of mortality.Final Rule Text: §170.306(b).

Record demographics. Enable a user to electronically record,modify, and retrieve patient demographic data including pre-ferred language, gender, race, ethnicity, date of birth, and dateand preliminary cause of death in the event of mortality. En-able race and ethnicity to be recorded in accordance with thestandard specified at §170.207(f).

Many commenters expressed the samecomments with respect to thiscertification criterion as they did for therecord demographics certificationcriterion for Complete EHRs and EHRModules designed for ambulatory

setting. These commentersrecommended the addition of otherdemographic information for additionalclarity, as discussed above.

Comment. A commenter stated that anEHR is not an appropriate source oflegal documentation for births anddeaths because they indicated that it isnot possible to obtain official birth anddeath certificates from a provider orhospital.

Response. In concert with andfollowing the changes made to thismeaningful use objective which are

explained in more detail in theMedicare and Medicaid EHR IncentivePrograms final rule, we believe that thechanges we have made to this specificpart of the certification criterion address

this commenter’s concern.Section 170.306(c)—Clinical DecisionSupport


Implement one clinical decisionsupport rule related to a high pri-ority hospital condition along withthe ability to track compliancewith that rule.

Implement one clinical decisionsupport rule.

Interim Final Rule Text:(1) Implement rules. Implement automated, electronic clinical de-

cision support rules (in addition to drug-drug and drug-allergycontraindication checking) according to a high priority hospitalcondition that use demographic data, specific patient diag-noses, conditions, diagnostic test results and/or patient medi-cation list.

(2) Alerts. Automatically and electronically generate and indicatein 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 bya user.

Final Rule Text: §170.306(c).(1) Implement rules. Implement automated, electronic clinical de-

cision support rules (in addition to drug-drug and drug-allergycontraindication checking) based on the data elements in-cluded in: problem list; medication list; demographics; and lab-oratory test results.

(2) Notifications. Automatically and electronically generate andindicate in real-time, notifications and care suggestions basedupon clinical decision support rules.


8/13/2019 2010-17210



This certification criterion is nowexactly the same as the certificationcriterion applicable to Complete EHRsand EHR Modules designed for anambulatory setting. As a result, ourresponses and subsequent changes tothe certification criterion above are alsoapplicable to this certification criterion.While this certification criterion is nowthe same as the certification criterion forComplete EHRs and EHR Modules

designed for an ambulatory setting, wehave not combined and moved theclinical decision support certificationcriteria to the general certificationcriteria section because the focus of themeaningful use objective is differentand specific to eligible hospitals. Wealso believe that it is useful to keepthese certification criteria separate

because we anticipate that thesecertification criteria could in the future

include different requirements, specificto the settings for which Complete EHRsand EHR Modules are developed.

Comments. Some commentersrequested that we clarify the meaning ofhigh priority hospital condition.

Response. We have removed thisterm, consistent with the other revisionswe made to this certification criterion.

Section 170.306(d)—Electronic Copy ofHealth Information


Provide patients with an electroniccopy of their health information(including diagnostic test results,problem list, medication lists,medication allergies, dischargesummary, procedures), upon re-quest.

More than 50% of all patients ofthe EP or the inpatient or emer-gency departments of the eligi-ble hospital or CAH (POS 21 or23) who request an electroniccopy of their health informationare provided it within 3 businessdays.

Interim Final Rule Text: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, immuniza-tions, procedures, and discharge summary in:


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 min-

imum, 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


Final Rule Text: §170.306(d).(1) Enable a user to create an electronic copy of a patient’s clin-

ical information, including, at a minimum, diagnostic test re-sults, problem list, medication list, medication allergy list, andprocedures:

(i) In human readable format; and(ii) On electronic media or through some other electronic means

in accordance with:(A) The standard (and applicable implementation specifications)

specified in §170.205(a)(1) or §170.205(a)(2); and(B) For the following data elements the applicable standard must

be used:

(1) Problems. The standard specified in §170.207(a)(1) or, at aminimum, the version of the standard specified in§ 170.207(a)(2);

(2 ) Procedures. The standard specified in § 170.207(b)(1) or§ 170.207(b)(2);

(3 ) Laboratory test results. At a minimum, the version of thestandard specified in §170.207(c); and

(4 ) Medications. The standard specified in §170.207(d).(2) Enable a user to create an electronic copy of a patient’s dis-

charge summary in human readable format and on electronicmedia or through some other electronic means.

Comment. A commenter expressedconcern that requiring organizations toprovide anything on electronic media

was dangerous and counterproductiveto the HITECH Act’s HIPAA Privacy andSecurity Rule changes. This commenteralso stated that thumb drives and CD/DVD burners are not available to staff.The commenter recommended that weremove this certification criterion andadopt a patient portal requirement inthe next round of rulemaking.

Response. While we understand thatin certain locations (e.g., areas that arereadily accessible to patients) healthcare professionals do not normally have

access to use certain ancillary features attheir workstations, we disagree thatrequiring organizations to provide

patients with an electronic copypresents problems related to HITECHmodifications to the HIPAA privacy andsecurity requirements. We do notspecify that electronic media such asthumb drives or CDs must be used. Aneligible hospital will be able todetermine, consistent with its securityposture, if certain electronic media ispermissible and if so, what types. It willalso be able to determine the means andlocation through which an electroniccopy may be provided, e.g., at the

records management department oroffice. As the commenter suggested, apatient portal would be an acceptable

mechanism to provide an electroniccopy.

Comment. A commenter stated thecertification criterion for eligiblehospitals should be limited toinformation or tests performed duringthe course of a patient visit or hospitalstay and include only summaryinformation of diagnostic test results orof information that is clinicallysignificant and discovered during theencounter or admission. Othercommenters requested that we clarify


8/13/2019 2010-17210



the reference to procedures. Thecommenters asked that the regulationsspecify whether the EHR technologymust enable the user to create anelectronic copy of procedures associatedwith the most recent hospitalization, orany historical procedures, or theprocedures that the patient shouldfollow-up to do after discharge.

Response. At a minimum, CertifiedEHR Technology must be capable ofgenerating an electronic copy of healthinformation that includes the elementsspecified by the certification criterion inan electronic copy. We do not specifythe time period for which the electroniccopy must cover as a condition ofcertification.

Comment. A commenter requestedthat we consider eliminating thereference to standards in thiscertification criterion for Stage 1 andfocusing on human readable formats.

Response. We disagree, as doing so

would run counter to our long termgoals and would not help build thefoundation necessary for morecomprehensive capabilities to be addedin the future.

Comments. A few commenters notedthat neither the CCD nor CCR contain anapplicable section for dischargesummary. One commenterrecommended that because theprovision of an electronic copy ofdischarge instructions was required byanother certification criterion, thatdischarge instructions should beremoved as an element in this electroniccopy.

Response. We reviewed commenters’concerns and agree that there is noapplicable section for a dischargesummary. Therefore, we have revisedthis certification criterion to reflect thatwhile the other data elements can beconveyed using the patient summaryrecord standards (CCR or CCD), we arenot requiring the use of any standardsfor the discharge summary section. Inorder to support the meaningful useobjective and measure, however, wenote that we do expect Certified EHRTechnology to be capable of providinga electronic copy of a discharge

summary like a patient summary record,

in human readable format and onelectronic media or through some otherelectronic means. Other electronicmeans could include, for example, thedischarge summary represented as aCCD plus the ‘‘Hospital Course’’ CDAsection or provided as a PDF. We haverevised the certification criterionaccordingly.

We note that our responses to thefollowing comments also apply to othercertification criteria that referenceprocedures.

Comments. A commenter requestedclarification as to what we meant by‘‘procedures’’ for hospitals, becausecoding for medical procedures typicallyoccurs after the patient has beendischarged. Another commenterrequested that we further clarify thesubset of relevant procedures thatshould be included. The commenterexplained that it believed includingCPT–4 or ICD–9 codes seemed

inappropriate for clinical summariessince these codes are used for‘‘procedures as billed,’’ and thecommenter further asked whether weintended to include only majorprocedures.

Response. We clarify that the adoptedstandard pertains to the vocabulary thatwould be used to express procedures,regardless of how they are selected, orincluded.

Comments. A commenter stated thatwith an X12 837 standard transaction,ICD–9–CM is accompanied by a flag thatindicates whether this code is being

used to bill for services meant toeliminate a diagnosis. The commenterstated that neither the CCR nor the CCDsupport such a flag, and concluded thatthere was no way to know whether ICD–9–CM codes used in either CCD or CCRcould accurately convey a patient’sproblems. The commenter alsorecommended SNOMED–CT® should beused with a CCD, because ICD–9 codeshave too little clinical detail. Anothercommenter favored the use ofSNOMED–CT® as well and stated thatSNOMED–CT® would be moreclinically accurate and better suited for

our purposes. Another commenter

encouraged us to adopt the CurrentDental Terminology.

Response. The diagnoses includedwithin the patient summary record aremeant to convey clinically relevantconditions as recorded in Certified EHRTechnology’s problem list, rather than

billing diagnoses. While we agree thatSNOMED–CT® provides additional

clinical detail, this is often not availablein current practice. Furthermore, whileits use is not precluded, we do not

believe that it is necessary to adopt theCurrent Dental Terminology as acondition of certification for allComplete EHRs and EHR Modules.

Comments. A commenterrecommended against the adoption ofthe alternative standard (CPT–4), unlesswe subsidized the cost of licensingCPT–4 as has been done for certainother code sets. Some commentersexpressed concerns about the licenserequirements and one commenter stated

that the license cost will likely bepassed down from the EHR developer tothe eligible professional or eligiblehospital. Some commenters believedthat if we intended to keep thisalternative standard, we should make itfreely available.

Response. We understand that mostcurrent EHR technology alreadyincludes the CPT–4 code sets, and we

believe that this indicates that thelicensing costs are not prohibitive.Regardless, we have adopted analternative standard to CPT–4,SNOMED–CT®, which is freely

available.Comment. A commenter noted thatthe certification criterion referencesimmunizations but the Medicare andMedicaid EHR Incentive Programsproposed rule did not includeimmunizations in the objective. Thecommenter suggested that we modifyour certification criterion to match theproposed rule.

Response. We have removed thisterm, consistent with the previousrevisions we have made to othercertification criteria above.

Section 170.306(e)—Electronic Copy of

Discharge Information


Provide patients with an electroniccopy of their discharge instruc-tions at time of discharge, uponrequest.

More than 50% of all patients whoare discharged from an eligiblehospital or CAH’s inpatient de-partment or emergency depart-ment (POS 21 or 23) and whorequest an electronic copy oftheir discharge instructions areprovided it.

Interim Final Rule Text:Enable a user to create an electronic copy of the discharge in-

structions and procedures for a patient, in human readable for-mat, at the time of discharge on electronic media or throughsome other electronic means.

Final Rule Text: §170.306(e).Electronic copy of discharge instructions. Enable a user to create

an electronic copy of the discharge instructions for a patient, inhuman readable format, at the time of discharge on electronicmedia or through some other electronic means.


8/13/2019 2010-17210



Comment. A few commentersexpressed support for this certificationcriterion. Some commenters requestedthat we clarify the meaning of‘‘procedures’’ in the context of thiscertification criterion.

Response. We have revised thiscertification criterion to be consistent

with the changes to the meaningful useobjective and measure in the Medicareand Medicaid EHR Incentive Programsfinal rule, which removes the word‘‘procedures’’ from the meaningful useobjective.

Comment. A commenter requestedthat we clarify the meaning of thephrase ‘‘at time of discharge’’ andspecifically, whether it means literallyat the time when a patient is dischargedor more broadly, soon after thedischarge occurs, in which case theinstructions could be made available tothe patient, for example, through a web

portal.Response. This phrase is derived from

the Medicare and Medicaid EHRIncentive Programs final rule, and CMShas provided clarifying remarks relatedto this comment.

Comment. One commenterrecommended that the certificationcriterion include consideration of thepatient’s preferred language.

Response. Like our prior responses,we do not believe that requiring thisinformation is appropriate or necessaryto include as a condition of certification.However, we do not preclude CompleteEHRs and EHR Modules from beingdesigned to reference a patient’spreferred language.

Section 170.306(f)—Exchange ClinicalInformation and Summary Record


Capability to exchange key clinicalinformation (for example, dis-charge summary, procedures,problem list, medication list,medication allergies, diagnostictest results), among providers ofcare and patient authorized enti-

ties electronically.

Performed at least one test of cer-tified EHR technology’s capacityto electronically exchange keyclinical information.

Interim Final Rule Text:(1) Electronically receive and display. Electronically receive a pa-

tient’s summary record from other providers and organizationsincluding, at a minimum, diagnostic test results, problem list,medication list, medication allergy list, immunizations, proce-dures, and discharge summary in accordance with§ 170.205(a) and upon receipt of a patient summary record for-

matted in an alternate standard specified in §170.205(a)(1),display it in human readable format.(2) Electronically transmit. Enable a user to electronically trans-

mit a patient’s summary record to other providers and organi-zations including, at a minimum, diagnostic results, problemlist, medication list, medication allergy list, immunizations, pro-cedures, and discharge summary in accordance with:

(i) One of the standards specified in §170.205(a)(1);The EP, eligible hospital or CAH

who transitions their patient toanother setting of care or pro-vider of care or refers their pa-tient to another provider of careshould provide summary of carerecord for each transition of careor referral.

The EP, eligible hospital or CAHwho transitions or refers theirpatient to another setting of careor provider of care provides asummary of care record formore than 50% of transitions ofcare and referrals .

(ii) The standard specified in § 170.205(a)(2)(i)(A), or, at a min-imum, 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).Final Rule Text: §170.306(f).

(1) Electronically receive and display. Electronically receive anddisplay a patient’s summary record from other providers andorganizations including, at a minimum, diagnostic test results,problem list, medication list, medication allergy list, and proce-dures in accordance with the standard (and applicable imple-mentation specifications) specified in §170.205(a)(1) or§ 170.205(a)(2). Upon receipt of a patient summary record for-matted according to the alternative standard, display it inhuman readable format.

(2) Electronically transmit. Enable a user to electronically trans-mit a patient’s summary record to other providers and organi-zations including, at a minimum, diagnostic results, problemlist, medication list, medication allergy list, and procedures in

accordance with:(i) The standard (and applicable implementation specifications)


be used:(A) Problems. The standard specified in §170.207(a)(1) or, at a

minimum, the version of the standard specified in§ 170.207(a)(2);

(B) Procedures. The standard specified in §170.207(b)(1) or§ 170.207(b)(2);

(C) Laboratory test results. At a minimum, the version of thestandard specified in §170.207(c); and

(D) Medications. The standard specified in §170.207(d).


8/13/2019 2010-17210



Overall this certification criterion isvery similar to the certification criterionapplicable to Complete EHRs and EHRModules designed for an ambulatorysetting. As a result, our responses andsubsequent changes to the certificationcriterion above are also applicable tothis certification criterion. Below are thecomments that are unique to this

certification criterion.Comment. A few commenters

requested clarification on what is meant by the term ‘‘discharge summary.’’ Thecommenter stated that neither the CCDnor the CCR has a document section ormodule for a ‘‘discharge summary.’’ Onecommenter suggested that we eitherdefine the term or remove it. At leastone commenter suggested that discharge

summary be initially permitted to be anunstructured CDA instead of requiringthe use of a CCD. As an alternative, itwas suggested that the CCD combinedwith the ‘‘Hospital Course’’ CDA section

be allowed to qualify as the dischargesummary.

Response. As noted in one of ourresponses above, we recognize that

neither CCD nor CCR specificallysupports the inclusion of dischargesummary. In the Medicare and MedicaidEHR Incentive Program final rule, CMSreferences discharge summary in themeaningful use objective as an exampleof ‘‘key clinical information’’ but furtherclarifies within the preamble of that rulethat it is up to an eligible professionalor eligible hospital to determine what

constitutes key clinical information. Inthat regard, CMS notes that we specifythe minimum set of information thatCertified EHR Technology must becapable of electronically transmitting.Given our prior statements regarding theability of CCD and CCR to support theinclusion of the discharge summary andthe principle expressed by CMS that wespecify a minimum set of information inthe adopted certification criterion, we

believe that in this instance it isappropriate to exclude dischargesummary from the certificationcriterion.

Section 170.306(g)—Reportable LabResults


Capability to submit electronic dataon reportable (as required bystate or local law) lab results to

public health agencies and actualsubmission in accordance withapplicable law and practice.

Performed at least one test of cer-tified EHR technology’s capacityto provide electronic submission

of reportable lab results to pub-lic health agencies and follow-upsubmission if the test is suc-cessful (unless none of the pub-lic health agencies to which eli-gible hospital or CAH submitssuch information have the ca-pacity to receive the informationelectronically).

Interim Final Rule Text:Electronically record, retrieve, and transmit reportable clinical lab

results to public health agencies in accordance with the stand-

ard specified in §170.205(f)(1) and, at a minimum, the versionof the standard specified in §170.205(f)(2).

Final Rule Text: §170.306(g).Reportable lab results. Electronically record, modify, retrieve, and

submit reportable clinical lab results in accordance with thestandard (and applicable implementation specifications) speci-fied in § 170.205(c) and, at a minimum, the version of thestandard specified in §170.207(c).

Comment. One commenter requestedthat we clarify the meaning of ‘‘LOINCwhen LOINC codes have been receivedfrom a laboratory.’’ The commenterquestioned whether the information

exchange for which this criterion wouldapply is solely exchange within anorganization or only betweenorganizations.

Response. For a more detailedresponse to this request for clarification,we refer to the relevant comments andresponses relating to the ‘‘incorporatelaboratory test results’’ certificationcriterion, where we discuss this issue atlength.

Comment. One commenter stated thatit believed the standards we haveadopted are too general or at too high a

level for vendors to be able toimplement them uniformly. Thiscommenter suggested that we clarifywhen lab results should be transmitted,for instance upon the occurrence ofparticular trigger events, or in responseto specific messages, and in accordancewith a reporting time table. Thecommenter queries, for example, if EHRsystems should use discharge as atrigger for the transmission of areportable condition using encounterlevel demographic segments, or whetherEHR systems should provide a periodic

batch reporting of reportable conditions(e.g. daily or weekly).

Response. We clarify that thecertification criterion does not specify,and is not intended to specify, the

requirements for how the reports are to be triggered nor the periodicity of thereporting requirements. As acertification criterion, it only specifiescapabilities necessary for certification.

Comment. A commenterrecommended that we clarify themeaning of ‘‘reportable’’ in thecertification criterion.

Response. Each public healthjurisdiction maintains its list of diseasesor conditions that require notification ofpublic health authorities by law. TheCDC and the Council of State andTerritorial Epidemiologists also

maintain a list of nationally notifiableconditions (http://www.cdc.gov/ncphi/ disss/nndss/phs/infdis.htm). Wereiterate, the adoption of thiscertification criterion is not intended toaffect applicable Federal or state lawconcerning public health authoritynotification requirements.

Comments. Many commentersrequested further specification of thedata format for transmitting informationto public health agencies. Most of thesecomments recommended HL7 2.5.1version, although at least one

commenter noted that HL7 2.3.1 wasstill being used by some public healthagencies. Another commenter suggestedthat either standard be allowed toaccommodate for the variation in public

health departments’ ability to receivethese reports. Many commenters raisedthe concern that the criterion appears toplace the burden of compliance on thesender. This problem could becompounded if states and localitiesadopt multiple standards, which wouldmake both compliance and certificationtesting difficult and burdensome.Several commenters raised the concernthat some public health agencies are notcapable of receiving electronic data. Onecommenter suggested removing thelanguage ‘‘or applicable state-designatedstandard format’’ and directly specifying

the format in the final rule. Onecommenter suggested having the statesagree upon a standard format. At leastone commenter requested additionalclarity, suggesting that the HL7 messageprofile types be specified: ORU messagefor public health reporting, ADT forsyndromic surveillance, and VXU forimmunizations. One commenter alsorequested that we clarify whether HL7V3 constructs would be allowable.

Response. We agree with the majorityof commenters, who requested greaterspecificity for this certification criterion.


http://www.cdc.gov/ncphi/disss/nndss/phs/infdis.htm





8/13/2019 2010-17210



Many of these commenters suggestedadopting implementation specificationsfor the adopted standard (HL7 2.5.1). Inresponse to those comments, and tomore fully support this meaningful useobjective and measure which specify thesubmission of laboratory results topublic health, we have decided to adoptthe HL7 Version 2.5.1 Implementation

Guide: Electronic Laboratory Reportingto Public Health, Release 1 (US Realm)to further constrain how HL7 2.5.1 isformatted for the purposes of submittinglaboratory test results to public health.With respect to the comment regardingHL7 V3, we do not believe that theindustry and public health departmentsare currently able to support the HL7 V3constructs on a widespread basis andare therefore not adopting them.

Comment. One commenter suggestedadding the term ‘‘modify’’ to thecertification criterion, while onecommenter requested clarification on

the term‘‘retrieve.

’’

Response. Consistent with thechanges we have made to the othercertification criterion, we have includedthe word ‘‘modify.’’

Comments. A few commenterssuggested the use of SNOMED–CT® andUCUM for reporting.

Response. We do not believe that theindustry and public health departmentsare currently able to support the use ofSNOMED–CT® and UCUM for reportingon a widespread basis.

d. Adoption and Realignment ofCertification Criteria To Support the

Final Requirements for Meaningful UseStage 1.

In the Interim Final Rule, we notedthat the Secretary was adopting aninitial set of standards, implementation

specifications, and certification criteriato ‘‘establish the capabilities and relatedstandards that certified electronic healthrecord (EHR) technology will need toinclude in order to, at a minimum,support the achievement of theproposed meaningful use Stage 1.’’ Wealso noted that the reason we routinelyreferred to eligible professionals and

eligible hospitals in the Interim FinalRule was ‘‘ because we have closelyaligned the initial set of standards,implementation specifications, andcertification criteria adopted by this ruleto focus on the capabilities that CertifiedEHR Technology must be able toprovide in order to support theachievement of the proposed criteria formeaningful use Stage 1 by eligibleprofessionals and eligible hospitalsunder the Medicare and Medicaid EHRIncentive Programs.’’ In this regard, andas many commenters acknowledged andexpressed in their comments, this final

rule and the Medicare and MedicaidEHR Incentive Program final rule areclosely and inextricably linked.Recognizing the unique connection

between these two rules, somecommenters went so far as to issue CMSand ONC a single set of commentsrecommending changes to both rules incontext. Many other commenters treated

both rules as almost being one in thesame, acknowledging that a change inMedicare and Medicaid EHR IncentivePrograms final rule would need to bereflected in this final rule. Othercommenters submitted comments toONC on the Medicare and Medicaid

EHR Incentive Programs proposed rule,and to CMS on the Interim Final Rule.As we discussed previously, CMS andONC shared these comments betweenthe offices and we included within our

review all comments that could bereasonably identified as comments onthe Interim Final Rule.

The following three certificationcriteria have been adopted as part of theinitial set of certification criteria,implementation specifications, andstandards in order to realign theadopted certification criteria with thefinal meaningful use Stage 1requirements and to ensure thatCertified EHR Technology will providesuch capabilities.

Record Advance Directives

In the Medicare and Medicaid EHRIncentive Programs proposed rule, theDepartment explained that the HITPolicy Committee had recommendedthat eligible hospitals ‘‘record advancedirectives.’’ Due in part to the ambiguityof the recommendation, the Departmentdiscussed but did not include theobjective ‘‘Record Advance Directives’’

for the reasons explained by CMS. In itsfinal rule, however, the Departmentstated that based on comments receivedas well as resolution of some of theambiguity associated with the measure,CMS was including this objectiveamong its meaningful use Stage 1objectives. The Department noted thatsome commenters reported that havingthis information available would alloweligible hospitals to make decisions thatwere better aligned with the patient’sexpress wishes. The ‘‘record advancedirectives’’ certification criterion wouldensure that Certified EHR Technology

enables users to electronically recordwhether a patient has an advancedirective, which in turn will helpensure that a patient’s wishes are knownand can be followed.


Record advance directives for pa-tients 65 years old or older.

More than 50% of all unique pa-tients 65 years old or older ad-mitted to the eligible hospital’sor CAH’s inpatient department(POS 21) have an indication ofan advance directive status re-corded.

Final Rule Text: §170.306(h).Advance directives. Enable a user to electronically record wheth-

er a patient has an advance directive.

Comments. The Department receivedseveral comments that we shouldinclude the capability to record advancedirectives as part of meaningful use ofCertified EHR Technology and,specifically, that it should be arequirement that pertains to eligiblehospitals. Other commenters reportedthat having this information availablefor the patient would allow eligiblehospitals to make decisions that were

better aligned with the patient’s express

wishes. The HIT Policy Committeeclarified that the purpose of themeaningful use Stage 1 measure would

be to indicate whether a patient has anadvanced directive. Furthermore, thecommittee recommended limiting thismeasure to patients 65 and older.

Response. We agree that the capabilityfor a Complete EHR or EHR Moduledesigned for an inpatient setting should

be included as a condition ofcertification. Including this certification

criterion in this final rule will enableeligible hospitals to meet a meaningfuluse objective they would otherwise nothave been able to meet. We do not

believe that the capability we haverequired will be a significant burden forComplete EHR and EHR Moduledevelopers and assume that somealready have this or a similar type ofcapability already built in.


8/13/2019 2010-17210


8/13/2019 2010-17210



8

http://www.w3.org/TR/WCAG20/. 9As previously mentioned, there are severalaccessibility standards for electronic andinformation technology currently in use. Forexample, Section 508 of the Rehabilitation Actrequires Federal agencies to ensure that electronicand information technology that they develop,procure, maintain, or use is accessible to personswith disabilities and authorizes the Architecturaland Transportation Barriers Compliance Board(Access Board) to promulgate standards settingforth the technical and functional performancecriteria necessary to implement the requirements ofSection 508. Information regarding the Electronicand Information Technology Standards can befound on the Access Board’s Web site at http://www.access-board.gov/508.htm.

Response. We agree with commentersthat unless we expressly adopt acertification criterion to specify thatCertified EHR Technology must becapable of performing percentage-basedcalculations for meaningful usemeasures that it would present asignificant burden to eligibleprofessionals and eligible hospitals andcould deter them from participating inthe Medicare and Medicaid EHRincentives programs. Accordingly, we

believe that it is critical to adopt thecertification criterion specified above.We clarify that Certified EHRTechnology must be capable ofcalculating all denominators for thosemeaningful use measures which arepercentage-based and for which CMSrequires an eligible professional oreligible hospital to submit the results atthe end of an EHR reporting period.(CMS provides a detailed discussion inthe Medicare and Medicaid EHRIncentive Programs final rule ondenominators.) We note that asdiscussed in the Medicare and MedicaidEHR Incentive Programs final rule underthe heading ‘‘Discussion of the BurdenCreated by the Measures associated withthe Stage 1 Meaningful Use Objectives,’’an eligible professional or eligiblehospital is responsible for verifying thatthe denominator produced by CertifiedEHR Technology is complete. Theeligible professional or eligible hospitalwould be expected to know whetherdata had been incorrectly entered intoCertified EHR Technology or whetherall patient records were included inCertified EHR Technology. For Stage 1meaningful use criteria, CMS identifiesthese measures in the table in its finalrule with the headings: ‘‘Measures witha Denominator of Unique PatientsRegardless of Whether the Patient’sRecords Are Maintained Using CertifiedEHR Technology’’ and ‘‘Measures with aDenominator of Based on CountingActions for Patients whose Records areMaintained Using Certified EHRTechnology.’’ We do not require, as acondition of certification, that aComplete EHR or EHR Module provideresults for the meaningful use measuresthat only require a ‘‘yes/no’’ attestationsince these results should be readilyapparent. These measures are alsoidentified by CMS in the table in itsfinal rule with the heading ‘‘MeasuresRequiring Only a Yes/No Attestation.’’We do not believe that adoption of thiscertification criterion poses a significanttechnical challenge. Rather, we believethat this capability will provideComplete EHR and EHR Modulesdevelopers with a platform from which

to innovate and compete regarding, forexample, the EHR products’ ease of use.

E. Additional Comments

Comments. In response to our requestfor public comment, severalcommenters recommended that weadopt certification criteria requiringtechnical capabilities to provide greater

access for people with disabilities.These commenters also pointed to a fewstandards currently being used to assureaccessibility, including the Web ContentAccessibility Guidelines (WCAG 2.0)and the Electronic and InformationTechnology Accessibility Standards.The commenters requested that wecoordinate more with the disabilitycommunities on accessibility andusability and how HIT will impactmembers of this community. Thecommenters requested that we clarifythe applicability of accessibilitystandards and that we add technological

non-discrimination as a goal to guidefuture standards work.Response. We appreciate the thorough

and thoughtful comments providedrelated to accessibility. We believe thatHIT has the potential to provide allpersons with more efficient access totheir health information. In that regard,we solicited public comment on theissue of accessibility and certification togarner more information about availablestandards and to begin a path forwardthat included these standards as part ofthe overall standards adoption process.We reiterate what we discussed in theinterim final rule when we provided thecontext for our solicitation of publiccomment on accessibility.

Nothing required by this interim final ruleshould be construed as affecting existinglegal requirements under other Federal laws.While the capabilities provided by CertifiedEHR Technology may assist in thecompliance with certain legal requirements,they do not in any way remove or alter thoserequirements * * *. As another example, inproviding patients with access to their onlinehealth information, it is important to notethat the accessibility requirements of theAmericans with Disabilities Act of 1990 andSection 504 of the Rehabilitation Act of 1973still apply to entities covered by these

Federal civil rights laws. Additionally, TitleVI of the Civil Rights Act of 1964 and itsimplementing regulations protect personsfrom unlawful discrimination on the basis ofrace, color and national origin. Under TitleVI and its implementing regulations,recipients of Federal financial assistancemust take reasonable steps to ensuremeaningful access to their programs,services, and activities by eligible limitedEnglish proficient persons.

While we have not yet adoptedspecific accessibility standards as acondition of certification, we believe

that the adoption of such standards ina future rulemaking would prove

beneficial, to enable all persons(including health care providers withdisabilities) to have equitable access toEHR technology and the electronicinformation it generates. In the interim,we encourage Complete EHR and EHRModule developers to design their EHR

technology with the needs of users ofassistive technology in mind, andremind eligible professionals andeligible hospitals who seek to adoptCertified EHR Technology to review andcomply with applicable legal obligationsregarding accessibility. Among the waysof designing certain capabilities withaccessibility in mind, we wouldencourage Complete EHR and EHRModule developers to considerimplementing, for example, the WCAG2.0 8 when providing web-orientedcontent so that it is more accessible topersons with disabilities. We expect the

HIT Standards Committee to identifyaccessibility-oriented standards 9 whenit issues recommendations regarding thestandards that the Secretary shouldadopt in future years.

Comments. Several commenters maderecommendations related to standardsthat we could adopt to support futurestages of meaningful use. Othercommenters expressed concerns relatedto the ‘‘candidate Stage 2 standards’’ thatwe referenced in the Interim Final Rule.Finally, commenters requested thatCertified EHR Technology includespecific capabilities that had norelationship to meaningful use.

Response. We have reviewed thesecomments and appreciate theforethought provided by commenters.Given that these suggestions were notgermane to the policies associated withthe Interim Final Rule we have notconsidered them for the purposes ofpromulgating this final rule.

F. Comments Beyond the Scope of ThisFinal Rule

In response to the Interim Final Rule,some commenters chose to raise issuesthat are beyond the scope of our


http://www.w3.org/TR/WCAG20/

http://www.access-board.gov/508.htm




http://www.w3.org/TR/WCAG20/

8/13/2019 2010-17210



10 http://sba.gov/idc/groups/public/documents/ sba _homepage/serv _sstd _tablepdf.pdf.

proposals. We do not summarize orrespond to those comments in this finalrule.

IV. Collection of InformationRequirements

This final rule contains no newinformation collection requirementssubject to review by the OMB under the

Paperwork Reduction Act (PRA).V. Regulatory Impact Analysis

A. Introduction

We have examined the impacts of thisfinal rule as required by ExecutiveOrder 12866 on Regulatory Planningand Review (September 30, 1993, asfurther amended), the RegulatoryFlexibility Act (RFA) (5 U.S.C. 601 etseq.), section 202 of the UnfundedMandates Reform Act of 1995 (2 U.S.C.1532) (UMRA), Executive Order 13132on Federalism (August 4, 1999), and theCongressional Review Act (5 U.S.C.

804(2)).Executive Order 12866 directsagencies to assess all costs and benefitsof available regulatory alternatives and,if regulation is necessary, to selectregulatory approaches that maximizenet benefits (including potentialeconomic, environmental, public healthand safety effects, distributive impacts,and equity). A regulatory impactanalysis (RIA) must be prepared formajor rules with economicallysignificant effects ($100 million or morein any one year). We have determinedthat this final rule is not aneconomically significant rule becausewe estimate that the costs to prepareComplete EHRs and EHR Modules to betested and certified will be less than$100 million per year. Nevertheless,

because of the public interest in thisfinal rule, we have prepared an RIA thatto the best of our ability presents thecosts and benefits of the final rule.

The RFA requires agencies to analyzeoptions for regulatory relief of small

businesses if a rule has a significantimpact on a substantial number of smallentities. For more information on SmallBusiness Administration’s (SBA’s) sizestandards, see the SBA’s Web site.10 We

examine the burden of the finalregulation in Section V.D below.Section 202 of the UMRA also

requires that agencies assess anticipatedcosts and benefits before issuing anyrule whose mandates require spendingin any one year of $100 million in 1995dollars, updated annually for inflation.In 2010, that threshold is approximately$135 million. This rule will not imposean unfunded mandate on States, tribal

government or the private sector of morethan $135 million annually.

Executive Order 13132 establishescertain requirements that an agencymust meet when it promulgates aproposed rule (and subsequent finalrule) that imposes substantial directcosts of compliance on State and localgovernments, preempts State law, or

otherwise has Federalism implications.We do not believe that the final ruleimposes substantial direct compliancecosts on State and local governments,preempts State law, or otherwise hasFederalism implications.

B. Why is this rule needed?

Section 3004(b)(1) of the PHSArequires the Secretary to adopt an initialset of standards, implementationspecifications, and certification criteria.On January 13, 2010, the Secretarypublished in the Federal Register aninterim final rule to adopt the initial set

of standards, implementationspecifications, and certification criteria.This final rule has been published toamend previously adopted standards,implementation specifications, andcertification criteria in order to realignsuch standards, implementationspecifications, and certification criteriawith final meaningful use Stage 1objectives and measures, and to respondto public comments received.Certification criteria and associatedstandards and implementationspecifications will be used to test andcertify Complete EHRs and EHRModules in order to make it possible foreligible professionals and eligiblehospitals to adopt and implementCertified EHR Technology. The use ofCertified EHR Technology is one of therequirements an eligible professional oreligible hospital needs to meet in orderto qualify for an incentive paymentunder the Medicare and Medicaid EHRIncentive Programs.

C. Executive Order 12866—RegulatoryPlanning and Review Analysis

1. Comment and Response

Comments. A few commenters offered

opinions related to the cost estimatesincluded in the Interim Final Rule. Onecommenter disagreed with ourapproach. This commenter contendedthat our analysis followed a simplistic,linear model that did not account for theother potential costs that Complete EHRand EHR Module developers and healthcare providers would bear. Thecommenter suggested that we addressother costs in our calculationsincluding: whether a Complete EHR orEHR Module developer has adequateresources available to modify its HIT in

order to prepare for certification; theloss of a Complete EHR or EHR Moduledeveloper’s net worth and dislocation ofjobs if it fails and goes out of business;and the resulting impacts that wouldoccur if a Complete EHR and EHRModule developer went out of businessand left behind customers (some ormany of which could then be ineligible

for Medicare and Medicaid EHRIncentive Programs) with unsupportedHIT. Another commenter questioned thecost estimates in the Interim Final Rule,

but acknowledged that it was notprepared to offer alternative costestimates. The commenter did state thatit believed our dollar values seemed lowand that the gap of 25%, representingpreviously CCHIT-certified-EHRs thatwill need additional preparation to betested and certified to the certificationcriteria adopted by the Secretary, alsoseemed low. The commenter suggesteda 40–50% gap. The commenter also

recommended that we revise our costestimates based on the certificationcriteria in the final rule to: considercosts associated with workflow redesignwithin an eligible professional oreligible hospitals environment; factor inthe costs for ‘‘interoperabilityimplementation’’ (no further explanationwas provided); account for the costsassociated with implementing theclinical quality measures certificationcriterion; account for the costs forhardware capable of supporting theadopted security requirements; andfactor in the costs for internal resources

and customer resources. Onecommenter noted that the cost related todentistry EHR technology may be higherdue to what it perceived as a lack ofcommercially available EHR technologyand that additional costs may beincurred by dentistry EHR developersthat are not as familiar as EHRdevelopers for other health providerswith the certification criteria adopted bythe Secretary. One commenter agreedwith the $10,000 to $250,000 cost rangewe estimated for the per-certification-criterion preparation, while anothercommenter seemed to misinterpret thisestimate as being the total cost toprepare a Complete EHR or EHRModule. This commenter offered that itcould take over 2,500 hours to preparea Complete EHR for certification. Onecommenter appeared to associate thecosts related to the preparation of aComplete EHR to be tested and certifiedwith the actual cost to be tested andcertified, but nonetheless expressedconcern that we had estimated that itwould cost a Complete EHR developerwhose EHR technology had notpreviously been certified no less than


http://sba.gov/idc/groups/public/documents/sba_homepage/serv_sstd_tablepdf.pdf










8/13/2019 2010-17210



$1.2 million to become compliant withthe Interim Final Rule’s requirements.The commenter requested that HHSprovide assistance to EHR vendors withrevenues of less than $1 million in orderto help offset the costs of thecertification process.

Response. We appreciate commenters’recommendations and suggestions

related to our cost analysis. While weunderstand why some commentersrecommended additional factors for usto consider as part of our analysis, wedo not believe many of those factors arerelevant for two primary reasons: (1) We

believe that it is improbable that thisrule will result in the outcomesspeculated and their associated costs;and (2) the factors contributing to orcausing the increased costs are outsidethe scope of this rule (e.g., hypothetical

business failure and job loss, workflowredesign) and could not be reasonably oraccurately estimated. In this regard, we

reiterate what we stated in the InterimFinal Rule related to how costs would be estimated. ‘‘This interim final ruleestimates the costs commercial vendors,open source developers, and relevantFederal agencies will incur to prepareComplete EHRs and EHR Modules to betested and certified to adoptedstandards, implementationspecifications, and certification criteria.The Medicare and Medicaid EHRIncentive Programs proposed ruleestimates the impacts related to theactions taken by eligible professionals oreligible hospitals to become meaningfulusers, including purchasing or self-

developing Complete EHRs or EHRModules. The HIT CertificationPrograms proposed rule estimates thetesting and certification costs forComplete EHRs and EHR Modules.’’Accordingly, we disagree with thecommenter who contended that ourestimates were too simplistic and linear.We believe that in the absence of anyadditional data or an alternative model(which no commenter provided), ourassumptions are sound and our analysisis reasonable for estimating the costsassociated with complying with thisfinal rule.

We believe that it is important to noteto commenters that compliance withthis final rule is voluntary and as such,seeking to have a Complete EHR or EHRModule certified is voluntary. AComplete EHR or EHR Moduledeveloper is not required to complywith this final rule in order to operateits business. Rather, a Complete EHR orEHR Module developer will need to relyupon this final rule only if it ultimatelyseeks to have its EHR technology testedand certified as being compliant withthe certification criteria adopted by the

Secretary. Consequently, if a CompleteEHR or EHR Module developer does nothave the resources available to redesignits Complete EHR or EHR Module toincorporate the standards andimplementation specifications or meetthe certification criteria adopted in thisrule, this rule does not create any newexpenses for its business. Given this

clarification, we believe that ourestimates represent a higher than likelynumber of Complete EHR and EHRModule developers that will preparetheir HIT to be tested and certified tothe certification criteria adopted by theSecretary, and thus, the highestpotential cost.

We considered whether an hourlypreparation cost should replace theassumptions we made in the InterimFinal Rule, but found it difficult todetermine what reasonable low andhigh hour ranges would be even if wewere to assume 2500 hours to be the

average. Further, for the purposes oftesting this alternative approach, weassumed that it would be reasonable forthe employees of a Complete EHR orEHR Module developer responsible forpreparing a Complete EHR or EHRModule for testing and certification to

be paid equivalent to a Federalemployee with a Federal SalaryClassification of GS–15 Step 1 ($59.30/hr plus 21.35/hr for benefits) given theeducational and professional experiencewe believe would be necessary to leadthis type of activity. Multiplying thetotal hourly rate by the 2500 hoursyields a total preparation cost of

approximately $201,000. Thus, even ifwe were to assume that a high averagefor preparation of a Complete EHR orEHR Module would be double what thecommenter stated, it would onlyrepresent close to $400,000 inpreparation costs. Accordingly, we

believe that our estimates are in factcomparatively high and the estimaterange covers a wide range ofpossibilities.

In the absence of additional data orany evidence to the contrary frompublic comment to guide revisions toour estimates, we are finalizing them

according to the data and assumptionswe identified in the Interim Final Rule.We believe that our estimates are sound,

based on reasonable assumptions anddata, and sufficiently accommodatevarying costs for different types ofComplete EHR and EHR Moduledevelopers. We believe that theadditional clarity and specificity wehave provided for some certificationcriteria and the removal of somerequired capabilities would furthercontribute to lowering the cost estimatesfor complying with this final rule.

Consequently, we anticipate actual costswill fall somewhere between the lowand mid-point ranges of our estimatesrather than between the mid-point andhigh ranges of our estimates.

Finally, with respect to thecommenter who expressed concernregarding the total costs associated withdeveloping a Complete EHR which had

never been certified, we note that ourestimates should not be construed toimply that a Complete EHR developerwould have to spend over $1 million inorder to prepare a Complete EHR. To thecontrary, had we calculated our lowrange for preparing a Complete EHR

based on the absolute low we estimatedfor a per certification cost ($10,000), thetotal cost would have only been$240,000, or one-fifth the cost weestimated in the Interim Final Rule. Theapproach we took in the Interim FinalRule was designed to be inclusive of amiddle range of possibilities, but was

never meant to preclude the possibilitythat a Complete EHR developer coulddesign a Complete EHR that wascompliant with the certification criteriaadopted by the Secretary for less thanwe estimated. Also in response to thecommenter’s request, we do not believethat it would be appropriate, nor are weauthorized, to provide subsidies toComplete EHR or EHR Moduledevelopers for the costs of the preparinga Complete EHR or EHR module fortesting and certification.

2. Executive Order 12866 Final Analysis

a. Costs

This final rule adopts standards,implementation specifications, andcertification criteria and consequentlyestablishes the capabilities thatComplete EHRs or EHR Modules willneed to demonstrate in order to becertified. Our analysis focuses on thedirect effects of the provisions of thisfinal rule—the costs incurred byComplete EHR and EHR Moduledevelopers to prepare Complete EHRsand EHR Modules to be tested andcertified in accordance with thecertification criteria adopted by the

Secretary. That is, we focus on thetechnological development costsnecessary to include the capabilities ina Complete EHR or EHR Module thatwill be compliant with the certificationcriteria adopted by the Secretary. Again,as noted above, the actual cost aComplete EHR or EHR Moduledeveloper will incur to be tested andcertified is accounted for in ourcertification programs final rules.

As we noted in the Interim Final Rule,we analyzed previously developedCCHIT ambulatory and inpatient


8/13/2019 2010-17210



11Some are marked with a conditionalcertification either ‘‘Pre-Market: These areconditionally certified EHRs which are newproducts that are fully certified once theiroperational use at a physician office site has beenverified.’’ or ‘‘eRx Conditional: These areconditionally certified pending advanced

ePrescribing EHRs that are in the process ofverifying their ability to conduct medicationhistory, formulary and eligibility checking througha national network for electronic-prescribingtransactions.’’ We do not believe that these caveatshave any discernible effect on our estimates.

12http://www.cchit.org/products/Ambulatory — when certification years 2006 and 2007 areunchecked. While 78 EHRs are now listed, we donot believe that changing our estimate would havea measureable effect on the overall costs.

13http://www.cchit.org/products/Inpatient.

certification criteria and believe thatmany of those criteria, but not all,require the exact same capabilities asthe certification criteria adopted by theSecretary at 45 CFR 170.302, 45 CFR170.304, and 45 CFR 170.306. Generallyspeaking, we believe this overlapincludes most of the clinically orientedcapabilities required by the certificationcriteria adopted by the Secretary.Accordingly, we believe that asignificant number of previouslyCCHIT-certified-EHRs will only incurmoderate costs to prepare forcertification. For the purpose ofestimating costs, we presume thatpreviously CCHIT-certified-EHRsinclude the functionality to meet thedefinition of a Complete EHR. As aresult, for our estimates in Table 1, weanticipate that these previously CCHIT-certified-EHRs will again be preparedfor certification as Complete EHRs. Weestimated in the Interim Final Rule that

there were 74 CCHIT-certified-EHRscertified to its 2008 ambulatorycertification criteria and 17 CCHIT-certified-EHRs certified to its 2007 or2008 inpatient certificationcriteria. 11, 12, 13 Of these 74 and 17previously CCHIT-certified-EHRs, weexpect that 90% will be prepared andsubmitted for certification according tothe certification criteria adopted by theSecretary. We do not believe that it isrealistic to assume that 100% ofpreviously CCHIT-certified-EHRs will

be prepared for certification for anumber of reasons. These reasons

include: (1) A recognition that mergersand acquisitions within the marketplacehave reduced the number of previouslyCCHIT-certified-EHRs; (2) that thesubsequent resources needed to marketand promote Certified EHR Technology

may not be available at the present time;and (3) that some previously CCHIT-certified-EHRs will be tested andcertified as EHR Modules rather thanComplete EHRs. Given theseassumptions, we have estimated thenumber of previously CCHIT-certified-EHRs that will be prepared to be testedand certified will be 65 and 15,

ambulatory and inpatient, respectively.We also believe it is reasonable toassume that of these 65 and 15, somewill require more preparation thanothers (i.e., we assume that some EHRsthat were previously CCHIT-certifiedwill include more capabilities than whatthey had when CCHIT originally testedand certified them, and they mayconsequently be able to more easilymeet the certification criteria adopted

by the Secretary). Based on thisassumption, we have created low andhigh ranges for the costs to preparepreviously CCHIT-certified ambulatory

and inpatient EHRs.In creating our low and high rangesfor the tables below, we assumed basedon our analysis of previously developedand required CCHIT certification criteriathat certain capabilities (e.g., thecapability to maintain a medication list)will have been widely implemented anddeployed in HIT so that there will belittle or no need to modify CompleteEHRs or EHR Modules for certification.We also assumed that the certificationcriteria adopted by the Secretary rangefrom relatively simple capabilities (e.g.,recording a patient’s smoking status) tomore sophisticated capabilities (e.g.,

clinical decision support). As a result,we have made a general assumption thatthe costs to prepare Complete EHRs andEHR Modules to be tested and certifiedwill vary depending on a number offactors including, but not limited to,

whether the Complete EHR or EHRModule: (1) Already includes thecapability; (2) includes some aspect ofthe capability which would need to beupdated; (3) does not currently includethe capability at all. We believe it isreasonable to estimate that it will costsomewhere between $10,000 and$250,000 per certification criterion to

prepare a Complete EHR for testing andcertification taking into account thefactors identified directly above. Wehave used this per certification criterionrange as the basis for our low and highcost range estimates. For the ease of ourcalculations, we have rounded to ‘‘40’’

the number of certification criteria thatthe Secretary is adopting.

For Table 1 we have made thefollowing assumptions based on ourunderstanding of the capabilitiespresent in previously CCHIT-certified-EHRs: (1) In general, Complete EHRdevelopers who previously obtained aCCHIT certification for their EHRtechnology will possess a Complete EHRthat will meet approximately 75% of theadopted certification criteria and, as aresult, these Complete EHR developersmay need to make more comprehensiveadjustments to their Complete EHRs inorder to prepare the Complete EHRs to

be tested and certified to the remaining25% of the certification criteria adopted

by the Secretary; (2) the average low andhigh per certification criterion cost forambulatory EHRs previously certified byCCHIT which need to be prepared fortesting and certification will be $50,000

and $150,000, respectively; and (3) theaverage low and high per certificationcriterion cost for previously CCHIT-certified inpatient EHRs to be preparedfor testing and certification will be$75,000 and $200,000, respectively.

TABLE 1—ESTIMATED ONE-TIME COSTS FOR COMPLETE EHR DEVELOPERS TO PREPARE PREVIOUSLY CCHIT–CERTIFIED-EHRS TO BE TESTED AND CERTIFIED (3-YEAR PERIOD)—TOTALS ROUNDED

TypeNumberprepared

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 estimateincludes the costs that we expect for

CCHIT-certified ambulatory EHRscertified prior to 2008 (‘‘out-of-date

CCHIT–Certified-EHRs’’) and neverpreviously CCHIT-certified-EHRs to be


http://www.cchit.org/products/Ambulatory


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

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


8/13/2019 2010-17210



14CCHIT began testing and certifying inpatientEHRs in 2007 and we assume that all of those EHRsare included in Table 1 which is why they are notincluded in this discussion.

15http://www.cchit.org/ about —‘‘* * * EHRproducts certified by mid-2009, representing over75% of the marketplace.’’

16This estimate is premised in part on the factthat IHS’s RPMS EHR was not included in Table 1

and that it will be preparing the RPMS EHR as aComplete EHR to meet the applicable certificationcriteria adopted by the Secretary for bothambulatory and inpatient settings.

prepared to be tested and certified asComplete EHRs rather than as EHRModules.14 We assume the EHRtechnology that falls into this categorymay require more extensive changesthan previously CCHIT-certified-EHRsidentified in Table 1. Again, we haveestimated low and high preparation costranges. We assume that there will be

very little growth in the Complete EHRmarket due to the market share 15 represented by the previously CCHIT-certified-EHRs included in Table 1 andthe upfront costs required to bring aComplete EHR to market. As a result, weexpect there to be 8 and 5 CompleteEHRs (for use by eligible professionalsand eligible hospitals, respectively)

prepared to be tested and certified to allof the applicable certification criteriaadopted by the Secretary.16

Again, using our general assumptionsdiscussed above (40 certification criteriaand a low and high range of $10,000 to$250,000 per certification criterion) wehave made the following additionalassumptions in our Table 2 calculations

based on our understanding of thecapabilities currently present in theseEHR technologies: (1) In general,Complete EHR developers who haveout-of-date CCHIT-Certified-EHRs orwho never previously had theirComplete EHRs certified by CCHIT willpossess Complete EHRs that will meetapproximately 40% of the adopted

certification criteria and, as a result,these Complete EHR developers mayneed to make more comprehensiveadjustments to their Complete EHRs inorder to prepare the Complete EHRs to

be tested and certified to the remaining60% of the certification criteria adopted

by the Secretary; (2) the average low andhigh per certification criterion costs for

Complete EHRs for eligibleprofessionals to be prepared to be testedand certified will be $50,000 and$150,000, respectively; and (3) theaverage low and high per certificationcriterion costs for Complete EHRs foreligible hospitals to be prepared to betested and certified will be $75,000 and$200,000, respectively.

TABLE 2—ESTIMATED ONE-TIME COSTS FOR COMPLETE EHR DEVELOPERS TO PREPARE NEVER CCHIT-CERTIFIED-EHRS AND OUT-OF-DATE CCHIT-CERTIFIED-EHRS TO BE TESTED AND CERTIFIED (3-YEAR PERIOD)—TOTALS ROUNDED

TypeNumber

prepared for

certification

One time cost per EHR ($M) Total cost for all EHRs over 3-yearperiod ($M)


Complete EHRs for Eligible Professionals 8 $1.2 $3.6 $2.4 $9.6 $28.8 $19.2Complete 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 weestimate relates to the number of EHRModules we expect to be prepared to betested and certified and the costsassociated with that preparation. Weclarify as noted in the TemporaryCertification Program final rule thatthese EHR Modules are not ‘‘self-developed,’’ and we assume that an EHRModule developer interested incommercially marketing its EHRModule to eligible professionals andeligible hospitals would develop them.We assumed in the Interim Final Rulethat certain types of EHR Modules (e.g.,computerized provider order entry;quality reporting; online patient portals)would be more likely than others to beprepared to be tested and certified, andwe estimated based on our assumption

that there would be 7 EHR Modulesprepared to be tested and certified foreach of the 7 types of EHR Modules weidentified. This estimate (number ofmodules X types of modules) resulted inan approximate number of 50 EHRModules that would be prepared to betested and certified. Again, we haveprovided low and high preparation costestimates in Table 3 below. We assumethat some of EHR Modules prepared forcertification will be capable of meetingapplicable certification criteria withlittle modification while other EHRModules will not. Given the potentialdifferences in preparation costs andcombinations of certification criteria tocreate EHR Modules, we believe it isreasonable to estimate a wide range ofcosts for preparing these types of EHR

Modules for testing and certification.We estimated in the Interim Final Ruleand reiterate below a low average one-time cost of $100,000 to prepare an EHRModule, based on the assumption thatsome of the less sophisticated EHRModules would only be prepared to betested and certified to 1 or 2certification criteria. We estimated inthe Interim Final Rule and reiterate

below, a high average cost one-time costof $500,000 to prepare an EHR Module,

based on the assumption that some ofthe more sophisticated EHR Moduleswould only be prepared to be tested andcertified to 1 or 2 of the morecomplicated certification criteria orwould be prepared to be tested andcertified to multiple certificationcriteria.

TABLE 3—ESTIMATED ONE-TIME COSTS TO EHR MODULE DEVELOPERS TO PREPARE EHR MODULES TO BE TESTED AND CERTIFIED (3-YEAR PERIOD)—TOTALS ROUNDED

Type Numberprepared

One-time cost per EHR module ($M) Total cost all EHR modules over 3-yearperiod ($M)

Low High Mid-pointLow High Mid-point

EHR Modules .. .. ... .. ... .. ... ... .. ... .. ... .. ... ... .. ... .. 50 $0.1 $0.5 $0.3 $5.0 $25.0 $15.0


http://www.cchit.org/

http://www.cchit.org/

8/13/2019 2010-17210



TABLE 3—ESTIMATED ONE-TIME COSTS TO EHR MODULE DEVELOPERS TO PREPARE EHR MODULES TO BE TESTED AND CERTIFIED (3-YEAR PERIOD)—TOTALS ROUNDED—Continued

TypeNumberprepared

One-time cost per EHR module ($M) Total cost all EHR modules over 3-yearperiod ($M)


Total .................................................... 50 .................. .................. .................. 5.0 25.0 15.0

In total, if we were to distribute thecosts to prepare Complete EHRs andEHR Modules between 2010 and 2012evenly per year, we believe they wouldlikely be in the range of $67.35 to $205.3million or $22.45 to $68.43 million peryear with an annual cost mid-point ofapproximately $45.44 million. However,we do not believe that the costs will be

spread evenly over these three years dueto market pressures and the fact thathigher upfront incentive payments areavailable under the Medicare andMedicaid EHR Incentive Programs. Weassume this factor will motivate agreater ratio of commercial vendors andopen source developers of CompleteEHRs and EHR Modules to prepare such

technology for testing and certificationin 2010 and 2011 rather than 2012. Asa result, we believe as represented inTable 4 that the costs attributable to thisfinal rule will be distributed as follows:45% for 2010, 40% for 2011 and 15%for 2012.

TABLE 6—DISTRIBUTED TOTAL PREPARATION COSTS FOR COMPLETE EHR AND EHR MODULE DEVELOPERS (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.352011 ............................................................................................... 40 26.94 82.12 54.532012 ............................................................................................... 15 10.10 30.80 20.453-Year Totals ................................................................................. ............................ 67.35 205.30 136.33

Note that these cost estimates do notinclude additional costs to prepare fortesting and certification that will likely

be incurred when we adopt additionalstandards, implementationspecifications, and certification criteriato support meaningful use Stages 2 and

3. We will account for costs associatedwith these additional standards,implementation specifications, andcertification criteria in futurerulemaking.

b. Benefits

We believe that there will be several benefits arising from this final rule. Byadopting the revisions to this initial set,the Secretary will set in motion what we

believe will be an iterative process tofurther enhance the interoperability,functionality, utility, and security ofhealth information technology and to

support the meaningful use of CertifiedEHR Technology. The capabilitiesspecified in the adopted certificationcriteria will help ensure that health careproviders have the necessaryinformation technology tools to improvepatient care, reduce medical errors andunnecessary tests. The standardsadopted will aid in fostering greaterinteroperability. We also believe thatthis final rule will serve as a catalyst fora more competitive and innovativemarketplace. Finally, adoptedcertification criteria can be used by

Complete EHR and EHR Moduledevelopers as technical requirements toensure that their HIT can be tested andcertified and subsequently adopted andimplemented as Certified EHRTechnology. Adopting thesecertification criteria will also ultimately

help enable eligible professionals andeligible hospitals to qualify for incentivepayments under Medicare and MedicaidEHR Incentive Programs.

D. Regulatory Flexibility Act Analysis

1. Comment and Response

Comment. Some commenters notedthat we incorrectly referenced theproportion of businesses in themarketplace that would qualify as small

businesses under the SBA’s sizestandard. The commenters cited apresentation by CCHIT which indicatedthat potentially up to 75% of CompleteEHR developers who design CompleteEHRs for ambulatory settings wouldqualify as small businesses.

Response. We appreciate commenterspointing out this additional information.We have revised the discussionaccordingly in the final RFA analysis.However, we do not believe that thisadditional information substantiallychanges our analysis. We do not believethat any relief can be provided to small

businesses under the SBA size standardthat would not undercut our

programmatic goals and objectives. AComplete EHR or EHR Moduledeveloper will need to design aComplete EHR or EHR Module that can

be tested and successfully certified to allapplicable certification criteria adopted

by the Secretary in order for the

Complete EHR or EHR Module to attaincertification. Accordingly, we see noviable alternatives to reducing therequirements in the final rule orproviding for alternatives to adoptedcertification criteria. Additionally, we

believe that the regulation builds in acertain amount of flexibility already inthat a small business without theresources available to develop aComplete EHR has the option to developan EHR Module which will presumablyrequire less of an investment (time andmoney) to develop.

2. Final RFA Analysis

The RFA requires agencies to analyzeoptions for regulatory relief of small

businesses if a rule has a significantimpact on a substantial number of smallentities.

While Complete EHRs and EHRModule developers represent a smallsegment of the overall informationtechnology industry, we believe that theentities impacted by this final rule mostlikely fall under the North AmericanIndustry Classification System (NAICS)code 541511 ‘‘Custom Computer


8/13/2019 2010-17210



17The SBA references that annual receipts means‘‘total income’’ (or in the case of a soleproprietorship, ‘‘gross income’’) plus ‘‘cost of goodssold’’ as these terms are defined and reported onInternal Revenue Service tax return forms. http:// www.sba.gov/idc/groups/public/documents/ sba _homepage/guide _to _size _standards.pdf.

Programming Services’’ specified at 13CFR 121.201 where the SBA publishes‘‘Small Business Size Standards byNAICS Industry.’’ The size standardassociated with this NAICS code is setat $25 million in annual receipts 17 which ‘‘indicates the maximum allowedfor a concern and its affiliates to beconsidered small entities.’’

Based on our analysis, we believe thatthere is enough data generally availableto establish that between 75% and 90%of entities that are categorized under theNAICS code 541511 are under the SBAsize standard, but note that the availabledata does not show how many of theseentities will develop a Complete EHR orEHR Module. We also note that with theexception of aggregate businessinformation available through the U.S.Census Bureau and the SBA related toNAICS code 541511, it appears thatmany Complete EHR and EHR Moduledevelopers are privately held or owned

and do not regularly, if at all, make theirspecific annual receipts publiclyavailable. As a result, it is difficult tolocate empirical data related to many ofthe Complete EHR and EHR Moduledevelopers to correlate to the SBA sizestandard.

We estimate that this final rule couldhave effects on Complete EHR and EHRModule developers, some of which may

be small entities. However, we believethat we have established the minimumamount of requirements necessary toaccomplish our policy goals and that noappropriate regulatory alternativescould be developed to lessen the

compliance burden associated with thisfinal rule. In order for a Complete EHRor EHR Module to provide thecapabilities an eligible professional oreligible hospital will be required to useunder the Medicare and Medicaid EHRIncentive Programs final rule, it willneed to comply with the applicablecertification criteria adopted by theSecretary. Moreover, we note that thisfinal rule does not impose the costscited in the regulatory impact analysisas compliance costs, but rather asinvestments which Complete EHR andEHR Module developers voluntarily

take on and expect to recover with anappropriate rate of return. Accordingly,we do not believe that the final rule willcreate a significant impact on asubstantial number of small entities.The Secretary certifies that this finalrule will not have a significant impact

on a substantial number of smallentities.

E. Executive Order 13132—Federalism

Executive Order 13132 establishescertain requirements that an agencymust meet when it promulgates aproposed rule (and subsequent finalrule) that imposes substantial direct

requirement costs on State and localgovernments, preempts State law, orotherwise has federalism implications.

Nothing in this final rule imposessubstantial direct compliance costs onState and local governments, preemptsState law or otherwise has federalismimplications. We are not aware of anyState laws or regulations that arecontradicted or impeded by any of thestandards, implementationspecifications, or certification criteriathat have been adopted.

The Office of Management and Budgetreviewed this final rule.

List of Subjects in 45 CFR Part 170

Computer technology, Electronichealth record, Electronic informationsystem, Electronic transactions, Health,Health care, Health informationtechnology, Health insurance, Healthrecords, Hospitals, Incorporation byreference, Laboratories, Medicaid,Medicare, Privacy, Reporting andrecordkeeping requirements, Publichealth, Security.

■ For the reasons set forth in thepreamble, 45 CFR subtitle A, subchapterD, part 170, is amended as follows:

PART 170–HEALTH INFORMATIONTECHNOLOGY STANDARDSIMPLEMENTATION SPECIFICATIONS,AND CERTIFICATION CRITERIA ANDCERTIFICATION PROGRAMS FORHEALTH INFORMATIONTECHNOLOGY

■ 1. The authority citation for part 170continues to read as follows:

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

■ 2. Amend §170.102 by revising thedefinitions of ‘‘Complete EHR,’’‘‘Certified EHR Technology,

’’and‘‘Disclosure’’ and adding the definition

of ‘‘Human readable format’’ to read asfollows:

§ 170.102 Definitions.

* * * * *Certified EHR Technology means:(1) A Complete EHR that meets the

requirements included in the definitionof a Qualified EHR and has been testedand certified in accordance with thecertification program established by theNational Coordinator as having met all

applicable certification criteria adopted by the Secretary; or

(2) A combination of EHR Modules inwhich each constituent EHR Module ofthe combination has been tested andcertified in accordance with thecertification program established by theNational Coordinator as having met allapplicable certification criteria adopted

by the Secretary, and the resultantcombination also meets therequirements included in the definitionof a Qualified EHR.

Complete EHR means EHR technologythat has been developed to meet, at aminimum, all applicable certificationcriteria adopted by the Secretary.

Disclosure is defined as it is in 45 CFR160.103.

* * * * *Human readable format means a

format that enables a human to read andeasily comprehend the informationpresented to him or her regardless of the

method of presentation.* * * * *■ 3. Revise subpart B to read as follows:

Subpart B—Standards andImplementation Specifications forHealth Information Technology

Sec.170.200 Applicability.170.202 [Reserved]170.205 Content exchange standards and

implementation specifications forexchanging electronic healthinformation.

170.207 Vocabulary standards for

representing electronic healthinformation.170.210 Standards for health information

technology to protect electronic healthinformation created, maintained, andexchanged.

170.299 Incorporation by reference.

§ 170.200 Applicability.

The standards and implementationspecifications adopted in this part applywith respect to Complete EHRs and EHRModules.

§170.202 [Reserved]

§ 170.205 Content exchange standardsand implementation specifications forexchanging electronic health information.

The Secretary adopts the followingcontent exchange standards andassociated implementationspecifications:

(a) Patient summary record—(1)Standard. Health Level Seven ClinicalDocument Architecture (CDA) Release2, Continuity of Care Document (CCD)(incorporated by reference in §170.299).Implementation specifications. TheHealthcare Information TechnologyStandards Panel (HITSP) Summary


http://www.sba.gov/idc/groups/public/documents/sba_homepage/guide_to_size_standards.pdf














8/13/2019 2010-17210



Documents Using HL7 CCD ComponentHITSP/C32 (incorporated by referencein § 170.299).

(2) Standard. ASTM E2369 StandardSpecification for Continuity of CareRecord and Adjunct to ASTM E2369(incorporated by reference in §170.299).

(b) Electronic prescribing. (1)Standard. The National Council for the

Prescription Drug Programs (NCPDP)Prescriber/Pharmacist Interface SCRIPTstandard, Implementation Guide,Version 8, Release 1 (Version 8.1)October 2005 (incorporated by referencein § 170.299)

(2) Standard. NCPDP SCRIPTStandard, Implementation Guide,Version 10.6 (incorporated by referencein § 170.299).

(c) Electronic submission of labresults to public health agencies.Standard. HL7 2.5.1 (incorporated byreference in § 170.299). Implementationspecifications. HL7 Version 2.5.1

Implementation Guide: ElectronicLaboratory Reporting to Public Health,Release 1 (US Realm) (incorporated byreference in § 170.299).

(d) Electronic submission to publichealth agencies for surveillance orreporting. (1) Standard. HL7 2.3.1(incorporated by reference in §170.299).

(2) Standard. HL7 2.5.1 (incorporated by reference in §170.299).Implementation specifications. PublicHealth Information Network HL7Version 2.5 Message StructureSpecification for National ConditionReporting Final Version 1.0 and Errata

and Clarifications National NotificationMessage Structural Specification(incorporated by reference in §170.299).

(e) Electronic submission toimmunization registries. (1) Standard.HL7 2.3.1 (incorporated by reference in§ 170.299). Implementationspecifications. Implementation Guidefor Immunization Data Transactionsusing Version 2.3.1 of the Health LevelSeven (HL7) Standard ProtocolImplementation Guide Version 2.2(incorporated by reference in §170.299).

(2) Standard. HL7 2.5.1 (incorporated by reference in §170.299).Implementation specifications. HL72.5.1 Implementation Guide forImmunization Messaging Release 1.0(incorporated by reference in §170.299).

(f) Quality reporting. Standard. TheCMS Physician Quality ReportingInitiative (PQRI) 2009 Registry XMLSpecification (incorporated by referencein § 170.299). Implementationspecifications. Physician QualityReporting Initiative MeasureSpecifications Manual for Claims andRegistry (incorporated by reference in§ 170.299).

§ 170.207 Vocabulary standards forrepresenting electronic health information.

The Secretary adopts the followingcode sets, terminology, andnomenclature as the vocabularystandards for the purpose ofrepresenting electronic healthinformation:

(a) Problems—(1) Standard. The code

set specified at 45 CFR 162.1002(a)(1)for the indicated conditions.

(2) Standard. International HealthTerminology Standards DevelopmentOrganization (IHTSDO) SystematizedNomenclature of Medicine ClinicalTerms (SNOMED CT®) July 2009version (incorporated by reference in§ 170.299).

(b) Procedures—(1) Standard. Thecode set specified at 45 CFR162.1002(a)(2).

(2) Standard. The code set specified at45 CFR 162.1002(a)(5).

(c) Laboratory test results. Standard.Logical Observation Identifiers Names

and Codes (LOINC®) version 2.27, whensuch codes were received within anelectronic transaction from a laboratory(incorporated by reference in § 170.299).

(d) Medications. Standard. Anysource vocabulary that is included inRxNorm, a standardized nomenclaturefor clinical drugs produced by theUnited States National Library ofMedicine.

(e) Immunizations. Standard. HL7Standard Code Set CVX—VaccinesAdministered, July 30, 2009 version(incorporated by reference in §170.299).

(f) Race and Ethnicity. Standard. The

Office of Management and BudgetStandards for Maintaining, Collecting,and Presenting Federal Data on Raceand Ethnicity, Statistical PolicyDirective No. 15, October 30, 1997(available at http:// www.whitehouse.gov/omb/rewrite/

fedreg/ombdir15.html ).

§ 170.210 Standards for health informationtechnology to protect electronic healthinformation created, maintained, andexchanged.

The Secretary adopts the followingstandards to protect electronic healthinformation created, maintained, and

exchanged:(a) Encryption and decryption ofelectronic health information—(1)General. Any encryption algorithmidentified by the National Institute ofStandards and Technology (NIST) as anapproved security function in Annex Aof the Federal Information ProcessingStandards (FIPS) Publication 140–2(incorporated by reference in §170.299).

(2) Exchange. Any encrypted andintegrity protected link.

(b) Record actions related toelectronic health information. The date,

time, patient identification, and useridentification must be recorded whenelectronic health information is created,modified, accessed, or deleted; and anindication of which action(s) occurredand by whom must also be recorded.

(c) Verification that electronic healthinformation has not been altered intransit. Standard. A hashing algorithm

with a security strength equal to orgreater than SHA–1 (Secure HashAlgorithm (SHA–1) as specified by theNational Institute of Standards andTechnology (NIST) in FIPS PUB 180–3(October, 2008)) must be used to verifythat electronic health information hasnot been altered.

(d) Record treatment, payment, andhealth care operations disclosures. Thedate, time, patient identification, useridentification, and a description of thedisclosure must be recorded fordisclosures for treatment, payment, andhealth care operations, as these terms

are defined at 45 CFR 164.501.§ 170.299 Incorporation by reference.

(a) Certain material is incorporated byreference into this subpart with theapproval of the Director of the FederalRegister under 5 U.S.C. 552(a) and 1CFR part 51. To enforce any editionother than that specified in this section,the Department of Health and HumanServices must publish notice of changein the Federal Register and the materialmust be available to the public. Allapproved material is available forinspection at the National Archives andRecords Administration (NARA). For

information on the availability of thismaterial at NARA, call 202–741–6030 orgo to http://www.archives.gov/

federal _register/ code _of _ federal _regulations/ ibr _locations.html. Also, it is availablefor inspection at U.S. Department ofHealth and Human Services, Office ofthe National Coordinator for HealthInformation Technology, Hubert H.Humphrey Building, Suite 729D, 200Independence Ave., SW., Washington,DC 20201, call ahead to arrange forinspection at 202–690–7151, and isavailable from the sources listed below.

(b) Health Level Seven, 3300Washtenaw Avenue, Suite 227, AnnArbor, MI 48104; Telephone (734) 677–7777 or http://www.hl7.org/ .

(1) Health Level Seven StandardVersion 2.3.1 (HL7 2.3.1), AnApplication Protocol for Electronic DataExchange in Healthcare Environments,April 14, 1999, IBR approved for§ 170.205.

(2) Health Level Seven MessagingStandard Version 2.5.1 (HL7 2.5.1), AnApplication Protocol for Electronic DataExchange in Healthcare Environments,


http://www.whitehouse.gov/omb/rewrite/fedreg/ombdir15.html




http://www.archives.gov/federal_register/code_of_federal_regulations/ibr_locations.html














http://www.hl7.org/

http://www.hl7.org/

http://www.hl7.org/








8/13/2019 2010-17210



February 21, 2007, IBR approved for§ 170.205.

(3) Health Level SevenImplementation Guide: ClinicalDocument Architecture (CDA) Release2—Continuity of Care Document (CCD),April 01, 2007, IBR approved for§ 170.205.

(4) HL7 Version 2.5.1 Implementation

Guide: Electronic Laboratory Reportingto Public Health, Release 1 (US Realm)HL7 Version 2.5.1: ORU∧R01, HL7Informative Document, February, 2010,IBR approved for § 170.205.

(5) [Reserved](c) ASTM International, 100 Barr

Harbor Drive, PO Box C700, WestConshohocken, PA, 19428–2959 USA;Telephone (610) 832–9585 or http:// www.astm.org/ .

(1) ASTM E2369–05: StandardSpecification for Continuity of CareRecord (CCR), year of adoption 2005,ASTM approved July 17, 2006, IBR

approved for § 170.205.(2) ASTM E2369–05 (Adjunct toE2369): Standard SpecificationContinuity of Care Record,—FinalVersion 1.0 (V1.0), November 7, 2005,IBR approved for § 170.205.

(d) National Council for PrescriptionDrug Programs, Incorporated, 9240 E.Raintree Drive, Scottsdale, AZ 85260–7518; Telephone (480) 477–1000; andFacsimile (480) 767–1042 or http:// www.ncpdp.org .

(1) National Council for PrescriptionDrug Programs Prescriber/PharmacistInterface SCRIPT Standard,Implementation Guide, Version 8,

Release 1, October 2005, IBR approvedfor § 170.205.

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

(3) [Reserved](e) Regenstrief Institute, Inc., LOINC®

c/o Medical Informatics The RegenstriefInstitute, Inc 410 West 10th Street, Suite2000 Indianapolis, IN 46202–3012;Telephone (317) 423–5558 or http:// loinc.org/ .

(1) Logical Observation IdentifiersNames and Codes (LOINC®) version

2.27, June 15, 2009, IBR approved for§ 170.207.(2) [Reserved](f) U.S. National Library of Medicine,

8600 Rockville Pike, Bethesda, MD20894; Telephone (301) 594–5983 orhttp://www.nlm.nih.gov/ .

(1) International Health TerminologyStandards Development OrganizationSystematized Nomenclature of MedicineClinical Terms (SNOMED CT®),International Release, July 2009, IBRapproved for § 170.207.

(2) [Reserved]

(g) Centers for Disease Control andPrevention, National Centers forImmunization and Respiratory DiseasesImmunization Information SystemSupport Branch—Informatics 1600Clifton Road Mailstop: E–62 Atlanta, GA30333

(1) HL7 Standard Code Set CVX—Vaccines Administered, July 30, 2009,

IBR approved for §170.207.(2) Implementation Guide for

Immunization Data Transactions usingVersion 2.3.1 of the Health Level Seven(HL7) Standard ProtocolImplementation Guide Version 2.2, June2006, IBR approved for §170.205.

(3) HL7 2.5.1 Implementation Guidefor Immunization Messaging Release1.0, May 1, 2010, IBR approved for§ 170.205.

(4) Public Health InformationNetwork HL7 Version 2.5 MessageStructure Specification for NationalCondition Reporting Final Version 1.0,

including Errata and Clarifications,National Notification MessageStructural Specification, 8/18/2007,August 18, 2007, IBR approved for§ 170.205.

(5) [Reserved](h) Centers for Medicare & Medicaid

Services, Office of Clinical Standardsand Quality, 7500 Security Boulevard,Baltimore, Maryland 21244; Telephone(410) 786–3000

(1) CMS PQRI 2009 Registry XMLSpecifications, IBR approved for§ 170.205.

(2) 2009 Physician Quality Reporting

Initiative Measure SpecificationsManual for Claims and Registry, Version3.0, December 8, 2008 IBR approved for§ 170.205.

(i) National Institute of Standards andTechnology, Information TechnologyLaboratory, National Institute ofStandards and Technology, 100 BureauDrive, Gaithersburg, MD 20899–8930,http://csrc.nist.gov/groups/STM/cmvp/ standards.html .

(1) Annex A: Approved SecurityFunctions for FIPS PUB 140–2, SecurityRequirements for CryptographicModules, Draft, January 27, 2010, IBR

approved for § 170.210.(2) [Reserved](j) American National Standards

Institute, Health InformationTechnology Standards Panel (HITSP)Secretariat, 25 West 43rd Street—FourthFloor, New York, NY 10036, http:// www.hitsp.org

(1) HITSP Summary Documents UsingHL7 Continuity of Care Document (CCD)Component, HITSP/C32, July 8, 2009,Version 2.5, IBR approved for § 170.205.

■ 4. Revise subpart C to read as follows:

Subpart C—Certification Criteria forHealth Information Technology

Sec.170.300 Applicability.170.302 General certification criteria for

Complete EHRs or EHR Modules.170.304 Specific certification criteria for

Complete EHRs or EHR Modulesdesigned for an ambulatory setting.

170.306 Specific certification criteria forComplete EHRs or EHR Modulesdesigned for an inpatient setting.

§ 170.300 Applicability.

(a) The certification criteria adoptedin this subpart apply to the testing andcertification of Complete EHRs and EHRModules.

(b) When a certification criterionrefers to two or more standards asalternatives, use of at least one of thealternative standards will be consideredcompliant.

(c) Complete EHRs and EHR Modulesare not required to be compliant with

certification criteria that are designatedas optional.

§ 170.302 General certification criteria forComplete EHRs or EHR Modules.

The Secretary adopts the followinggeneral certification criteria forComplete EHRs or EHR Modules.Complete EHRs or EHR Modules mustinclude the capability to perform thefollowing functions electronically,unless designated as optional, and inaccordance with all applicablestandards and implementationspecifications adopted in this part:

(a) Drug-drug, drug-allergy interaction

checks—(1) Notifications. Automaticallyand electronically generate and indicatein real-time, notifications at the point ofcare for drug-drug and drug-allergycontraindications based on medicationlist, medication allergy list, andcomputerized provider order entry(CPOE).

(2) Adjustments. Provide certain userswith the ability to adjust notificationsprovided for drug-drug and drug-allergyinteraction checks.

(b) Drug-formulary checks. Enable auser to electronically check if drugs arein a formulary or preferred drug list.

(c) Maintain up-to-date problem list.Enable a user to electronically record,modify, and retrieve a patient’s problemlist for longitudinal care in accordancewith:

(1) The standard specified in§ 170.207(a)(1); or

(2) At a minimum, the version of thestandard specified in §170.207(a)(2).

(d) Maintain active medication list.Enable a user to electronically record,modify, and retrieve a patient’s activemedication list as well as medicationhistory for longitudinal care.


http://www.astm.org/



http://www.ncpdp.org/



http://loinc.org/

http://loinc.org/

http://loinc.org/

http://www.nlm.nih.gov/


http://csrc.nist.gov/groups/STM/cmvp/standards.html



http://www.hitsp.org/


http://loinc.org/

http://loinc.org/










8/13/2019 2010-17210



(e) Maintain active medication allergylist. Enable a user to electronicallyrecord, modify, and retrieve a patient’sactive medication allergy list as well asmedication allergy history forlongitudinal care.

(f) Record and chart vital signs—(1)Vital signs. Enable a user toelectronically record, modify, and

retrieve a patient’s vital signs including,at a minimum, height, weight, and

blood pressure.(2) Calculate body mass index.

Automatically calculate and display body mass index (BMI) based on apatient’s height and weight.

(3) Plot and display growth charts.Plot and electronically display, uponrequest, growth charts for patients 2–20years old.

(g) Smoking status. Enable a user toelectronically record, modify, andretrieve the smoking status of a patient.Smoking status types must include:

current every day smoker; current someday smoker; former smoker; neversmoker; smoker, current statusunknown; and unknown if ever smoked.

(h) Incorporate laboratory testresults—(1) Receive results.Electronically receive clinical laboratorytest results in a structured format anddisplay such results in human readableformat.

(2) Display test report information.Electronically display all theinformation for a test report specified at42 CFR 493.1291(c)(1) through (7).

(3) Incorporate results. Electronicallyattribute, associate, or link a laboratory

test result to a laboratory order orpatient record.

(i) Generate patient lists. Enable auser to electronically select, sort,retrieve, and generate lists of patientsaccording to, at a minimum, the dataelements included in:

(1) Problem list;(2) Medication list;(3) Demographics; and(4) Laboratory test results.(j) Medication reconciliation. Enable a

user to electronically compare two ormore medication lists.

(k) Submission to immunization

registries. Electronically record, modify,retrieve, and submit immunizationinformation in accordance with:

(1) The standard (and applicableimplementation specifications)specified in § 170.205(e)(1) or§ 170.205(e)(2); and

(2) At a minimum, the version of thestandard specified in §170.207(e).

(l) Public health surveillance.Electronically record, modify, retrieve,and submit syndrome-based publichealth surveillance information inaccordance with the standard (and

applicable implementationspecifications) specified in§ 170.205(d)(1) or § 170.205(d)(2).

(m) Patient-specific educationresources. Enable a user toelectronically identify and providepatient-specific education resourcesaccording to, at a minimum, the dataelements included in the patient’s:

problem list; medication list; andlaboratory test results; as well asprovide such resources to the patient.

(n) Automated measure calculation.For each meaningful use objective witha percentage-based measure,electronically record the numerator anddenominator and generate a reportincluding the numerator, denominator,and resulting percentage associated witheach applicable meaningful usemeasure.

(o) Access control. Assign a uniquename and/or number for identifying andtracking user identity and establish

controls that permit only authorizedusers to access electronic healthinformation.

(p) Emergency access. Permitauthorized users (who are authorized foremergency situations) to accesselectronic health information during anemergency.

(q) Automatic log-off. Terminate anelectronic session after a predeterminedtime of inactivity.

(r) Audit log. (1)—Record actions.Record actions related to electronichealth information in accordance withthe standard specified in § 170.210(b).

(2) Generate audit log. Enable a userto generate an audit log for a specifictime period and to sort entries in theaudit log according to any of theelements specified in the standard at§ 170.210(b).

(s) Integrity. (1) Create a messagedigest in accordance with the standardspecified in § 170.210(c).

(2) Verify in accordance with thestandard specified in § 170.210(c) uponreceipt of electronically exchangedhealth information that suchinformation has not been altered.

(3) Detection. Detect the alteration ofaudit logs.

(t) Authentication. Verify that aperson or entity seeking access toelectronic health information is the oneclaimed and is authorized to accesssuch information.

(u) General encryption. Encrypt anddecrypt electronic health information inaccordance with the standard specifiedin §170.210(a)(1), unless the Secretarydetermines that the use of suchalgorithm would pose a significantsecurity risk for Certified EHRTechnology.

(v) Encryption when exchangingelectronic health information. Encryptand decrypt electronic healthinformation when exchanged inaccordance with the standard specifiedin § 170.210(a)(2).

(w) Optional. Accounting ofdisclosures. Record disclosures made fortreatment, payment, and health care

operations in accordance with thestandard specified in §170.210(d).

§ 170.304 Specific certification criteria forComplete EHRs or EHR Modules designedfor an ambulatory setting.

The Secretary adopts the followingcertification criteria for Complete EHRsor EHR Modules designed to be used inan ambulatory setting. Complete EHRsor EHR Modules must include thecapability to perform the followingfunctions electronically and inaccordance with all applicablestandards and implementationspecifications adopted in this part:

(a) Computerized provider orderentry. Enable a user to electronicallyrecord, store, retrieve, and modify, at aminimum, the following order types:

(1) Medications;(2) Laboratory; and(3) Radiology/imaging.(b) Electronic prescribing. Enable a

user to electronically generate andtransmit prescriptions and prescription-related information in accordance with:

(1) The standard specified in§ 170.205(b)(1) or § 170.205(b)(2); and

(2) The standard specified in§ 170.207(d).

(c) Record demographics. Enable auser to electronically record, modify,and retrieve patient demographic dataincluding preferred language, gender,race, ethnicity, and date of birth. Enablerace and ethnicity to be recorded inaccordance with the standard specifiedat § 170.207(f).

(d) Patient reminders. Enable a user toelectronically generate a patientreminder list for preventive or follow-upcare according to patient preferences

based on, at a minimum, the dataelements included in:

(1) Problem list;(2) Medication list;

(3) Medication allergy list;(4) Demographics; and(5) Laboratory test results.(e) Clinical decision support —(1)

Implement rules. Implement automated,electronic clinical decision supportrules (in addition to drug-drug anddrug-allergy contraindication checking)

based on the data elements included in:problem list; medication list;demographics; and laboratory testresults.

(2) Notifications. Automatically andelectronically generate and indicate in


8/13/2019 2010-17210



real-time, notifications and caresuggestions based upon clinicaldecision support rules.

(f) Electronic copy of healthinformation. Enable a user to create anelectronic copy of a patient’s clinicalinformation, including, at a minimum,diagnostic test results, problem list,medication list, and medication allergy

list in:(1) Human readable format; and(2) On electronic media or through

some other electronic means inaccordance with:

(i) The standard (and applicableimplementation specifications)specified in § 170.205(a)(1) or§ 170.205(a)(2); and

(ii) For the following data elementsthe applicable standard must be used:

(A) Problems. The standard specifiedin § 170.207(a)(1) or, at a minimum, theversion of the standard specified in§ 170.207(a)(2);

(B) Laboratory test results. At aminimum, the version of the standardspecified in §170.207(c); and

(C) Medications. The standardspecified in § 170.207(d).

(g) Timely access. Enable a user toprovide patients with online access totheir clinical information, including, ata minimum, lab test results, problemlist, medication list, and medicationallergy list.

(h) Clinical summaries. Enable a userto provide clinical summaries topatients for each office visit thatinclude, at a minimum, diagnostic testresults, problem list, medication list,

and medication allergy list. If theclinical summary is providedelectronically it must be:

(1) Provided in human readableformat; and

(2) Provided on electronic media orthrough some other electronic means inaccordance with:



(A) Problems. The standard specified

in § 170.207(a)(1) or, at a minimum, theversion of the standard specified in§ 170.207(a)(2);



(i) Exchange clinical information and patient summary record —(1)Electronically receive and display.Electronically receive and display apatient’s summary record, from otherproviders and organizations including,

at a minimum, diagnostic tests results,problem list, medication list, andmedication allergy list in accordancewith the standard (and applicableimplementation specifications)specified in § 170.205(a)(1) or§ 170.205(a)(2). Upon receipt of apatient summary record formattedaccording to the alternative standard,

display it in human readable format.(2) Electronically transmit. Enable a

user to electronically transmit a patientsummary record to other providers andorganizations including, at a minimum,diagnostic test results, problem list,medication list, and medication allergylist in accordance with:



(A) Problems. The standard specified

in § 170.207(a)(1) or, at a minimum, theversion of the standard specified in§ 170.207(a)(2);



(j) Calculate and submit clinicalquality measures—(1) Calculate (i)Electronically calculate all of the coreclinical measures specified by CMS foreligible professionals.

(ii) Electronically calculate, at aminimum, three clinical qualitymeasures specified by CMS for eligibleprofessionals, in addition to thoseclinical quality measures specified inparagraph (1)(i).

(2) Submission. Enable a user toelectronically submit calculated clinicalquality measures in accordance with thestandard and implementationspecifications specified in § 170.205(f).

§ 170.306 Specific certification criteria forComplete EHRs or EHR Modules designedfor an inpatient setting.

The Secretary adopts the followingcertification criteria for Complete EHRsor EHR Modules designed to be used in

an inpatient setting. Complete EHRs orEHR Modules must include thecapability to perform the followingfunctions electronically and inaccordance with all applicablestandards and implementationspecifications adopted in this part:

(a) Computerized provider orderentry. Enable a user to electronicallyrecord, store, retrieve, and modify, at aminimum, the following order types:


(b) Record demographics. Enable auser to electronically record, modify,and retrieve patient demographic dataincluding preferred language, gender,race, ethnicity, date of birth, and dateand preliminary cause of death in theevent of mortality. Enable race andethnicity to be recorded in accordancewith the standard specified at

§ 170.207(f).(c) Clinical decision support —(1)

Implement rules. Implement automated,electronic clinical decision supportrules (in addition to drug-drug anddrug-allergy contraindication checking)

based on the data elements included in:problem list; medication list;demographics; and laboratory testresults.

(2) Notifications. Automatically andelectronically generate and indicate inreal-time, notifications and caresuggestions based upon clinicaldecision support rules.

(d) Electronic copy of healthinformation. (1) Enable a user to createan electronic copy of a patient’s clinicalinformation, including, at a minimum,diagnostic test results, problem list,medication list, medication allergy list,and procedures:

(i) In human readable format; and(ii) On electronic media or through

some other electronic means inaccordance with:

(A) The standard (and applicableimplementation specifications)specified in § 170.205(a)(1) or§ 170.205(a)(2); and

(B) For the following data elements

the applicable standard must be used:(1) Problems. The standard specified

in §170.207(a)(1) or, at a minimum, theversion of the standard specified in§ 170.207(a)(2);

(2) Procedures. The standard specifiedin § 170.207(b)(1) or § 170.207(b)(2);

(3) Laboratory test results. At aminimum, the version of the standardspecified in §170.207(c); and

(4) Medications. The standardspecified in § 170.207(d).

(2) Enable a user to create anelectronic copy of a patient’s dischargesummary in human readable format and

on electronic media or through someother electronic means.(e) Electronic copy of discharge

instructions. Enable a user to create anelectronic copy of the dischargeinstructions for a patient, in humanreadable format, at the time of dischargeon electronic media or through someother electronic means.

(f) Exchange clinical information and patient summary record —(1)Electronically receive and display.Electronically receive and display apatient’s summary record from other


8/13/2019 2010-17210



providers and organizations including,at a minimum, diagnostic test results,problem list, medication list,medication allergy list, and proceduresin accordance with the standard (andapplicable implementationspecifications) specified in§ 170.205(a)(1) or § 170.205(a)(2). Uponreceipt of a patient summary record

formatted according to the alternativestandard, display it in human readableformat.

(2) Electronically transmit. Enable auser to electronically transmit apatient’s summary record to otherproviders and organizations including,at a minimum, diagnostic results,problem list, medication list,medication allergy list, and proceduresin accordance with:

(i) The standard (and applicableimplementation specifications)

specified in §170.205(a)(1) or§ 170.205(a)(2); and


(A) Problems. The standard specifiedin § 170.207(a)(1) or, at a minimum, theversion of the standard specified in§ 170.207(a)(2);

(B) Procedures. The standardspecified in § 170.207(b)(1) or§ 170.207(b)(2);

(C) Laboratory test results. At aminimum, the version of the standardspecified in §170.207(c); and

(D) Medications. The standardspecified in § 170.207(d).

(g) Reportable lab results.Electronically record, modify, retrieve,and submit reportable clinical labresults in accordance with the standard(and applicable implementationspecifications) specified in §170.205(c)

and, at a minimum, the version of thestandard specified in §170.207(c).

(h) Advance directives. Enable a userto electronically record whether apatient has an advance directive.

(i) Calculate and submit clinicalquality measures—(1) Calculate.Electronically calculate all of theclinical quality measures specified by

CMS for eligible hospitals and criticalaccess hospitals.

(2) Submission. Enable a user toelectronically submit calculated clinicalquality measures in accordance with thestandard and implementationspecifications specified in §170.205(f).

Dated: July 9, 2010.

Kathleen Sebelius,

Secretary.

[FR Doc. 2010–17210 Filed 7–12–10; 8:45 am]

BILLING CODE 4150–45–P