Summary of Proposed Rule 2015 Edition Health Information ... · certified to this criterion to meet the CEHRT definition. 6. It would include the 2015 Edition Health IT certification

1

Prepared by Health Policy Alternatives, Inc. April 16, 2015

Summary of Proposed Rule 2015 Edition Health Information Technology (Health IT) Certification Criteria, 2015

Edition Base Electronic Health Record (EHR) Definition, and ONC Health IT Certification Program Modifications

[RIN 0991-AB93]

I. Introduction On March 30, 2015, the Office of the National Coordinator (ONC) for Health Information Technology (HIT) caused to have published in the Federal Register a notice of proposed rulemaking (NPRM) to propose 2015 Edition Health Information Technology (Health IT) certification criteria (2015 Edition) for electronic health record (EHR) technology for meaningful use (MU) under the Medicare and Medicaid EHR Incentive Programs; to propose a new 2015 Edition definition of Base EHR, and to propose changes to the ONC Health IT Certification Program to make that program more open and accessible to additional types of health IT and health IT that supports various care and practice settings. The NPRM seeks comment on a significant number of issues, and the deadline for submission of comments is May 29, 2015. Comments must be identified by “RIN 0991-AB93” and may be submitted through the Federal eRulemaking Portal (http://www.regulations.gov), through the mail,1 or by hand delivery or courier.2 ONC focuses on how health IT certification may support an interoperable nationwide health information infrastructure and the health care continuum through the use of certified health IT. Specifically, ONC proposes the following:

• Improve interoperability. To adopt new and updated vocabulary and content standards for the structured recording and exchange of health information, including a Common Clinical Data Set composed primarily of data expressed using adopted standards; and rigorously testing an identified content exchange standard (Consolidated Clinical Document Architecture (C-CDA)).

• Facilitate accessibility and exchange of data. To revise the 2015 Edition Base EHR definition by including enhanced data portability, transitions of care, and application programming interface (API) capabilities.

• ONC Health IT Certification Program. To establish a framework that makes the program open and accessible to more types of health IT, health IT that supports a variety of care and practice settings, various HHS programs, and public and private interests.

• EHR Incentive Programs. To adopt a set of certification criteria to support the Stage 3 proposals of the Medicare and Medicaid EHR Incentive Programs.

1 Address: Department of Health and Human Services, Office of the National Coordinator for Health Information Technology, Attention: 2015 Edition Health IT Certification Criteria Proposed Rule, Hubert H. Humphrey Building, Suite 729D, 200 Independence Ave, S.W., Washington, D.C. 20201. Submit one original and two copies. 2 Address: Office of the National Coordinator for Health Information Technology, Attention: 2015 Edition Health IT Certification Criteria Proposed Rule, Hubert H. Humphrey Building, Suite 729D, 200 Independence Ave, S.W., Washington, D.C. 20201. Submit one original and two copies.

http://www.regulations.gov/

2


• Address health disparities. To provide certification to standards for the collection of social, psychological, and behavioral data, for the exchange of sensitive health information (Data Segmentation for Privacy), and for the accessibility of health IT.

• Privacy and security. To ensure all health IT presented for certification have the relevant capabilities.

• Patient safety. To improve patient safety by applying enhanced user-centered design principles to health IT, enhancing patient matching, requiring relevant patient information to be exchanged, improving the surveillance of certified health IT, and making more information about certified products publicly available and accessible.

• Reliability and transparency. To increase the reliability and transparency of certified health IT through surveillance and disclosure requirements.

• Certification flexibility. Provide health IT developers with more flexibility and opportunities for certification that support both interoperability and innovation.

ONC repeatedly notes through the proposed rule that it intends to make the ONC Health IT Certification Program more open and accessible to other types of health IT beyond EHR technology and for health IT that supports care and practice settings beyond the ambulatory and inpatient settings used for purposes of the EHR Incentive Programs. ONC considers the proposed rule to be economically significant (having an annual effect on the economy of $100 million or more). II. Application Access to Common Clinical Data Set ONC proposes a new certification criterion for application programming interface (API) named the “Application Access to Common Clinical Data Set”. This criterion would require the demonstration of an API that responds to data requests for any one, and for all, of the data referenced in the Common Clinical Data Set (CCDS). ONC seeks to validate the continued interoperability of certified health IT and the ability to exchange health information by proposing a new certification criterion to rigorously assess a product’s C-CDA creation performance (for both C-CDA version 1.1 and 2.0) when presented for certification for such capabilities. III. Revisions to Terms and to Definitions of Certain Terms ONC would make the following name changes for the 2015 Edition certification criteria:

• The term “EHR Module” would become “Health IT Module.” • The term “EHR technology” would become “health IT.”

Base EHR. For purposes of the 2015 Edition, ONC proposes several changes to the definition of the term Base EHR as follows:

1. The term would be named 2015 Edition Base EHR and the current term would be redesignated as 2014 Edition Base HER.

2. It would exclude privacy and security capabilities and certification criteria. Privacy and security capabilities would be addressed by requiring health IT developers to meet privacy and security certification criteria rather than imposing the duty on eligible professionals (EPs) and eligible hospitals and eligible critical access hospitals

3


(collectively EHs) to ensure that their technology is certified to the necessary privacy and security criteria.

3. It would only require the capability to record and export clinical quality measure (CQM) data meaning that the definition would no longer include capabilities to import, calculate and report CQM data or any other CQM-related requirements.

4. It would include the 2015 Edition “smoking status” and “implantable device list” certification criteria as patient demographic and clinical health information data.

5. It would include the 2015 Edition “application access to Common Clinical Data Set” certification criterion to both capture and query information relevant to health care quality and exchange electronic health information with, and integrate such information from other sources. Thus, all EPs and EHs would have to adopt a Health IT Module certified to this criterion to meet the CEHRT definition.

6. It would include the 2015 Edition Health IT certification criteria corresponding to the remaining 2014 Edition referenced in the 2014 Edition Base EHR definition (shown in the table 5 of the proposed rule and reproduced below).

Table 5. Certification Criteria Required to Satisfy 2015 Edition Base EHR Definition

Base EHR Capabilities Certification Criteria Patient demographic and clinical health information

Demographics §170.315(a)(5) Problem List §170.315(a)(7) Medication List §170.315(a)(8) Medication Allergy List §170.315(a)(9) Smoking Status §170.315(a)(12) Implantable Device List §170.315(a)(20)

Capacity to provide clinical decision support

Clinical Decision Support § 170.315(a)(10)

Capacity to support physician order entry

Computerized Provider Order Entry §170.315(a)(1), (2) or (3)

Capacity to capture and query information relevant to health care quality

Clinical Quality Measures §170.315(c)(1)

Capacity to exchange electronic health information with, and integrate such information from other sources

Transitions of Care §170.315(b)(1) Data Portability §170.315(b)(6) Application Access to Common Clinical Data Set §170.315(g)(7) Direct Project §170.315(h)(1) or Direct Project, Edge Protocol, and XDR/XDM §170.315(h)(2)

ONC proposes to continue the same policy on marketing; thus developers may market their technology as meeting the 2015 Edition Base EHR definition when their Health IT Modules are certified to all the 2015 health IT certification criteria shown above. CEHRT. ONC proposes to discontinue use of the term CEHRT under its regulations. ONC reasons that since the term is used to support the EHR Incentive Programs, it should only be part of those regulations. ONC notes that the Centers for Medicare & Medicaid Services (CMS) proposes to adopt a CEHRT definition (in 42 CFR 495.4) that covers all the relevant compliance

4


timelines and would still refer to the relevant Base EHR definitions and certification criteria adopted by ONC. Common Clinical Data Set (CCDS). ONC proposes to change the name of the “Common MU Data Set” to the “Common Clinical Data Set;” it also proposes additional changes for proposed new and updated standards and code sets as well as revisions to support patient safety through clearly referenced data elements and new patient data; these proposed changes would only affect certification to the 2015 Edition. ONC proposes to include “immunizations”3 and “Unique Device Identifiers of a patient’s Implantable Devices” in the CCDS for 2015 Edition certification. Additionally, ONC would also include “assessment and plan of treatment,” “goals,” and “health concerns”4 for 2015 Edition certification which are intended to replace “care plan fields, including goals and instructions” in the Common MU Data Set for in 2014 Edition certification. There was confusion among stakeholders whether to interpret “care plan fields, including goals and instructions” as applying to a single patient encounter (or single inpatient stay) or as applying to a comprehensive shared care plan (representing the synthesis and reconciliation of multiple plans of care). ONC clarifies for purposes of certification to the 2014 Edition that this is intended to be a single provider’s documentation of their assessment, plan of treatment, goals, and health concerns. ONC also seeks comment on how it may continue to engage the public to keep the CCDS relevant to clinical practice. ONC proposes to include the following vocabulary standards for the CCDS for 2015 Edition certification:

• Health Level 7 (HL7) Version 3 (“AdministrativeGender” and a nullFlavor value) for sex,

• “Race & Ethnicity – Centers for Disease Control and Prevention (CDC)” code system in PHIN Vocabulary Access and Distribution System (VADS) and the Office of Management and Budget (OMB) standard for race and ethnicity,

• Tags for Identifying Languages – Request for Comment (RFC) 5646 for preferred language,

• The September 2014 Release of the U.S. Edition of Systemized Nomenclature of Medical Clinical Terms (SNOMED CT®) for problems and procedures,

• The February 2, 2015 monthly version of RxNorm for medications and medication allergies,

• Logical Observation Identifiers Names and Codes (LOINC®) version 2.50 for laboratory tests, and

• LOINC® codes, metadata, and relevant UCUM unit of measures specified for vital signs. ONC notes that for race and ethnicity a Health IT Module must express both detailed races and ethnicities according to the Race & Ethnicity–CDC code system and the aggregate OMB code for each race and ethnicity identified by the patient.

3 Immunizations would have to be coded according to the CVX code set (HL7 Standard Code Set CVX—Vaccines Administered, updates through February 2, 2015) and the National Drug Code (NDC) code set (NDC – Vaccine Codes, updates through January 15, 2015) as part of the “Common Clinical Data Set.” 4 Data would be included in accordance with the C-CDA Release 2.0 “Assessment and Plan Section (V2)” or both the “Assessment Section (V2)” and “Plan of Treatment Section (V2);” the “Goals Section;” and the “Health Concerns Section.”

5


Use of FDA Definitions. ONC proposes to adopt the same definitions established by the Food and Drug Administration for “Implantable Device,” “Unique Device Identifier,” “Device Identifier,” and “Production Identifier.” IV. ONC HIT Certification Program ONC proposes a number of changes to the certification program to reflect its goals of making the program more open and accessible to other types of health IT beyond EHR technology and for health IT that supports care and practice settings beyond the ambulatory and inpatient settings used for purposes of the EHR Incentive Programs. ONC proposes a significant number of terminology changes, including the following:

• The name of the program would become the ONC Health IT Certification Program (Program).

• References to HIT would all be changed to health IT (or Health IT in the case of its use as a proper noun).

• References to EHR Modules would be changed to Health IT Modules. ONC reassures readers that the proposed name change of EHR Modules is a change in name alone; it would not affect the certification of previously certified EHR Modules, or the ability of EPs and EHs to use the technologies to meet the CEHRT definition. Of greater importance, ONC proposes to no longer require ONC-ACBs to certify Health IT Modules to the 2015 Edition “meaningful use measurement” certification criteria (§170.315(g)(1) “automated numerator recording” and §170.315(g)(2) “automated measure calculation”). ONC notes that developers are welcome to seek certification to §170.315(g)(1) or (g)(2), especially since Stage 3 of the EHR Incentive Programs (as proposed) would require EPs and EHs to have health IT certified to those criteria to meet CEHRT requirements. Per the Health Information Technology Policy Committee (HITPC) recommendations, ONC developed proposals to make the Program “more agnostic” to care and practice settings. As noted above, ONC proposes to remove meaningful use measurement certification requirements; it also proposes to add data segmentation certification criteria to support settings for patients with more sensitive health issues, such as behavioral health, and to modify 2014 Edition certification criteria by adding new or enhanced functionalities for the 2015 Edition (e.g., transitions of care at §170.315(b)(1)). ONC anticipates issuing general interoperability guidance for the 2015 Edition, but it has no plan to independently develop or issue certification tracks by care or practice setting. It appears to be open to working with other agencies, provider associations, etc., to identify functionality and certification criteria to support stakeholders. ONC also seeks comment on future certification criteria to support long-term post-acute care, behavioral health, pediatrics, and other care and settings. Its proposal would also permit further referencing and use of certified health IT beyond the EHR Incentive programs. Health IT Module Certification Requirements. Privacy and Security. ONC proposes several changes to the privacy and security certification to the 2015 Edition. Under the new approach, privacy and security (P&S) requirements will vary

6


based on the regulatory functional area (i.e., Health IT Modules with capabilities under one or more of the following areas: clinical, care coordination, clinical quality measures, patient engagement, public health, transport methods (and other protocols), and administrative functional areas). The policy would not require each criterion to include all P&S functionalities but would include sufficient safeguards for each criterion. Thus a Health IT Module presented for any certification criteria that falls under a regulatory functional area must be certified as either (i) technically demonstrating, through system documentation and certification testing, that it meets at least a minimal set of P&S certification criterion (referred to as “Approach 1”) or (ii) demonstrating, through system documentation sufficiently detailed to enable integration such that the Module has implemented service interfaces for each applicable P&S criterion to enable access to external services to meet the P&S criterion (referred to as “Approach 2”) as follows: If the Health IT Module includes capabilities for certification listed under:

The Module must be certified to Approach 1 or Approach 2 for each of the P&S certification criteria listed in the “Approach 1” column

Approach 1 Approach 2

§170.315(a) Clinical

§170.315(d)(1) (authentication, access control, and authorization), (d)(2) (auditable events and tamper resistance), (d)(3) (audit reports), (d)(4) (amendments), (d)(5) (automatic log-off), (d)(6)(emergency access), and (d)(7) (end-user device encryption)

For each applicable P&S certification criterion not certified for approach 1, there must be system documentation sufficiently detailed to enable integration such that the Health IT Module has implemented service interfaces for each applicable privacy and security certification criterion that enable the Health IT Module to access external services necessary to meet the privacy and security certification criterion.

§170.315(b) Care Coordination §170.315(d)(1) through (d)(3) and (d)(5) through (d)(8) (integrity)

§170.315(c) Clinical Quality Measures

§170.315(d)(1) through (d)(3)

§170.315(e) Patient Engagement §170.315(d)(1) through (d)(3), (d)(5), and (d)(7)

§170.315(f) Public Health §170.315(d)(1) through (d)(3) and (d)(7)

§170.315(h) Transport Methods (and other protocols)

§170.315(d)(1) through (d)(3)

§170.315(i) Administrative §170.315(d)(1) through (d)(3) and (d)(5) through (d)(8)

Appendix A of the proposed rule includes a list of all P&S certification requirements for each 2015 Edition criterion. ONC seeks comment on the clarity and feasibility of this proposal. Design and Performance. For the 2015 Edition certification criteria, ONC-ACBs would have to certify a Health IT Module for design and performance as follows:

Certification Criteria Design and Performance Criteria Clinical: §170.315(a)(1) – (10), (18), (20), (22), (23)

Care Coordination: §170.315(b) (2), (3), and (4) §170.315(g)(3) Safety-enhanced design

All Criteria §170.315(g)(4) Quality management system §170.315(g)(8) Accessibility-centered design

Clinical: §170.315(a) Care Coordination: §170.315(b)

Patient Engagement: §170.315(e)

§170.315(g)(5) Accessibility technology compatibility

Any criterion with C-CDA creation capabilities §170.315(g)(6) Consolidated CDA creation performance (where multiple criteria require C-CDA creation, (g)(6)

7


Certification Criteria Design and Performance Criteria testing need only be done for one criterion)

ONC-ACB Principles of Proper Conduct: In-the-Field Surveillance. ONC proposes to require ONC-ACBs to initiate in-the-field surveillance of certified Complete EHRs and certified Health IT Modules to assure that the technology continues to meet certification requirements when implemented and used in a production environment (i.e., in the field). ONC-ACBs would have to assess the capabilities in a production environment based on the use of the capability with protected health information unless use of test data provides an equivalent assessment. ONC notes that in the field would only occasionally mean in-person site visits; ONC-ACBs would conduct most assessments using remote methods. ONC seeks comments on the proposal, the method for conducting the assessments, ways to minimize burden and costs, and appropriate industry standards. ONC proposes both reactive and randomized in-the-field surveillance as part of the ONC-ACB certification which would be enforceable by the ONC-Approved Accreditor (ONC-AA). Reactive surveillance would be a requirement for ONC-ACBs to conduct in-the-field surveillance when it becomes aware of facts or circumstances indicating questions regarding continued compliance of certification requirements (typically from user feedback, including complaints). The ONC-ACB would also have to consider the impact and effect of disclosures by the developer on the product’s continued conformance to the relevant criteria (such as whether the developer substantially restricts or limits the capability’s use or failed to disclose material information about the implementation or use of the capability) that could substantially interfere with the use of capabilities. ONC notes that an entire certified Complete EHR or certified Health IT Module could be rendered non-conforming; ONC expects the National Coordinator to prioritize certain criteria for surveillance for which ONC-ACBs would give special scrutiny to complaints. ONC-ACBs would also have to verify the developer has met the mandatory disclosure requirements. ONC-ACBs would also conduct randomized surveillance each year of 10 percent of certified Complete EHRs or certified Health IT Modules it certified for prioritized criteria to detect patterns of non-conformance that could give rise to a corrective action plan. Randomized surveillance of certified Complete EHRs or certified Health IT Modules may not be done more frequently than annually, and in-the-field surveillance would be initiated at the lesser of (i) 10 locations or (ii) 5 percent of all locations at which the technology is implemented and in use. The locations would be selected at random and reflect diversity of practice types, sizes, settings, and locales. Where there is a pattern of nonconformity (defined as nonconformity with respect to any prioritized criteria at 20 percent or more of the locations), the developer would have to submit corrective action plan within 30 days of a deficiency notice. The plan would have to include, for each certification criteria or disclosure deficiency, a description of (i) the deficiency, (ii) the extent of the deficiency, (iii) the proposed corrective action (generally and at each surveilled location), and (iv) the timeframe for completion of the corrective action. The ONC-ACB may suspend (and later terminate) a certification if the developer fails to timely submit the corrective

8


action plan; fails to comply with ONC-ACB directions to address plan aspects that do not meet applicable requirements; or fails to complete the plan within 6 months. ONC-ACBs would be required to report results of in-the-field surveillance to the National Coordinator at least quarterly (ONC notes that currently there can be a 14-month lag between surveillance and reporting). Additionally, corrective action plans would be reported to the Certified Health IT Product List (CHPL) in a timely and effective manner (which means the data would be available to the public at least weekly). ONC notes that these requirements are minimum requirement and do not limit the ability or duty of ONC-ACBs to conduct additional surveillance. The requirements for randomized surveillance would apply effective January 1, 2016; all other requirements would be effective immediately. ONC seeks comment on the timeline and ways to minimize disruption. ONC-ACB Principles of Proper Conduct: Transparency and Disclosure Requirements Citing myriad concerns with the lack of transparency in the health IT marketplace, ONC proposes to strengthen its transparency and disclosure requirements under the Program. First, ONC proposes to modify the requirement on developers to conspicuously disclose any additional types of costs a user may incur to implement or use the capabilities of certified health IT for purposes of the EHR Incentive programs to expand disclosure for all purposes within the certification—not just for the EHR Incentive programs. Second, ONC proposes to expand the disclosure requirement to address more than just additional costs; ONC would have developers disclose “material information about limitations” associated with certified health IT products. Third, ONC proposes broader disclosure requirements and greater detail. Developers would have to be more proactive in describing the types of limitations and additional costs that a user might pay (rather than the current standard “would pay”) to achieve use within the product’s certification, such as those based on potential conditions applicable to a user or options available to a user. Developers would have to provide detailed descriptions of any material information on limitations or additional costs; the term “material” would mean that failure to disclose the information could substantially interfere with a user’s ability to implement the health IT consistent with the certification. Some examples include the following:

• Costs or fees to buy, license, implement, maintain, upgrade, use of support (or enable) the capabilities, or in connection with data generated using the capabilities.

• Contractual or other limitations on use for any purpose within the technology’s certification, or in connection with data generated using the capabilities.

• Technical, practical or other limitations that could prevent or impair successful implementation, configuration, customization, maintenance, support, or use of any capability, or prevent or limit use, exchange, or portability of data generated using the capabilities.

ONC seeks comment on its examples above; on whether it should revise or add types of information; and on whether it should require disclosure of more specific cost structures.

9


ONC clarifies that developers would not have to disclose specific prices but would have to describe the nature and magnitude of additional costs so a person could estimate those costs, including information to help estimate cost to use the transitions of care capability. Developers would not have to disclose trade secrets or intellectual property or information of which they are unaware (such as costs/limitations associated with third party technologies and services). ONC would expect developers to provide detailed descriptions of additional considerations a customer would need to know to reliably estimate costs and resources required; however ONC would qualify this requirement based on the developer’s knowledge of the customer’s circumstances and based on its range of experience (such as with other customers). Additionally, ONC-ACBs would have to get a “voluntary public attestation from every health IT developer” to which it issues (or has issued) a certification for any edition of health IT. The attestation would be a pledge to be transparent and would require the voluntary disclosure of the information described above to (i) customers before providing any certified health IT or related product or service, (ii) prospective customers, and (iii) any other person on request. Only the attestation would be required; compliance with the attestation would be voluntary. ONC-ACB Principles of Proper Conduct: Open Data Certified Health IT Product List (CHPL) In response to stakeholders who believe that the links maintained by ONC-ACBs on the CHPL to test result summaries for certification under the Program and the access to those summaries as a PDF makes analysis difficult, ONC proposes to convert the CHPL to an open data file represented in both XML and JSON with accompanying API functionality. ONC estimates this may take between 12 and 18 months. For the 2015 Edition and subsequent editions, ONC also proposes that ONC-ACBs report more information to ONC in their weekly reports on the current list of products on the CHPL. The information reporting requirements are approximately double what is required for the 2014 Edition products included on the CHPL and are found at §170.523(f)(1), as proposed to be amended. ONC believes that the expanded list of data would subsume data included in the test result summaries; therefore, beginning with the 2015 Edition, ONC would strike the requirement for ONC-ACBs to maintain hyperlinks to test result summaries. With respect to corrective action plans under randomized in-the-field surveillance (described above), the initiation of such a plan would trigger the duty to report the surveillance-related data to be included in the open data file—this reporting is separate from the quarterly reporting requirement for all surveillance results. This reporting requirement applies to both the 2014 and 2015 Editions certified health IT. However, ONC-ACBs may not report data that would identify any user or location nor may they submit or disclose developer proprietary business information or trade secrets. ONC would provide additional guidance to ONC-ACBs regarding the reporting of this data. ONC seeks comments on whether there are additional data generated during testing that would be useful to the public to have disclosed. ONC-ACB Principles of Proper Conduct: Records Retention. ONC proposes to require ONC-ACBs to retain records related to certification of Complete EHRs and Health IT Modules (including EHR Modules) for 6 years. ONC also proposes to make records of certifications done

10


under the Program available to other agencies within HHS (such as CMS and the OIG) during the 6-year retention period. ONC-ACB Principles of Proper Conduct: Complaints Reporting. ONC proposes to require ONC-ACBs to provide the National Coordinator with quarterly lists of complaints received. The lists would specify the number of complaints, the nature of the complaints, and the type of complainant (i.e., provider, developer etc.). ONC-ACB Principles of Proper Conduct: Adaptations and Updates of Health IT. ONC proposes to require ONC-ACBs to get reports on a monthly basis from developers of all adaptations and updates (including changes to user-facing aspects) made to their certified health IT. ONC seeks comments on whether more frequently reporting is appropriate. Even where a developer would have no adaption or update to report, it would still have to provide a record to the ONC-ACB indicating that there is no adaption or update. ONC would not require reporting of this information to ONC or to be included on the CHPL. The purpose of this reporting would appear to be to inform ONC-ACBs in selecting certified health IT for purpose of their surveillance duties. This would apply to health IT certified to the 2014 Edition and the 2015 Edition criteria, and would be effective beginning on the first calendar month that begins 30 days after the effective date of the final rule. Decertification of Health IT—Request for Comment In the Consolidated and Further Continuing Appropriations Act, 2015 (Public Law 113-235), Congress urged ONC (among other things) to use its authority to decertify CEHRT that proactively blocks information sharing. Noting that ONC-ACBs currently have the authority to certify and terminate certifications for health IT, ONC seeks comment from all stakeholders on the circumstances, due process procedures, remedies, and other factors it should consider in establishing new program requirements and processes for ONC (or ONC-ACBs) to terminate certifications. ONC encourages commenters to consider “potentially profound asymmetric impacts” that revoking a certification could create, including impacts on those who rely on the CEHRT for the EHR Incentive programs and other programs. V. 2015 Edition Health IT Certification Criteria As in past proposals for new editions of certification criteria, the proposed 2015 Edition criteria would retain some of the 2014 Edition EHR certification criteria unchanged; modify some of the 2014 Edition criteria; propose new criteria; update standards; and clarify regulatory text. One revision is that the capabilities of each 2015 certification criterion apply to any health care setting unless otherwise specified. Also, because Complete EHR certifications will no longer be issued beginning with the 2015 Edition, no criterion is labelled as optional [(though certain capabilities within a criterion may be so labelled)]. ONC notes that all standards and implementation specifications have been developed or adopted by voluntary consensus standards bodies, except for the following where ONC was not aware of any voluntary consensus standard that would serve as an appropriate alternative:

• Transport standards at §170.202.

11


• Electronic submission medical documentation (esMD) at §170.205(a)(5)(iii) and (iv). • Reporting syndromic surveillance and immunization information to public health

agencies at §170.205(d)(4) and (e)(4). • Race and ethnicity at §170.207(f)(2). • Protection of electronic health information at §170.210.

ONC also includes in section VI of the proposed rule a complete list the standards and implementation specifications it proposes to adopt, as well as a summary for each and a uniform resource locator (URL). ONC also proposes to adopt the following minimum standards code sets (the first four of which are newer version of previously adopted code sets and the last two are new):

• September 2014 Release of the U.S. Edition of SNOMED CT®. • LOINC® version 2.50. • February 2, 2015 monthly version of RxNorm. • February 2, 2015 version of the CVX code set. • National Drug Codes (NDC) – Vaccine Codes, updates through January 15, 2015. • “Race & Ethnicity – CDC” code system in the PHIN Vocabulary Access and Distribution

System (VADS) Release 3.3.9 (June 17, 2011)). ONC also provides a table of object identifiers (OIDs) for certain code systems for developers. ONC proposes to modify definitions of “new,” “revised,” and “unchanged” as applied to the 2015 Edition criteria as compared to previous Edition criteria for purposes of gap certification as follows:

• New refers to criteria that as a whole only include capabilities never referenced in previously adopted editions and to which a Health IT Module presented for certification to the 2015 Edition could have never previously been certified.

• Revised refers to criteria that include capabilities referenced in a previously adopted editions as well as changed or additional new capabilities; and to which a Health IT Module presented for certification to the 2015 Edition could not have been previously certified to all of the included capabilities.

• Unchanged refers to criteria that include the same capabilities as compared to prior editions; and to which a Health IT Module presented for certification to the 2015 Edition could have been previously certified to all of the included capabilities.

ONC notes that all capabilities listed in a criterion are expected to be performed electronically unless otherwise noted. The appendices to this summary contain tables showing the proposed certification criteria for 2015 Edition EHR in the order listed under the proposed regulatory text and provide a column for other information and commentary relevant to each of the certification criteria. ONC proposes several new certification criteria; for example:

12


• Implantable device lists: To record, change, and access a list of unique device identifiers (UDIs); to parse certain data from a UDI; to retrieve the Device Description attribute associated with a UDI in the Global Unique Device Information Database (GUDID) maintained by the FDA; and make both the parsed data and retrieved data user accessible.

• Patient health information capture: A replacement for the 2014 Edition advance directive certification criterion, to store and permit access (through links) to an advance directive and other health information documents (e.g., a birth plan); also permit a user to record and access information directly from a patient, such a through a mobile device.

• Data segmentation for privacy – send and receive: Two new certification criteria (in proposed §170.315(b)(7) and (8)) to separately track (i.e., segment) individually identifiable health information protected by state or federal privacy laws more restrictive than the HIPAA Privacy Rule (one criterion each for sending and receiving the data).

• Electronic Submission of Medical Documentation (esMD): CMS and ONC established the esMD initiative to develop use cases and standards for electronic exchange of medical documentation among providers and Medicare review contractors, including for purposes of prior authorization and pre- and post-payment review under the fee-for-service program; esMD certification criterion at proposed §170.315(i)(1) includes four capabilities: create document templates; embed a digital signature in a CDA document; create and transmit external digital signatures for documents; and create and transmit external digital signatures for electronic transactions for purpose of data integrity and non-repudiation authenticity.

• Transport methods and other protocols: Two new criteria at proposed 170.315(h)(4) and (5) related to provider directory capabilities; health IT must be able to query a provider using the Integrating the Healthcare Enterprise (IHE) Healthcare Provider Directory (HPD) directory; respond to such a query; or both.

• Decision Support – Knowledge Artifact: To electronically send and receive clinical decision support knowledge artifacts in accordance with a Health eDecisions (HeD) standard.

• Decision Support – Service: To electronically make an information request with patient data and receive electronic clinical guidance in accordance with a HeD standard.

• Care plan: To record, change, access, create, and receive care plan information using a Care Plan document template in C-CDA Release 2.0 Templates for Clinical Notes.

• CQM - Filter: For use in newer programs, such as Medicare Shared Savings Program, Pioneer ACOs, the PQRS group practice reporting option, and the Comprehensive Primary Care Initiative which requires performance measurement by eligible practice site rather than by individual practitioners; health IT must be able to filter by any combination of the required data elements (i.e., by any one or a combination of any of the data elements (e.g., combination of TIN and NPI or combination of all data).

• Social, psychological, and behavioral data: To record, change, and access a patient’s social, psychological, and behavioral data based on SNOMED CT® and LOINC® codes.

• Transmission to public health agencies—Case reporting, Antimicrobial use and resistance reporting, and Health care surveys: Three new certification criteria to report data to public health agencies at proposed §170.315(f)(5) through (7)).

• Accessibility technology compatibility: Applicable to Health IT Modules presented for certification to clinical, care coordination, and patient engagement criteria; intended to ensure health IT is accessible to visually impaired and disabled individuals.

13


• Application access to common clinical data set (CCDS): Focus on ability of health IT to respond to requests for patient data from other applications for any one or more (or all) of the CCDS data through the demonstration of an application programming interface (API).

• Accessibility-centered design: Requires identification of user-centered design standards or laws for accessibility applied (or complied with) in the development of specific capabilities included in a Health IT; would also require identification of failure to apply or comply with such standards or laws. This applies to all certification criteria.

Some proposed changes of note to the 2014 Edition certification criteria include the following:

• Computerized provider order entry (CPOE): To mandate that the criterion be split into 3 separate criteria by order type (medications, laboratory, and diagnostic imaging). ONC seeks comment on whether a Health IT Module should (for purposes of testing and certification) include the capability to include any or all of the following in a transmitted order: secondary diagnosis codes, reasons for order, comment fields for the ordering provider, and other data elements.5

• Vital signs: To expand the types of vital signs for recording; 2) require each type of vital sign to have a specific LOINC® code attributed to it; 3) that The Unified Code of Units of Measure, Revision 1.9, October 23, 2013 (“UCUM Version 1.9”) be used to record vital sign measurements; and 4) that certain metadata accompany each vital sign, including date, time, and measuring- or authoring-type source.

• Clinical decision support (CDS): To adopt an updated Infobutton standard and two updated implementation guides (IGs); to require certification only to the Infobutton standard (and associated IG); and to require the ability to record users’ actions in response to CDS interventions.

• Electronic notes: ONC appears to omit this certification criterion. • Family Health History: To adopt two family health history certification criteria (Family

Health History and Family Health History-Pedigree), both of which are revised. • Patient-Specific Education Resources: To remove the requirement to electronically

identify resources based on “laboratory values/results,” and to clarify resources must be electronically identified using Infobutton and another method that does not rely on Infobutton.

• Transitions of care (ToC): To expand on the 2014 Edition optional criterion by using updated C-CDA standard; to require capabilities to detect valid and invalid C-CDA documents, to require Health IT Module certified to SMTP-based edge to accept and process XDM packages it receives; to include a limited set of standardized data in the ToC “create” element; and to seek comment on C-CDA appropriateness of tagging health information with provenance metadata.

• Electronic prescribing: To require receipt and response for additional transactions or segments (Change, Refill, and Cancel Prescription; Fill Status; and Medication History); to require directions for medication use transmitted as e-prescriptions to be codified in a structured format; and to limit e-prescriptions to the metric unit standard only.

5 ONC clarifies that any specific data element requirements adopted in the final rule would only apply in the absence of a standard for testing and certification.

14


• Clinical quality measures (CQMs): To require that a system user be able to export and import CQM at any time and without subsequent developer assistance to operate (beyond normal orientation/training); to record structured data to filter CQM results to create different patient population groupings by various data elements, including practice site, TIN or NPI, diagnosis, and/or demographics; to seek comment on the most appropriate standard (Quality Reporting Document Architecture (QRDA) or a QRDA-like standard); and to reserve the criterion for CQM submission for the relevant Medicare payment system rulemaking in 2015.

• View, download, transmit to 3rd party (VDT): To revise the text to clarify that this capability is patient-facing and for patients to use; to include the Common Clinical Data Set (CCDS) and diagnostic image reports; to require the same API capabilities applicable to the CCDS apply to this criterion; to include the addressee of an ambulatory or inpatient summary; to provide patient laboratory test reports; and for the view capability, to be compliant with Web Content Accessibility Guidelines (WCAG) 2.0 Level A. ONC seeks comments on a number of issues, including whether to require compliance with WCAG 2.0 Level AA.

• Clinical summary: ONC does not propose a 2015 Edition clinical summary certification criterion; it believes the capabilities under VDT criterion adequately support proposals of the EHR Incentive Programs.

• Transmission to Immunization Registries: To adopt an updated IG, require National Drug Codes (NDC) for recording administered vaccines, require CVX codes for historical vaccines, and require a Health IT Module display an immunization history and forecast from an immunization registry

• Safety enhanced design: To add criteria for error prevention and to clarify compliance requirements for data elements in National Institute of Standards and Technology Interagency/Internal Report (NISTIR) 7742.

Eligibility for Gap Certification. Table 4 in the proposed rule contains a crosswalk of the unchanged 2015 Edition certification criteria to the corresponding 2014 Edition for purposes of gap certification; gap certification eligibility is also noted for each of the certification criteria in the appendices to this summary.

Pharmacogenomics Data—Request for Comment

ONC notes that pharmacogenomics data identifies genetic variants in individuals that alter their metabolism or other interactions with medications and can lead to serious adverse events, and that in general health IT has not captured genomic and genetic patient information in a structured manner as is the case for other clinical findings or lab-derived data. ONC also correctly observes that individually identifiable genetic information is subject to the HIPAA Privacy Rule and may also be subject to additional federal and state privacy laws and regulations. ONC signals an interest in establishing certification criteria for this purpose and seeks input on factors it should consider for health IT that permits a user to disclose or use genetic information in a manner that complies with privacy laws. ONC and the National Institutes of Health seek comment on the following questions:

15


• Whether the 2015 Edition “medication allergy list” criterion should include the capability to integrate genotype-based drug metabolizer rate information.

• Whether the 2015 Edition “drug-drug, drug-allergy interactions checks for CPOE” criterion or as a separate certification criterion should include pharmacogenomic CDS for “drug-genome interactions.”

• Whether a 2015 Edition criterion for CDS should be offered that incorporates a patient’s pharmacogenomic genotype data into the CPOE prescribing process with the goal of avoiding adverse prescribing outcomes for known drug-genotype interactions.

• Whether there are certification approaches that could enhance the end-user’s (provider’s) adoption and continued use of health IT implementations that guide prescribing through CDS using pharmacogenomic data.

• Whether there are existing or developing standards applicable to the capture, storage, display, and exchange of potentially clinically relevant genomic data, including the pharmacogenomic subset.

• Whether certification should be offered for health IT functionality that could facilitate HIPAA-compliant sharing of discrete elements of a patient’s genomic information from their record to the family history section of a relative’s record.

• Whether the proposed “data segmentation for privacy” criteria would provide needed health IT functions with respect to the storage, use, transmission, and disclosure of genetic, genomic, and pharmacogenomics information that is subject to protections under HIPAA and additional state and federal privacy and protection laws such as the Genetic Information Nondiscrimination Act (GINA).217

• Whether the proposed “data segmentation for privacy” criteria adequately balance complex genetic privacy issues, such as those related to behavioral health, with the clinical value of context-appropriate availability of a patient’s actionable genetic and genomic information.

• Whether health IT should be required to apply different rules for the use and exchange of genetic, genome, and pharmacogenomics data based on different groupings of diseases or conditions based on the sensitivity of the information, such as those related to behavioral health.

• Whether there are other factors ONC should consider for health IT that allows the user to use or disclose genetic information subject to federal and state privacy laws.

VI. Collection of Information Requirements; Regulatory Impact Analysis ONC believes that the Paperwork Reduction Act collection of information requirements do not apply to this proposed rule because fewer than 10 annual respondents under the ONC Health IT Certification Program must comply with collection and reporting requirements. ONC believes

16


the longer records retention requirement (from 5 to 6 years) will not impose a burden and that the requirement for quarterly lists of complaints will pose a minimal burden. The change to the surveillance requirements for 2014 Edition certifications will pose a minimal burden (117 total hours annually), and the new surveillance requirements for 2015 Edition certifications will require 234 total hours annually. The estimated annual aggregate burden is 375 hours. ONC determines that the rule is economically significant because it estimates that costs to develop and prepare health IT for testing and certification will exceed $100 million per year. The ONC analysis focuses on the technological and preparation costs of EHR technology developers to upgrade previously certified technology or develop new health IT for testing and certification; it does not examine costs EPs, EHs and CAHs would incur to adopt and implement the technology. Additionally, ONC considers these costs to be investment costs rather than compliance costs. ONC divides the certification criteria into Stage 3 Criteria (criteria associated with the Stage 3 proposed objectives and measures for the EHR Incentive programs) and Independent Criteria (all other proposed criteria). Tables 6 through 9 of the proposed rule set forth the estimated hours and costs by criterion for Stage 3 Criteria and for Independent Criteria. ONC reduces its estimates for the number of health IT developers in part due to increases in interoperability requirements and market share gains by certain developers (including through acquisitions of other developers). ONC estimates each developer will have 2.5 products per Stage 3 criterion and 1 product per each Independent criterion. ONC assumes $61 per hour for a software developer. Table 10 of the proposed rule (reproduced below) shows estimated overall costs over a four-year period (2015 through 2018) ranging from $197.43 million to $407.20 million with an uneven distribution over that period for each year.

Table 10. Distributed Total Development and Preparation Costs (in Millions) for Health IT Developers (4 year period) – Totals Rounded

Year Ratio Total Low Cost

Estimate Total High Cost

Estimate Total Average Cost Estimate

2015 25% $49.36 $101.80 $75.58 2016 30% $59.23 $122.16 $90.70 2017 30% $59.23 $122.16 $90.70 2018 15% $29.61 $61.08 $45.35

4-Year Totals $197.43 $407.20 $302.32 ONC believes the benefits of the proposed rule include the new and updated standards and implementation specifications (especially for interoperability) that directly support the EHR Incentive programs. It also points to certification criteria that support collection of patient data to support health disparities as well as enhanced requirements to support usability and patient safety. Finally in making the ONC Health IT Certification Program open and accessible to more types of health IT, including health IT for a variety of care and practice settings, ONC believes this will help providers, customers, and developers. As it has in the past, ONC struggles to calculate the number of developers who might qualify as small businesses for purposes of the Regulatory Flexibility Act because it is unclear how many

17


of those entities will actually develop a health IT product for certification to the 2015 Edition, but it 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 again asserts that its proposals would result in the minimum amount of requirements to accomplish its policy goals and also believes that no alternative would lessen the burden. Further, as noted above, ONC characterizes costs as investment rather than compliance costs, and thus believes the proposed rule will not significantly impact a substantial number of small businesses. ONC does request comment on small entities they may not have identified that may be affected in a significant way by the NPRM. ONC also believes that the NPRM does not raise Federalism issues or issues under the Unfunded Mandates Act of 1995.

18


Appendix A—Proposed Clinical 2015 Edition EHR Certification Criteria

Proposed 2015 Edition EHR Certification Criteria: CLINICAL

Observations

Health IT must be able to electronically perform the following capabilities under all applicable standards and implementation specifications: Proposed §170.315(a) Clinical (1) COMPUTERIZED PROVIDER ORDER ENTRY (CPOE)—MEDICATIONS Technology must enable a user to electronically record, change, and access medication orders.

• Unchanged certification criterion • Base EHR—Included. To meet BASE EHR definition, CPOE must be certified to

one of the three order types—medication, laboratory, or diagnostic imaging under paragraphs (1), (2) or (3) of proposed §170.315(a)

• Gap certification status: Eligible (2) Computerized provider order entry (CPOE)—Laboratory (i) Technology must enable a user to record, change, and access laboratory orders. (ii) Technology must be able to receive and incorporate a new or updated laboratory order compendium in accordance with the content exchange standard specified in §170.205(l)(2) and, at a minimum, the version of the vocabulary standard in §170.207(c)(3). (iii) Ambulatory setting only. Technology must enable a user to create laboratory orders for electronic transmission in accordance with the content exchange standard specified in §170.205(l)(1) and, at a minimum, the version of the vocabulary standard in §170.207(c)(3).

• Revised certification criterion • Base EHR—Included. To meet BASE EHR definition, CPOE must be certified

to one of the three order types—medication, laboratory, or diagnostic imaging under paragraphs (1), (2) or (3) of proposed §170.315(a)

• For the ambulatory setting only, proposes to adopt HL7 Version 2.5.1 Implementation Guide: S&I Framework Laboratory Orders (LOI) from EHR, Draft Standard for Trial Use, Release 2 – US Realm (“Release 2”)

• For all settings, proposes to adopt o HL7 Version 2.5.1 Implementation Guide: S&I Framework Laboratory

Test Compendium Framework, Release 2, (“electronic Directory of Services (eDOS) IG”)

o LOINC® version 2.50 as the vocabulary standard (which includes CLIA test requisition information (42 CFR 493.1241(c)(1) – (8)) included in the content message)

• Gap certification status: Not Eligible (3) COMPUTERIZED PROVIDER ORDER ENTRY (CPOE)—DIAGNOSTIC IMAGING Technology must enable a user to record, change, and access diagnostic imaging orders.

• Unchanged certification criterion (other than name change) • Base EHR—Included. To meet BASE EHR definition, CPOE must be certified

to one of the three order types—medication, laboratory, or diagnostic imaging • Gap certification status: Eligible

(4) DRUG-DRUG, DRUG-ALLERGY INTERACTION CHECKS FOR CPOE (i) INTERVENTIONS. Before a medication order is completed and acted upon during CPOE, interventions must automatically indicate to a user drug-drug and drug-allergy contraindications based on a patient’s medication list and medication allergy list.

• Revised certification criterion • Proposed new requirements for capabilities to record user actions for interventions

and enable users to view actions taken: o Technology must be able to record at least one action taken in response

to a DDI/DAI check and by whom the action is taken; and

19



Observations

(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. (iii) INTERACTION CHECK RESPONSE DOCUMENTATION. (A) Technology must be able to record at least one action taken and by whom in response to drug-drug or drug-allergy interaction checks. (B) Technology must be able to generate either a human readable display or human readable report of actions taken and by whom in response to drug-drug or drug-allergy interaction checks.

o Technology must be able to generate either a human readable display or human readable report of actions taken and by whom

• ONC does not specify the type of actions the technology must be able to record and seeks comment on the requirement to record actions should be for a subset of DDI/DAI interventions and what sources it should consider to define the subset

• ONC does not seek to infer a specific workflow/user interface, nor does it propose to establish uses for the user action, who should be able to view the information, or who could adjust the capability

• ONC encourages developers to build in functionality to inform users of new or updated DDI/DAI when medication or medication allergy lists are updated; ONC seeks comment on whether this should be a separate certification criterion or built into existing criteria, such as this criterion, clinical decision support, etc.

• Gap certification status: Not Eligible (5) DEMOGRAPHICS (i) Enable a user to record, change, and access patient demographic data including preferred language, sex, race, ethnicity, and date of birth. (A) RACE & ETHNICITY.

(1) Enable each one of a patient’s races [ethnicities] to be recorded in accordance, at a minimum, with the vocabulary standard, specified in §170.207(f)(2) (Race & Ethnicity–CDC code system), and whether a patient declines to specify race. (2) Enable each one of a patient’s ethnicities to be recorded in accordance, at a minimum, with the vocabulary standard, specified in §170.207(f)(2) (Race & Ethnicity–CDC code system), and whether a patient declines to specify ethnicity. (3) Aggregate each one of the patient’s races and ethnicities recorded in accordance with (1) and (2) above to the categories in the vocabulary standard specified in §170.207(f)(1) (OMB code for each race and ethnicity).

(B) Enable preferred language to be recorded in accordance with the vocabulary standard in §170.207(g)(2) (RFC 5646), and whether a patient declines to specify a preferred language. (C) Enable sex to be recorded in accordance with the vocabulary standard in §170.207(n)(1) (HL7 Version 3).

• Revised certification criterion • Base EHR—Included • New standards for recording race and ethnicities

o Minimum vocabulary standard— Race & Ethnicity–CDC code system o Must be able to record each of the patient’s races & ethnicities (ONC

does not expect a drop down menu of 900 entries) o Requirement to aggregate using OMB code for each race & ethnicity

• New standard for recording preferred language—Request for Comments (RFC) 5646 “Tags for Identifying Languages, September 2009” (the certification test would be whether the Module can record preferred language using any of the codes in RFC 5646)

o ONC envisions developer and provider collaboration on appropriate implementation

• New standard for recording sex— HL7 Version 3 (AdministrativeGender) and a nullFlavor value as follows: male (M), female (F), and unknown (UNK)

• ONC notes that for the inpatient setting requirement, it proposes to require the capability that a user be able to record, change and access preliminary cause of death and date of death; the date of death capability was required as part of the 2011 Edition but omitted from the 2014 Edition certification criterion

• Gap certification status: Not Eligible

20



Observations

(ii) Inpatient setting only. Enable a user to record, change, and access the preliminary cause of death and date of death in the event of mortality. (6) VITAL SIGNS, BODY MASS INDEX, AND GROWTH CHARTS (i) VITAL SIGNS. Enable a user to record, change, and access, at a minimum, a patient’s vital signs including, at a minimum, patient's height, weight, diastolic blood pressure, systolic blood pressure, heart rate, respiratory rate, temperature, oxygen saturation in arterial blood by pulse oximetry, body mass index [ratio], and mean blood pressure in accordance with the following

(A)The vocabulary standard specified in § 170.207(k)(1) and with the associated applicable unit of measure for the vital sign in the vocabulary standard specified in § 170.207(m)(1); (B) METADATA. For each vital sign specified above, the technology must also record the following:

(1) Date and time of vital sign measurement or end time of vital sign measurement; (2) The measuring- or authoring-type source of the vital sign measurement; and (3) Optional. Date and time of vital sign measurement or end time of vital sign measurement in accordance with the standard in § 170.210(g); and

(C) Metadata for oxygen saturation in arterial blood by pulse oximetry. For the oxygen saturation in arterial blood by pulse oximetry, the technology must enable a user to record, change, and access the patient’s inhaled oxygen concentration identified, at a minimum, with the version of the vocabulary standard adopt in § 170.207(c)(3) and attributed with LOINC® code 8478-0.

(ii) OPTIONAL – Body mass index percentile per age and sex. Enable a user to record, change, and access a patient’s body mass index [percentile] per age and sex for patients two to twenty years of age in accordance with the following (The patient’s body mass index [percentile] per age and sex must be recorded in numerical values only.):

(A) Identified, at a minimum, with the version of the standard adopt in § 170.207(c)(3) and attributed with LOINC® code 59576-9 and with the associated applicable unit of measure in the standard specified in § 170.207(m)(1); and (B) METADATA. The technology must also record the following:

(1) Date and time of vital sign measurement or end time of vital sign

• Revised certification criterion • Must be capable of recording vital signs natively • Must be capable of recording diastolic and systolic blood pressure separately • Must be able to attribute a specific LOINC® code to each type of vital sign as

follows: o “Systolic blood pressure” with LOINC® code 8480-6; o “Diastolic blood pressure” with LOINC® code 8462-4; o “Body height” with LOINC® code 8302-2; o “Body weight measured” with LOINC® code 3141-9; o “Heart rate” with LOINC® code 8867-4; o “Respiratory rate” with LOINC® code 9279-1; o “Body temperature” with LOINC® code 8310-5; o “Oxygen saturation in arterial blood by pulse oximetry” with LOINC®

code 59408-5; o “Body mass index (BMI) [Ratio]”with LOINC® code 39156-5; and o “Mean blood pressure” with LOINC® code 8478-0

• Vital signs must be able to be recorded with the following metadata: o Date and time of vital sign measurement, or end time of vital sign

measurement, with optional certification in accordance with the clock synchronization standard (§170.210(g));

o The measuring- or authoring-type source of the vital sign measurement (e.g., user who documented the vital sign or the medical device that was used to measure the vital sign); and

o For oxygen saturation, “inhaled oxygen concentration” with LOINC®

code 3150-0. • All units of measures for a vital sign value must be recorded with UCUM Version

1.9. • Optional certification for Pediatric vital signs:

o BMI per age and sex (with LOINC® code 59576-9) for youth 2-20 years of age;

o Weight for length per age and sex (with a LOINC® code to be determined) and/or head occipital-frontal circumference (with LOINC®

21



Observations

measurement; (2) The measuring- or authoring-type source of the vital sign measurement; (3) The patient’s date of birth; (4) The patient’s sex in accordance with the standard specified in § 170.207(n)(1); and (5) Optional. Date and time of vital sign measurement or end time of vital sign measurement in accordance with the standard in § 170.210(g).

(iii) Optional – Weight for length per age and sex. Enable a user to record, change, and access a patient’s weight for length per age and sex for patients less than three years of age in accordance with the following (The patient’s weight for length per age and sex must be recorded in numerical values only.):

(A) Identified, at a minimum, with the version of the standard adopt in § 170.207(c)(3) and attributed with the LOINC® code and with the associated applicable unit of measure in the standard specified in § 170.207(m)(1); and (B) METADATA. The technology must record the following:

(1) Date and time of vital sign measurement or end time of vital sign measurement; (2) The measuring- or authoring-type source of the vital sign measurement; (3) The patient’s date of birth; (4) The patient’s sex in accordance with the standard specified in §170.207(n)(1); and (5) Optional. Date and time of vital sign measurement or end time of vital sign measurement in accordance with the standard in § 170.210(g).

(iv) Optional – Head occipital-frontal circumference. Enable a user to record, change, and access a patient’s head occipital-frontal circumference for patients less than three years of age in accordance with the following (The patient’s head occipital-frontal circumference must be recorded in numerical values only.):

(A) Identified, at a minimum, with the version of the standard adopt in § 170.207(c)(3) and attributed with LOINC® code 8287-5 and with the associated applicable unit of measure in the standard specified in § 170.207(m)(1); and (B) METADATA. The technology must also record the following:

code 8287-5) for infants less than 3 years of age; and o Each optional vital sign value measure must be recorded with UCUM

Version 1.9. • ONC seeks comment on

o Additional vital sign metadata that should be included and the best available standards for representing metadata;

o Which vital signs should include metadata and whether it should be measured or self-reported;

o Feasibility and implementation considerations related to the use of the less granular LOINC® codes, including

Requiring attribution of vital signs using specific LOINC® codes and associated metadata;

Whether the specific LOINC® codes proposed are correct; Standards to record source of vital sign measurement; and Whether the proposal will ensure vital sign data a user enters

will be semantically and syntactically identical to information coming out of the system and being exchanged.

o Should Module be capable of recording metadata specific to particular vital signs findings/results

o Whether the proposed definition of arterial blood oxygen saturation should be presented in a “more method-agnostic way” and whether capture and exchange of more robust metadata should be required


22



Observations

(1) Date and time of vital sign measurement or end time of vital sign measurement; (2) The measuring- or authoring-type source of the vital sign measurement; (3) The patient’s date of birth; (4) The patient’s age in accordance with the vocabulary standard specified in § 170.207(n)(1); and (5) OPTIONAL. Date and time of vital sign measurement or end time of vital sign measurement in accordance with the standard in § 170.210(g).

(v) Optional – Calculate body mass index. Automatically calculate and display body mass index based on a patient's height and weight. (vi) Optional – Plot and display growth charts. Plot and display, upon request, growth charts for patients. (7) PROBLEM LIST Enable a user to record, change, and access a patient’s active problem list: Ambulatory setting. Over multiple encounters in accordance with, at a minimum, the version of the SNOMED CT® vocabulary standard, specified in §170.207(a)(4). Inpatient setting. For the duration of an entire hospitalization in accordance with, at a minimum, the version of the SNOMED CT® vocabulary standard, specified in §170.207(a)(4).

• Revised certification criterion • Base EHR—Included • Would require September 2014 Release of the U.S. Edition of SNOMED CT® as

baseline version vocabulary standard • Gap certification status: Not Eligible

(8) MEDICATION LIST Enable a user to record, change, and access a patient’s active medication list as well as medication history: Ambulatory setting. Over multiple encounters. Inpatient setting. For the duration of an entire hospitalization.

• Unchanged certification criterion • Base EHR—Included • Gap certification status: Eligible

(9) MEDICATION ALLERGY LIST Enable a user to record, change, and access a patient’s active medication allergy list as well as medication allergy history: Ambulatory setting. Over multiple encounters. Inpatient setting. For the duration of an entire hospitalization.

• Unchanged certification criterion • Base EHR—Included • Gap certification status: Eligible

(10) 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

• Revised certification criterion • Base EHR—Included • Requires certification only to the updated Infobutton standard and one of the two

23



Observations

decision support interventions (in addition to drug-drug and drug-allergy contraindication checking) based on each one and at least one combination of the following data: (A) Problem list; (B) Medication list; (C) Medication allergy list; (D) At least one demographic [see paragraph (5) above]; (E) Laboratory tests; and (F) Vital signs. (ii) LINKED REFERENTIAL CLINICAL DECISION SUPPORT.

(A) Technology must be able to identify for a user diagnostic and therapeutic reference information in accordance with the Infobutton functional standard, and implementation standards at §170.204(b)(3) or §170.204(b)(4). (B) For purposes of paragraph (A) immediately above, technology must be able to identify for a user diagnostic or therapeutic reference information based on each one and at least one combination of the following data elements: (1) Problem list; (2) Medication list; and (4) Demographics.

(iii) CLINICAL DECISION SUPPORT CONFIGURATION.

(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) Technology must enable interventions to be

(1) Based on data in (1) Problem list; (2) Medication list; (3) Medication allergy list; (4) Demographics; (5) Laboratory tests and values/results; and (6) Vital signs. (2) When a patient’s medications, medication allergies, problems and laboratory tests and values/results are incorporated from a transition of care/referral summary received pursuant to §170.315(b)(2)(iii)(D) (see below). (3) Ambulatory setting only: When a patient’s laboratory tests and values/results are incorporated pursuant to §170.315(b)(4) (see below).

(iv) CDS INTERVENTION INTERACTION. Interventions provided to a user in clauses (i) through (iii) immediately above must occur when a user is interacting with technology. (v) SOURCE ATTRIBUTES. Enable a user to review the attributes as indicated for

following implementation guides (IGs) o HL7 Implementation Guide: Service Oriented Architecture

Implementations of the Context-aware Knowledge Retrieval (Infobutton) Domain, Release 1, August 2013 (SOA Release 1 IG)

o The updated Infobutton URL-based IG (HL7 Version 3 Implementation Guide: Context-aware Knowledge Retrieval (Infobutton), Release 4, June 2014 (URL-based release 4 IG)

• Clarifies required capability to electronically identify for a user diagnostic and therapeutic reference information in accordance with Infobutton and one of the two IGs (SOA Release 1 IG or URL-based release 4 IG)

• 2014 Edition still permits using the Infobutton standard or another method • Must be able to record at least one action taken (and by whom) when a CDS

intervention is provided to a user. • Must be able to generate either a human readable display or report of the

responses and actions taken (and by whom) when a CDS intervention is provided • In response to confusion about use of the terms automatically and trigger in the

2014 Edition, ONC clarifies that all types of interventions are permitted and there was no intent to be prescriptive on how the interventions are deployed (i.e., triggered, automatically, etc.)

• Clarifies that under the 2014 Edition CDS criterion, technology must enable CDS interventions when a patient’s medications, medication allergies, and problems are incorporated from a transition of care/care referral summary

• ONC seeks comment on whether it should require technology to be able to request patient specific education resources based on a patient’s preferred language under the CDS certification criterion; however, testing and certification would only focus on the ability to make the request using a preferred language


24



Observations

all clinical decision support resources: (A) For evidence-based decision support interventions under clause (i) immediately above,

(1) Bibliographic citation of the intervention (clinical research/guideline); (2) Developer of the intervention (translation from clinical research/guideline); (3) Funding source of intervention development technical implementation; and (4) Release and, if applicable, revision date(s) of the intervention.

(B) For linked referential clinical decision support in clause (ii) immediately above and drug-drug, drug-allergy interaction checks in (4) above, the developer of the intervention, and where clinically indicated, the bibliographic citation of the intervention (clinical research/guideline).

(vi) INTERVENTION RESPONSE DOCUMENTATION. (A) Technology must be able to record at least one action taken and by whom in response to clinical decision support interventions. (B) Technology must be able to generate either a human readable display or human readable report of actions taken and by whom in response to clinical decision support interventions. (11) DRUG-FORMULARY AND PREFERRED DRUG LIST CHECKS Technology must meet one of the following requirements: (i) DRUG FORMULARY CHECK.

(A) Automatically check whether a drug formulary exists for a given patient and medication. (B) Indicate for a user the last update of the drug formulary; and (C) Receive and incorporate a formulary and benefit file in accordance with the NCPDP Formulary and Benefit standard specified in § 170.205(n)(1).

(ii) PREFERRED DRUG LIST CHECK. (A) Automatically check whether a preferred drug list exists for a given patient and medication. (B) Indicate for a user the last update of the preferred drug list.

• Revised certification criterion • Criterion split based on whether drug formularies and preferred drug lists • Preferred drug list included for cases where a health IT system does not use

external drug formularies • Proposes to adopt the NCPDP Formulary and Benefit Standard v3.0 • ONC seeks comment on

o More recent versions of the NCPDP Formulary and Benefit Standard o Whether to adopt versions 4.0, 4.1, or 4.2 of the NCPDP Formulary and

Benefit Standard; and comments on potential system burdens in incorporating formulary and benefit files

o Best standard for individual-level, real-time formulary benefit checking (for patient co-pay use) and

whether to offer health IT certification to the standard whether to include this as a capability under this criterion

25



Observations

whether to establish it as a separate criterion • Gap certification status: Not Eligible

(12) SMOKING STATUS Enable a user to record, change, and access the smoking status of a patient in accordance with, at a minimum, the vocabulary standard specified at §170.207(a)(4).

• Revised certification criterion • Base EHR—Included • Permits certification in any of the available codes for smoking status in, at a

minimum, the September 2014 Release of the U.S. Edition of SNOMED CT® • No longer a proposed meaningful use measure and objective for this requirement • Gap certification status: Not Eligible

(13) IMAGE RESULTS 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.

• Unchanged certification criteria for both settings • Gap certification status: Eligible

(14) FAMILY HEALTH HISTORY Enable a user to record, change, and access a patient’s family health history in accordance with the familial concepts or expressions included in, at a minimum, the version of the vocabulary standard in §170.207(a)(4).

• Revised certification criterion • Would require September 2014 Release of the U.S. Edition of SNOMED CT® as

baseline version vocabulary standard • Gap certification status: Not Eligible

(15) FAMILY HEALTH HISTORY - PEDIGREE Technology must be able to create and incorporate a patient’s family health history in accordance with the content exchange standard and implementation specification specified at §170.205(m)(1).

• Revised certification criterion (formerly part of 2014 Edition Family Health History criterion)

• Must create and incorporate a patient’s family health history according to o HL7 Pedigree IG standard, and o HL7 Pedigree IG, HL7 Version 3 Implementation Guide: Family

History/Pedigree Interoperability, Release 1. • Gap certification status: Not Eligible

(16) PATIENT LIST CREATION Enable a user to dynamically select, sort, access, and create patient list 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) at least one demographic listed in paragraph (5) above, (v) Laboratory tests and values/results, and (vi) FOR THE AMBULATORY SETTING ONLY, patient communication preferences.

• Unchanged certification criterion • Incorporates guidance in FAQ 39 (http://www.healthit.gov/policy-researchers-

implementers/39-question-04-13-039) • Clarifies that technology must be able to use at least one of the more specific data

categories listed under the demographics certification criterion • For ambulatory setting only, requires patient communication preferences • Gap certification status: Eligible

(17) PATIENT-SPECIFIC EDUCATION RESOURCES Technology must be able to: (i) Identify patient-specific education resources based on data included in the

• Revised certification criterion • Requires certification only to the updated Infobutton standard and either SOA

Release 1 IG or URL-based Release 4 IG

http://www.healthit.gov/policy-researchers-implementers/39-question-04-13-039


26



Observations

patient’s problem list and medication list in accordance with the Infobutton functional standard (and implementation standards) at §170.204(b)(3) or (b)(4). (ii) Request that patient-specific education resources be identified in accordance with the vocabulary standard in §170.207(g)(2).

• Eliminates the 2014 Edition requirement for electronically identifying patient-specific education resources based on lab values/results (Infobutton does not support this level of data specificity)

• Technology must be able to request patient-specific education resources based on a patient’s preferred language

o Request must be made in accordance with RFC 5646 o Testing and certification of preferred language would be limited to

the value set of ISO 639-1 o Focus is on the ability to make a request using a preferred language

and Infobutton • Gap certification status: Not Eligible

(18) ELECTRONIC MEDICATION ADMINISTRATION RECORD (i) In combination with an assistive technology that provides automated information on the “rights” specified in (A) through (E) immediately below, enable a user to electronically verify the following before administering medication(s):

(A) Right patient. The patient to whom the medication is to be administered matches the medication to be administered. (B) Right medication. The medication to be administered matches the medication ordered for the patient. (C) Right dose. The dose of the medication to be administered matches the dose of the medication ordered for the patient. (D) Right route. The route of medication delivery matches the route specified in the medication order. (E) Right time. The time that the medication was ordered to be administered compared to the current time.

(ii) RIGHT DOCUMENTATION. Record the time and date in accordance with the protection standard for synchronized clocks, specified in §170.210(g), and user identification when a medication is administered.

• Unchanged certification criterion for inpatient setting • Gap certification status: Eligible

(19) PATIENT HEALTH INFORMATION CAPTURE Technology must be able to enable a user to: (i) Identify, record, and access patient health information documents; (ii) Reference and link to patient health information documents; and (iii) Record and access information directly shared by a patient.

• New certification criterion • Replacement for 2014 Edition advance directive criterion • Technology would have to link to an internet site storing the document; intranet

alone would not suffice • Gap certification status: Not Eligible

27



Observations

(20) IMPLANTABLE DEVICE LIST (i) Enable a user to record, change, and access a list of Unique Device Identifiers associated with a patient’s Implantable Device(s). (ii) Parse the following data elements from a Unique Device Identifier:

(A) Device Identifier; (B) Batch/lot number; (C) Expiration date; (D) Production date; and (E) Serial number.

(iii) Retrieve the “Device Description” attribute associated with a Unique Device Identifier in the Global Unique Device Identification Database (GUDID). (iv) For each Unique Device Identifier in a patient’s list of implantable devices, enable a user to access the following:

(A) The parsed data elements specified under clause (ii) above that are associated with the UDI; and (B) The retrieved data element specified under clause (iii) above.

• New certification criterion • Base EHR—Included • Patient unique device identifier included in the Common Clinical Data Set • Uses FDA definitions of terms • More narrow in scope than what ONC had previously proposed; focuses on

baseline functionality to use and exchange UDIs o Not required to exchange/display contextual information o Not required to capture UDI at point of care


(21) Social, psychological, and behavioral data. Enable a user to record, change, and access, at a minimum, one of the following patient social, psychological, and behavioral data.

(i) SEXUAL ORIENTATION. Enable sexual orientation to be recorded in accordance with the standard specified in §170.207(o)(1) and whether a patient declines to specify sexual orientation. (ii) GENDER IDENTITY. Enable gender identity to be recorded in accordance with the standard specified in §170.207(o)(2) and whether a patient declines to specify gender identity. (iii) FINANCIAL RESOURCE STRAIN. Enable financial resource strain to be recorded in accordance with the standard specified in §170.207(o)(3) and whether a patient declines to specify financial resource strain. (iv) EDUCATION. Enable education to be recorded in accordance with the standard specified in §170.207(o)(4) and whether a patient declines to specify education.

• New certification criterion • Data must be coded at a minimum with version 2.50 of LOINC®; the proposed

rule contains tables with proposed question and answer sets for these elements • Sexual orientation / gender identity must be coded at a minimum with September

2014 Release of the U.S. Edition of SNOMED CT® and HL7 Version 3. ONC seeks comment on whether:

o Appropriate measures are included o Standardized questions for sexual orientation/gender identity should

be used and if so what vocabulary standard is best suited o A minimum number of data measures should be used for

certification o These measures should be a separate certification criterion

• ONC seeks comments on the work information – Industry/occupation (I/O) data measures, including

28



Observations

(v) STRESS. Enable stress to be recorded in accordance with the standard specified in §170.207(o)(5) and whether a patient declines to specify stress. (vi) DEPRESSION. Enable depression to be recorded in accordance with the standard specified in §170.207(o)(6) and whether a patient declines to specify stress. (vii) PHYSICAL ACTIVITY. Enable physical activity to be recorded in accordance with the standard specified in §170.207(o)(7) and whether a patient declines to specify physical activity. (viii) ALCOHOL USE. Enable alcohol use to be recorded in accordance with the standard specified in §170.207(o)(8) and whether a patient declines to specify alcohol use. (ix) SOCIAL CONNECTION AND ISOLATION. Enable social connection and isolation to be recorded in accordance the standard specified in §170.207(o)(9) and whether a patient declines to specify social connection and isolation. (x) EXPOSURE TO VIOLENCE (INTIMATE PARTNER VIOLENCE). Enable exposure to violence (intimate partner violence) to be recorded in accordance with the standard specified in §170.207(o)(10) and whether a patient declines to specify exposure to violence (intimate partner violence).

o What support is needed for developers and users to record, change and access the employment measures

o What experience stakeholders have carrying out these capabilities o For providers,

How useful are these capabilities, and what additional data elements should be provided

How useful is history of positions data element (with data time stamped, linked, retained and accessible

Narrative text versus codes CDC-Census codes, SNOMED CT® codes, and other

standards and codes • ONC seeks comment on data elements for US Uniformed/Military Service:

o Whether the focus should be solely on US Military Service o Whether the applicable SNOMED CT® codes are the most

appropriate o Which concepts/values should ONC use to capture US Military

Service or all uniformed service • ONC seeks comment on what additional data should be included in this criterion • Gap certification status: Not Eligible • No relationship to proposed Stage 3 Objectives, although ONC believes that

patient self-reported responses to the question and answer sets proposed under the criterion could be used for the Stage 3 patient engagement objective, which includes patient-generated health data

(22) Decision support – knowledge artifact. Enable a user to send and receive clinical decision support knowledge artifacts in accordance with the standard specified in §170.204(d)(1).

• New certification criterion • Adopts HL7 Version 3 Standard: Clinical Decision Support Knowledge Artifact

Specification, Release 1.2 DSTU (July 2014) (“HeD standard Release 1.2”) • ONC seeks comment on which specific types of CDS Knowledge Artifacts it

should focus testing and certification to HeD standard Release 1.2 as well as comments on alternative standards

• Gap certification status: Not Eligible (23) Decision support – service. Enable a user to send and receive electronic clinical guidance in accordance with the standard specified in §170.204(e)(1).

• New certification criterion • Adopts HL7 Implementation Guide: Decision Support Service, Release 1.1

(March 2014), US Realm DSTU Specification • Gap certification status: Not Eligible

29


Appendix B—Proposed Care Coordination 2015 Edition EHR Certification Criteria

Proposed 2015 Edition EHR Certification Criteria: CARE COORDINATION

Observations

Health IT must be able to electronically perform the following capabilities under all applicable standards and implementation specifications: Proposed §170.315(b) Care Coordination (1) TRANSITIONS OF CARE (i) SEND AND RECEIVE VIA EDGE PROTOCOL. Technology must be able to:

(A) Send transitions of care/referral summaries through a method that conforms to the standard specified at §170.202(d); and (B) Receive transitions of care/referral summaries through a method that conforms to the standard specified at §170.202(d) from a service that has implemented the standard specified in §170.202(a). (C) XDM processing. Receive and make available the contents of a XDM package formatted in accordance with the standard adopted in § 170.205(p)(1) if the technology is also being certified using an SMTP-based edge protocol.

(ii) VALIDATE AND DISPLAY.

(A) Technology must demonstrate its ability to detect valid and invalid transition of care/referral summaries received and formatted in accordance with both of the standards specified in § 170.205(a)(3) and (4). This includes the ability to:

(1) Parse each of the document types formatted according to the following document templates: CCD; Consultation Note; History and Physical; Progress Note; Care Plan; Transfer Summary; Referral Note, and Discharge Summary. (2) Detect errors in corresponding “document-templates,” “section-templates,” and “entrytemplates,” including invalid vocabulary standards and codes not specified in either of the standards adopted in §170.205(a)(3) and (4); (3) Identify valid document-templates and process the data elements required in the corresponding section-templates and entry-templates from either of the standards adopted in §170.205(a)(3) and (4); (4) Correctly interpret empty sections and null combinations; and (5) Record errors encountered and allow for a user to be notified of or

• Revised certification criterion for both settings • Base EHR—Included • To address “bilateral asynchronous cutover,” technology must demonstrate

conformance and capability to create and parse both versions of the Consolidated CDA standard:

o HL7 Implementation Guide for CDA® Release 2: Consolidated CDA Templates for Clinical Notes (US Realm), Draft Standard for Trial Use, Release 2.0 [C-CDA 2.0]

o HL7 Implementation Guide for CDA® Release 2: IHE Health Story Consolidation, (US Realm) Draft Standard for Trial Use July 2012, DSTU Release 1.1 [C-CDA 1.1]

o ONC seeks comment on alternative approaches for the creation of C-CDA documents

• Technology must detect valid and invalid C-CDA documents, including document, section, and entry level templates for data elements specified in the criterion to demonstrate baseline capability to prepare necessary data for clinical information reconciliation and incorporation. This includes the abilities to:

o Detect invalid C-CDA documents (i.e., data that does not conform to either C-CDA 1.1 or 2.0); invalid vocabularies and codes (i.e., those codes not specified in either C-CDA 1.1 or 2.0)

o Identify valid C-CDA document templates and process required data elements, sections, and entries

o Correctly interpret empty sections and nullFlavor combinations • Technology must support the “IHE XDR profile for Limited Metadata Document

Sources” edge protocol or an SMTP-focused edge protocol (SMTP alone or SMTP in combination with either IMAP4 or POP3).

o For a Health IT Module that is also being certified to the SMTP-based edge, the Module must demonstrate the ability to accept and process an XDM package it receives.

• Includes an updated Common Clinical Data Set with references to new and

30



Observations

review the errors produced. (B) Technology must be able to display in human readable format the data included in transition of care/referral summaries received and formatted according to the standards specified in §170.205(a)(3) and (4). (C) SECTION VIEWS. Allow for individual display each additional section or sections (and the accompanying document header information) that were included in a transition of care/referral summary received and formatted in accordance with either of the standards adopted in §170.205(a)(3) and (4).

(iii) CREATE. (A) Enable a user to create a transition of care/referral summary:

(1) Formatted according to the standards adopted at §170.205(a)(3); (2) Formatted according to the standards adopted at §170.205(a)(4); and (3) Includes, at a minimum, the Common Clinical Data Set and the following data expressed, where applicable, according to the specified standard(s):

(i) ENCOUNTER DIAGNOSES. The standard specified in §170.207(i) or, at a minimum, the version of the standard specified §170.207(a)(4); (ii) Cognitive status; (iii) Functional status; (iv) Ambulatory setting only. The reason for referral; and referring or transitioning provider's name and office contact information; and (v) Inpatient setting only. Discharge instructions.

(B) PATIENT MATCHING DATA QUALITY. Technology must be capable of creating a transition of care/referral summary that includes the following data and, where applicable, represent such data according to the additional constraints specified below:

(1) DATA. First name, last name, maiden name, middle name (including middle initial), suffix, date of birth, place of birth, current address, historical address, phone number, and sex. (2) CONSTRAINT. Represent last/family name according to the CAQH Phase II Core 258: Eligibility and Benefits 270/271 Normalizing Patient Last Name Rule version 2.1.0. (3) CONSTRAINT. Represent suffix according to the CAQH Phase II Core 258: Eligibility and Benefits 270/271 Normalizing Patient Last Name Rule version 2.1.0 (JR, SR, I, II, III, IV, V, RN, MD, PHD, ESQ). If no suffix exists, the field should be entered as null.

updated vocabulary standards code sets • Transition of care/referral summary must include encounter diagnoses using either

o September 2014 Release of the U.S. Edition of SNOMED CT®, or o ICD-10

• Includes a limited set of standardized data for the “create” portion of the criterion; ONC clarifies that the data must be captured when it is exchanged (not upon data entry)

• ONC also seeks comment on: o The proposed approach for patient matching; o Whether if should adopt a separate health IT certification criterion for the

capability to create a summary record formatted to the C-CDA Release 2.0 with or without the ability to meet the requirements of the Common Clinical Data Set definition; and

o With respect to C-CDA data provenance— The maturity and appropriateness of the implementation guide

HL7 IG for CDA Release 2: Data Provenance, Release 1 (US Realm) (DSTU) to tag health information with provenance metadata in connection with C-CDA; and

The usefulness of the IG in connection with certification criteria, such as ToC and View, Download, and Transmit to a 3rd Party (VDT).


31



Observations

(4) CONSTRAINT. Represent the year, month and date of birth as required fields while hour, minute and second should be optional fields. If hour, minute and second are provided then either time zone offset should be included unless place of birth (city, region, country) is provided; in latter local time is assumed. If date of birth is unknown, the field should be marked as null. (5) CONSTRAINT. Represent phone number (home, business, cell) in the ITU format specified in ITU-T E.123 and ITU-T E.164. If multiple phone numbers are present, all should be included. (6) CONSTRAINT. Represent sex in accordance with the standard adopted at §170.207(n)(1).

(2) Clinical information reconciliation and incorporation. (i) GENERAL REQUIREMENTS. Clauses (ii) and (iii) below must be completed based on the receipt of a transition of care/referral summary formatted in accordance with the standard adopted in §170.205(a)(3) as well as separately to the standard adopted in §170.205(a)(4) using the Continuity of Care Document, Discharge Summary Document and Referral Summary document templates. (ii) CORRECT PATIENT. Upon receipt of a transition of care/referral summary formatted according to either of the standards adopted at §170.205(a)(3) or (4), technology must be able to demonstrate that the transition of care/referral summary received is or can be properly matched to the correct patient. (iii) RECONCILIATION. Enable a user to reconcile the data that represent a patient's active medication list, medication allergy list, and problem list as follows. For each list type:

(A) Simultaneously display (i.e., in a single view) the data from at least two sources in a manner that allows a user to view the data and their attributes, which must include, at a minimum, the source and last modification date; (B) Enable a user to create a single reconciled list of medications, medication allergies, or problems; (C) Enable a user to review and validate the accuracy of a final set of data; and (D) Upon a user's confirmation, automatically update the list, and incorporate the following data expressed according to the specified standard(s):

• Revised certification criterion. • Testing would include ability to incorporate valid C-CDAs with variations of data

elements to be reconciled; C-CDA must be created based on reconciliation and incorporation process in order to validate incorporation results

• Technology must be able to reconcile problem, medication, and medication allergy data from valid C-CDAs (both Release 1.1. and 2.0) with variations of data elements to be reconciled and then generate a conformant C-CDA document based on the reconciled information.


32



Observations

(1) MEDICATIONS. At a minimum, the version of the standard specified in §170.207(d)(2); (2) PROBLEMS. At a minimum, the version of the standard specified in §170.207(a)(3); (3) MEDICATION ALLERGIES. At a minimum, the version of the standard specified in §170.207(d)(2).

(iv) SYSTEM VERIFICATION. Based on the data reconciled and incorporated, the technology must be able to create a file formatted according to the standard adopted at § 170.205(a)(4) using the Continuity of Care Document document template.

(3) ELECTRONIC PRESCRIBING (i) Enable a user to prescribe, send, and respond to prescription-related transactions for electronic transmission in accordance with the standard specified at §170.205(b)(2), and, at a minimum, the version of the standard specified in §170.207(d)(3), as follows:

(A) Create new prescriptions (NEWRX); (B) Change prescriptions (RXCHG, CHGRES); (C) Cancel prescriptions (CANRX, CANRES); (D) Refill prescriptions (REFREQ, REFRES); (E) Receive fill status notifications (RXFILL); and (F) Request and receive medication history information (RXHREQ, RXHRES).

(ii) Enable a user to enter, receive, and transmit structured and codified prescribing instructions for the transactions listed in clause (i) above for electronic transmission in accordance with the standard specified at §170.205(b)(2) and, at a minimum, for at least the following component composites: (A) Repeating Sig; (B) Code System; (C) Sig Free Text String; (D) Dose; (E) Dose Calculation; (F) Vehicle; (G) Route of Administration; (H) Site of Administration; (I) Sig Timing; (J) Duration; (K) Maximum Dose Restriction; (L) Indication; and (M) Stop. (iii) Technology must limit a user’s ability to prescribe all medications in only the metric standard.

• Revised certification criterion • Includes additional NCPDP SCRIPT v.10.6 transactions in addition to New

Prescription transaction for testing and certification (see Table 3 of the proposed rule)

o ONC seeks comment on the proposed transactions and segments; on other NCPDP SCRIPT v.10.6 transactions that should be considered; and what factors to consider for end-to-end prescriber-to-receiver testing

• Adopts the February 2, 2015 version of RxNorm as the baseline minimum standards code set for coding medications

• Technology must enable user to enter, receive and transmit codified Sig instructions (i.e., free text format e-prescribing with medication name, dose, route of administration, frequency of administration and other special instructions)

o Structured format in accordance with NCPDP Structured and Codified Sig Format Implementation Guide v1.2 embedded within NCPDP SCRIPT v10.6

o Applies to New, Change, Refill, and Cancel Prescription; Fill Status; and Medication History

o Health IT Module must include all structured Sig segment components enumerated in NCPDP SCRIPT v10.6

o ONC welcomes comment on this proposal • Health IT Module:

o Would limit user’s ability to e-prescribe medications only to the metric standard; and

o Must always be capable of—

33



Observations

(iv) Technology must always insert leading zeroes before the decimal point for amounts less than one and must not allow trailing zeroes after a decimal point when a user prescribes medications.

Inserting leading zeros before the decimal point for amounts less than one; and

Precluding trailing zeros after the decimal point. o ONC welcomes comments, including on the feasibility of the proposal

• Gap certification status: Not Eligible (4) INCORPORATE LABORATORY TESTS AND VALUES/RESULTS (i) RECEIVE RESULTS.

(A) Ambulatory setting only: (1) Receive and incorporate clinical laboratory tests and values/results in accordance with the content exchange standard specified in §170.205(j)(2), and, at a minimum, LOINC® vocabulary standard specified in §170.207(c)(3). (2) Display the tests and values/results received in human readable format. (B) Inpatient setting only: Receive clinical laboratory tests and values/results in a structured format and display such tests and values/results in human readable format.

(ii) Display the test report information:

(A) Specified in 42 CFR 493.1291(a)(1) through (a)(3) and (c)(1) through (c)(7); (B) Related to reference intervals or normal values as specified in 42 CFR 493.1291(d); (C) For alerts and delays as specified in 42 CFR 493.1291(g) and (h); and (D) For corrected reports as specified in 42 CFR 493.1291(k)(2).

(iii) Attribute, associate, or link a laboratory test and value/result with a laboratory order or patient record.

• Revised certification criterion • For the ambulatory setting, adopts the updated version of the implementation

guide: HL7 Version 2.5.1 Implementation Guide: S&I Framework Lab Results Interface, DSTU Release 2 (US Realm) (LRI Release 2)

• Provides more specific requirements for how technology must electronically display information in a test report

• Adopts the updated version of LOINC® vocabulary standard (version 2.50) • ONC seeks comment on EHR-S Functional Requirements of LRI IG/Testing and

Certification requirements (HL7 EHR-S Functional Requirements for the V2.5.1 Implementation Guide: S&I Framework Lab Results Interface R2, Release 1, US Realm, Draft Standard for Trial Use, Release 1 (“EHR-S IG”)) for the following:

o The clarity and completeness of EHR-S IG in describing requirements for receipt and incorporation of lab results to measure conformity of a Health IT Module to LRI Release 2;

o How Modules should be tested and certified consistently and uniformly for incorporation of lab results data; and

o Which specific capabilities included in EHR-S IG should be part of testing and certification for this criterion.


(5) TRANSMISSION OF LABORATORY TESTS REPORTS Technology must be able to electronically create laboratory test reports for electronic transmission in accordance with: (i) The content exchange standard specified in §170.205(j)(2), and, (ii) At a minimum, LOINC® vocabulary standard specified in §170.207(c)(3).

• Revised certification criterion • Adopts HL7 Version 2.5.1 Implementation Guide: S&I Framework Lab Results

Interface, Draft Standard for Trial Use, Release 2, US Realm (“LRI Release 2”) • Adopts the updated version of LOINC® vocabulary standard (version 2.50) • Gap certification status: Not Eligible

34



Observations

(6) DATA PORTABILITY (i) GENERAL REQUIREMENTS FOR EXPORT SUMMARY CONFIGURATION. A user must be able to set the following configuration options when using technology to create an export summary or set of export summaries for patients whose information is stored in the technology. A user must be able to execute these capabilities at any time the user chooses and without subsequent developer assistance to operate. (ii) DOCUMENT CREATION CONFIGURATION

(A) DOCUMENT-TEMPLATE TYPES. A user must be able to configure the technology to create an export summary or export summaries formatted according to the standard adopted at §170.205(a)(4) for any of the following document-template types.

(1) GENERALLY APPLICABLE. CCD; Consultation Note; History and Physical; Progress Note; Care Plan; Transfer Summary; and Referral Note. (2) INPATIENT SETTING ONLY. Discharge Summary.

(B) For any document-template selected the technology must be able to include, at a minimum, the Common Clinical Data Set and the following data expressed, where applicable, according to the specified standard(s):

(1) ENCOUNTER DIAGNOSES. The vocabulary standard specified in §170.207(i) or, at a minimum, the version of the standard at §170.207(a)(4); (2) COGNITIVE STATUS; (3) FUNCTIONAL STATUS; (4) AMBULATORY SETTING ONLY. The reason for referral; and referring or transitioning provider's name and office contact information; and (5) INPATIENT SETTING ONLY. Discharge instructions.

(C) Use of the “unstructured document” document-level template is prohibited for compliance with the standard adopted at §170.205(a)(4)).

(iii) TIMEFRAME CONFIGURATION. A user must be able to configure the technology to set the time period within which data would be used to create the export summary or summaries. This must include the ability to enter in a start and end date range as well as the ability to set a date at least three years into the past from the current date.

• Revised certification criterion • Base EHR—Included • ONC reports both developer “confusion about scope” and providers

dissatisfaction with the technology products; proposes major revisions and greater specificity and emphasizes the following:

o Capability must be user-focused and user driven o User must be able to configure the Health IT Module to create an export

summary for a given patient (or a set of export summaries for as many patients selected).

o Export summaries must be able to create according to the following document templates in C-CDA R2.0: CCD; Consultation Note; History and Physical; Progress Note; Care Plan; Transfer Summary; and Referral Note.

o Requires a minimum data set to be included in export summaries o User must be able to configure the technology to

Set the time period within which data is used to create the export summary; and

Create an export summary based on relative date or time, specific date or time, and when user signs an order or note

o All these capabilities must be configured and executed by the user without help from the developer personnel or the need to ask for developer action

• ONC proposes to adopt two new certification criteria (see paragraphs (7) and (8) immediately below) to separately track (i.e., segment) individually identifiable health information protected by state or federal privacy laws more restrictive than the HIPAA Privacy Rule (one criterion each for send and receipt of the data)


35



Observations

(iv) EVENT CONFIGURATION. A user must be able to configure the technology to create an export summary or summaries based on the following user selected events:

(A) A relative date or time (e.g., the first of every month); (B) A specific date or time (e.g., on 10/24/2015); and (C) When a user signs a note or an order.

(v) LOCATION CONFIGURATION. A user must be able to configure and set the storage location to which the export summary or export summaries are intended to be saved. (7) DATA SEGMENTATION FOR PRIVACY – SEND Technology must enable a user to create a summary record formatted in accordance with each of the standards adopted in §170.205(a)(3) and (4) that is tagged as restricted and subject to restrictions on re-disclosure according to the standard adopted in §170.205(o)(1).

• New certification criterion • Intended to permit users to comply with varying privacy law requirements at the

state and federal level beyond the HIPAA Privacy Rule in an electronic environment

o Applies security labels (privacy metadata) so appropriate access control decisions may be made for downstream use, access or disclosure for specially protected data

o Metadata applied in layers (i.e., at the header, section or entry levels of a C-CDA document)

• Module must be able to send documents using document level tagging • Content exchange standards: both versions of the Consolidated CDA standard:

o HL7 Implementation Guide for CDA® Release 2: Consolidated CDA Templates for Clinical Notes (US Realm), Draft Standard for Trial Use, Release 2.0 [C-CDA 2.0]

o HL7 Implementation Guide for CDA® Release 2: IHE Health Story Consolidation, (US Realm) Draft Standard for Trial Use July 2012, DSTU Release 1.1 [C-CDA 1.1]

• Restrictions on redisclosure context exchange standard: HL7 Implementation Guide: Data Segmentation for Privacy (DS4P), Release 1

• ONC notes that the application of the privacy standard at the document level is an initial step


36



Observations

(8) DATA SEGMENTATION FOR PRIVACY – RECEIVE Technology must enable a user to: (i) Receive a summary record that is tagged as restricted and subject to restrictions on redisclosure according to the standard adopted in §170.205(o)(1); (ii) Apply document-level tagging and sequester the document from other documents received; and (iii) View the restricted document (or data), without incorporating the document (or data).

• New certification criterion • Module must be able to receive privacy data in accordance with HL7

Implementation Guide: Data Segmentation for Privacy (DS4P), Release 1 • Recipient must be able to receive, recognize, and view documents with privacy

metadata tagging indicating certain restrictions with the document sequestered from other health IT data


(9) CARE PLAN Technology must enable a user to record, change, access, create, and receive care plan information in accordance with the Care Plan document template in the standard adopted in §170.205(a)(4).

• New certification criterion • C-CDA Release 2.0 Templates for Clinical Notes includes a Care Plan document

template which provides a structured for documenting information such as goals, health concerns, health status evaluations and outcomes, and interventions

o Is distinct from Plan of Care Section in previous versions of C-CDA • Criterion focuses only on user's ability to record, change, access, create, and

receive care plan information • ONC seeks comment on whether certain optional “Sections” in the template

should be required (e.g., “Health Status Evaluations and Outcomes Section” and “Interventions Section (V2)”) as part of the certification criterion


37


Appendix C—Proposed Clinical Quality Measures 2015 Edition EHR Certification Criteria

Proposed 2015 Edition EHR Certification Criteria: CLINICAL QUALITY MEASURES

Observations

Health IT must be able to electronically perform the following capabilities under all applicable standards and implementation specifications: Proposed §170.315(c) Clinical Quality Measures (1) CLINICAL QUALITY MEASURES – RECORD AND EXPORT (i) RECORD. For each and every CQM for which the technology is presented for certification, the technology must be able to record all of the data that would be necessary to calculate each CQM. Data required for CQM exclusions or exceptions must be codified entries, which may include specific terms as defined by each CQM, or may include codified expressions of “patient reason,” “system reason,” or “medical reason.” (ii) EXPORT. A user must be able to export a data file formatted in accordance with the content exchange standards specified at §170.205(h) for one or multiple patients that includes all of the data captured for each and every CQM to which the technology was certified under clause (i) immediately above. A user must be able to execute this capability at any time the user chooses and without subsequent developer assistance to operate.

• Revised certification criterion • Base EHR—Included • Name change: “Record and export” instead of “Capture and export” • User must be able to export CQM data

o At any time and without subsequent developer assistance beyond normal orientation/training; and

o For one or multiple patients • Because of the timing of the proposed rule and the development (but not

completion) of a harmonized standard for CQM and CDS standards, ONC seeks comment on which of the following content exchange standards it should adopt for this criterion:

o HL7 Implementation Guide for CDA Release 2: Quality Reporting Document Architecture (QRDA), DSTU Release 2 (July 2012);

o HL7 Implementation Guide for CDA Release 2: Quality Reporting Document Architecture (QRDA), DSTU Release 2 (July 2012) and the September 2014 Errata; or

o A QRDA-like standard based on the anticipated Quality Improvement and Clinical Knowledge (QUICK) Fast Health Interoperability Resource (FHIR)-based DSTU.CQM standards

• Gap certification status: Not Eligible (2) CLINICAL QUALITY MEASURES – IMPORT AND CALCULATE (i) IMPORT. Enable a user to import a data file in accordance with the standard specified at § 170.205(h) for one or multiple patients and use such data to perform the capability specified in clause (ii) below. A user must be able to execute this capability at any time the user chooses and without subsequent developer assistance to operate. (ii) Technology must be able to calculate each and every clinical quality measure for which it is presented for certification.

• Revised certification criterion • Name change: “Import and calculate” instead of “Incorporate and calculate” • User must be able to import CQM data

o At any time and without subsequent developer assistance beyond normal orientation/training; and

o For one or multiple patients • Eliminates exception under 2014 Edition; technology for the 2015 Edition must

demonstrate capability to import data even if it is also certified to provide “record and export” and “electronic submission/report” functions

38


Proposed 2015 Edition EHR Certification Criteria: CLINICAL QUALITY MEASURES

Observations

• For testing, the technology must be able to import a larger number of test records and automatically “de-duplicate” them for accurate CQM calculation. ONC seeks comment on an appropriate number of test records

• ONC also solicits comments for the appropriate QRDA standards for this criterion • Gap certification status: Not Eligible

(3) CLINICAL QUALITY MEASURES – ELECTRONIC SUBMISSION [RESERVED; 2014 Edition criterion shown below] Enable a user to electronically create a data file for transmission of clinical quality measurement data: (i) In accordance with the content exchange standards specified at §170.205(h) and (k); and (ii) That can be electronically accepted by CMS.

• ONC will propose a certification policy and associated standards for this criterion in the Medicare proposed and final rulemaking cycles for the Hospital Inpatient Prospective Payment System and the Physician Fee Schedule

• ONC will likely engage in more renaming; this criterion would be referred to as CQM -Report

(4) CLINICAL QUALITY MEASURES –FILTER (i) Technology must be able to record the data listed in clause (iii) below in accordance with the identified standards, where specified. (ii) Technology must be able to filter CQM results at the patient and aggregate levels by each one and any combination of the data listed in clause (iii) below. (iii) DATA. (A) TIN; (B) NPI; (C) Provider type; (D) Patient insurance; (E) Patient age; (F) Patient sex in accordance with, at a minimum, the version of the standard specified in §170.207(n)(1); (G) Patient race and ethnicity in accordance with, at a minimum, the version of the standard specified in §170.207(f)(2); (H) Patient problem list data in accordance with, at a minimum, the version of the standard specified in §170.207(a)(4); and (I) Practice site address..

• New certification criterion • Adopted to respond to newer programs, such as the Pioneer ACO, the PQRS

group practice reporting option, and the Comprehensive Primary Care Initiative which requires performance measurement by eligible practice site rather than by individual practitioners

• Technology must be able to filter by any combination of the data elements (i.e., by any one (e.g., provider type) or a combination of any of the data elements (e.g., combination of TIN and NPI or combination of all data)

• All combinations must be demonstrated for certification • ONC seeks comment on

o With respect to patient insurance, whether other payer value sets (beyond Medicare, Medicaid and another commercial insurance) could be used to support this proposal;

o Whether the Healthcare Provider Taxonomy Code set is appropriate for classifying provider types;

o Standards that could be used to collect practice site address data; o Appropriateness of proposed data elements for CQM filtering and

additional elements that should be included (and standardized vocabularies)


39


Appendix D—Proposed Privacy and Security 2015 Edition EHR Certification Criteria

Proposed 2015 Edition EHR Certification Criteria: PRIVACY AND SECURITY

Observations

Health IT must be able to electronically perform the following capabilities under all applicable standards and implementation specifications: Proposed §170.315(d) Privacy and security (1) AUTHENTICATION, ACCESS CONTROL, AND AUTHORIZATION (i) Verify against a unique identifier(s) (e.g., username or number) that a person seeking access to electronic health information is the one claimed; and (ii) Establish the type of access to electronic health information a user is permitted based on the unique identifier(s) provided in clause (i) above, and the actions the user is permitted to perform with the EHR technology.

• Unchanged certification criterion • Gap certification status: Eligible

(2) AUDITABLE EVENTS AND TAMPER-RESISTANCE (i) RECORD ACTIONS. Technology must be able to:

(A) Record actions related to electronic health information in accordance with the protection standard specified in §170.210(e)(1); (B) Record the audit log status (enabled or disabled) in accordance with the standard specified in §170.210(e)(2) unless it cannot be disabled by any user; and (C) Record the encryption status (enabled or disabled) of electronic health information locally stored on end-user devices by technology in accordance with the standard specified in §170.210(e)(3) unless the technology prevents electronic health information from being locally stored on end-user devices (see paragraph (7) below).

(ii) DEFAULT SETTING. Technology must be set by default to perform the capabilities specified in clause (i)(A) above and, where applicable, clause (i)(B) or (i)(C) (above), or both clauses (i)(B) or (i)(C) (above). (iii) WHEN DISABLING THE AUDIT LOG IS PERMITTED. For each capability specified in clause (i) above that technology permits to be disabled, the ability to do so must be restricted to a limited set of users. (iv) AUDIT LOG PROTECTION. Actions and statuses recorded in accordance with clause (i) above must not be capable of being changed, overwritten, or deleted by the technology. (v) DETECTION. Technology must be able to detect whether the audit log has been altered.

• Unchanged certification criterion • ONC seeks comment on the following:

o Whether it needs to explicitly modify or add to the overall auditing standard at §170.210(e) to record additional data elements for “logging emergency access or user privilege changes” to specifically require auditing of this information or event or whether it is already audited at the point of authentication; the OIG noted in a report that ONC test procedures did not address common security issues;

o Recommended standards for the auditing described above; o Whether there is a critical subset of events for which the audit log may

never be turned off in light of current safeguards limiting the authority to turn off the audit log to a limited set of users. ONC seeks specific comment on whether—

There is an alternative approach; There is a critical subset of events for which the audit log must

always remained enabled (if so which events and why); and There would be negative consequences from keeping an audit

log functionally enabled at all times • Gap certification status: Eligible

(3) AUDIT REPORT(S) • Unchanged certification criterion

40



Observations

Enable a user to create an audit report for a specific time period and to sort entries in the audit log according to each of the data specified in the protection standard at §170.210(e).

• Gap certification status: Eligible

(4) AMENDMENTS Enable a user to select the record affected by a patient’s request for amendment and perform the capabilities specified in clause (i) or (ii) below. (i) ACCEPTED AMENDMENT. For an accepted amendment, append the amendment to the affected record or include a link that indicates the amendment’s location. (ii) DENIED AMENDMENT. For a denied amendment, at a minimum, append the request and denial of the request to the affected record or include a link that indicates this information’s location.

• Unchanged certification criterion • ONC notes that this criterion only partially addresses the amendment of protected

health information requirements under 45 CFR 164.526 • Gap certification status: Eligible

(5) AUTOMATIC LOG-OFF (i) Automatically stop user access to health information after a predetermined period of inactivity. (ii) Require user authentication in order to resume or regain the access that was stopped.

• Unchanged certification criterion • ONC clarifies that this criterion requires a Health IT Module to demonstrate that it

can automatically stop user access to health information after a predetermined period of inactivity and require user authentication to resume or regain the access that was stopped

• ONC does not believe this clarification would impact testing and certification, but it welcomes comments on this issue


(6) EMERGENCY ACCESS Permit an identified set of users to access electronic health information during an emergency.

• Unchanged certification criterion • Gap certification status: Eligible

(7) END-USER DEVICE ENCRYPTION Clause (i) or (ii) below must be met to satisfy this certification criterion. (i) Technology that is designed to locally store electronic health information on end-user devices must encrypt the electronic health information stored on such devices after use of technology on those devices stops.

(A) Electronic health information that is stored must be encrypted in accordance with the protection standard specified in §170.210(a)(3). (B) DEFAULT SETTING. Technology must be set by default to perform this capability and, unless this configuration cannot be disabled by any user, the ability to change the configuration must be restricted to a limited set of

• Unchanged certification criterion • Requires certification to most recent version of Annex A: Approved Security

Functions (Draft, October 8, 2014) for Federal Information Processing Standards (FIPS) Publication 140-2

• ONC does not believe this clarification would impact testing and certification, but it welcomes comments on this issue


41



Observations

identified users. (ii) Technology is designed to prevent electronic health information from being locally stored on end-user devices after use of technology on those devices stops. (8) INTEGRITY (i) Create a message digest in accordance with the protection standard specified in §170.210(c) [(i.e., a hashing algorithm with a security strength equal to or greater than Secure Hash Algorithm (SHA)-1 as specified by the National Institute of Standards and Technology (NIST) in U.S. Federal Information Processing Standard (FIPS) PUB 180-3)]. (ii) Verify in accordance with the protection standard specified in §170.210(c) upon receipt of electronically exchanged health information that such information has not been altered.

• Unchanged certification criterion • ONC proposes a change to the testing and certification: this criterion would be

tested and certified to support the context for which it was adopted – upon receipt of a summary record in order to ensure the integrity of the information exchanged

• ONC believes this criterion would be most frequently paired with the ToC certification criterion for testing and certification

• ONC seeks comment on whether to set the baseline standard as SHA-2 in lieu of the current SHA-1; ONC notes that Microsoft and Google intend to sunset SHA-1 by January 1, 2017; alternatively, ONC could continue the SHA-1 baseline for a period and then shift to SHA-2 beginning in 2017


(9) ACCOUNTING OF DISCLOSURES Record disclosures made for treatment, payment, and health care operations in accordance with the protection standard specified in §170.210(d) (i.e., date, time, patient identification, user identification, and description of the disclosure must be recorded for disclosures for treatment, payment, and health care operations).

• Unchanged certification criterion • Removes “optional” designation since ONC Complete EHRs have been phased

out for the 2015 Edition • Gap certification status: Eligible

42


Appendix E—Proposed Patient Engagement 2015 Edition EHR Certification Criteria

Proposed 2015 Edition EHR Certification Criteria: PATIENT ENGAGEMENT

Observations

Health IT must be able to electronically perform the following capabilities under all applicable standards and implementation specifications: Proposed §170.315(e) Patient Engagement (1) VIEW, DOWNLOAD, AND TRANSMIT TO 3RD PARTY (i) Patients (and their authorized representatives) must be able to use technology to view, download, and transmit their health information to a 3rd party in the manner specified below. Access to these capabilities must be online and through a secure channel that ensures all content is encrypted and integrity-protected in accordance with the standard for encryption and hashing algorithms specified at § 170.210(f). (A) VIEW. Patients (and their authorized representatives) must be able to use health IT to view in accordance with the functional standard adopted at §170.204(a)(1), at a minimum, the following data:

(1) The Common Clinical Data Set (which should be in their English (i.e., non-coded) representation if they associate with a vocabulary/code set). (2) Ambulatory setting only. Provider’s name and office contact information. (3) Inpatient setting only. Admission and discharge dates and locations; discharge instructions; reason(s) for hospitalization. (4) LABORATORY TEST REPORT(S). Laboratory test report(s), including:

(i) The information for a test report as specified all the data specified in 42 CFR 493.1291(c)(1) through (7); (ii) The information related to reference intervals or normal values as specified in 42 CFR 493.1291(d); and (iii) The information for corrected reports as specified in 42 CFR 493.1291(k)(2).

(5) Diagnostic image report(s). (B) DOWNLOAD.

(1) Patients (and their authorized representatives) must be able to use technology to download an ambulatory summary or inpatient summary (as applicable to the health IT setting for which certification is requested) in only human readable format, in only the format specified in accordance to the content exchange standard adopted at §170.205(a)(4), or in both

• Revised certification criteria for both settings • Clarifies focus is on patient use • Includes updated Common Clinical Data Set (CCDS) and updated C-CDA Draft

Standard for Trial Use, Release 2.0 • Technology must make diagnostic image reports (containing a consulting

specialist’s interpretation of image data) available to patient • ONC seeks comment on 4—

o Whether it should require testing and certification for the availability of additional patient data (e.g., encounter diagnoses, cognitive status, functional status, etc.); and

o Whether the technology should permit patients to select information for VDT or API based on a specific date or time, time period, or all available information.

• Requires the same API capabilities as required for CCDS o Requires ONC-ACBs to include hyperlink to allow any party to access

the API’s documentation and terms of use o ONC coordinated with CMS to allow responses to data requests executed

by API functionality to count in the numerator for the VDT meaningful use measure

• Requires that a patient must be able to download an ambulatory or inpatient summary in either, or both, human readable or C-CDA format

o Notes that use of “unstructured document” document-level template is prohibited for compliance with C-CDA Templates for Clinical Notes, DSTU, Release 2.0.

• For the activity history log, adds a new data element: addressee of a transmission of an ambulatory or inpatient summary

• Technology must provide access to patient laboratory test reports that include data specified in 42 CFR 493.1291(c)(1) through (7) as well as information related to reference intervals or normal values and information for corrected reports

• Requires compliance with Web Content Accessibility Guidelines (WCAG) 2.0

43



Observations

formats. The use of the “unstructured document” document-level template is prohibited for compliance with the standard adopted at §170.205(a)(4). (2) When downloaded according to the content exchange standard adopted at §170.205(a)(4), the ambulatory summary or inpatient summary must include, at a minimum, the following data (which, for the human readable version, should be in their English representation if they associate with a vocabulary/code set):

(i) Ambulatory setting only. All of the data elements specified in clauses (A)(1), (A)(2), (A)(4), and (A)(5) above. (ii) Inpatient setting only. All of the data elements specified in clauses (A)(1) and (A)(3) through (A)(5) above.

(3) Inpatient setting only. Patients (and their authorized representatives) must be able to download transition of care/referral summaries that were created as a result of a transition of care (pursuant to the capability expressed in the ToC certification criterion).

(C) TRANSMIT TO THIRD PARTY. Patients (and their authorized representatives) must be able to:

(1) Transmit the ambulatory summary or inpatient summary (as applicable to the health IT setting for which certification is requested) created in clause (B)(2) above in accordance with at least one of the following:

(i) The transport standard specified in §170.202(a). (ii) Through a method that conforms to the standard specified at § 170.202(d) and leads to such summary being processed by a service that has implemented the standard specified in §170.202(a).

(2) Inpatient setting only. Transmit transition of care/referral summaries (as a result of a transition of care/referral) selected by the patient (or their authorized representative) in accordance with at least one of the following:

(i) The standard specified in §170.202(a). (ii) Through a method that conforms to the standard specified at §170.202(d) and leads to such summary being processed by a service that has implemented the standard specified in §170.202(a).

(ii) ACTIVITY HISTORY LOG. (A) When electronic health information is viewed, downloaded, or transmitted to a third-party using the capabilities included in clauses (i)(A) through (i)(C) above or when an application requests electronic health information using the capability specified at clause (iii) below, the

Level A for the “view” capability. ONC seeks comment on appropriateness of adopting WCAG 2.0 Level AA compliance requirements

• ONC notes that there are no separate guidelines for “mobile accessibility” and that it is considered to be covered by WCAG 2.0 guidelines; ONC seeks comments on what challenges exist when applying WCAG 2.0 guidelines to mobile accessibility

• ONC request for comment on Transmit: Whether it would be beneficial to include Direct Project’s Implementation Guide for Direct Project Trust Bundle Distribution specification as part of the certification as well as whether there are any additional requirements needed to support scalable trust between Security/Trust Agents (STAs)

• ONC request for comment C-CDA Creation Capability: Whether there are potential means to provide explicit implementation clarity and consistency; should ONC limit the scope of C-CDA creation capability to focus solely on the creation of a C-CDA document template based on C-CDA Release 2.0

• ONC request for comment C-CDA Data Provenance: With respect to C-CDA data provenance—

o The maturity and appropriateness of the implementation guide HL7 IG for CDA Release 2: Data Provenance, Release 1 (US Realm) (DSTU) to tag health information with provenance metadata in connection with C-CDA; and

o The usefulness of the IG in connection with certification criteria, such as ToC and View, Download, and Transmit to a 3rd Party (VDT)


44



Observations

following information must be recorded and made accessible to the patient: (1) The action(s) (i.e., view, download, transmission, API response) that occurred; (2) The date and time each action occurred in accordance with the protection standard specified at §170.210(g); (3) The user who took the action; and (4) Where applicable, the addressee to whom an ambulatory summary or inpatient summary was transmitted.

(B) Technology presented for certification may demonstrate compliance with clause (ii)(A) above if it is also certified to the certification criterion adopted at §170.315(d)(2) [i.e., auditable events and tamper-resistance] and the information required to be recorded in clause (ii)(A) above is accessible by the patient. (iii) APPLICATION ACCESS. Patients (and their authorized representatives) must be able to use an application that can interact with the following capabilities. Additionally, the following technical outcomes and conditions must be met through the demonstration of an application programming interface (API) that can respond to requests from other applications for data specified within the Common Clinical Data Set. (A) SECURITY. The API must include a means to establish a trusted connection with the application requesting patient data, including a means for the requesting application to register with the data source, be authorized to request data, and log all interactions between the application and the data source. (B) PATIENT SELECTION. The API must include a means for the application to query for an ID or other token of a patient’s record in order to subsequently execute data requests for that record in accordance with subclause (C) below. (C) DATA REQUESTS, RESPONSE SCOPE, AND RETURN FORMAT. The API must enable and support both of the following data request interactions:

(1) DATA-CATEGORY REQUEST. The API must support syntax that allows it to respond to requests for each of the individual data categories specified in the Common Clinical Data Set and return the full set of data for that data category (according to the specified standards, where applicable) in either XML or JSON.

45



Observations

(2) ALL-REQUEST. The API must support syntax that allows it to respond to a request for all of the data categories specified in the Common Clinical Data Set at one time and return such data (according to the specified standards, where applicable) in a summary record formatted according to the standard adopted at §170.205(a)(4).

(D) DOCUMENTATION. The API must include accompanying documentation that contains, at a minimum:

(1) API syntax, function names, required and optional parameters and their data types, return variables and their types/structures, exceptions and exception handling methods and their returns. (2) The software components and configurations that would be necessary for an application to implement in order to be able to successfully interact with the API and process its response(s).

(E) TERMS OF USE. The terms of use for the API must be provided, including, at a minimum, any associated developer policies and required developer agreements. (2) SECURE MESSAGING Enable a user to send messages to, and receive messages from, a patient in a manner that ensures:

(i) Both the patient (or authorized representative) and technology user are authenticated; and (ii) The message content is encrypted and integrity-protected in accordance with the standard for encryption and hashing algorithms specified at §170.210(f) (i.e., any encryption and hashing algorithm identified by NIST as an approved security function in Annex A of FIPS Publication 140-2).

• Unchanged certification criteria for ambulatory setting • Gap certification status: Eligible

46


Appendix F—Proposed Public Health 2015 Edition EHR Certification Criteria

Proposed 2015 Edition EHR Certification Criteria: PUBLIC HEALTH

Observations

Health IT must be able to electronically perform the following capabilities under all applicable standards and implementation specifications: Proposed §170.315(f) Public Health (1) TRANSMISSION TO IMMUNIZATION REGISTRIES (i) Technology must be able to create immunization information for electronic transmission in accordance with:

(A) The standard and applicable implementation specifications specified in §170.205(e)(4); (B) At a minimum, the version of the standard specified in §170.207(e)(3) for historical vaccines; and (C) At a minimum, the version of the standard specified in §170.207(e)(4) for administered vaccines.

(ii) Technology must enable a user to request, access, and display a patient’s evaluated immunization history and the immunization forecast from an immunization registry in accordance with the standard at §170.205(e)(4).

• Revised certification criterion • Updates the content exchange standard implementation guide (HL7 Version 2.5.1:

Implementation Guide for Immunization Messaging, Release 1.5 (October 2014)) • Codes:

o Technology must electronically create immunization information for electronic transmission to immunization registries using NDC codes for vaccines administered

o For historical vaccines, continue use of CVX codes and the HL7 Standard Code Set CVX—Vaccines Administered, updates through February 2, 2015

o ONC seeks comment on whether it should allow use of NDC codes for administered vaccines as an option for certification but continue to require CVX codes for the 2015 Edition

o ONC also seeks comment on whether it should require CVX plus the HL7 Standard Code Set MVX - Manufacturers of Vaccines Code Set (October 30, 2014 version) as an alternative to NDC codes for administered vaccines; ONC also invites comment from providers and developers on implementation burden

o ONC notes that with respect to the Common Clinical Data Set, immunizations must be represented in both CVX and NDC codes

• Technology must enable a user to request, access, and display a patient’s immunization history and forecast from an immunization registry in accordance with the HL7 Version 2.5.1: Implementation Guide for Immunization Messaging, Release 1.5

o ONC seeks comment on this proposal and also on whether it should include an immunization history information reconciliation capability in this criterion and the factors to be considered regarding the reconciliation of immunization history information

• ONC proposes to drop the certification criterion Immunization Information • Gap certification status: Not Eligible

47



Observations

(2) TRANSMISSION TO PUBLIC HEALTH AGENCIES—SYNDROMIC SURVEILLANCE (i) Ambulatory setting only:

(A) Technology must be able to create syndrome-based public health surveillance information for electronic transmission. (B) OPTIONAL. Technology must be able to create syndrome-based public health surveillance information for electronic transmission that contains the following data: (1) Patient demographics; (2) Provider specialty; (3) Provider address; (4) Problem list; (5) Vital signs; (6) Laboratory test values/results; (7) Procedures; (8) Medication list; and (9) Insurance.

(ii) Inpatient setting only. Technology must be able to create syndrome-based public health surveillance information for electronic transmission in accordance with the standard (and applicable implementation specifications) specified in §170.205(d)(4).

• Revised certification criterion • For the inpatient setting, ONC references an updated implementation guide for the

HL7 2.5.1 standard: Public Health Information Network (PHIN) Messaging Guide for Syndromic Surveillance: Emergency Department, Urgent, Ambulatory Care, and Inpatient Settings, Release 2.0, September 2014 (“Release 2.0”)

• For the ambulatory setting, ONC would permit— o The use of any electronic means for sending syndromic surveillance data

to public health agencies (due to the lack of mature IGs); and o Optional certification to certain syndromic surveillance data elements


(3) TRANSMISSION TO PUBLIC HEALTH AGENCIES—REPORTABLE LABORATORY TESTS AND VALUES/RESULTS Technology must be able to create reportable laboratory tests and values/results for electronic transmission in accordance with:

(i) The content exchange standard (and applicable implementation specifications) specified in §170.205(g)(2); and (ii) At a minimum, the versions of the vocabulary standards specified in §170.207(a)(4) and in §170.207(c)(3).

• Revised certification criterion • Renamed to identify the intended recipient of the transmissions • Adopts the following updated standards / IGs:

o CDC content exchange standard implementation guide HL7 Version 2.5.1. Implementation Guide: Electronic Laboratory Reporting to Public Health, Release 2 (US Realm), DSTU R1.1, 2014 (Release 2, DSTU R1.1)

o September 2014 Release of the U.S. Edition of SNOMED CT® o LOINC® version 2.50

• Gap certification status: Not Eligible (4) TRANSMISSION TO CANCER REGISTRIES Technology must be able to create cancer case information for electronic transmission in accordance with:

(i) The content exchange standard (and applicable implementation specifications) specified in §170.205(i)(2); and (ii) At a minimum, the versions of the vocabulary standards specified in §170.207(a)(4) and in §170.207(c)(3).

• Revised certification criterion • Adopts the following updated standards / IGs:

o HL7 Implementation Guide for CDA© Release 2: Reporting to Public Health Cancer Registries from Ambulatory Healthcare Providers Release 1 (HL7 IG Release 1).

o September 2014 Release of the U.S. Edition of SNOMED CT® o LOINC® version 2.50

• ONC proposes to drop the certification criterion Cancer Case Information • Gap certification status: Not Eligible

48



Observations

(5) TRANSMISSION TO PUBLIC HEALTH AGENCIES – CASE REPORTING Technology must be able to create case reporting information for electronic transmission in accordance with the standard specified in § 170.205(q)(1).

• New certification criterion • Standard: IHE Quality, Research, and Public Health Technical Framework

Supplement, Structured Data Capture, Trial Implementation (September 5, 2014) o Requires compliance with existing standards, such as CDA Release 2 o Technology must be able to create and send a constrained ToC document

to a public health agency; accept a URL in return; direct end users to the URL; and adhere to security requirements for transmission

• ONC seeks comment on whether it should adopt HL7 FHIR Implementation Guide: Structure Data Capture (SDC), Release 1 (with a DSTU ballot planned for mid-2015) as a replacement for, or in addition to, the IHE standard above

• Gap certification status: Not Eligible (6) TRANSMISSION TO PUBLIC HEALTH AGENCIES – ANTIMICROBIAL USE AND RESISTANCE REPORTING Technology must be able to create antimicrobial use and resistance reporting information for electronic transmission in accordance with the standard specified in § 170.205(r)(1).

• New certification criterion • Standard: HL7 Implementation Guide for CDA® Release 2 – Level 3: Healthcare

Associated Infection Reports, Release 1, U.S. Realm (August 2013) • Testing and certification will include conformance with the following sections of

the IG: o HAI Antimicrobial Use and Resistance (AUR) Antimicrobial Resistance

Option (ARO) Report (Numerator) specific document template in Section 2.1.2.1 (pages 69-72);

o Antimicrobial Resistance Option (ARO) Summary Report (Denominator) specific document template in Section 2.1.1.1 (pages 54-56);

o Antimicrobial Use (AUP) Summary Report (Numerator and Denominator) specific document template in Section 2.1.1.2 (pages 56-58); and

o All named constraints within the specified document template • Gap certification status: Not Eligible

(7) TRANSMISSION TO PUBLIC HEALTH AGENCIES – HEALTH CARE SURVEYS Technology must be able to create health care survey information for electronic transmission in accordance with the standard specified in § 170.205(s)(1).

• New certification criterion • Standard: HL7 Implementation Guide for CDA® Release 2: National Health Care

Surveys (NHCS), Release 1 - US Realm, DSTU (December 2014) • ONC clarifies that the IG is intended to transmit survey data for both the National

Ambulatory Medical Care Survey (NAMCS) and the National Hospital Ambulatory Medical Care Survey (NHAMCS)


49


Appendix G—Proposed Design and Performance 2015 Edition EHR Certification Criteria

Proposed 2015 Edition EHR Certification Criteria: DESIGN AND PERFORMANCE

Observations

Health IT must be able to electronically perform the following capabilities under all applicable standards and implementation specifications: Proposed §170.315(g) Design and Performance (1) AUTOMATED NUMERATOR RECORDING For each meaningful use objective with a percentage-based measure, technology must be able to create a report or file that enables a user to review the patients or actions that would make the patient or action eligible to be included in the measure's numerator. The information in the report or file created must be of sufficient detail such that it enables a user to match those patients or actions to meet the measure’s denominator limitations when necessary to generate an accurate percentage.

• Unchanged certification criterion • Test procedure would be different to be consistent with applicable MU objectives

and measures • Gap certification status: Eligibility is fact specific

(2) AUTOMATED MEASURE CALCULATION For each meaningful use objective with a percentage-based measure that is supported by a capability included in a technology, record the numerator and denominator and create a report including the numerator, denominator, and resulting percentage associated with each applicable meaningful use measure.

• Unchanged certification criterion • Technology must support all CMS-acceptable approaches for numerator and

denominator measurement • ONC proposes to apply its interpretation of the requirement in FAQ 32

[http://www.healthit.gov/policy-researchers-implementers/32-question-11-12-032] • Test procedure would be different to be consistent with applicable MU objectives

and measures • Gap certification status: Eligibility is fact specific

(3) SAFETY-ENHANCED DESIGN (i) User-centered design (UCD) processes must be applied to each capability a technology includes that is specified in the following certification criteria: paragraphs (a)(1) through (10) and (18), (20), (22), (23), and (b)(2) through (4) above. (ii) The following information must be submitted on the user-centered design processed used:

(A) Name, description and citation (ULR and/or publication citation) for an industry or federal government standard; or (B) Name the process(es), provide an outline of the process(es), a short description of the process(es), and an explanation of the reason(s) why use of any of the existing user-centered design standards was impractical.

• Revised certification criterion • Adds seven new criteria: demographics, vital signs, problem list, implantable

device list, decision support – knowledge artifact, decision support – service, and incorporate laboratory tests/results

o ONC seeks comment on criteria that should be included on the list • Clarifies (in §170.315(g)(3)(iii)) that findings must be submitted for each and

every one of the listed criteria and that the findings become part of the publicly available test results on the CHPL

o ONC recommends a cohort of test participants of not less than 15 for each category of anticipated clinical end users for critical tasks where user interface design could impact patient safety; cohorts should not include employees of the developer

o ONC seeks comment on whether it should establish a minimum cohort number in regulations


50



Observations

(iii) The following information/sections from NISTIR 7742 must be submitted for each capability to which user-centered design processes were applied:

(A) Name and version of the product; date and location of the test; test environment; description of the intended users; and total number of participants; (B) Description of participants, including: sex; age; education; occupation/role; professional experience; computer experience; and product experience; (C) Description of the user tasks that were tested and association of each task to corresponding certification criteria; (D) List of the specific metrics captured during the testing, including; task success (%); task failures (%); task standard deviations (%); task performance time; and user satisfaction rating (based on a scale with 1 as very difficult and 5 as very easy); (E) Test results for each task using metrics listed above in clause (ii)(A) through (D); (F) Results and data analysis narrative, including: major test finding; effectiveness; efficiency; satisfaction; and areas for improvement.

(iv) Submit test scenarios used in summative usability testing.

• ONC seeks comment on options in lieu of or in addition to summative testing; developers believe that summative testing may not adequately reflect the design research throughout a product’s lifecycle

• ONC-ACBs should be notified when an adaptation or update changes user-interface aspects of one or more capabilities of health IT to which UCD has been applied

• Gap certification status: Eligibility is fact specific

(4) QUALITY MANAGEMENT SYSTEM (i) For each capability that a technology includes and for which that capability's certification is sought, the use of a Quality Management System (QMS) in the development, testing, implementation, and maintenance of that capability must be identified that is:

(A) Compliant with a QMS established by the Federal government or a standards developing organization; or (B) Mapped to one or more QMS established by the Federal government or standards developing organization(s).

(ii) If a single QMS was used for applicable capabilities, it would only need to be identified once. (iii) If different QMS were applied to specific capabilities, each QMS applied would need to be identified.

• Revised certification criteria for both settings • All Health IT Modules must be certified to this criterion • Requires the identification of the QMS use to develop, test, implement, and

maintain certified capabilities • Permits use of a recognized federal or standards developing organization QMS or

mapping to one or more of such a QMS • Gap certification status: Not Eligible

(5) ACCESSIBILITY TECHNOLOGY COMPATIBILITY For each capability technology includes that is specified in the certification

• New certification criterion • Applicable to Health IT Modules presented for certification to clinical, care

51



Observations

criteria at paragraphs (a), (b), and (e) of this section, the capability must be compatible with at least one accessibility technology that includes text-to-speech functionality.

coordination, and patient engagement criteria • Intended to ensure health IT is accessible to visually impaired and disabled

individuals • Developers need not license or provide the accessibility technology to users • Accessibility technology must be identified in testing report and would be

publicly available as part of information on the CHPL • ONC seeks comment on the extent to which this criterion would help in

complying with federal and state disability laws and whether this would serve as a valuable market distinction for developers and consumers

• Gap certification status: Not Eligible (6) CONSOLIDATED CDA CREATION PERFORMANCE The following technical and performance outcomes must be demonstrated related to Consolidated CDA creation. The capabilities required under clause (i) through (iii) below can be demonstrated in tandem and do not need to be individually addressed in isolation or sequentially. (i) REFERENCE C-CDA MATCH. Upon the entry of clinical data consistent with the Common Clinical Data Set, the technology must be able to create a data file formatted in accordance with each of the standards adopted in §170.205(a)(3) and (4) that matches a gold-standard, reference data file. (ii) DOCUMENT-TEMPLATE CONFORMANCE. Upon the entry of clinical data consistent with the Common Clinical Data Set, the technology must be able to create a data file formatted in accordance with each of the standards adopted in §170.205(a)(3) and (4) that demonstrates a valid implementation of each of the following document templates (as applicable to the adopted standard):

(A) Generally applicable. CCD; Consultation Note; History and Physical; Progress Note; Care Plan; Transfer Summary; and Referral Note. (B) Inpatient setting only. Discharge Summary.

(iii) VOCABULARY CONFORMANCE. Upon the entry of clinical data consistent with the Common Clinical Data Set, the technology must be able to create a data file formatted in accordance with each of the standards adopted in §170.205(a)(3) and (4) that demonstrates the required vocabulary standards (and value sets) are properly implemented.

• New certification criterion • New performance standard focused on health IT system behavior and performance

for C-CDA creation; intended to rigorously assess a product’s C-CDA creation performance (for both C-CDA Release 1.1 and 2.0) for any criterion requiring C-CDA creation

• ONC-ACBs may not issue a certification to a product requiring C-CDA creation unless it is tested and satisfied to this criterion

o Where a product has multiple criteria requiring C-CDA creation, testing would only be required for one of those criteria; ONC seeks comment on this

• Reference C-CDA match to gold standard, reference data file includes the 2014 and 2015 edition data elements coded according to HL 7 C-CDA standards and regulatory requirements proposed for the Common Clinical Data Set definition

• Document-template conformance must be both C-CDA 1.1 and 2.0 standards • Vocabulary conformance requires the health IT to be formatted using vocabulary

and value sets adopted under the 2014 and 2015 edition. • ONC seeks comments on whether it should add additional requirements to

evaluate the completeness of the data included in a C-CDA order to ensure the data recorded by health IT is equivalent to the data included in a created C-CDA


52



Observations

(7) APPLICATION ACCESS TO COMMON CLINICAL DATA SET The following technical outcomes and conditions must be met through the demonstration of an application programming interface (API) that can respond to requests from other applications for data specified within the Common Clinical Data Set. (i) SECURITY. The API must include a means to establish a trusted connection with the application requesting patient data, including a means for the requesting application to register with the data source, be authorized to request data, and log all interactions between the application and the data source. (ii) PATIENT SELECTION. The API must include a means for the application to query for an ID or other token of a patient’s record in order to subsequently execute data requests for that record in accordance with paragraph (g)(7)(iii) of this section. (iii) DATA REQUESTS, RESPONSE SCOPE, AND RETURN FORMAT. The API must enable and support both of the following data request interactions:

(A) DATA-CATEGORY REQUEST. The API must support syntax that allows it to respond to requests for each of the individual data categories specified in the Common Clinical Data Set and return the full set of data for that data category (according to the specified standards, where applicable) in either XML or JSON. (B) ALL-REQUEST. The API must support syntax that allows it to respond to a request for all of the data categories specified in the Common Clinical Data Set at one time and return such data (according to the specified standards, where applicable) in a summary record formatted according to the standard adopted at § 170.205(a)(4).

(iv) DOCUMENTATION. The API must include accompanying documentation that contains, at a minimum:

(A) API syntax, function names, required and optional parameters and their data types, return variables and their types/structures, exceptions and exception handling methods and their returns.

• New certification criterion • Base EHR—Included • Focus is on ability of health IT to respond to requests for patient data from other

applications for any one or more (or all) of the Common Clinical Data Set data • ONC believes this provides developers with sufficient flexibility to implement

APIs that best suit customer needs • Intent of the criterion is to allow (but not require) developers to implement the

Fast Health Interoperability Resource (FHIR®) REST API and accompanying FHIR standard specifications; ONC seeks comment if the specifications in this criterion do not accomplish this

• Technical documentation and terms of use must be submitted as part of testing o ONC-ACBs must include a hyperlink as part of the product’s

certification on the CHPL to permit interested party to see the documentation and terms of use

• ONC seeks comment on the following: o Possible additional requirements to ensure an open ecosystem around

APIs so patients may share their information with tools they choose; o The feasibility of additional API capabilities under this criterion,

including secure message read/write capability, schedule read/write capability, ordering/e-prescribing capability, and task list read/write capability; and

o Potential ways to provide explicit implementation clarity and consistency for the C-CDA Creation capability—should the capability be limited to the creation of a C-CDA document template based on Release 2.0


53



Observations

(B) The software components and configurations that would be necessary for an application to implement in order to be able to successfully interact with the API and process its response(s).

(v) TERMS OF USE. The terms of use for the API must be provided, including, at a minimum, any associated developer policies and required developer agreements. (8) ACCESSIBILITY-CENTERED DESIGN For each capability that a Health IT Module includes and for which that capability’s certification is sought, the use of a health IT accessibility-centered design standard or law in the development, testing, implementation and maintenance of that capability must be identified. (i) If a single accessibility-centered design standard or law was used for applicable capabilities, it would only need to be identified once. (ii) If different accessibility-centered design standards and laws were applied to specific capabilities, each accessibility-centered design standard or law applied would need to be identified. This would include the application of an accessibility-centered design standard or law to some capabilities and none to others. (iii) If no accessibility-centered design standard or law was applied to all applicable capabilities such a response is acceptable to satisfy this certification criterion.

• New certification criterion • All Health IT Modules must be certified to this criterion; ONC seeks comment on

whether it should limit the certification criteria to which this criterion would apply • Requires identification of user-centered design standards or laws for accessibility

applied (or complied with) in the development of specific capabilities included in a Health IT; would also require identification of failure to apply or comply with such standards or laws

• Intended to increase transparency around application of user-centered design standards for accessibility to health IT and compliance of health IT with accessibility laws

• In conjunction with NIST, ONC provides a list of those standards and laws in the proposed rule; ONC seeks comment on whether the items in the list are appropriate

• ONC would permit a response that “no health IT accessibility-centered design standard or law was applied to all applicable capabilities” to satisfy the criterion


54


Appendix H—Proposed Transport Methods and Other Protocols 2015 Edition EHR Certification Criteria

Proposed 2015 Edition EHR Certification Criteria: TRANSPORT METHODS AND OTHER PROTOCOLS

Observations

Health IT must be able to electronically perform the following capabilities under all applicable standards and implementation specifications: Proposed §170.315(h) Transport Methods and Other Protocols (1) DIRECT PROJECT (i) APPLICABILITY STATEMENT FOR SECURE HEALTH TRANSPORT Technology must be able to send and receive health information in accordance with the standards specified in §170.202(a). (ii) OPTIONAL – APPLICABILITY STATEMENT FOR SECURE HEALTH TRANSPORT AND DELIVERY NOTIFICATION IN DIRECT. Technology must be able to send and receive health information in accordance with the standard specified in §170.202(e)(1).

• Unchanged certification criteria for both settings • Base EHR—Included. Technology must be certified to this criterion or to (h)(2)

below • Enables technology to be tested and certified to send and receive according to the

Applicability Statement for Secure Health Transport (the primary Direct Project specification)

• Provides an optional capability for certification: to send and receive according to the Implementation Guide for Delivery Notification in Direct, Version 1.0, June 29, 2012; this IG provides enables Security/Trust Agents (STAs) to provide high level of assurance that a message has arrived at its destination as well as success/failure notices to the sender (e.g., that lab results are received by a provider)

• Gap certification status: Eligible (2) DIRECT PROJECT, EDGE PROTOCOL, AND XDR/XDM Technology must be able to send and receive health information in accordance with: (i) The standards specified in §170.202(a); (ii) The standard specified in §170.202(b); and (iii) Both edge protocol methods specified by the standard in §170.202(d).

• Unchanged certification criteria for both settings • Base EHR—Included. Technology must be certified to this criterion or to (h)(1)

above • Enables technology to be tested and certified to send and receive according to the

o The Applicability Statement for Secure Health Transport (the primary Direct Project specification),

o Both Edge Protocols methods; and o The XDR and XDM for Direct Messaging Specification

• Gap certification status: Eligible (3) SOAP TRANSPORT AND SECURITY SPECIFICATION AND XDR/XDM FOR DIRECT MESSAGING Technology must be able to send and receive health information in accordance with the standards specified in §170.202(b) and (c).

• Unchanged certification criteria for both settings • Enables EHR technology to be tested and certified to send and receive according

to the: o The Transport and Security Specification (the SOAP-Based Secure

Transport RTM), and o The XDR and XDM for Direct Messaging Specification


55


Proposed 2015 Edition EHR Certification Criteria: TRANSPORT METHODS AND OTHER PROTOCOLS

Observations

(4) HEALTHCARE PROVIDER DIRECTORY – QUERY REQUEST In accordance with the standard specified in §170.202(f)(1), technology must be able to make, at a minimum, the following queries to a directory and subsequently process the response returned:

(i) Query for an individual provider; (ii) Query for an organizational provider; (iii) Query for both individual and organizational providers in a single query; and (iv) Query for relationships between individual and organizational providers. (v) OPTIONAL- FEDERATION. In accordance with the standard specified in §170.202(f)(1), technology must be able to process federated responses.

• New certification criterion • The HITPC recommended adoption of provider directory capabilities • Technology must be able to query a provider using the Integrating the Healthcare

Enterprise (IHE) Healthcare Provider Directory (HPD) directory • Optional capability: Module must follow an approved federated IHE HPD

o Federated meaning the ability to query individual directory sources and directory sources federated by third parties (e.g., HIOs, RHIOs, HISPs)

• Criterion establish a minimum set of queries that technology must support: querying individual and organizational providers (including in a single query); querying provider relationships; and electronically processing the response per the IHE HDP Profile

• Gap certification status: Not Eligible (5) HEALTHCARE PROVIDER DIRECTORY – QUERY RESPONSE In accordance with the standard specified in §170.202(f)(1), technology must be able to, at a minimum, respond to the following queries to a directory:

(i) Query for an individual provider; (ii) Query for an organizational provider; (iii) Query for both individual and organizational providers in a single query; and (iv) Query for relationships between individual and organizational providers. (v) OPTIONAL- FEDERATION. In accordance with the standard specified in §170.202(f)(1), technology must be able to federate queries to other directories.

• New certification criterion • Companion criterion to query request criterion above • Separation of query request and response intended to provide flexibility for

developers; technology may be presented for one or both criteria • Technology must support responding to same queries initiated by systems that

seek certification to the query request criterion for interoperability • Must respond to queries using the IHE HDP Profile • Similar optional capability to address federated requirements (which is

incorporated in IHE HDP Profile) • Gap certification status: Not Eligible

56


Appendix I—Proposed Administrative 2015 Edition EHR Certification Criteria

Proposed 2015 Edition EHR Certification Criteria: ADMINISTRATIVE

Observations

Health IT must be able to electronically perform the following capabilities under all applicable standards and implementation specifications: Proposed §170.315(i) Administrative (1) ELECTRONIC SUBMISSION OF MEDICAL DOCUMENTATION (i) DOCUMENT TEMPLATES. Health IT must be able to create electronic documents for transmission formatted according to the following standard and applicable implementation specifications adopted at §170.205(a)(4) and (a)(5)(i). With respect to §170.205(a)(5)(i):

(A) Health IT must be able to create the following document types, regardless of the setting for which it is designed: Diagnostic Imaging Report; Unstructured Document; Enhanced Operative Note Document; Enhanced Procedure Note Document; and Interval Document. (B) Ambulatory setting only. Health IT must be able to create an Enhanced Encounter Document. (C) Inpatient setting only. Health IT must be able to create an Enhanced Hospitalization Document.

(ii) DIGITAL SIGNATURE. (A) APPLYING A DIGITAL SIGNATURE. Technology must be able to apply a digital signature in accordance with the implementation specification adopted at §170.205(a)(5)(ii) to a document formatted according to the following standard and applicable implementation specifications adopted at §170.205(a)(4) and (a)(5)(i). It must also be able to demonstrate that it can support the method for delegation of right assertions.

(1) The cryptographic module used as part of the technology must: be validated to meet or exceed FIPS 140-2 Level 1; include a digital signature system and hashing that are compliant with FIPS 186-2 and FIPS 180-2; and store the private key in a FIPS-140-2 Level 1 validated cryptographic module using a FIPS-approved encryption algorithm. This requirement may be satisfied through documentation only. (2) Technology must support multi-factor authentication that meets or exceeds Level 3 assurance as defined in NIST Special Publication 800-63-2. (3) After ten minutes of inactivity, technology must require the certificate

• New certification criterion • CMS and ONC established the Electronic Submission of Medical Documentation

(esMD) initiative for use cases and standards for electronic exchange of medical documentation among providers and Medicare review contractors, including for purposes of prior authorization and pre- and post-payment review

• The esMD criterion includes four capabilities: creation of document templates; embed a digital signature in a CDA document; create and transmit external digital signatures for documents; and create and transmit external digital signatures for electronic transactions for purpose of data integrity and non-repudiation authenticity

• Capability 1-Document templates: o The proposed IG: HL7 Implementation Guide for CDA Release 2:

Additional CDA R2 Templates – Clinical Documents for Payers – Set 1, Release 1 – US Realm in combination with the C-CDA Release 2.0 standard (CDP1 IG)

o Intended to exchange comprehensive clinical information, including information provider needs to substantiate medical necessity

o When provider applies a digital signature, the result is a non-repudiation declaration of the encounter information

o Technology must create a document conforming to the CDP1 IG along with appropriate use of nullFlavors as well as generate document level templates (including the unstructured document)

o Health IT designed for the ambulatory setting would also need to be certified to the Enhanced Encounter Document

o Health IT designed for the inpatient setting would also need to be certified to the Enhanced Hospitalization Document

• Capability 2-Digital Signatures: o The proposed IG: HL7 Implementation Guide for CDA Release 2:

Digital Signatures and Delegation of Rights, Release 1 (DSDR IG) o DSDR IG defines a method to embed digital signatures in a CDA

57


Proposed 2015 Edition EHR Certification Criteria: ADMINISTRATIVE

Observations

holder to re-authenticate to access the private key. (4) If implemented as a software function, the system must clear the plain text private key from the system memory to prevent the unauthorized access to, or use of, the private key when the signing module is deactivated. (5) Technology must record time and date consistent with the standard adopted at §170.210(g).

(B) VALIDATING A DIGITAL SIGNATURE. Technology must be able validate a digital signature that has been applied to a document according to the implementation specification adopted at §170.205(a)(5)(ii). (iii) AUTHOR OF RECORD LEVEL 1. Using the same system capabilities expressed in clause (ii) above, technology must be able to apply a digital signature according to the implementation specification adopted at §170.205(a)(5)(iii) to sign single or bundles of documents a document formatted according to the following standard and applicable implementation specifications adopted at §170.205(a)(4) and (a)(5)(i). (iv) TRANSACTIONS. Using the same system capabilities expressed in clause (ii) above, technology must be able to apply a digital signature according to the implementation specification adopted at §170.205(a)(5)(iv) to a transaction and include the signature as accompanying metadata in the signed transaction.

document and includes an optional method to specify delegation of rights assertions (which must be included to meet the criterion)

o Permits accurate authentication (and validation) of signatures and signers o Must meet requirements relating to cryptographic module, multi-factor

authentication, inactivity period (10 minutes), prevent unauthorized access to the plain text private key, and synced with the NIST time source.

• Capability 3-External Digital Signatures: o The proposed IG: Author of Record Level 1: Implementation Guide o Provides ability to digitally sign one document or multiple documents

and embed the W3C compliant XADES signature in a signature document that may accompany the signed documents or as a “wrapper” for the documents

• Capability 4-Data integrity and non-repudiation authenticity: o The proposed IG: Provider Profiles Authentication: Registration

Implementation Guide o Functionality uses the W3C compliant XADES digital signature standard

to sign the contents of an electronic transaction and include the signature as accompanying metadata in the signed transaction to ensure the non-repudiation identity of the sender and that the recipient can validate the authenticity and integrity of the transaction information
