[RIN 0991-AB82] Table of Contents

Transcription

1 1 Summary of Final Rule Health Information Technology: Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology, 2014 Edition; Revisions to the Permanent Certification Program for Health Information Technology [RIN 0991-AB82] Table of Contents Subject Page I. Introduction 1 II. Definitions 2 III. New, Revised, and Unchanged Certification Criteria 6 IV. Permanent Certification Program for HIT 10 V. Additional Matters 12 VI. Regulatory Impact Analysis 13 Appendix A Clinical 2014 Edition EHR Certification Criteria 15 Appendix B Care Coordination 2014 Edition EHR Certification Criteria 22 Appendix C Clinical Quality Measures 2014 Edition EHR Certification Criteria 27 Appendix D Privacy and Security 2014 Edition EHR Certification Criteria 28 Appendix E Patient Engagement 2014 Edition EHR Certification Criteria 32 Appendix F Public Health 2014 Edition EHR Certification Criteria 36 Appendix G Utilization 2014 Edition EHR Certification Criteria 38 I. Introduction On September 4, 2012, the Office of the National Coordinator (ONC) for Health Information Technology (HIT) caused to have published in the Federal Register a final rule to revise the initial set of standards, implementation specifications, and certification criteria for electronic health record (EHR) technology previously adopted for Stage 1 meaningful use (MU) under the Medicare and Medicaid EHR Incentive Programs, and to adopt new standards, implementation specifications, and certification criteria, for Stages 1 and 2 MU beginning in fiscal or calendar year 2014 (FY/CY 2014), as the case may be. The final rule takes effect on October 4, Certification criteria adopted before this final rule is referred to as "2011 Edition EHR" and certification criteria adopted under this final rule is referred to as "2014 Edition EHR." The final rule indicates which certification criteria are new, revised, or unchanged and, where applicable, permits use of prior test results for certification to the 2014 Edition EHR under a gap certification process. The final rule redefines Certified EHR Technology (CEHRT) to consist of 1) Base EHR technology (the fundamental capabilities all eligible professionals (EPs), eligible hospitals (EHs), and critical access hospitals (CAHs) would require); 2) additional EHR technology required to meet the applicable stage of MU; and 3) capabilities to capture, calculate and report clinical

2 2 quality measures (CQMs). ONC permits EP, EHs, and CAHs to adopt and use EHR technology that meets the 2014 CEHRT definition to achieve MU before 2014; ONC believes this new dynamic CEHRT definition provides greater flexibility. ONC makes changes to the permanent certification program, which it believes will improve regulatory clarity and transparency, and reduce regulatory burdens and increase regulatory flexibility, as follows: 1. The process to adopt newer versions of minimum standard code sets is revised to afford industry flexibility in use those versions in a timelier manner. 2. ONC-Authorized Certification Bodies (ONC-ACBs) will follow a different process to certify EHR Modules and will provide clearer implementation direction and compliance for certification criteria. 3. EHR Modules need not be certified to privacy and security certification criteria. 4. ONC establishes a method for representing certified Complete EHRs and EHR Modules, including those that meet the definition of BASE EHR. 5. Test results used for certification must be made publicly available. 6. EHR technology developers must include in their marketing notice of additional types of costs purchasers would incur to implement the certified Complete EHRs and EHR Modules to meet MU objectives and measures. 7. The program is renamed the ONC HIT Certification Program. ONC estimates aggregate 3-year costs for EHR technology developers of roughly $195 million, the bulk of which is expected to be incurred in the first two years (2012 and 2013). The rule is highly technical and will be of special interest to EHR technology vendors and HIT experts. This summary includes appendices that contain tables showing the certification criteria for 2014 Edition EHR and related observations. II. Definitions Certified EHR Technology (CEHRT) ONC finalizes its proposal to redefine CEHRT by allowing the selection of CEHRT based on requirements to demonstrate MU without buying EHR technology they might not otherwise choose in order to demonstrate MU. Thus for fiscal year or calendar year 2014, as the case may be (FY/CY 2014), CEHRT means EHR technology certified under the ONC HIT Certification Program to the 2014 Edition EHR criteria that: 1) has capabilities required as part of a Base EHR (defined below) and 2) includes capabilities to meet the MU objectives and measures that EPs, EHs, and CAHs seek to achieve (but would generally exclude technology for which an exclusion to an objective would apply or under which a MU menu set could be deferred). This can be met by one or any combination of the following: a Complete EHR, a single certified EHR module, or a combination of separately certified EHR modules. ONC emphasizes for FY/CY 2014 and subsequent years, EPs, EHs, and CAHs must have Base EHR technology notwithstanding a possible exclusion from a MU objective and measure; for example, were an EP able to claim an exclusion for computerized provider order entry (CPOE), the EP would nonetheless be required to have the technology because CPOE is included in the definition of Base EHR. For periods before FY/CY 2014, the EHR technology may be certified to the 2011 Edition EHR or to the

3 3 equivalent 2014 Edition, equivalent meaning capabilities at least equal to those previously adopted under the 2011 Edition EHR certification criteria. Commenters were generally supportive of the revised definition but were concerned about the timing of the requirements, noting that more time was required for developing, testing and certification as well as subsequent implementation by EPs, EHs, and CAHs. ONC believes there will be adequate time for providers to adopt and implement EHR technology that meets the new definition, and notes that CMS has adopted "three-month quarter EHR reporting periods" in FY/CY ONC rejects a number of alternative implementation policies suggested by commenters, but does adopt a suggestion to permit EPs, EHs, and CAHs to use for EHR reporting periods in FY/CY 2012 and 2013 technology that satisfies the CEHRT definition applicable in FY/CY 2014 and subsequent years. ONC believes that any misalignment issues relating to clinical quality measures (CQMs) (i.e., providers who want to use 2014 Edition would still need the 2011 Edition to calculate CQMs for EHR reporting periods in 2013) are resolved by a CMS-developed policy to accommodate this situation. Table 4 in the rule contains a crosswalk between equivalent 2011 Edition and 2014 Edition EHR. The revised CEHRT definition would apply regardless of the MU Stage of an EP, EH, or CAH, as demonstrated in Table 5 of the rule and reproduced below. Table 5: Revised Definition of CEHRT EHR Reporting Periods FY/CY 2011 FY/CY 2012 FY/CY 2013 FY/CY2014 MU Stage 1 MU Stage 1 MU Stage 1 MU Stage 1 or MU Stage 2 All EPs, EHs, and CAHs must have: 1) EHR technology that has been certified to all applicable 2011 Edition EHR certification criteria or equivalent 2014 Edition EHR certification criteria adopted by the Secretary; or 2) EHR technology that has been certified to the 2014 Edition EHR certification criteria that meets the Base EHR definition and would support the objectives, measures, and their ability to successfully report CQMs, for MU Stage 1. All EPs, EHs, and CAHs must have EHR technology certified to the 2014 Edition EHR certification criteria that meets the Base EHR definition and would support the objectives, measures, and their ability to successfully report the CQMs, for the MU stage that they seek to achieve. Commenters raised questions about the ONC possession policy as it applies to the revised definition of CEHRT. Before the revised CEHRT definition, a provider would need to possess technology certified to all relevant mandatory criteria (ambulatory setting for EPs and inpatient setting for EHs and CAHs). The revised definition of CEHRT applicable on or after FY/CY 2014 limits the potential quantity of EHR technology required to be possessed (i.e., only the technology that supports Base EHR, objectives and measures, and ability to submit CQMs for the applicable MU stage). What confuses commenters is the treatment in FY/CY 2013 of EPs, EHs, and CAHs who purchase EHR technology that meets the FY/CY 2014 revised definition of CERHT. ONC responds that EPs, EHs, and CAHs must continue to possess all of a certified Complete EHR or certified EHR Module (i.e., the capabilities for which certification is required) to receive the benefit of the certification; possession of only components of a certified Complete EHR or certified EHR Module may not be used to satisfy the definition. ONC notes that the possession policy applies only with respect to capabilities in EHR technology for which certification is required.

4 4 Base EHR ONC substitutes the term "Base EHR" for "Qualified EHR" and defines it as an electronic record of health information on an individual that should be part of any CEHRT for demonstration of MU and that meets the certification criteria indicated in Table 6 of the rule with respect to the following: Includes patient demographic and clinical health information, such as medical history and problem lists; Capacity to provide clinical decision support; Capacity to support physician order entry; Capacity to capture and query information relevant to health care quality; Capacity to exchange electronic health information with, and integrate such information from other sources; and Capacity to protect the confidentiality, integrity, and availability of health information stored and exchanged. Base EHR may be satisfied through one or any combination of the following: 1) a Complete EHR, 2) a single certified EHR Module, or 3) a combination of separately certified EHR Modules. In response to comments, ONC removes three certification criteria from the definition of Base EHR (drug-drug, drug allergy interaction check; vital signs; and view, download, and transmit to a 3 rd party), and adds an initial data portability certification criterion. The abilities to capture, calculate and electronically submit CQMs to CMS ( (c)(1) through (c)(3)) are included in the Base EHR definition. This must include certification to no fewer than the minimum of CQMs an EP, EH or CAH must report under the MU Incentive programs beginning in FY/CY For EPs to meet the definition of Base EHR technology, they must have technology certified to (c)(1) and (c)(2) for no fewer than 9 CQMs covering at least 3 domains and include at least 6 CQMs from the "recommended core," as identified in the CMS Stage 2 final rule. For EHs and CAHs to meet that definition, they must have technology certified to (c)(1) and (c)(2) for no fewer than 16 CQMs covering at least 3 domains as identified in the CMS Stage 2 final rule. ONC declines to either require technology to be certified to all CQMs selected by CMS for the EHR Incentive Programs or to establish a list of required CQMs by practice specialty. ONC finalizes its proposal to add privacy and security capabilities to the definition of Base EHR and therefore what must be included in any CEHRT for the 2014 Edition EHR, and to make certification for these capabilities consistent across the ambulatory and inpatient settings. In response to a comment, ONC continues to believe that "integration certification" is not appropriate for the ONC HIT Certification Program at this time, even if only applied in the context of privacy and security capabilities. Complete EHRs and EHR Modules

5 5 Due to its revisions to the definition of Base EHR, ONC revises its proposed definition of Complete EHR and establishes two separate Complete EHR definitions for 2011 and 2014 EHR editions. For 2014 Edition EHR, a Complete EHR must have the capabilities to meet the Base EHR definitions and all other capabilities required to meet the applicable MU objectives and measures, as well as successfully report CQMs selected by CMS for the MU stage the EP, EH, or CAH seeks to achieve. ONC clarifies this may be setting-specific and must meet, at a minimum, all mandatory certification criteria applicable to that setting. For years before FY/CY 2014, ONC adds to the definition that would otherwise apply to CEHRT for 2011 Edition EHR (i.e., technology required by the definition of a "Qualified EHR") technology that satisfies the equivalent 2014 Edition EHR certification criteria. ONC clarifies that while equivalency permits EPs, EHs, and CAHs to use a combination of EHR technology certified to both 2011 and 2014 Edition EHR criteria, a certification cannot be issued for a Complete EHR based on such a combination. With the support of some commenters, ONC rejects requests from developers that they be permitted to sell any component of a Complete EHR or EHR Module and still refer to it as CEHRT, indicating that EPs, EHs, and CAHs require the confidence that certification is assigned to the Complete EHR or EHR Module, rather than to one or more capabilities. ONC believes that allowing separate components to derive certified status would undermine the ONC HIT Certification Program. ONC encourages technology developers to seek certification for separate components of their Complete EHRs or EHR Modules, where possible. ONC permits adaptations (meaning software designed to run on a different medium) of certified Complete EHRs or EHR Modules without additional certification requirements if the full and exact same capabilities exist in the adapted version (i.e., "the technology must include the full and exact same capabilities required by the certification criteria to which the EHR technology it is serving as an adaptation of was certified"). While adaptations may require user interface and other design feature changes, ONC focuses on the requirement that the capabilities in the adaptation are a "one-for-one match" with the capabilities adapted from the Complete EHR or EHR Module, which may be less than the overall capabilities in that Complete EHR or EHR Module. Users would have to assure themselves that the adaptation does not present privacy or security concerns (perhaps through contractual assurances), and ONC expects developers would include the relevant privacy and security capabilities in the adaptations. ONC emphasizes that developers would not need additional certification for an adaptation nor have to attest to the functionality, capabilities, or otherwise for the adaptation, but adaptations must conform to the certification provisions issued for the Complete EHR or EHR Module. ONC cautions that an adaptation would not be independently listed on the Certified HIT Products List (CHPL) unless the developer seeks a separate certification for it; thus, as part of the attestation process, an EP, EH, or CAH would have to select the certified Complete EHR or EHR Module from which the adaptation was created. Terms Used in Certification Criteria ONC finalizes its proposals to clarify certain terminology and substitute new terminology for several terms previously used in certification criteria to clarify intent and use plain language where possible as follows. ONC only modifies the term incorporate from its proposed definition:

6 6 User does not mean patient. Record means ability to capture and store information in EHR technology. Change means ability to alter/edit information previously recorded in EHR technology; a change must be retained and viewable; substitutes change for modify. Access means ability to examine or review information in or through EHR technology; substitutes access for retrieve ; does not necessarily include capability to obtain/transfer data from an external source. Incorporate means to electronically process structured information from another source such that it is combined (in structured form) with information maintained by EHR technology and is subsequently available for use within the EHR technology by a user. Create means to produce or generate information electronically. Transmit means to send from one point to another. In response to comments, ONC creates the term Common MU Data Set to refer to the same data types and elements for which certification is required in multiple certification criteria as reflected in Table 2 of the preamble and reproduced below. Having done this, ONC declines to separately define a Summary Care Record. Table 2. Common MU Data Set 1. Patient name 2. Sex 3. Date of birth 4. Race 5. Ethnicity 6. Preferred language 7. Smoking status 8. Problems 9. Medications 10. Medication allergies 11. Laboratory test(s) 12. Laboratory value(s)/result(s) 13. Vital signs (height, weight, BP, BMI) 14. Care plan field(s), including goals and instructions 15. Procedures 16. Care team members III. New, Revised, and Unchanged Certification Criteria The appendices to this summary contain tables showing the final certification criteria for 2014 Edition EHR in the order listed under the regulatory text (which differs from the order in which the certification criteria are addressed in the preamble) and provides a column for other information and commentary relevant to each of the certification criteria. ONC clarifies that this final rule, and the certification criteria adopted under the final rule, apply only to EHR technology and not to the use of that technology in order to demonstrate or achieve meaningful use. Thus, ONC states that this rule speaks only to the technical capabilities that EHR technology must possess, and other requirements that must be met, for that technology to be certified. New certification criteria are criteria that: 1) only specify capabilities that have never been included in previously adopted certification criteria; or 2) were previously adopted as mandatory for a particular setting that are subsequently adopted as mandatory or optional capability for a different setting.

7 7 Revised criteria from previously adopted certification criteria are criteria that: 1) include changes to capabilities previously specified; 2) have a new mandatory capability not previously included; or 3) were previously adopted as an optional capability for a particular setting that is subsequently adopted as mandatory for that setting. ONC notes that, under certain circumstances, certification criteria could be both new and revised. In the final rule, ONC includes in this category certain certification criteria that were proposed as unchanged. Unchanged criteria from previously adopted certification criteria are criteria that: 1) include only the same capabilities as previously specified; 2) have capabilities that apply to the same setting; and 3) remain mandatory or are redesignated optional for the same setting. ONC clarifies that merged capabilities from multiple previously adopted certification criteria, or fewer capabilities from previously adopted criteria, constitute unchanged criteria if the capabilities remain the same. All certification criteria and all capabilities within a certification criterion apply to both ambulatory and inpatient settings unless otherwise indicated. Complete EHRs and EHR Modules are not required to be compliant with certification criteria, or capabilities listed therein, that are designated as optional. Where a certification criterion refers to alternative standards, use of only one alternative is required to satisfy the criterion. Quality Systems and Patient Safety Events ONC had intended to publish a quality management document for inclusion in the rule which would be customized for EHR technology development to provide specific guidance to EHR technology developers on best practices in software design processes and would include new documentation requirements for EHR technology developers to describe how their development processes either align with, or deviate from, the quality management principles and processes in the ONC quality management document. ONC also considered adding these documentation requirements as a new certification criterion. ONC did not publish the document in time for public comment, but with the encouragement of commenters it adopts a new certification criterion for all EHR technology (including EHR Modules) certified to the 2014 Edition EHR certification criteria. For each capability that an EHR technology includes and for which that capability's certification is sought, the developer must identify a Quality Management System (QMS) used in the development, testing, implementation and maintenance of that capability. This requirement is a change from the ONC proposal and is intended to provide great flexibility to developers, even to the extent that where a developer did not use a QMS for a capability, simply noting that fact still satisfies the criterion for that capability. ONC reiterates its policy goals: to increase familiarity with quality management processes; to increase transparency for purchasers and other stakeholders; and to set a foundation for more rigorous future certification criteria for quality management processes. ONC does not believe the requirement will add any significant burden on developers. ONC had also considered requiring EHR technology to enable a user to generate files with data required by the Agency for Healthcare Research and Quality (AHRQ) Common Format as a first

8 8 step to reporting potential adverse events to patient safety organizations. Commenters did not believe the AHRQ Common Format was sufficiently mature for use at this time, and ONC does not adopt a certification criterion for the 2014 Edition EHR certification criteria. Further detail on both these certification criteria is displayed in the table contained in Appendix G to this summary. Clinical Quality Measures (CQMs) The HIT Standards Committee (HITSC) recommended certain vocabularies and code sets for inclusion in the Quality Data Model (QDM) 33, but did not recommend CQM certification criteria or offer recommendations for the certification of CQMs. For the 2014 Edition EHR certification criteria, ONC revises previously adopted CQM certification criteria at paragraphs (1), (2), and (3) of (c) for both ambulatory and inpatient settings by focusing on four factors: 1. Data capture the capability of EHR technology to electronically record the data that would be required in order to calculate CQMs; 2. Data Export the capability of EHR technology to export a data file that includes all data captured for CQMs; 3. Import and Calculate the capability of EHR technology to electronically import a data file and correctly calculate the result for CQMs; and 4. Electronic Submission the capability of EHR technology to create a data file for transmission of CQM data that can be electronically accepted by CMS. Data Capture ONC agrees with commenters that capture of the entirety of the QDM is not appropriate as a requirement for certification, and observes that it does not know of any systematic constraints on the QDM that meet its needs of certification for 2014 Edition EHR. ONC is hopeful that future versions of the QDM may provide guidance which ONC would incorporate in subsequent rulemaking. ONC encourages developers to offer the broadest range of measures for certification to meet EP, EH and CAH needs for the EHR Incentive Programs, but notes it may mandate more expansive requirements if developers' products do not satisfy provider needs. With strong support from commenters, ONC adopts the CQM-by-CQM Data Capture option; thus EHR technology for CQM capture must be able to capture the data elements specified in the Data Element Catalog required for each and every CQM for which the technology seeks certification. The Data Element Catalog (adopted at (c)) includes supplemental data elements required for CQM data submission to CMS which will be required for capture and transmission in each and every CQM report. ONC clarifies that this criterion does not require demonstration of manual data entry through a user interface; instead, the technology must capture the information in some manner, including from other systems (e.g., practice management systems). ONC reiterates that 2014 Edition EHR will require that all data elements of CQMs be captured as structured data, which is not required under 2011 Edition EHR.

9 9 With respect to CQM exclusions, ONC agrees with comments indicating that all data elements needed for CQM calculation should be discrete and codified. ONC believes where granular level data is available in coded form, it should be employed, but it does not require exclusions and exceptions to be captured to the granular level of detail described by a CQM that is developed for manual chart abstraction. ONC does not require free text submissions, but permits its capture and availability as a supplement to a codified entry. ONC permits codified entries to include CQM-specific defined terms as well as more general concepts: "patient reason," "system reason," and "medical reason." ONC does not require linking CQM and clinical decision support (CDS) for 2014 Edition EHR, but does see the value of that link and encourages developers to incorporate CDS for the clinical areas of their CQMs. Data Export ONC requires that all EHR technology be capable of not only capturing data for CQMs but also of exporting the data, especially in the case of an EP, EH, or CAH electing to use another certified EHR Module to perform the calculation of CQM results. ONC belies this preserves portability and flexibility for providers, affording providers options of using regional or national CQM calculation and/or reporting solutions. ONC adopts QRDA Category I as the standard for the export functionality as it has been balloted through HL7 and has been accepted by CMS as an form of quality data reporting; ONC disagrees with commenters who believe the criterion or standard format provides little value added. Import and Calculate Commenters expressed dissatisfaction with products certified under the temporary certification program due to light testing requirements and the absence of any testing of the accuracy of embedded measures. ONC finalizes a more specific certification requirement that EHR technology be able to import QRDA Category I files that have been generated by the data export capability described above, and notes that EHR technology with be tested and certified for this capability. Where EHR technology is presented for testing to all three CQM certification criteria, a separate capability to "import" will not be assessed because the CQM capabilities within the technology are in essence self-contained; however, all other capabilities required under those criteria will be tested. ONC also substitutes the term import for the proposed term incorporate for greater clarity. Many comments focused on selection, content, and management of CQMs which ONC finds are beyond the scope of this rule; ONC also notes that CMS is the agency responsible for reliability and validity testing for the technical specifications of CQMs. Electronic Submission Referred to as reporting in the proposed rule, ONC adopts for this criterion both the HL7 QRDA Category I standard (for patient level data submissions) and HL7 QRDA Category III (for aggregate data level submissions) to accommodate CMS specifications in its Stage 2 MU final rule for XML data file formats to accept electronic submissions of aggregate- and patient-level data reporting. While ONC agrees that the timing of the HL7 QRDA Category III balloting is "suboptimal," it believes that its use is preferable given the alternative of waiting for CMS to develop an XML data file template which would largely duplicate the QRDA Category III

10 10 standard. EHR technology, regardless of setting, must be certified to create results for transmission to CMS according to both standards. ONC notes the criterion has been clarified to indicate that CMS must be able to receive (i.e., electronically accept) an electronic data file created by EHR technology and submitted by an EP, EH, or CAH. Gap Certification A certification criteria-specific analysis of a Complete EHR or EHR Module previously certified to the 2011 Edition EHR must be conducted to determine whether new testing is required for certification to the 2014 EHR Edition under the gap certification process. For those criteria identified by ONC as unchanged, test results for certification for the 2011 Edition EHR may be used for certification to the 2014 Edition EHR. However, for each new or revised criterion for the 2014 Edition EHR, ONC requires test results from an NVLAP-accredited testing laboratory. The analysis must examine more than change in capabilities because changes in standards or implementation specifications for the 2014 Edition EHR would also require new testing for a certification criterion. For example, ONC updates versions of certain vocabulary standards in the final rule: 1) For SNOMED CT, the July 2012 International Release and the March 2012 U.S. Extension; 2) For LOINC, Version 2.40; 3) For RxNorm, the August 2012 version; and 4) For CVX code sets, the July 11, 2012 updated version. In response to a comment, ONC clarifies that a previously certified Complete EHR or EHR Module does not need to maintain the same scope of certification (i.e., be certified only to the corresponding 2014 Edition EHR certification criteria) to be gap certified. ONC intends to furnish additional guidance to ensure consistent implementation of gap certification by ONC- ACBs. Table 3 of the final rule provides a crosswalk of unchanged 2014 Edition EHR certification criteria to the corresponding criteria under the 2011 Edition EHR. The table does not include those certification criteria that were proposed as unchanged but were revised for the final rule (e.g., drug-formulary checks at (a)(10), etc.). ONC also identifies those criteria that were not adopted for the 2014 Edition EHR. IV. Permanent Certification Program for HIT ONC renames the permanent certification program the ONC HIT Certification Program. Due to the frequency of newer versions (meaning final or release versions) of minimum standard code sets, ONC modifies the procedure for their adoption. ONC establishes a new process which is essentially default approval by the Secretary of the newer version unless the Secretary prohibits its use. Thus the newer version could be used voluntarily by developers for certification and be implemented as an upgrade to a previously certified Complete EHR or EHR Module Based without affecting certification status, though developers still have the option of certifying their technology to the standard specified in regulations. In order to prohibit a newer version, ONC would use its current process which involves identification of the newer version, an HITSC recommendation, public input, the recommendation of the National Coordinator, approval by the Secretary, and guidance issued by the ONC. Under certain circumstances, for example where a newer version has an immediate negative effect on interoperability, expedited

11 11 review would be available without seeking HITSC recommendation. ONC-ACBs would not be required to certify Complete EHRs and EHR Modules according to newer versions until publication of the updated standard in the Federal Register. For certification of EHR Modules to the 2014 Edition EHR certification criteria, because the definition of Base EHR requires all mandatory privacy and security certification criteria, EHR Modules are not required to meet the privacy and security certification criteria adopted at (d). ONC again reminds EPs, EHs and CAHs that they must implement their EHR technology in conformance with applicable federal and state law, such as the HIPAA Privacy Rule, and cautions them to carefully evaluate whether implementation of an additional separate EHR Module poses new risks to privacy and security. ONC intends to monitor these requirements for possible changes in future rulemaking. ONC also requires that EHR Modules presented for certification for capabilities supporting a MU objective with a percentage-based measure be certified to the relevant utilization certification criteria of (g), including the newly added quality management system certification criteria at (g)(4). For each Complete EHR and EHR Module that is certified, ONC-ACBs must include a hyperlink for the public to use to access the test results used to certify the technology. The hyperlink will be available on the CHPL and will be functional for at least 5 years, unless the technology is removed from the CHPL. Commenters generally supported this requirement though some expressed concerns about the public availability of source codes or copyrighted materials. ONC will require public access to the test results but will instruct ONC-ACBs to exclude certain information, such as source codes, screenshots, and negative test results. With respect to representing the status of a Complete EHR or EHR Module as certified compliant, ONC finalizes its proposal to refer to the edition year (i.e., 2014 Edition EHR compliant) rather than referring to specific years (i.e., 2011/2012 compliant). For technologies currently designated 2011/2012 compliant, in lieu of requiring redesignation to 2011 Edition EHR compliant, ONC permits the continued use of the current designation for EHR reporting periods beginning in fiscal or calendar year ONC also makes a technical change to the language of the certification disclaimer to drop any reference to incentive payments as those payments end in 2016 under the Medicare EHR Incentive Program. In the case of an updated certification to a previously certified EHR Module, ONC finalizes its proposal to eliminate the requirement that no new privacy and security certification criteria applicable to the EHR Module are adopted. Thus an updated certification is permitted if the certification criteria have not been revised. However, ONC specifies that updating an EHR Module's certification to the 2014 Edition EHR is not available. With respect to identifying Complete EHR or EHR Module or Modules as Base EHR, ONC does not require developers to identify their CEHRT as Base EHR, believing that competition in the marketplace would lead to the same result. ONC prefers that the CHPL website have a function to identify whether EHR Modules selected from the CHPL meet the definition of Base EHR.

12 12 V. Additional Matters ONC requested comment in the proposed rule on whether it should require, as part of the 2014 Edition EHR, the capability to record disability status (including functional, behavioral, and cognitive status) of patients; whether there are existing appropriate standards for recording disability status (such as the CARE assessment tool); and if adopted, whether certification criteria should be mandatory or optional and whether it should be included in other certification criteria, such as transitions of care. Commenters supported the concept but did not express consensus on basic issues, such as a single definition for disability or the standard for recording or transmitting disability status. Other commenters raised legal concerns over potential impacts of erroneous application of disability status to a patient record for purposes of benefit determinations, entitlement to protected class, etc. ONC is undaunted and will seek further stakeholder input to identify a specific standard to record a patient's disability. ONC agrees to consider disability in terms of functional and cognitive status (at a minimum), and finds Consolidated CDA as a start. Because the transitions of care criteria require use of Consolidated CDA, ONC requires that EHR technology be capable of including patient data on functional and cognitive status to align this information for inclusion by CMS in the transition of care/referrals in the Stage 2 final rule. ONC sought comment on the feasibility and value of requiring EHR developers to disclose the full cost of a certified Complete EHR or EHR Module (i.e., a single price for all the capabilities of the technology) on their websites and in all marketing materials etc., to increase clear price transparency. Comments varied but many focused on the concept of full cost and how that is evaluated; for example, under a total ownership cost concept, costs would also include implementation costs, customization, training, and maintenance. Concern was also expressed about the potential to hinder innovation, product development, pricing, and market strategies, as well as competition. Nonetheless, ONC finalizes an approach under (k)(1)(iii) under which developers must notify EPs, EHs, and CAHs of additional types of costs (not the actual dollar amounts) that they would pay to implement capabilities a certified Complete EHR or EHR Module's includes to achieve MU objectives and measures. These are costs above the purchase price to acquire or upgrade EHR technology capabilities, such as monthly service fees or onetime or ongoing interface development and configuration fees. ONC notes that developers can meet the requirement by disclosing both the type of additional cost and to what the cost is attributed. This requirement does not apply to EHR technology self-developers (i.e. those developers who are not commercial vendors) as they do not market or sell their technology. ONC also sought comment on whether it should adopt certification criteria for other health care settings, such as long-term care, post-acute care, and mental and behavioral health settings. While commenters generally support certification for other settings, they noted the lack of financial incentives was a major barrier and that the private sector has established voluntary certification programs for these settings which provide for greater flexibility. Commenters instead suggested that ONC support interoperability and secure electronic exchange of health information across all settings.

13 13 VI. Regulatory Impact Analysis ONC received no comments on its burden estimate for the new information collection requirement on ONC-ACBs to report test results hyperlinks for each EHR technology they certify. Thus ONC repeats its assumption that all 6 applicants will become ONC-ACBs and that each will report 4 hyperlinks per week at 5 minutes per hyperlink for an aggregate 103 annual additional burden hours, resulting in an increase of the total annual burden hours to 435. ONC rejects comments indicating that it failed to account for costs of public health agencies and of EPs, EHs, and CAHs in meeting the meeting the final rule requirements as outside the scope of the rule. ONC finds that the rule is not economically significant because it estimates that costs to prepare Complete EHRs and EHR Modules for testing and certification will be less than $100 million per year. The ONC analysis focuses on the technological and preparation costs of EHR Technology developers to upgrade previously certified, or develop new, Complete EHRs and EHR Modules for testing and certification. Taking into account the revised definition of CEHRT (which permits providers to select only the certification criteria that support MU objectives and measures for the stage they seek to accomplish) and other factors, ONC estimates that a range of 10 percent fewer and 10 percent more EHR technologies will be developed to each 2014 Edition EHR certification criteria. In table 14 of the final rule, ONC estimates overall costs for the threeyear period beginning with 2012 at a range from $ million to $ million (a slight increase from the proposed rule estimate), and believes that, due to market pressure, the vast majority of costs will be incurred before Table 14. Distributed Total Development and Preparation Costs (in Millions) for Complete EHR and EHR Module Developers (3 year period) Totals Rounded Year Ratio Total Low Cost Estimate Total High Cost Estimate Total Average Cost Estimate % $45.85 $ $ % $45.85 $ $ % $10.20 $28.90 $ Year Totals $ $ $ Assuming $60 per hour for a software developer (and relying to some degree on its own research), ONC identifies 3 levels of effort for development and preparation to meet 2014 Edition EHR certification criteria (level 1: hours, level 2: hours, and level 3: hours) and calculates estimated costs by each category of certification criterion (i.e., new, revised and unchanged) in tables 7 through 13 of the final rule. The estimated cost (unchanged from the proposed rule) for an ONC-ACB to report test results hyperlinks for each EHR technology it certifies is $ annually, based on annual burden hours for a GS-9 Step-1 employee equivalent, resulting in annual aggregate costs for all ONC-ACBs of $3,136 to comply with the new requirement. ONC does not believe the federal government will incur additional costs to post test result hyperlinks. ONC believes the rule would occasion many benefits, especially improvements in interoperability, functionality, utility and security of EHR technology which should improve patient care and reduce medical errors and unnecessary medical tests. ONC also finds that its

14 14 revised definition of CEHRT, its process to approve newer versions of minimum standards, and its approach to privacy and security certification will reduce regulatory burden and improve flexibility for developers and EPs, EHs, and CAHs. ONC has difficulty calculating the number of developers who might qualify as small businesses for purposes of the Regulatory Flexibility Act because it is unclear how many of those entities will actually develop a Complete EHR or EHR Module, but notes that more than 60 percent of EHR developers that have Complete EHRs or EHR Modules certified to 2011 Edition EHR have fewer than 51 employees. ONC believes the final rule results in the minimum amount of requirements to accomplish its policy goals and also believes there are no alternatives that would lessen the burden. Further, ONC notes that the costs estimated are investment rather than compliance costs, and thus believes the rule will not significantly impact a substantial number of small businesses. Finally, ONC observes that the rule does not raise Federalism issues or issues under the Unfunded Mandates Act of 1995.

15 15 Appendix A Clinical 2014 Edition EHR Certification Criteria CLINICAL A Complete EHR or EHR Module must include the capability to: (a) Clinical (1) COMPUTERIZED PROVIDER ORDER ENTRY (CPOE) Enable a user to electronically record, change, and access the following order types, at a minimum: (i) Medications, (ii) Laboratory, and (iii) Radiology/imaging. (2) DRUG-DRUG, DRUG-ALLERGY INTERACTION CHECKS (i) INTERVENTIONS. Before a medication order is completed and acted upon during CPOE, interventions must automatically and electronically indicate to a user drug-drug and drug-allergy contraindications based on a patient's medication list and medication allergy list. (ii) ADJUSTMENTS. (A) Enable the severity level of interventions provided for drug-drug interaction checks to be adjusted. (B) Limit the ability to adjust severity levels to an identified set of users or available as a system administrative function. Base EHR Tech Requirement. Unchanged certification criterion for both settings (with refinements) which ONC adopts as proposed. Commenters sought clarification of the denominator (e.g., clarifying which orders count), of what providers may enter the orders, and how current MU EHR users should report measures when transitioning to 2014 Edition EHR. ONC declines to respond to any of these queries, indicating that those are matters for CMS. ONC does note that the change in the CPOE denominator affects the automated measure calculation criterion (see (g)(2)) which was revised for the 2014 Edition. No transport standard is required as the criterion does not require transmission. ONC declines to separate radiology orders into a separate criterion, notwithstanding any applicable enhanced clinical functionality. Revised certification criterion for both settings. ONC removes this criterion from the definition of Base EHR. ONC adopts commenters' recommendation to substitute the language "order completed and acted upon" in lieu of "order placed" to highlight the real-time nature of the interaction as well as clarifying that the provider must see the interaction and be able to act on it. ONC specifies the medication list and medication allergy list must be patient specific. ONC removes user ability to adjust drug-allergy interaction checks, notwithstanding commenter concerns with alert fatigue and other concerns. ONC clarifies that 1) adjustments apply to level of severity notifications, and that health care providers are able to reduce the frequency of/thresholds for certain interventions under (a)(2)(ii)(A); and 2) "identified set of users" to adjust severity levels is limited to those assigned; who those individuals are (e.g., a systems administrator, physician) is not addressed under the criterion. ONC does not require use of HL7 "Infobutton" standard, and it encourages developers to provide access to FDA Drug Safety Alerts (see also the clinical decision support certification criterion).

16 16 CLINICAL (3) DEMOGRAPHICS (i) Enable a user to electronically record, change, and access patient demographic data including preferred language, sex, race, ethnicity, and date of birth. (A) Enable race and ethnicity to be recorded in accordance with the OMB race and ethnicity vocabulary standard, specified in (f), and whether a patient declines to specify race and/or ethnicity. (B) Enable preferred language to be recorded in accordance with the ISO alpha-3 codes vocabulary standard, specified in (g), and whether a patient declines to specify a preferred language. (ii) Inpatient setting only. Enable a user to electronically record, change, and access preliminary cause of death in the event of a mortality. (4) VITAL SIGNS, BODY MASS INDEX, AND GROWTH CHARTS (i) VITAL SIGNS. Enable a user to electronically record, change and access, at a minimum, a patient s height/length, weight, and blood pressure. Height/length, weight, and blood pressure must be recorded in numerical values only. (ii) CALCULATE BODY MASS INDEX. Automatically calculate and electronically display body mass index based on a patient s height and weight. (iii) Optional: PLOT AND DISPLAY GROWTH CHARTS. Plot and electronically display, upon request, growth charts for patients. (5) PROBLEM LIST Enable a user to electronically record, change, and access a patient s problem list: (i) Ambulatory setting only: Over multiple encounters in accordance with, at a minimum, the version of the IHTSDO SNOMED CT vocabulary standard, Base EHR Tech Requirement. Revised certification criterion for both settings. Per the HITSC clarification, ONC adopts the preferred language standard ISO but limited to active languages included in ISO ONC adopts the OMB standard for Race and Ethnicity Revisions to the Standards for the Classification of Federal Data on Race and Ethnicity issued 10/30/97, believing it to be a more appropriate standard than alternatives proposed by commenters. ONC notes that the technology must provide the option for one or more racial designations, and must be capable of aggregating/mapping more granular race and/or ethnicity data to the minimum race and ethnicity categories if a developer uses this approach. As CMS does for Stage 2 MU, ONC substitutes the term sex (physiological characteristics at time of birth) for the proposed term gender. ONC does not require the capability to record gender identity or sexual orientation. ONC agrees with comments and drops the requirement that preliminary cause of death be recorded according to a specific standard, and allows free text entry. Unchanged certification criterion for both settings with refinements. ONC removes this criterion from the definition of Base EHR. ONC declines to require that the technology natively record vital signs in specific vocabularies believing that to be too burdensome; however, ONC intends to require for the next Edition EHR that the technology be able to record all vital signs to standardized terminologies. ONC explicitly requires that the height/length, weight, and blood pressure (BP) data be recorded only in numeric values (precluding entries such as "lbs"). Other attributes (e.g., arm used for BP) should be specified in supplemental fields. ONC does not believe this refinement will cause any significant burden. ONC continues to believe that "plot and display growth charts" should be made optional; ONC excludes an age range requirement. Base EHR Tech Requirement. Revised certification criterion for both settings. ONC agrees with commenters who indicated that use of the term "longitudinal care" in this context causes confusion, and it substitutes in the regulation text more useful descriptions ("over multiple encounters" and "for the duration of an entire hospitalization") rather than another term.

17 17 CLINICAL specified in (a)(3); or (ii) Inpatient setting only: For the duration of an entire hospitalization in accordance with, at a minimum, the version of the IHTSDO SNOMED CT vocabulary standard, specified in (a)(3). (6) MEDICATION LIST Enable a user to electronically record, change, and access a patient s active medication list as well as medication history: (i) Ambulatory setting. Over multiple encounters; or (ii) Inpatient setting. For the duration of an entire hospitalization. (7) MEDICATION ALLERGY LIST Enable a user to electronically record, change, and access a patient s active medication allergy list as well as medication allergy: (i) Ambulatory setting. Over multiple encounters; or (ii) Inpatient setting. For the duration of an entire hospitalization. (8) CLINICAL DECISION SUPPORT (i) EVIDENCE-BASED DECISION SUPPORT INTERVENTIONS. Enable a limited set of identified users to select (i.e., activate) one or more electronic clinical ONC adopts the IHTSDO SNOMED CT, International Release July 2012 and US Extension to SNOMED CT March 2012 Release. ONC notes that interface terms, local terms or other terms may be displayed in lieu of SNOMED CT to find, select, or view a problem list, but the technology must be able to record the semantic representation of the list in SNOMED CT because this is a MU requirement. Commenters indicating that few hospitals use SNOMED CT get no relief from ONC; rather ONC seems to view this requirement as moving all EPs, EHs, and CAHs to this standard. ONC notes that the National Library of Medicine is developing mapping tools from SNOMED CT to ICD-10-CM. ONC again notes that the requirement does not preclude ICD-10-CM use for capture/transmission of encounter billing diagnoses. Base EHR Tech Requirement. Proposed as Unchanged certification criterion for both settings (without refinements); ONC adopts it with regulatory text changes to clarify the meaning of the term "longitudinal care" in this context. ONC agrees with comments that the term is confusing, and it substitutes in the regulation text more useful descriptions ("over multiple encounters" and "for the duration of an entire hospitalization"). ONC requires both use of RxNorm where EHR technology is used to perform external transmissions (e.g., for transitions of care) and the capability to reconcile a patient's medication list as part of the "clinical information reconciliation" criteria. Thus, ONC reasons that it is not necessary to require that the technology natively record medications directly into RxNorm. Base EHR Tech Requirement. Unchanged certification criterion for both settings (without refinements); ONC adopts it with the same regulatory text change for longitudinal care (and for the same rationale) as it does for the adopted certification criteria medication list and problem list. ONC declines to expand the criterion to include additional allergens as those capabilities would be beyond MU requirements. It also declines, as it did for the medication list criterion, to require the technology to natively record medications directly into RxNorm. Base EHR Tech Requirement. Revised certification criterion for both settings. ONC substitutes the term clinical decision support intervention for clinical

18 18 CLINICAL decision support interventions (in addition to drug-drug and drug-allergy contraindication checking) based on the data elements included in each one or at least one combination of the following data: (A) Problem list; (B) Medication list; (C) Medication allergy list; (D) Demographics; (E) Laboratory tests and values/results; and (F) Vital signs. (ii) LINKED REFERENTIAL CLINICAL DECISION SUPPORT. (A) EHR technology must be able to: (1) Electronically identify for a user diagnostic and therapeutic reference information; or (2) Electronically identify for a user diagnostic and therapeutic reference information in accordance with the Infobutton functional standard, and relevant implementation specification, specified at (b). (B) For paragraph (A) above, EHR technology must be able to electronically identify for a user diagnostic or therapeutic reference information based on each one and at least one combination of the following data: (1) Problem list; (2) Medication list; (3) Medication allergy list; (4) Demographics; (5) Laboratory tests and values/results; and (6) Vital signs. (iii) CONFIGURE CLINICAL DECISION SUPPORT. (A) Enable interventions and reference resources specified in clauses (i) and (ii) immediately above to be configured by a limited set of identified users (e.g., system administrator) based on a user s role. (B) EHR technology must enable interventions to be electronically triggered: (1) Based on the data elements specified in clause (i) immediately above. (2) When a patient s medications, medication allergies, and problems are incorporated from a transition of care/referral summary received pursuant to transitions of care certification criteria. See (b)(1)(iii) below. (3) Ambulatory setting only. When a patient s laboratory tests and values/results are incorporated pursuant to care coordination criterion for incorporating laboratory tests and values/results. See (b)(5)(i)(a)(1) below. decision support rule to allow for greater variety of decision support mechanisms to improve clinical performance and outcomes. For purposes of counting or measuring that a CDS event was enabled or activated, ONC believes the best method of tracking CDS interventions is when they are enabled; if the technology can record such an event, it can generate a report indicating that the interventions were enabled across a given timeframe. ONC also clarifies that 1) it intended for a limited set of identified users to be able to select the CDS interventions (which makes it apparent when they were enabled); and 2) use of "activate" in the proposed regulation text was meant as an example. The focus is on the guidance the intervention offers through EHR technology though ONC notes locally defined and developed CDS content and references may be used with the capabilities of the certified technology. ONC agrees with commenter concerns about "hard coding" CDS to CQMs, and believes technology should leverage standards where possible to retrieve CDS content from external sources. ONC agrees with commenters that the HL7 Infobutton standard is not appropriate for interactive CDS interventions, but it believes HL7 Context-Aware Knowledge Retrieval is an important standard and thus adopts it as an alternative. ONC notes that it expects to require the standard in future rulemaking. In response to comments on CDS configuration, ONC substantially revises its proposal on configuration of CDS for a given setting by removing references to workflow and setting, but still requires that CDS be configured based on a user's role. ONC notes that "user" is not limited to health care professionals. These comments also focused on the timing of CDS interventions being triggered based on data incorporated from a transition of care/referral summary; ONC agrees that reconciling that information takes many steps to determine what is clinically significant and valid. ONC provides three specific instances that are required for certification (items (1), (2), and (3) in the adjacent cell of this row). ONC further clarifies that EHR technology must demonstrate that "it behaves differently in two states: before and after incorporation of new information." However, ONC does not specify any timing requirements (i.e., the technology need not trigger an intervention at the time of incorporation). With respect to source attributes, ONC notes that it only requires availability of information to the end user--not the automatic display of the source or that the

19 19 CLINICAL (iv) AUTOMATICALLY AND ELECTRONICALLY INTERACT. Interventions triggered in accordance with clauses (i) through (iii) immediately above must automatically and electronically occur when a user is interacting with EHR technology. (v) SOURCE ATTRIBUTES. Enable a user to review the attributes as indicated for all clinical decision support resources: (A) For evidence-based decision support interventions under clause (i) above: (1) Bibliographic citation of the intervention (clinical research/guideline); (2) Developer of the intervention (translation from clinical research/guideline); (3) Funding source of the intervention development technical implementation; and (4) Release and, if applicable, revision date(s) of the intervention or reference source. (B) For linked referential clinical decision support in clause (ii) above and drug-drug, drug-allergy interaction checks in (a)(2), the developer of the intervention, and where clinically indicated, the bibliographic citation of the intervention (clinical research/guideline). (9) ELECTRONIC NOTES Enable a user to electronically record, change, access, and search electronic notes. (10) DRUG-FORMULARY CHECKS EHR technology must automatically and electronically check whether a drug formulary (or preferred drug list) exists for a given patient and medication. technology create the content for the source attributes. Where some commenters sought to eliminate the source attribute requirements for drug-drug and drugallergy CDS interventions, ONC instead modifies the criterion to require only bibliographic citation and identification of the intervention developer. ONC further clarifies that global citations are allowed where all interventions of a given type are provided by the same reference. ONC also provides further descriptions of these requirements: o A "bibliographic citation" is a reference to a publication of clinical research that documents the clinical value of the intervention. If no reference exists, the technology should so indicate. o The "developer of the intervention (translation from clinical research/guideline)" is the team, entity, etc., that interpreted the clinical research and translated it into computable form. o The "funding source of the intervention development technical implementation" is the source of funding for the work performed by the "developer of the intervention," which could be a governmental agency or the same organization as the developer of the intervention. If this is unknown, the technology should so indicate. New certification criterion for both settings. CMS includes electronic notes objective and measure for MU Stage 2 menu set. The search capability required is to search free text and data fields of electronic notes only within an electronic note not across notes. Permits range of options to capture notes (e.g., templates, free text, text searchable scanned notes). Proposed as Unchanged certification criterion for both settings; ONC revises the criteria as follows: EHR technology must automatically check for the existence of a drug formulary that is specific to a patient for the medication to be prescribed. Hyperlinks alone to a patient's drug formulary do not meet the revised criterion. ONC declines to require additional capabilities (e.g., ensuring real-time information) but encourages developers to do so.

20 20 CLINICAL (11) SMOKING STATUS Enable a user to electronically record, change, and access the smoking status of a patient in accordance with the vocabulary standard specified at (h) which lists SNOMED CT codes for the following smoking status types: (i) current every day smoker; (ii) current some day smoker; (iii) former smoker; (iv) never smoker; (v) smoker, current status unknown; (vi) unknown if ever smoked; (vii) heavy tobacco smoker; and (viii) light tobacco smoker. (12) IMAGING Electronically indicate to a user the availability of a patient s images and narrative interpretations (relating to the radiographic or other diagnostic test(s)) and enable electronic access to such images and narrative interpretations. (13) FAMILY HEALTH HISTORY Enable a user to electronically record, change, and access a patient s family health history according to: (i) at a minimum, the version of the SNOMED CT vocabulary standard, specified in (a)(3); or (ii) the HL7 Pedigree standard, specified in (j) (14) PATIENT LIST CREATION Enable a user to electronically and dynamically select, sort, access, and create patient lists by: date and time; and based on each one and at least one combination of the following data: (i) Problems, (ii) Medications, (iii) Medication allergies, (iv) Demographics, (v) Laboratory tests and values/results; and ambulatory setting only: (vi) Patient communication preferences. ONC notes the ONC HIT Certification Program does not provide for reciprocity for certification (e.g., for Surescript's certification) and declines to require it. Proposed as Unchanged certification criterion for both settings; ONC revises the criteria as follows: ONC adds two additional smoking status codes light tobacco smokers (10 or fewer cigarettes/day) and heavy tobacco smokers (more than 10 cigarettes/day) or the equivalent in cigar or pipe smoke. It provides available SNOMED CT codes for developers and implementers of the technology, and indicates these codes must also be used when smoking status is required under other certification criteria (e.g., transitions of care). New certification criterion for both settings. Electronic access means direct access to both images and narratives (i.e., no login to separate electronic system or repository). ONC drops its proposed requirement for immediate access to images and narratives as it is vague and difficult to implement. Must be able to retrieve and display narrative information. Must be able to directly link to images stored in EHR system or provide contextsensitive link (i.e., link has parameters to access images themselves) to external applications affording access to images and narratives. ONC clarifies there is no requirement for capability to store images. ONC declines to adopt any particular standard (e.g., DICOM) as unnecessary. New certification criterion for both settings. Family defined as the patient s first-degree relatives; ONC clarifies no requirement to access records of patient s first degree relatives. Family health history must be captured in structured data. ONC combines the separate 2011 Edition EHR certification criteria "patient lists" and "patient reminders" into a single certification criterion for 2014 Edition EHR. In response to comments, ONC adds 1) "dynamically" to the criterion to clarify that a user must be able to create a patient reminder list on an ad-hoc basis according to at least the parameters specified in the criterion; and 2) a date and time component (performing date range searches; notes when patients last seen). ONC advises it intends for future EHR Editions to require technology to be able