Home
gpo.gov
govinfo.gov

e-CFR Navigation Aids

Browse

Simple Search

Advanced Search

 — Boolean

 — Proximity

 

Search History

Search Tips

Corrections

Latest Updates

User Info

FAQs

Agency List

Incorporation By Reference

eCFR logo

Related Resources

Electronic Code of Federal Regulations

We invite you to try out our new beta eCFR site at https://ecfr.federalregister.gov. We have made big changes to make the eCFR easier to use. Be sure to leave feedback using the Help button on the bottom right of each page!

You are now viewing previous e-CFR data


   

Now viewing e-CFR data in effect on June 19, 2019

Title 45Subtitle ASubchapter D → Part 170


Title 45: Public Welfare


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


Contents

Subpart A—General Provisions

§170.100   Statutory basis and purpose.
§170.101   Applicability.
§170.102   Definitions.

Subpart B—Standards and Implementation Specifications for Health Information Technology

§170.200   Applicability.
§170.202   Transport standards and other protocols.
§170.204   Functional standards.
§170.205   Content exchange standards and implementation specifications for exchanging electronic health information.
§170.207   Vocabulary standards for representing electronic health information.
§170.210   Standards for health information technology to protect electronic health information created, maintained, and exchanged.
§170.299   Incorporation by reference.

Subpart C—Certification Criteria for Health Information Technology

§170.300   Applicability.
§§170.302-170.306   [Reserved]
§170.314   2014 Edition electronic health record certification criteria.
§170.315   2015 Edition health IT certification criteria.

Subpart D [Reserved]

Subpart E—ONC Health IT Certification Program

§170.500   Basis and scope.
§170.501   Applicability.
§170.502   Definitions.
§170.503   Requests for ONC-AA status and ONC-AA ongoing responsibilities.
§170.504   Reconsideration process for requests for ONC-AA status.
§170.505   Correspondence.
§170.510   Authorization scope for ONC-ACB status.
§170.511   Authorization scope for ONC-ATL status.
§170.520   Application.
§170.523   Principles of proper conduct for ONC-ACBs.
§170.524   Principles of proper conduct for ONC-ATLs.
§170.525   Application submission.
§170.530   Review of application.
§170.535   ONC-ACB and ONC-ATL application reconsideration.
§170.540   ONC-ACB and ONC-ATL status.
§170.545   Complete EHR certification.
§170.550   Health IT Module certification.
§170.553   [Reserved]
§170.555   Certification to newer versions of certain standards.
§170.556   In-the-field surveillance and maintenance of certification for Health IT.
§170.557   Authorized testing and certification methods.
§170.560   Good standing as an ONC-ACB or ONC-ATL.
§170.565   Revocation of ONC-ACB or ONC-ATL status.
§170.570   Effect of revocation on the certifications issued to Complete EHRs and EHR Module(s).
§170.575   Removal of the ONC-AA.
§170.580   ONC review of certified health IT.
§170.581   Certification ban.
§170.599   Incorporation by reference.

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

Source: 75 FR 2042, Jan. 13, 2010, unless otherwise noted.

return arrow Back to Top

Subpart A—General Provisions

return arrow Back to Top

§170.100   Statutory basis and purpose.

The provisions of this subchapter implement sections 3001(c)(5) and 3004 of the Public Health Service Act.

[75 FR 36203, June 24, 2010]

return arrow Back to Top

§170.101   Applicability.

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

return arrow Back to Top

§170.102   Definitions.

For the purposes of this part:

2014 Edition Base EHR means an electronic record of health-related information on an individual that:

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

(2) Has the capacity:

(i) To provide clinical decision support;

(ii) To support physician order entry;

(iii) To capture and query information relevant to health care quality;

(iv) To exchange electronic health information with, and integrate such information from other sources;

(v) To protect the confidentiality, integrity, and availability of health information stored and exchanged; and

(3) Has been certified to the certification criteria adopted by the Secretary:

(i) For at least one of the four criteria adopted at §170.314(a)(1), (18), (19), or (20);

(ii) At §170.314(a)(3);

(iii) At §170.314(a)(5) through (8);

(iv) Both §170.314(b)(1) and (2); or, both §170.314(b)(8) and (h)(1); or §170.314(b)(1) and (2) combined with either §170.314(b)(8) or (h)(1), or both §170.314(b)(8) and (h)(1);

(v) At §170.314(b)(7);

(vi) At §170.314(c)(1) through (3);

(vii) At §170.314(d)(1) through (8);

(4) Has been certified to the certification criteria at §170.314(c)(1) and (2):

(i) For no fewer than 9 clinical quality measures covering at least 3 domains from the set selected by CMS for eligible professionals, including at least 6 clinical quality measures from the recommended core set identified by CMS; or

(ii) For no fewer than 16 clinical quality measures covering at least 3 domains from the set selected by CMS for eligible hospitals and critical access hospitals.

2014 Edition EHR certification criteria means the certification criteria at §170.314.

2015 Edition Base EHR means an electronic record of health-related information on an individual that:

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

(2) Has the capacity:

(i) To provide clinical decision support;

(ii) To support physician order entry;

(iii) To capture and query information relevant to health care quality;

(iv) To exchange electronic health information with, and integrate such information from other sources; and

(3) Has been certified to the certification criteria adopted by the Secretary in §170.315(a)(1), (2), or (3); (a)(5) through (9); (a)(11); (a)(14); (b)(1) and (6); (c)(1); (g)(7) through (9); and (h)(1) or (2);

2015 Edition health IT certification criteria means the certification criteria in §170.315.

Certification criteria means criteria:

(1) To establish that health information technology meets applicable standards and implementation specifications adopted by the Secretary; or

(2) That are used to test and certify that health information technology includes required capabilities.

Common Clinical Data Set means the following data expressed, where indicated, according to the specified standard(s):

(1) Patient name. For certification to both the 2014 Edition EHR certification criteria and the 2015 Edition health IT certification criteria.

(2) Sex. (i) No required standard for certification to the 2014 Edition EHR certification criteria.

(ii) The standard specified in §170.207(n)(1) for certification to the 2015 Edition health IT certification criteria.

(3) Date of birth. For certification to both the 2014 Edition EHR certification criteria and the 2015 Edition health IT certification criteria.

(4) Race. (i) The standard specified in §170.207(f)(1) for certification to the 2014 Edition EHR certification criteria.

(ii) For certification to the 2015 Edition health IT certification criteria:

(A) The standard specified in §170.207(f)(2);

(B) The standard specified in §170.207(f)(1) for each race identified in accordance §170.207(f)(2).

(5) Ethnicity. (i) The standard specified in §170.207(f)(1) for certification to the 2014 Edition EHR certification criteria.

(ii) For certification to the 2015 Edition health IT certification criteria:

(A) The standard specified in §170.207(f)(2);

(B) The standard specified in §170.207(f)(1) for each ethnicity identified in accordance §170.207(f)(2).

(6) Preferred language. (i) The standard specified in §170.207(g)(1) for certification to the 2014 Edition EHR certification criteria.

(ii) The standard specified in §170.207(g)(2) for certification to the 2015 Edition Health IT certification criteria.

(7) Smoking status. For certification to both the 2014 Edition EHR certification criteria and the 2015 Edition health IT certification criteria: The standard specified in §170.207(h).

(8) Problems. (i) At a minimum, the standard specified in §170.207(a)(3) for certification to the 2014 Edition EHR certification criteria.

(ii) At a minimum, the standard specified in §170.207(a)(4) for certification to the 2015 Edition Health IT certification criteria.

(9) Medications. (i) At a minimum, the standard specified in §170.207(d)(2) for certification to the 2014 Edition EHR certification criteria.

(ii) At a minimum, the standard specified in §170.207(d)(3) for certification to the 2015 Edition Health IT certification criteria.

(10) Medication allergies. (i) At a minimum, the standard specified in §170.207(d)(2) for certification to the 2014 Edition EHR certification criteria.

(ii) At a minimum, the standard specified in §170.207(d)(3) for certification to the 2015 Edition Health IT certification criteria.

(11) Laboratory test(s). (i) At a minimum, the standard specified in §170.207(c)(2) for certification to the 2014 Edition EHR certification criteria.

(ii) At a minimum, the standard specified in §170.207(c)(3) for certification to the 2015 Edition Health IT certification criteria.

(12) Laboratory value(s)/result(s). For certification to both the 2014 Edition EHR certification criteria and the 2015 Edition health IT certification criteria.

(13) Vital signs. (i) Height/length, weight, blood pressure, and BMI for certification to the 2014 Edition EHR certification criteria.

(ii) For certification to the 2015 Edition Health IT certification criteria:

(A) The patient's diastolic blood pressure, systolic blood pressure, body height, body weight, heart rate, respiratory rate, body temperature, pulse oximetry, and inhaled oxygen concentration must be exchanged in numerical values only; and

(B) In accordance with the standard specified in §170.207(c)(3) and with the associated applicable unit of measure for the vital sign measurement in the standard specified in §170.207(m)(1).

(C) Optional. The patient's BMI percentile per age and sex for youth 2-20 years of age, weight for age per length and sex for children less than 3 years of age, and head occipital-frontal circumference for children less than 3 years of age must be recorded in numerical values only in accordance with the standard specified in §170.207(c)(3) and with the associated applicable unit of measure for the vital sign measurement in the standard specified in §170.207(m)(1). For BMI percentile per age and sex for youth 2-20 years of age and weight for age per length and sex for children less than 3 years of age, the reference range/scale or growth curve should be included as appropriate.

(14) Care plan field(s), including goals and instructions. For certification to the 2014 Edition EHR certification criteria.

(15) Procedures—(i)(A) At a minimum, the version of the standard specified in §170.207(a)(3) for certification to the 2014 Edition EHR certification criteria and §170.207(a)(4) for certification to the 2015 Edition health IT certification criteria, or §170.207(b)(2); or

(B) For technology primarily developed to record dental procedures, the standard specified in §170.207(b)(3) for certification to both the 2014 Edition EHR certification criteria and the 2015 Edition health IT certification criteria.

(ii) Optional. The standard specified in §170.207(b)(4) for certification to both the 2014 Edition EHR certification criteria and the 2015 Edition health IT certification criteria.

(16) Care team member(s). For certification to both the 2014 Edition EHR certification criteria and the 2015 Edition health IT certification criteria.

(17) Immunizations. In accordance with, at a minimum, the standards specified in §170.207(e)(3) and (4) for certification to the 2015 Edition health IT certification criteria.

(18) Unique device identifier(s) for a patient's implantable device(s). In accordance with the “Product Instance” in the “Procedure Activity Procedure Section” of the standard specified in §170.205(a)(4) for certification to the 2015 Edition health IT certification criteria.

(19) Assessment and plan of treatment. For certification to the 2015 Edition health IT certification criteria:

(i) In accordance with the “Assessment and Plan Section (V2)” of the standard specified in §170.205(a)(4); or

(ii) In accordance with the “Assessment Section (V2)” and “Plan of Treatment Section (V2)” of the standard specified in §170.205(a)(4).

(20) Goals. In accordance with the “Goals Section” of the standard specified in §170.205(a)(4) for certification to the 2015 Edition health IT certification criteria.

(21) Health concerns. In accordance with the “Health Concerns Section” of the standard specified in §170.205(a)(4) for certification to the 2015 Edition health IT certification criteria.

Complete EHR, 2014 Edition means EHR technology that meets the Base EHR definition and has been developed to meet, at a minimum, all mandatory 2014 Edition EHR certification criteria for either an ambulatory setting or inpatient setting

Day or Days means a calendar day or calendar days.

Device identifier is defined as it is in 21 CFR 801.3.

Disclosure is defined as it is in 45 CFR 160.103.

Global Unique Device Identification Database (GUDID) is defined as it is in 21 CFR 801.3.

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

Human readable format means a format that enables a human to read and easily comprehend the information presented to him or her regardless of the method of presentation.

Implantable device is defined as it is in 21 CFR 801.3.

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

Production identifier is defined as it is in 21 CFR 801.3.

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

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

(2) Has the capacity:

(i) To provide clinical decision support;

(ii) To support physician order entry;

(iii) To capture and query information relevant to health care quality; and

(iv) To exchange electronic health information with, and integrate such information from other sources.

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

Unique device identifier is defined as it is in 21 CFR 801.3.

[75 FR 2042, Jan. 13, 2010, as amended at 75 FR 36203, June 24, 2010; 75 FR 44649, July 28, 2010; 77 FR 54283, Sept. 4, 2012; 78 FR 65887, Nov. 4, 2013; 79 FR 52933, Sept. 4, 2014; 79 FR 54477, 54478, Sept. 11, 2014; 80 FR 62741, Oct. 16, 2015; 80 FR 76871, Dec. 11, 2015]

return arrow Back to Top

Subpart B—Standards and Implementation Specifications for Health Information Technology

Source: 75 FR 44649, July 28, 2010, unless otherwise noted.

return arrow Back to Top

§170.200   Applicability.

The standards and implementation specifications adopted in this part apply with respect to Complete EHRs and Health IT Modules.

[75 FR 44649, July 28, 2010, as amended at 80 FR 62743, Oct. 16, 2015]

return arrow Back to Top

§170.202   Transport standards and other protocols.

The Secretary adopts the following transport standards:

(a) Direct Project—(1) Standard. ONC Applicability Statement for Secure Health Transport, Version 1.0 (incorporated by reference in §170.299).

(2) Standard. ONC Applicability Statement for Secure Health Transport, Version 1.2 (incorporated by reference in §170.299).

(b) Standard. ONC XDR and XDM for Direct Messaging Specification (incorporated by reference in §170.299).

(c) Standard. ONC Transport and Security Specification (incorporated by reference in §170.299).

(d) Standard. ONC Implementation Guide for Direct Edge Protocols (incorporated by reference in §170.299).

(e) Delivery notification—(1) Standard. ONC Implementation Guide for Delivery Notification in Direct (incorporated by reference in §170.299).

(2) [Reserved]

[77 FR 54284, Sept. 4, 2012, as amended at 79 FR 54478, Sept. 11, 2014; 80 FR 62743, Oct. 16, 2015]

return arrow Back to Top

§170.204   Functional standards.

The Secretary adopts the following functional standards:

(a) Accessibility—(1) Standard. Web Content Accessibility Guidelines (WCAG) 2.0, Level A Conformance (incorporated by reference in §170.299).

(2) Standard. Web Content Accessibility Guidelines (WCAG) 2.0, Level AA Conformance (incorporated by reference in §170.299).

(b) Reference source. Standard. HL7 Version 3 Standard: Context-Aware Retrieval Application (Infobutton) (incorporated by reference in §170.299). (1) Implementation specifications. HL7 Version 3 Implementation Guide: URL-Based Implementations of the Context-Aware Information Retrieval (Infobutton) Domain, (incorporated by reference in §170.299).

(2) Implementation specifications. HL7 Implementation Guide: Service-Oriented Architecture Implementations of the Context-aware Knowledge Retrieval (Infobutton) Domain, Draft Standard for Trial Use, Release 1 (incorporated by reference in §170.299).

(3) Standard. HL7 Version 3 Standard: Context Aware Knowledge Retrieval Application. (“Infobutton”), Knowledge Request, Release 2 (incorporated by reference in §170.299). Implementation specifications. HL7 Implementation Guide: Service-Oriented Architecture Implementations of the Context-aware Knowledge Retrieval (Infobutton) Domain, Release 1 (incorporated by reference in §170.299).

(4) Standard. HL7 Version 3 Standard: Context Aware Knowledge Retrieval Application (“Infobutton”), Knowledge Request, Release 2 (incorporated by reference in §170.299). Implementation specifications. HL7 Version 3 Implementation Guide: Context-Aware Knowledge Retrieval (Infobutton), Release 4 (incorporated by reference in §170.299).

(c) Clinical quality measure-by-measure data. Data Element Catalog, (incorporated by reference in §170.299).

[77 FR 54284, Sept. 4, 2012, as amended at 80 FR 62743, Oct. 16, 2015]

return arrow Back to Top

§170.205   Content exchange standards and implementation specifications for exchanging electronic health information.

The Secretary adopts the following content exchange standards and associated implementation specifications:

(a) Patient summary record—(1) Standard. Health Level Seven Clinical Document Architecture (CDA) Release 2, Continuity of Care Document (CCD) (incorporated by reference in §170.299). Implementation specifications. The Healthcare Information Technology Standards Panel (HITSP) Summary Documents Using HL7 CCD Component HITSP/C32 (incorporated by reference in §170.299).

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

(3) Standard. HL7 Implementation Guide for CDA® Release 2: IHE Health Story Consolidation, (incorporated by reference in §170.299). The use of the “unstructured document” document-level template is prohibited.

(4) Standard. HL7 Implementation Guide for CDA® Release 2: Consolidated CDA Templates for Clinical Notes (US Realm), Draft Standard for Trial Use, Volume 1—Introductory Material, Release 2.1 and HL7 Implementation Guide for CDA® Release 2: Consolidated CDA Templates for Clinical Notes (US Realm), Draft Standard for Trial Use, Volume 2—Templates and Supporting Material, Release 2.1 (incorporated by reference in §170.299).

(b) Electronic prescribing. (1) [Reserved]

(2) Standard. NCPDP SCRIPT Standard, Implementation Guide, Version 10.6 (incorporated by reference in §170.299).

(c) [Reserved]

(d) Electronic submission to public health agencies for surveillance or reporting. (1) [Reserved]

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

(3) Standard. HL7 2.5.1 (incorporated by reference in §170.299). Implementation specifications. PHIN Messaging Guide for Syndromic Surveillance (incorporated by reference in §170.299) and Conformance Clarification for EHR Certification of Electronic Syndromic Surveillance, Addendum to PHIN Messaging Guide for Syndromic Surveillance (incorporated by reference in §170.299).

(4) Standard. HL7 2.5.1 (incorporated by reference in §170.299). Implementation specifications. PHIN Messaging Guide for Syndromic Surveillance: Emergency Department, Urgent Care, Inpatient and Ambulatory Care Settings, Release 2.0, April 21, 2015 (incorporated by reference in §170.299) and Erratum to the CDC PHIN 2.0 Implementation Guide, August 2015; Erratum to the CDC PHIN 2.0 Messaging Guide, April 2015 Release for Syndromic Surveillance: Emergency Department, Urgent Care, Inpatient and Ambulatory Care Settings (incorporated by reference in §170.299).

(e) Electronic submission to immunization registries. (1) [Reserved]

(2) [Reserved]

(3) Standard. HL7 2.5.1 (incorporated by reference in §170.299). Implementation specifications. HL7 2.5.1 Implementation Guide for Immunization Messaging, Release 1.4, (incorporated by reference in §170.299).

(4) Standard. HL7 2.5.1 (incorporated by reference in §170.299). Implementation specifications. HL7 2.5.1 Implementation Guide for Immunization Messaging, Release 1.5 (incorporated by reference in §170.299) and HL7 Version 2.5.1 Implementation Guide for Immunization Messaging (Release 1.5)—Addendum, July 2015 (incorporated by reference in §170.299).

(f) [Reserved]

(g) Electronic transmission of lab results to public health agencies. Standard. HL7 2.5.1 (incorporated by reference in §170.299). Implementation specifications. HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health, Release 1 (US Realm) (incorporated by reference in §170.299) with Errata and Clarifications, (incorporated by reference in §170.299) and ELR 2.5.1 Clarification Document for EHR Technology Certification, (incorporated by reference in §170.299).

(h) Clinical quality measure data import, export and reporting—(1) Standard. HL7 Implementation Guide for CDA® Release 2: Quality Reporting Document Architecture (incorporated by reference in §170.299).

(2) Standard. HL7 CDA® R2 Implementation Guide: Quality Reporting Document Architecture—Category I (QRDA I); Release 1, DSTU Release 3 (US Realm), Volume 1—Introductory Material and HL7 CDA® R2 Implementation Guide: Quality Reporting Document Architecture—Category I (QRDA I); Release 1, DSTU Release 3 (US Realm), Volume 2—Templates and Supporting Material (incorporated by reference in §170.299).

(i) Cancer information—(1) Standard. HL7 Clinical Document Architecture (CDA), Release 2.0, Normative Edition (incorporated by reference in §170.299). Implementation specifications. Implementation Guide for Ambulatory Healthcare Provider Reporting to Central Cancer Registries, HL7 Clinical Document Architecture (CDA), Release 1.0 (incorporated by reference in §170.299).

(2) Standard. HL7 Clinical Document Architecture (CDA), Release 2.0, Normative Edition (incorporated by reference in §170.299). Implementation specifications. HL7 CDA© Release 2 Implementation Guide: Reporting to Public Health Cancer Registries from Ambulatory Healthcare Providers, Release 1; DSTU Release 1.1, Volume 1—Introductory Material and HL7 CDA© Release 2 Implementation Guide: Reporting to Public Health Cancer Registries from Ambulatory Healthcare Providers, Release 1; DSTU Release 1.1 (US Realm), Volume 2—Templates and Supporting Material (incorporated by reference in §170.299).

(j) Electronic incorporation and transmission of lab results. Standard. HL7 Version 2.5.1 Implementation Guide: S&I Framework Lab Results Interface, (incorporated by reference in §170.299).

(k) Clinical quality measure aggregate reporting—(1) Standard. Quality Reporting Document Architecture Category III, Implementation Guide for CDA Release 2 (incorporated by reference in §170.299).

(2) Standard. Errata to the HL7 Implementation Guide for CDA® Release 2: Quality Reporting Document Architecture—Category III, DSTU Release 1 (US Realm), September 2014 (incorporated by reference in §170.299).

(l)-(n) [Reserved]

(o) Data segmentation for privacy—(1) Standard. HL7 Implementation Guide: Data Segmentation for Privacy (DS4P), Release 1 (incorporated by reference in §170.299).

(2) [Reserved]

(p) XDM package processing—(1) Standard. IHE IT Infrastructure Technical Framework Volume 2b (ITI TF-2b) (incorporated by reference in §170.299).

(2) [Reserved]

(q) [Reserved]

(r) Public health—antimicrobial use and resistance information—(1) Standard. The following sections of HL7 Implementation Guide for CDA® Release 2—Level 3: Healthcare Associated Infection Reports, Release 1, U.S. Realm (incorporated by reference in §170.299). Technology is only required to conform to the following sections of the implementation guide:

(i) HAI Antimicrobial Use and Resistance (AUR) Antimicrobial Resistance Option (ARO) Report (Numerator) specific document template in Section 2.1.2.1 (pages 69-72);

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

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

(2) [Reserved]

(s) Public health—health care survey information—(1) Standard. HL7 Implementation Guide for CDA® Release 2: National Health Care Surveys (NHCS), Release 1—US Realm, HL7 Draft Standard for Trial Use, Volume 1—Introductory Material and HL7 Implementation Guide for CDA® Release 2: National Health Care Surveys (NHCS), Release 1—US Realm, HL7 Draft Standard for Trial Use, Volume 2—Templates and Supporting Material (incorporated by reference in §170.299).

(2) [Reserved]

[75 FR 44649, July 28, 2010, as amended at 75 FR 62690, Oct. 13, 2010; 77 FR 54284, Sept. 4, 2012; 79 FR 54478, Sept. 11, 2014; 80 FR 62743, Oct. 16, 2015]

return arrow Back to Top

§170.207   Vocabulary standards for representing electronic health information.

The Secretary adopts the following code sets, terminology, and nomenclature as the vocabulary standards for the purpose of representing electronic health information:

(a) Problems. (1) [Reserved]

(2) [Reserved]

(3) Standard. IHTSDO SNOMED CT® International Release July 2012 (incorporated by reference in §170.299) and US Extension to SNOMED CT® March 2012 Release (incorporated by reference in §170.299).

(4) Standard. IHTSDO SNOMED CT®, U.S. Edition, September 2015 Release (incorporated by reference in §170.299).

(b) Procedures. (1) [Reserved]

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

(3) Standard. The code set specified at 45 CFR 162.1002(a)(4).

(4) Standard. The code set specified at 45 CFR 162.1002(c)(3) for the indicated procedures or other actions taken.

(c) Laboratory tests. (1) [Reserved]

(2) Standard. Logical Observation Identifiers Names and Codes (LOINC®) Database version 2.40, a universal code system for identifying laboratory and clinical observations produced by the Regenstrief Institute, Inc. (incorporated by reference in §170.299).

(3) Standard. Logical Observation Identifiers Names and Codes (LOINC®) Database version 2.52, a universal code system for identifying laboratory and clinical observations produced by the Regenstrief Institute, Inc. (incorporated by reference in §170.299).

(d) Medications. (1) [Reserved]

(2) Standard. RxNorm, a standardized nomenclature for clinical drugs produced by the United States National Library of Medicine, August 6, 2012 Release (incorporated by reference in §170.299).

(3) Standard. RxNorm, a standardized nomenclature for clinical drugs produced by the United States National Library of Medicine, September 8, 2015 Release (incorporated by reference in §170.299).

(e) Immunizations. (1) [Reserved]

(2) Standard. HL7 Standard Code Set CVX—Vaccines Administered, updates through July 11, 2012 (incorporated by reference in §170.299).

(3) Standard. HL7 Standard Code Set CVX—Vaccines Administered, updates through August 17, 2015 (incorporated by reference in §170.299).

(4) Standard. National Drug Code Directory (NDC)—Vaccine NDC Linker, updates through August 17, 2015 (incorporated by reference in §170.299).

(f) Race and Ethnicity—(1) Standard. The Office of Management and Budget Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity, Statistical Policy Directive No. 15, as revised, October 30, 1997 (incorporated by reference in §170.299).

(2) Standard. CDC Race and Ethnicity Code Set Version 1.0 (March 2000) (incorporated by reference in §170.299).

(g) Preferred language—(1) Standard. As specified by the Library of Congress, ISO 639-2 alpha-3 codes limited to those that also have a corresponding alpha-2 code in ISO 639-1 (incorporated by reference in §170.299).

(2) Standard. Request for Comments (RFC) 5646 (incorporated by reference in §170.299).

(h) Smoking status. Standard. Smoking status must be coded in one of the following SNOMED CT® codes:

(1) Current every day smoker. 449868002

(2) Current some day smoker. 428041000124106

(3) Former smoker. 8517006

(4) Never smoker. 266919005

(5) Smoker, current status unknown. 77176002

(6) Unknown if ever smoked. 266927001

(7) Heavy tobacco smoker. 428071000124103

(8) Light tobacco smoker. 428061000124105

(i) Encounter diagnoses. Standard. The code set specified at 45 CFR 162.1002(c)(2) for the indicated conditions.

(j) Family health history. HL7 Version 3 Standard: Clinical Genomics; Pedigree, (incorporated by reference in §170.299).

(k)-(l) [Reserved]

(m) Numerical references—(1) Standard. The Unified Code of Units of Measure, Revision 1.9 (incorporated by reference in §170.299).

(2) [Reserved]

(n) Sex—(1) Standard. Birth sex must be coded in accordance with HL7 Version 3 Standard, Value Sets for AdministrativeGender and NullFlavor (incorporated by reference in §170.299), attributed as follows:

(i) Male. M

(ii) Female. F

(iii) Unknown. nullFlavor UNK

(2) [Reserved]

(o) Sexual orientation and gender identity—(1) Standard. Sexual orientation must be coded in accordance with, at a minimum, the version of SNOMED CT® codes specified in paragraph (a)(4) of this section for paragraphs (o)(1)(i) through (iii) of this section and HL7 Version 3 Standard, Value Sets for AdministrativeGender and NullFlavor (incorporated by reference in §170.299), for paragraphs (o)(1)(iv) through (vi) of this section, attributed as follows:

(i) Lesbian, gay or homosexual. 38628009

(ii) Straight or heterosexual. 20430005

(iii) Bisexual. 42035005

(iv) Something else, please describe. nullFlavor OTH

(v) Don't know. nullFlavor UNK

(vi) Choose not to disclose. nullFlavor ASKU

(2) Standard. Gender identity must be coded in accordance with, at a minimum, the version of SNOMED CT® codes specified in paragraph (a)(4) of this section for paragraphs (o)(2)(i) through (v) of this section and HL7 Version 3 Standard, Value Sets for AdministrativeGender and NullFlavor (incorporated by reference in §170.299), for paragraphs (o)(2)(vi) and (vii) of this section, attributed as follows:

(i) Male. 446151000124109

(ii) Female. 446141000124107

(iii) Female-to-Male (FTM)/Transgender Male/Trans Man. 407377005

(iv) Male-to-Female (MTF)/Transgender Female/Trans Woman. 407376001

(v) Genderqueer, neither exclusively male nor female. 446131000124102

(vi) Additional gender category or other, please specify. nullFlavor OTH

(vii) Choose not to disclose. nullFlavor ASKU

(p) Social, psychological, and behavioral data—(1) Financial resource strain. Financial resource strain must be coded in accordance with, at a minimum, the version of LOINC® codes specified in paragraph (c)(3) of this section and attributed with the LOINC® code 76513-1 and LOINC® answer list ID LL3266-5.

(2) Education. Education must be coded in accordance with, at a minimum, the version of LOINC® codes specified in paragraph (c)(3) of this section and attributed with LOINC® code 63504-5 and LOINC® answer list ID LL1069-5.

(3) Stress. Stress must be coded in accordance with, at a minimum, the version of LOINC® codes specified in paragraph (c)(3) of this section and attributed with the LOINC® code 76542-0 and LOINC® answer list LL3267-3.

(4) Depression. Depression must be coded in accordance with, at a minimum, the version of LOINC® codes specified in paragraph (c)(3) of this section and attributed with LOINC® codes 55757-9, 44250-9 (with LOINC® answer list ID LL358-3), 44255-8 (with LOINC® answer list ID LL358-3), and 55758-7 (with the answer coded with the associated applicable unit of measure in the standard specified in §170.207(m)(1)).

(5) Physical activity. Physical activity must be coded in accordance with, at a minimum, the version of LOINC® codes specified in paragraph (c)(3) of this section and attributed with LOINC® codes 68515-6 and 68516-4. The answers must be coded with the associated applicable unit of measure in the standard specified in §170.207(m)(1).

(6) Alcohol use. Alcohol use must be coded in accordance with, at a minimum, the version of LOINC® codes specified in paragraph (c)(3) of this section and attributed with LOINC® codes 72109-2, 68518-0 (with LOINC® answer list ID LL2179-1), 68519-8 (with LOINC® answer list ID LL2180-9), 68520-6 (with LOINC® answer list ID LL2181-7), and 75626-2.

(7) Social connection and isolation. Social connection and isolation must be coded in accordance with, at a minimum, the version of LOINC® codes specified in paragraph (c)(3) of this section and attributed with the LOINC® codes 76506-5, 63503-7 (with LOINC answer list ID LL1068-7), 76508-1 (with the associated applicable unit of measure in the standard specified in §170.207(m)(1)), 76509-9 (with the associated applicable unit of measure in the standard specified in §170.207(m)(1)), 76510-7 (with the associated applicable unit of measure in the standard specified in §170.207(m)(1)), 76511-5 (with LOINC answer list ID LL963-0), and 76512-3 (with the associated applicable unit of measure in the standard specified in §170.207(m)(1)).

(8) Exposure to violence (intimate partner violence). Exposure to violence: Intimate partner violence must be coded in accordance with, at a minimum, the version of LOINC® codes specified in paragraph (c)(3) of this section and attributed with the LOINC® code 76499-3, 76500-8 (with LOINC® answer list ID LL963-0), 76501-6 (with LOINC® answer list ID LL963-0), 76502-4 (with LOINC® answer list ID LL963-0), 76503-2 (with LOINC® answer list ID LL963-0), and 76504-0 (with the associated applicable unit of measure in the standard specified in §170.207(m)(1)).

(q) Patient matching—(1) Phone number standard. ITU-T E.123, Series E: Overall Network Operation, Telephone Service, Service Operation and Human Factors, International operation—General provisions concerning users: Notation for national and international telephone numbers, email addresses and web addresses (incorporated by reference in §170.299); and ITU-T E.164, Series E: Overall Network Operation, Telephone Service, Service Operation and Human Factors, International operation—Numbering plan of the international telephone service: The international public telecommunication numbering plan (incorporated by reference in §170.299).

(2) [Reserved]

(r) Provider type—(1) Standard. Crosswalk: Medicare Provider/Supplier to Healthcare Provider Taxonomy, April 2, 2015 (incorporated by reference in §170.299).

(2) [Reserved]

(s) Patient insurance—(1) Standard. Public Health Data Standards Consortium Source of Payment Typology Code Set Version 5.0 (October 2011) (incorporated by reference in §170.299).

(2) [Reserved]

[75 FR 44649, July 28, 2010, as amended at 77 FR 54284, Sept. 4, 2012; 79 FR 54478, Sept. 11, 2014; 80 FR 62744, Oct. 16, 2015; 80 FR 76871, Dec. 11, 2015]

return arrow Back to Top

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

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

(a) Encryption and decryption of electronic health information—(1) General. Any encryption algorithm identified by the National Institute of Standards and Technology (NIST) as an approved security function in Annex A of the Federal Information Processing Standards (FIPS) Publication 140-2, (January 27, 2010) (incorporated by reference in §170.299).

(2) General. Any encryption algorithm identified by the National Institute of Standards and Technology (NIST) as an approved security function in Annex A of the Federal Information Processing Standards (FIPS) Publication 140-2, October 8, 2014 (incorporated by reference in §170.299).

(b) [Reserved]

(c) Hashing of electronic health information—(1) Standard. A hashing algorithm with a security strength equal to or greater than SHA-1 (Secure Hash Algorithm (SHA-1)) as s specified by the National Institute of Standards and Technology (NIST) in FIPS PUB 180-4 (March 2012)).

(2) Standard. A hashing algorithm with a security strength equal to or greater than SHA-2 as specified by NIST in FIPS Publication 180-4 (August 2015) (incorporated by reference in §170.299).

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

(e) Record actions related to electronic health information, audit log status, and encryption of end-user devices. (1)(i) The audit log must record the information specified in sections 7.2 through 7.4, 7.6, and 7.7 of the standard specified in §170.210(h) and changes to user privileges when health IT is in use.

(ii) The date and time must be recorded in accordance with the standard specified at §170.210(g).

(2)(i) The audit log must record the information specified in sections 7.2 and 7.4 of the standard specified at §170.210(h) when the audit log status is changed.

(ii) The date and time each action occurs in accordance with the standard specified at §170.210(g).

(3) The audit log must record the information specified in sections 7.2 and 7.4 of the standard specified at §170.210(h) when the encryption status of electronic health information locally stored by health IT on end-user devices is changed. The date and time each action occurs in accordance with the standard specified at §170.210(g).

(f) Encryption and hashing of electronic health information. Any encryption and hashing algorithm identified by the National Institute of Standards and Technology (NIST) as an approved security function in Annex A of the FIPS Publication 140-2 (incorporated by reference in §170.299).

(g) Synchronized clocks. The date and time recorded utilize a system clock that has been synchronized following (RFC 1305) Network Time Protocol, (incorporated by reference in §170.299) or (RFC 5905) Network Time Protocol Version 4, (incorporated by reference in §170.299).

(h) Audit log content. ASTM E2147-01 (Reapproved 2013), (incorporated by reference in §170.299).

[75 FR 44649, July 28, 2010, as amended at 77 FR 54285, Sept. 4, 2012; 79 FR 54478, Sept. 11, 2014; 80 FR 62745, Oct. 16, 2015]

return arrow Back to Top

§170.299   Incorporation by reference.

(a) Certain material is incorporated by reference into this subpart with the approval of the Director of the Federal Register under 5 U.S.C. 552(a) and 1 CFR part 51. To enforce any edition other than that specified in this section, the Department of Health and Human Services must publish a document in the Federal Register and the material must be available to the public. All approved material is available for inspection at U.S. Department of Health and Human Services, Office of the National Coordinator for Health Information Technology, 330 C Street SW., Washington, DC 20201, call ahead to arrange for inspection at 202-690-7151, and is available from the sources listed below. It is also available for inspection at the National Archives and Records Administration (NARA). For information on the availability of this material at NARA, call 202-741-6030 or go to http://www.archives.gov/federal_register/code_of_federal_regulations/ibr_locations.html.

(b) American National Standards Institute, Health Information Technology Standards Panel (HITSP) Secretariat, 25 West 43rd Street—Fourth Floor, New York, NY 10036, http://www.hitsp.org.

(1) HITSP Summary Documents Using HL7 Continuity of Care Document (CCD) Component, HITSP/C32, July 8, 2009, Version 2.5, IBR approved for §170.205.

(2) [Reserved]

(c) ASTM International, 100 Barr Harbor Drive, PO Box C700, West Conshohocken, PA, 19428-2959 USA; Telephone (610) 832-9585 or http://www.astm.org/.

(1) ASTM E2147-01 (Reapproved 2013) Standard Specification for Audit and Disclosure Logs for Use in Health Information Systems, approved March 1, 2013, IBR approved for §170.210(h).

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

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

(d) Centers for Disease Control and Prevention, 2500 Century Parkway, Mailstop E-78, Atlanta, GA 30333, USA (800-232-4636); http://www.cdc.gov/ehrmeaningfuluse/.

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

(2) IIS: HL7 Standard Code Set CVX—Vaccines Administered, updates through July 11, 2012, IBR approved for §170.207.

(3) Implementation Guide for Immunization Data Transactions using Version 2.3.1 of the Health Level Seven (HL7)Standard Protocol Implementation Guide Version 2.2, June 2006, IBR approved for §170.205.

(4) HL7 2.5.1 Implementation Guide for Immunization Messaging Release 1.0, May 1, 2010, IBR approved for §170.205.

(5) PHIN Messaging Guide for Syndromic Surveillance: Emergency Department and Urgent Care Data, ADT Messages A01, A03, A04, and A08, HL7 Version 2.5.1 (Version 2.3.1 Compatible), Release 1.1, August 2012, IBR approved for §170.205.

(6) Conformance Clarification for EHR Certification of Electronic Syndromic Surveillance, ADT MESSAGES A01, A03, A04, and A08, HL7 Version 2.5.1, Addendum to PHIN Messaging Guide for Syndromic Surveillance: Emergency Department and Urgent Care Data (Release 1.1), August 2012, IBR approved for §170.205.

(7) HL7 2.5.1 Implementation Guide for Immunization Messaging, Release 1.4, August 1, 2012, IBR approved for §170.205.

(8) Implementation Guide for Ambulatory Healthcare Provider Reporting to Central Cancer Registries, HL7 Clinical Document Architecture (CDA), Release 1.0, August 2012, IBR approved for §170.205.

(9) ELR 2.5.1 Clarification Document for EHR Technology Certification, July 16, 2012, IBR approved for §170.205.

(10) PHIN Messaging Guide for Syndromic Surveillance: Emergency Department, Urgent Care, Inpatient and Ambulatory Care Settings, Release 2.0, April 21, 2015, IBR approved for §170.205(d).

(11) Erratum to the CDC PHIN 2.0 Implementation Guide, August 2015; Erratum to the CDC PHIN 2.0 Messaging Guide, April 2015 Release for Syndromic Surveillance: Emergency Department, Urgent Care, Inpatient and Ambulatory Care Settings, IBR approved for §170.205(d).

(12) HL7 2.5.1 Implementation Guide for Immunization Messaging, Release 1.5, October 1, 2014, IBR approved for §170.205(e).

(13) HL7 Version 2.5.1 Implementation Guide for Immunization Messaging (Release 1.5)—Addendum, July 2015, IBR approved for §170.205(e).

(14) HL7 Standard Code Set CVX—Vaccines Administered, updates through August 17, 2015, IBR approved for §170.207(e).

(15) National Drug Code Directory (NDC)—Vaccine NDC Linker, updates through August 17, 2015, IBR approved for §170.207(e).

(16) CDC Race and Ethnicity Code Set Version 1.0 (March 2000), IBR approved for §170.207(f).

(e) Centers for Medicare & Medicaid Services, Office of Clinical Standards and Quality, 7500 Security Boulevard, Baltimore, Maryland 21244; Telephone (410) 786-3000

(1) CMS PQRI 2009 Registry XML Specifications, IBR approved for §170.205.

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

(3) Crosswalk: Medicare Provider/Supplier to Healthcare Provider Taxonomy, April 2, 2015, IBR approved for §170.207(r).

(f) Health Level Seven, 3300 Washtenaw Avenue, Suite 227, Ann Arbor, MI 48104; Telephone (734) 677-7777 or http://www.hl7.org/

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

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

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

(4) HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health, Release 1 (US Realm) HL7 Version 2.5.1: ORU^R01, HL7 Informative Document, February, 2010, IBR approved for §170.205.

(5) HL7 Version 3 Standard: Context-Aware Retrieval Application (Infobutton); Release 1, July 2010, IBR approved for §170.204.

(6) HL7 Version 3 Implementation Guide: URL-Based Implementations of the Context-Aware Information Retrieval (Infobutton) Domain, Release 3, December 2010, IBR approved for §170.204.

(7) HL7 Version 3 Implementation Guide: Context-Aware Knowledge Retrieval (Infobutton) Service-Oriented Architecture Implementation Guide, Release 1, HL7 Draft Standard for Trial Use, March 2011, IBR approved for §170.204.

(8) HL7 Implementation Guide for CDA® Release 2: IHE Health Story Consolidation, DSTU Release 1.1 (US Realm) Draft Standard for Trial Use July 2012, IBR approved for §170.205.

(9) HL7 Clinical Document Architecture, Release 2.0, Normative Edition, May 2005, IBR approved for §170.205.

(10) HL7 Version 2.5.1 Implementation Guide: S&I Framework Lab Results Interface, Release 1—US Realm [HL7 Version 2.5.1: ORU−R01] Draft Standard for Trial Use, July 2012, IBR approved for §170.205.

(11) HL7 Version 3 Standard: Clinical Genomics; Pedigree, Release 1, Edition 2011, March 2012, IBR approved for §170.207.

(12) HL7 Implementation Guide for CDA® Release 2: Quality Reporting Document Architecture, DTSU Release 2 (Universal Realm), Draft Standard for Trial Use, July 2012, IBR approved for §170.205.

(13) HL7 v2.5.1 IG: Electronic Laboratory Reporting to Public Health (US Realm), Release 1 Errata and Clarifications, September, 29, 2011, IBR approved for §170.205.

(14) HL7 Implementation Guide for CDA® Release 2: Quality Reporting Document Architecture—Category III, DSTU Release 1 (US Realm) Draft Standard for Trial Use, November 2012, IBR approved for §170.205.

(15) HL7 Version 3 Standard: Context Aware Retrieval Application (“Infobutton”), Knowledge Request, Release 2, 2014 Release, IBR approved for §170.204(b).

(16) HL7 Implementation Guide: Service-Oriented Architecture Implementations of the Context-aware Knowledge Retrieval (Infobutton) Domain, Release 1, August 9, 2013, IBR approved for §170.204(b).

(17) HL7 Version 3 Implementation Guide: Context-Aware Knowledge Retrieval (Infobutton), Release 4, June 13, 2014, IBR approved for §170.204(b).

(18) HL7 Implementation Guide for CDA® Release 2: Consolidated CDA Templates for Clinical Notes (US Realm), Draft Standard for Trial Use, Volume 1—Introductory Material, Release 2.1, August 2015, IBR approved for §170.205(a).

(19) HL7 Implementation Guide for CDA® Release 2: Consolidated CDA Templates for Clinical Notes (US Realm), Draft Standard for Trial Use, Volume 2—Templates and Supporting Material, Release 2.1, August 2015, IBR approved for §170.205(a).

(20) HL7 CDA® R2 Implementation Guide: Quality Reporting Document Architecture—Category I (QRDA I); Release 1, DSTU Release 3 (US Realm), Volume 1—Introductory Material, June 2015, IBR approved for §170.205(h).

(21) HL7 CDA® R2 Implementation Guide: Quality Reporting Document Architecture—Category I (QRDA I); Release 1, DSTU Release 3 (US Realm), Volume 2—Templates and Supporting Material, June 2015, IBR approved for §170.205(h).

(22) HL7 CDA© Release 2 Implementation Guide: Reporting to Public Health Cancer Registries from Ambulatory Healthcare Providers, Release 1; DSTU Release 1.1 (US Realm), Volume 1—Introductory Material, April 2015, IBR approved for §170.205(i).

(23) HL7 CDA© Release 2 Implementation Guide: Reporting to Public Health Cancer Registries from Ambulatory Healthcare Providers, Release 1; DSTU Release 1.1 (US Realm), Volume 2—Templates and Supporting Material, April 2015, IBR approved for §170.205(i).

(24) Errata to the HL7 Implementation Guide for CDA® Release 2: Quality Reporting Document Architecture—Category III, DSTU Release 1 (US Realm), September 2014, IBR approved for §170.205(k).

(25) HL7 Version 3 Implementation Guide: Data Segmentation for Privacy (DS4P), Release 1, Part 1: CDA R2 and Privacy Metadata Reusable Content Profile, May 16, 2014, IBR approved for §170.205(o).

(26) HL7 Implementation Guide for CDA® Release 2—Level 3: Healthcare Associated Infection Reports, Release 1 (U.S. Realm), August 9, 2013, IBR approved for §170.205(r).

(27) HL7 Implementation Guide for CDA® Release 2: National Health Care Surveys (NHCS), Release 1—US Realm, HL7 Draft Standard for Trial Use, Volume 1—Introductory Material, December 2014, IBR approved for §170.205(s).

(28) HL7 Implementation Guide for CDA® Release 2: National Health Care Surveys (NHCS), Release 1—US Realm, HL7 Draft Standard for Trial Use, Volume 2—Templates and Supporting Material, December 2014, IBR approved for §170.205(s).

(29) HL7 Version 3 (V3) Standard, Value Sets for AdministrativeGender and NullFlavor, published August 1, 2013, IBR approved for §170.207(n) and (o).

(g) Integrating the Healthcare Enterprise (IHE), 820 Jorie Boulevard, Oak Brook, IL, Telephone (630) 481-1004, http://http://www.ihe.net/.

(1) IHE IT Infrastructure Technical Framework Volume 2b (ITI TF-2b), Transactions Part B—Sections 3.29—2.43, Revision 7.0, August 10, 2010, IBR approved for §170.205(p).

(2) [Reserved]

(h) Internet Engineering Task Force (IETF) Secretariat, c/o Association Management Solutions, LLC (AMS), 48377 Fremont Blvd., Suite 117, Fremont, CA, 94538, Telephone (510) 492-4080, http://www.ietf.org/rfc.html.

(1) Network Time Protocol (Version 3) Specification, Implementation and Analysis, March 1992, IBR approved for §170.210.

(2) Network Time Protocol Version 4: Protocol and Algorithms Specification, June 2010, IBR approved for §170.210.

(3) Request for Comment (RFC) 5646, “Tags for Identifying Languages, September 2009,” copyright 2009, IBR approved for §170.207(g).

(i) International Telecommunication Union (ITU), Place des Nations, 1211 Geneva 20 Switzerland, Telephone (41) 22 730 511, http://www.itu.int/en/pages/default.aspx.

(1) ITU-T E.123, Series E: Overall Network Operation, Telephone Service, Service Operation and Human Factors, International operation—General provisions concerning users: Notation for national and international telephone numbers, e-mail addresses and web addresses, February 2001, IBR approved for §170.207(q).

(2) ITU-T E.164, Series E: Overall Network Operation, Telephone Service, Service Operation and Human Factors, International operation—Numbering plan of the international telephone service, The international public telecommunication numbering plan, November 2010, IBR approved for §170.207(q).

(j) Library of Congress, Network Development and MARC Standards Office, Washington, DC 20540-4402, Tel: (202) 707-6237 or http://www.loc.gov/standards/iso639-2/.

(1) ISO 639-2. Codes for the Representation of Names of Languages Part 2: Alpha-3 Code, April 8, 2011, IBR approved for §170.207.

(2) [Reserved]

(k) National Council for Prescription Drug Programs, Incorporated, 9240 E. Raintree Drive, Scottsdale, AZ 85260-7518; Telephone (480) 477-1000; and Facsimile (480) 767-1042 or http://www.ncpdp.org.

(1) National Council for Prescription Drug Programs Prescriber/Pharmacist Interface SCRIPT Standard, Implementation Guide, Version 8, Release 1, October 2005, IBR approved for §170.205.

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

(l) National Institute of Standards and Technology, Information Technology Laboratory, National Institute of Standards and Technology, 100 Bureau Drive, Gaithersburg, MD 20899-8930, http://csrc.nist.gov/groups/STM/cmvp/standards.html.

(1) Annex A: Approved Security Functions for FIPS PUB 140-2, Security Requirements for Cryptographic Modules, Draft, January 27, 2010, IBR approved for §170.210.

(2) Annex A: Approved Security Functions for FIPS PUB 140-2, Security Requirements for Cryptographic Modules, Draft, May 30, 2012, IBR approved for §170.210.

(3) Annex A: Federal Information Processing Standards (FIPS) Publication 140-2, Security Requirements for Cryptographic Modules, October 8, 2014, IBR approved for §170.210(a).

(4) FIPS PUB 180-4, Secure Hash Standard (August 2015), IBR approved for §170.210(c).

(m) Office of the National Coordinator for Health Information Technology (ONC), 330 C Street SW., Washington, DC 20201, http://healthit.hhs.gov.

(1) Applicability Statement for Secure Health Transport, Version 1.1, July 10, 2012, IBR approved for §170.202; available at http://healthit.hhs.gov/portal/server.pt/community/healthit_hhs_gov__direct_project/3338.

(2) XDR and XDM for Direct Messaging Specification, Version 1, March 9, 2011, IBR approved for §170.202; available at http://healthit.hhs.gov/portal/server.pt/community/healthit_hhs_gov__direct_project/3338.

(3) Transport and Security Specification, Version 1.0, June 19, 2012, IBR approved for §170.202.

(4) ONC Implementation Guide for Direct Edge Protocols, Version 1.1, June 25, 2014, IBR approved for §170.202; available at http://www.healthit.gov/sites/default/files/implementationguidefordirectedgeprotocolsv1_1.pdf.

(n) Public Health Data Standards Consortium, 111 South Calvert Street, Suite 2700, Baltimore, MD 21202, http://www.phdsc.org/.

(1) Public Health Data Standards Consortium Source of Payment Typology Code Set Version 5.0 (October 2011), IBR approved for §170.207(s).

(2) [Reserved]

(o) Regenstrief Institute, Inc., LOINC® c/o Regenstrief Center for Biomedical Informatics, Inc., 410 West 10th Street, Suite 2000, Indianapolis, IN 46202-3012, http://loinc.org/.

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

(2) Logical Observation Identifiers Names and Codes (LOINC®) Database version 2.40, Released June 2012, IBR approved for §170.207.

(3) Logical Observation Identifiers Names and Codes (LOINC®) Database version 2.52, Released June 2015, IBR approved for §170.207(c).

(4) The Unified Code of Units for Measure, Revision 1.9, October 23, 2013, IBR approved for §170.207.

(p) The Direct Project, c/o the Office of the National Coordinator for Health Information Technology (ONC), 330 C Street SW., Washington, DC 20201, http://healthit.hhs.gov.

(1) Applicability Statement for Secure Health Transport, Version 1.2, August 2015, IBR approved for §170.202(a).

(2) Implementation Guide for Delivery Notification in Direct, Version 1.0, June 29, 2012, IBR approved for §170.202(e).

(q) U.S. National Library of Medicine, 8600 Rockville Pike, Bethesda, MD 20894; Telephone (301) 594-5983 or http://www.nlm.nih.gov/.

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

(2) International Health Terminology Standards Development Organisation (IHTSDO) Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT®) International Release July 31, 2012, IBR approved for §170.207.

(3) US Extension to SNOMED CT® March 2012 Release, IBR approved for §170.207.

(4) RxNorm, August 6, 2012 Full Release Update, IBR approved for §170.207.

(5) Data Element Catalog, Version 1.1, October 2012, IBR approved for §170.204.

(6) International Health Terminology Standards Development Organization (IHTSDO) Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT®) U.S. Edition, September 2015 Release, IBR approved for §170.207(a).

(7) RxNorm, September 8, 2015 Full Release Update, IBR approved for §170.207(d).

(r) World Wide Web Consortium (W3C)/MIT, 32 Vassar Street, Room 32-G515, Cambridge, MA 02139 USA, http://www.w3.org/standards/

(1) Web Content Accessibility Guidelines (WCAG) 2.0, December 11, 2008, IBR approved for §170.204.

(2) [Reserved]

[75 FR 44649, July 28, 2010, as amended at 75 FR 62690, Oct. 13, 2010; 77 FR 54285, Sept. 4, 2012; 77 FR 72991, Dec. 7, 2012; 79 FR 54478, Sept. 11, 2014; 80 FR 62745, Oct. 16, 2015; 81 FR 72463, Oct. 19, 2016]

return arrow Back to Top

Subpart C—Certification Criteria for Health Information Technology

Source: 75 FR 44651, July 28, 2010, unless otherwise noted.

return arrow Back to Top

§170.300   Applicability.

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

(b) When a certification criterion refers to two or more standards as alternatives, use of at least one of the alternative standards will be considered compliant.

(c) Complete EHRs and EHR Modules are not required to be compliant with certification criteria or capabilities specified within a certification criterion that are designated as optional.

(d) In §§170.314 and 170.315, all certification criteria and all capabilities specified within a certification criterion have general applicability (i.e., apply to any health care setting) unless designated as “inpatient setting only” or “ambulatory setting only.”

(1) Inpatient setting only means that the criterion or capability within the criterion is only required for certification of health IT designed for use in an inpatient setting.

(2) Ambulatory setting only means that the criterion or capability within the criterion is only required for certification of health IT designed for use in an ambulatory setting.

[75 FR 44649, July 28, 2010, as amended at 77 FR 54286, Sept. 4, 2012; 80 FR 62747, Oct. 16, 2015]

return arrow Back to Top

§§170.302-170.306   [Reserved]

return arrow Back to Top

§170.314   2014 Edition electronic health record certification criteria.

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

(a) Clinical—(1) Computerized provider order entry. Enable a user to electronically record, change, and access the following order types, at a minimum:

(i) Medications;

(ii) Laboratory; and

(iii) Diagnostic imaging.

(2) Drug-drug, drug-allergy interaction checks—(i) Interventions. Before a medication order is completed and acted upon during computerized provider order entry (CPOE), interventions must automatically and electronically indicate to a user drug-drug and drug-allergy contraindications based on a patient's medication list and medication allergy list.

(ii) Adjustments. (A) Enable the severity level of interventions provided for drug-drug interaction checks to be adjusted.

(B) Limit the ability to adjust severity levels to an identified set of users or available as a system administrative function.

(3) Demographics. (i) Enable a user to electronically record, change, and access patient demographic data including preferred language, sex, race, ethnicity, and date of birth.

(A) Enable race and ethnicity to be recorded in accordance with the standard specified in §170.207(f)(1) and whether a patient declines to specify race and/or ethnicity.

(B) Enable preferred language to be recorded in accordance with the standard specified in §170.207(g)(1) and whether a patient declines to specify a preferred language.

(ii) Inpatient setting only. Enable a user to electronically record, change, and access preliminary cause of death in the event of a mortality.

(4) Vital signs, body mass index, and growth charts—(i) Vital signs. Enable a user to electronically record, change, and access, at a minimum, a patient's height/length, weight, and blood pressure. Height/length, weight, and blood pressure must be recorded in numerical values only.

(ii) Calculate body mass index. Automatically calculate and electronically display body mass index based on a patient's height and weight.

(iii) Optional—Plot and display growth charts. Plot and electronically display, upon request, growth charts for patients.

(5) Problem list. Enable a user to electronically record, change, and access a patient's active problem list:

(i) Ambulatory setting. Over multiple encounters in accordance with, at a minimum, the version of the standard specified in §170.207(a)(3); or

(ii) Inpatient setting. For the duration of an entire hospitalization in accordance with, at a minimum, the version of the standard specified in §170.207(a)(3).

(6) Medication list. Enable a user to electronically record, change, and access a patient's active medication list as well as medication history:

(i) Ambulatory setting. Over multiple encounters; or

(ii) Inpatient setting. For the duration of an entire hospitalization.

(7) Medication allergy list. Enable a user to electronically record, change, and access a patient's active medication allergy list as well as medication allergy history:

(i) Ambulatory setting. Over multiple encounters; or

(ii) Inpatient setting. For the duration of an entire hospitalization.

(8) Clinical decision support—(i) Evidence-based decision support interventions. Enable a limited set of identified users to select (i.e., activate) one or more electronic clinical 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) Demographics;

(E) Laboratory tests and values/results; and

(F) Vital signs.

(ii) Linked referential clinical decision support. (A) EHR technology must be able to:

(1) Electronically identify for a user diagnostic and therapeutic reference information; or

(2) Electronically identify for a user diagnostic and therapeutic reference information in accordance with the standard specified at §170.204(b) and the implementation specifications at §170.204 (b)(1) or (2).

(B) For paragraph (a)(8)(ii)(A) of this section, EHR technology must be able to electronically identify for a user diagnostic or therapeutic reference information based on each one and at least one combination of the data referenced in paragraphs (a)(8)(i)(A) through (F) of this section.

(iii) Clinical decision support configuration. (A) Enable interventions and reference resources specified in paragraphs (a)(8)(i) and (ii) of this section to be configured by a limited set of identified users (e.g., system administrator) based on a user's role.

(B) EHR technology must enable interventions to be electronically triggered:

(1) Based on the data referenced in paragraphs (a)(8)(i)(A) through (F) of this section.

(2) When a patient's medications, medication allergies, and problems are incorporated from a transition of care/referral summary received pursuant to paragraph (b)(1)(iii)(B) or (b)(9)(ii)(D) of this section.

(3) Ambulatory setting only. When a patient's laboratory tests and values/results are incorporated pursuant to paragraph (b)(5)(i)(A)(1) of this section.

(iv) Automatically and electronically interact. Interventions triggered in accordance with paragraphs (a)(8)(i) through (iii) of this section must automatically and electronically occur when a user is interacting with EHR technology.

(v) Source attributes. Enable a user to review the attributes as indicated for all clinical decision support resources:

(A) For evidence-based decision support interventions under paragraph (a)(8)(i) of this section:

(1) Bibliographic citation of the intervention (clinical research/guideline);

(2) Developer of the intervention (translation from clinical research/guideline);

(3) Funding source of the intervention development technical implementation; and

(4) Release and, if applicable, revision date(s) of the intervention or reference source.

(B) For linked referential clinical decision support in paragraph (a)(8)(ii) of this section and drug-drug, drug-allergy interaction checks in paragraph(a)(2) of this section, the developer of the intervention, and where clinically indicated, the bibliographic citation of the intervention (clinical research/guideline).

(9) Electronic notes. Enable a user to electronically record, change, access, and search electronic notes.

(10) Drug-formulary checks. EHR technology must automatically and electronically check whether a drug formulary (or preferred drug list) exists for a given patient and medication.

(11) Smoking status. Enable a user to electronically record, change, and access the smoking status of a patient in accordance with the standard specified at §170.207(h).

(12) Image results. Electronically indicate to a user the availability of a patient's images and narrative interpretations (relating to the radiographic or other diagnostic test(s)) and enable electronic access to such images and narrative interpretations.

(13) Family health history. Enable a user to electronically record, change, and access a patient's family health history according to:

(i) At a minimum, the version of the standard specified in §170.207(a)(3); or

(ii) The standard specified in §170.207(j).

(14) Patient list creation. Enable a user to electronically and dynamically select, sort, access, and create patient lists by: date and time; and based on each one and at least one combination of the following data:

(i) Problems;

(ii) Medications;

(iii) Medication allergies;

(iv) Demographics;

(v) Laboratory tests and values/results; and

(vi) Ambulatory setting only. Patient communication preferences.

(15) Patient-specific education resources. EHR technology must be able to electronically identify for a user patient-specific education resources based on data included in the patient's problem list, medication list, and laboratory tests and values/results:

(i) In accordance with the standard specified at §170.204(b) and the implementation specifications at §170.204(b)(1) or (2); and

(ii) By any means other than the method specified in paragraph (a)(15)(i) of this section.

(16) Inpatient setting only—electronic medication administration record. (i) In combination with an assistive technology that provides automated information on the “rights” specified in paragraphs (a)(16)(i)(A) through (E) of this section, 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. Electronically record the time and date in accordance with the standard specified in §170.210(g), and user identification when a medication is administered.

(17) Inpatient setting only—advance directives. Enable a user to electronically record whether a patient has an advance directive.

(18) Optional—computerized provider order entry—medications. Enable a user to electronically record, change, and access medication orders.

(19) Optional—computerized provider order entry—laboratory. Enable a user to electronically record, change, and access laboratory orders.

(20) Optional—computerized provider order entry—diagnostic imaging. Enable a user to electronically record, change, and access diagnostic imaging orders.

(b) Care coordination—(1) Transitions of care—receive, display, and incorporate transition of care/referral summaries—(i) Receive. EHR technology must be able to electronically receive transition of care/referral summaries in accordance with:

(A) The standard specified in §170.202(a)(1).

(B) Optional. The standards specified in §170.202(a)(1) and (b).

(C) Optional. The standards specified in §170.202(b) and (c).

(ii) Display. EHR technology must be able to electronically display in human readable format the data included in transition of care/referral summaries received and formatted according to any of the following standards (and applicable implementation specifications) specified in: §170.205(a)(1), §170.205(a)(2), and §170.205(a)(3).

(iii) Incorporate. Upon receipt of a transition of care/referral summary formatted according to the standard adopted at §170.205(a)(3), EHR technology must be able to:

(A) Correct patient. Demonstrate that the transition of care/referral summary received is or can be properly matched to the correct patient.

(B) Data incorporation. Electronically incorporate the following data expressed according to the specified standard(s):

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

(C) Section views. Extract and 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 the standard adopted at §170.205(a)(3).

(2) Transitions of care—create and transmit transition of care/referral summaries—(i) Create. Enable a user to electronically create a transition of care/referral summary formatted according to the standard adopted at §170.205(a)(3) that includes, at a minimum, the Common Clinical Data Set and the following data expressed, where applicable, according to the specified standard(s):

(A) Encounter diagnoses. The standard specified in §170.207(i) or, at a minimum, the version of the standard specified §170.207(a)(3);

(B) Immunizations. The standard specified in §170.207(e)(2);

(C) Cognitive status;

(D) Functional status; and

(E) Ambulatory setting only. The reason for referral; and referring or transitioning provider's name and office contact information.

(F) Inpatient setting only. Discharge instructions.

(ii) Transmit. Enable a user to electronically transmit the transition of care/referral summary created in paragraph (b)(2)(i) of this section in accordance with:

(A) The standard specified in §170.202(a)(1).

(B) Optional. The standards specified in §170.202(a)(1) and (b).

(C) Optional. The standards specified in §170.202(b) and (c).

(3) Electronic prescribing. Enable a user to electronically create prescriptions and prescription-related information for electronic transmission in accordance with:

(i) The standard specified in §170.205(b)(2); and

(ii) At a minimum, the version of the standard specified in §170.207(d)(2).

(4) Clinical information reconciliation. Enable a user to electronically reconcile the data that represent a patient's active medication, problem, and medication allergy list as follows. For each list type:

(i) Electronically and simultaneously display (i.e., in a single view) the data from at least two list 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.

(ii) Enable a user to create a single reconciled list of medications, medication allergies, or problems.

(iii) Enable a user to review and validate the accuracy of a final set of data and, upon a user's confirmation, automatically update the list.

(5) Incorporate laboratory tests and values/results—(i) Receive results—(A) Ambulatory setting only. (1) Electronically receive and incorporate clinical laboratory tests and values/results in accordance with the standard specified in §170.205(j) and, at a minimum, the version of the standard specified in §170.207(c)(2).

(2) Electronically display the tests and values/results received in human readable format.

(B) Inpatient setting only. Electronically receive clinical laboratory tests and values/results in a structured format and electronically display such tests and values/results in human readable format.

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

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

(6) Inpatient setting only—transmission of electronic laboratory tests and values/results to ambulatory providers. EHR technology must be able to electronically create laboratory test reports for electronic transmission in accordance with the standard specified in §170.205(j) and with laboratory tests expressed in accordance with, at a minimum, the version of the standard specified in §170.207(c)(2).

(7) Data portability. Enable a user to electronically create a set of export summaries for all patients in EHR technology formatted according to the standard adopted at §170.205(a)(3) that represents the most current clinical information about each patient and 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 at §170.207(a)(3);

(ii) Immunizations. The standard specified in §170.207(e)(2);

(iii) Cognitive status;

(iv) Functional status; and

(v) Ambulatory setting only. The reason for referral; and referring or transitioning provider's name and office contact information.

(vi) Inpatient setting only. Discharge instructions.

(8) Optional—Transitions of care—(i) Send and receive via edge protocol. EHR technology must be able to electronically:

(A) Send transitions of care/referral summaries through a method that conforms to the standard specified at §170.202(d) and that leads to such summaries being processed by a service that has implemented the standard specified in §170.202(a)(1); 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)(1).

(ii)(A) Display. EHR technology must be able to electronically display in human readable format the data included in transition of care/referral summaries received and formatted according to any of the following standards (and applicable implementation specifications) specified in: §170.205(a)(1) through (3).

(B) Section views. Extract and 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 the standard adopted at §170.205(a)(3).

(iii) Create. Enable a user to electronically create a transition of care/referral summary formatted according to the standard adopted at §170.205(a)(3) that includes, at a minimum, the Common Clinical Data Set and the following data expressed, where applicable, according to the specified standard(s):

(A) Encounter diagnoses. The standard specified in §170.207(i) or, at a minimum, the version of the standard specified §170.207(a)(3);

(B) Immunizations. The standard specified in §170.207(e)(2);

(C) Cognitive status;

(D) Functional status;

(E) Ambulatory setting only. The reason for referral; and referring or transitioning provider's name and office contact information; and

(F) Inpatient setting only. Discharge instructions.

(9) Optional—clinical information reconciliation and incorporation—(i) Correct patient. Upon receipt of a transition of care/referral summary formatted according to the standard adopted at §170.205(a)(3), EHR technology must be able to demonstrate that the transition of care/referral summary received is or can be properly matched to the correct patient.

(ii) Reconciliation. Enable a user to electronically reconcile the data that represent a patient's active medication, problem, and medication allergy list as follows. For each list type:

(A) Electronically and simultaneously display (i.e., in a single view) the data from at least two list 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 electronically incorporate the following data expressed according to the specified standard(s):

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

(c) Clinical quality measures—(1) Clinical Quality Measures—capture and export—(i)—Capture. For each and every CQM for which the EHR technology is presented for certification, EHR technology must be able to electronically record all of the data identified in the standard specified at §170.204(c) 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. EHR technology must be able to electronically export a data file formatted in accordance with the standards specified at §170.205(h)(1) that includes all of the data captured for each and every CQM to which EHR technology was certified under paragraph (c)(1)(i) of this section.

(2) Clinical quality measures—import and calculate—(i) Import. EHR technology must be able to electronically import a data file formatted in accordance with the standard specified at §170.205(h)(1) and use such data to perform the capability specified in paragraph (c)(2)(ii) of this section. EHR technology presented for certification to all three of the certification criteria adopted in paragraphs (c)(1) through (3) of this section is not required to meet paragraph (c)(2)(i).

(ii) Calculate. EHR technology must be able to electronically calculate each and every clinical quality measure for which it is presented for certification.

(3) Clinical quality measures—electronic submission. Enable a user to electronically create a data file for transmission of clinical quality measurement data:

(i) In accordance with the standards specified at §170.205(h)(1) and (k)(1); and

(ii) That can be electronically accepted by CMS.

(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 paragraph (d)(1)(i) of this section, and the actions the user is permitted to perform with the EHR technology.

(2) Auditable events and tamper-resistance—(i) Record actions. EHR technology must be able to:

(A) Record actions related to electronic health information in accordance with the 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 EHR technology in accordance with the standard specified in §170.210(e)(3) unless the EHR technology prevents electronic health information from being locally stored on end-user devices (see 170.314(d)(7) of this section).

(ii) Default setting. EHR technology must be set by default to perform the capabilities specified in paragraph (d)(2)(i)(A) of this section and, where applicable, paragraphs (d)(2)(i)(B) or (C), or both paragraphs (d)(2)(i)(B) and (C).

(iii) When disabling the audit log is permitted. For each capability specified in paragraphs (d)(2)(i)(A) through (C) of this section that EHR technology permits to be disabled, the ability to do so must be restricted to a limited set of identified users.

(iv) Audit log protection. Actions and statuses recorded in accordance with paragraph (d)(2)(i) of this section must not be capable of being changed, overwritten, or deleted by the EHR technology.

(v) Detection. EHR technology must be able to detect whether the audit log has been altered.

(3) Audit report(s). 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 standards at §170.210(e).

(4) Amendments. Enable a user to electronically select the record affected by a patient's request for amendment and perform the capabilities specified in paragraphs (d)(4)(i) or (ii) of this section.

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

(5) Automatic log-off. Prevent a user from gaining further access to an electronic session after a predetermined time of inactivity.

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

(7) End-user device encryption. Paragraph (d)(7)(i) or (ii) of this section must be met to satisfy this certification criterion.

(i) EHR 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 EHR technology on those devices stops.

(A) Electronic health information that is stored must be encrypted in accordance with the standard specified in §170.210(a)(1).

(B) Default setting. EHR 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 identified users.

(ii) EHR technology is designed to prevent electronic health information from being locally stored on end-user devices after use of EHR technology on those devices stops.

(8) Integrity. (i) Create a message digest in accordance with the standard specified in §170.210(c)(1).

(ii) Verify in accordance with the standard specified in §170.210(c)(1) upon receipt of electronically exchanged health information that such information has not been altered.

(9) Optional—accounting of disclosures. Record disclosures made for treatment, payment, and health care operations in accordance with the standard specified in §170.210(d).

(e) Patient engagement—(1) View, download, and transmit to 3rd party. (i) EHR technology must provide patients (and their authorized representatives) with an online means to view, download, and transmit to a 3rd party the data specified below. Access to these capabilities must be 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. Electronically view in accordance with the 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; and reason(s) for hospitalization.

(B) Download. (1) Electronically download an ambulatory summary or inpatient summary (as applicable to the EHR technology setting for which certification is requested) in human readable format or formatted according to the standard adopted at §170.205(a)(3) that includes, 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 specified in paragraph (e)(1)(i)(A)(1) and (2) of this section.

(ii) Inpatient setting only. All of the data specified in paragraphs (e)(1)(i)(A)(1) and (3) of this section.

(2) Inpatient setting only. Electronically download transition of care/referral summaries that were created as a result of a transition of care (pursuant to the capability expressed in the certification criterion adopted at paragraph (b)(2) of this section).

(C) Transmit to third party. (1) Electronically transmit the ambulatory summary or inpatient summary (as applicable to the EHR technology setting for which certification is requested) created in paragraph (e)(1)(i)(B)(1) of this section in accordance with at least one of the following:

(i) The standard specified in §170.202(a)(1).

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

(2) Inpatient setting only. Electronically 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)(1).

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

(ii) Activity history log. (A) When electronic health information is viewed, downloaded, or transmitted to a third-party using the capabilities included in paragraphs (e)(1)(i)(A) through (C) of this section, the following information must be recorded and made accessible to the patient:

(1) The action(s) (i.e., view, download, transmission) that occurred;

(2) The date and time each action occurred in accordance with the standard specified at §170.210(g); and

(3) The user who took the action.

(B) EHR technology presented for certification may demonstrate compliance with paragraph (e)(1)(ii)(A) of this section if it is also certified to the certification criterion adopted at §170.314(d)(2) and the information required to be recorded in paragraph (e)(1)(ii)(A) is accessible by the patient.

(2) Ambulatory setting only—clinical summary—(i) Create. Enable a user to create a clinical summary for a patient in human readable format and formatted according to the standards adopted at §170.205(a)(3).

(ii) Customization. Enable a user to customize the data included in the clinical summary.

(iii) Minimum data from which to select. EHR technology must permit a user to select, at a minimum, the following data when creating a clinical summary:

(A) Common Clinical Data Set (which, for the human readable version, should be in their English representation if they associate with a vocabulary/code set)

(B) The provider's name and office contact information; date and location of visit; reason for visit; immunizations and/or medications administered during the visit; diagnostic tests pending; clinical instructions; future appointments; referrals to other providers; future scheduled tests; and recommended patient decision aids.

(3) Ambulatory setting only—secure messaging. Enable a user to electronically send messages to, and receive messages from, a patient in a manner that ensures:

(i) Both the patient (or authorized representative) and EHR 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).

(f) Public health—(1) Immunization information. Enable a user to electronically record, change, and access immunization information.

(2) Transmission to immunization registries. EHR technology must be able to electronically create immunization information for electronic transmission in accordance with:

(i) The standard and applicable implementation specifications specified in §170.205(e)(3); and

(ii) At a minimum, the version of the standard specified in §170.207(e)(2).

(3) Transmission to public health agencies—syndromic surveillance. EHR technology must be able to electronically create syndrome-based public health surveillance information for electronic transmission in accordance with:

(i) Ambulatory setting only. (A) The standard specified in §170.205(d)(2).

(B) Optional. The standard (and applicable implementation specifications) specified in §170.205(d)(3).

(ii) Inpatient setting only. The standard (and applicable implementation specifications) specified in §170.205(d)(3).

(4) Inpatient setting only—transmission of reportable laboratory tests and values/results. EHR technology must be able to electronically create reportable laboratory tests and values/results for electronic transmission in accordance with:

(i) The standard (and applicable implementation specifications) specified in §170.205(g); and

(ii) At a minimum, the versions of the standards specified in §170.207(a)(3) and (c)(2).

(5) Optional—ambulatory setting only—cancer case information. Enable a user to electronically record, change, and access cancer case information.

(6) Optional—ambulatory setting only—transmission to cancer registries. EHR technology must be able to electronically create cancer case information for electronic transmission in accordance with:

(i) The standard (and applicable implementation specifications) specified in §170.205(i)(1); and

(ii) At a minimum, the versions of the standards specified in §170.207(a)(3) and (c)(2).

(7) Optional—Ambulatory setting only—Transmission to public health agencies—syndromic surveillance. EHR technology must be able to electronically create syndrome-based public health surveillance information for electronic transmission.

(i) Optional. That contains the following data:

(A) Patient demographics;

(B) Provider specialty;

(C) Provider address;

(D) Problem list;

(E) Vital signs;

(F) Laboratory test values/results;

(G) Procedures;

(H) Medication list; and

(I) Insurance.

(ii) [Reserved]

(g) Utilization—(1) Optional—Automated numerator recording. For each meaningful use objective with a percentage-based measure, EHR 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.

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

(3) Safety-enhanced design. User-centered design processes must be applied to each capability an EHR technology includes that is specified in the following certification criteria: §170.314(a)(1), (2), (6) through (8), (16) and (18) through (20) and (b)(3), (4), and (9).

(4) Quality management system. For each capability that an EHR 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.

(i) If a single QMS was used for applicable capabilities, it would only need to be identified once.

(ii) If different QMS were applied to specific capabilities, each QMS applied would need to be identified. This would include the application of a QMS to some capabilities and none to others.

(iii) If no QMS was applied to all applicable capabilities such a response is acceptable to satisfy this certification criterion.

(h) Transport methods—(1) Optional—Applicability Statement for Secure Health Transport. Enable health information to be electronically sent and electronically received in accordance with the standard specified in §170.202(a)(1).

(2) Optional—Applicability Statement for Secure Health Transport and XDR/XDM for Direct Messaging. Enable health information to be electronically sent and electronically received in accordance with the standards specified in §170.202(a)(1) and (b).

(3) Optional—SOAP Transport and Security Specification and XDR/XDM for Direct Messaging. Enable health information to be electronically sent and electronically received in accordance with the standards specified in §170.202(b) and (c).

[77 FR 54287, Sept. 4, 2012, as amended at 79 FR 54478, Sept. 11, 2014; 80 FR 62747, Oct. 16, 2015]

return arrow Back to Top

§170.315   2015 Edition health IT certification criteria.

The Secretary adopts the following certification criteria for health IT. Health IT must be able to electronically perform the following capabilities in accordance with all applicable standards and implementation specifications adopted in this part:

(a) Clinical—(1) Computerized provider order entry—medications. (i) Enable a user to record, change, and access medication orders.

(ii) Optional. Include a “reason for order” field.

(2) Computerized provider order entry—laboratory. (i) Enable a user to record, change, and access laboratory orders.

(ii) Optional. Include a “reason for order” field.

(3) Computerized provider order entry—diagnostic imaging. (i) Enable a user to record, change, and access diagnostic imaging orders.

(ii) Optional. Include a “reason for order” field.

(4) Drug-drug, drug-allergy interaction checks for CPOE—(i) Interventions. Before a medication order is completed and acted upon during computerized provider order entry (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.

(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 in at least one of these two ways:

(1) To a specific set of identified users.

(2) As a system administrative function.

(5)Demographics. (i) Enable a user to record, change, and access patient demographic data including race, ethnicity, preferred language, sex, sexual orientation, gender identity, and date of birth.

(A) Race and ethnicity. (1) Enable each one of a patient's races to be recorded in accordance with, at a minimum, the standard specified in §170.207(f)(2) and whether a patient declines to specify race.

(2) Enable each one of a patient's ethnicities to be recorded in accordance with, at a minimum, the standard specified in §170.207(f)(2) and whether a patient declines to specify ethnicity.

(3) Aggregate each one of the patient's races and ethnicities recorded in accordance with paragraphs (a)(5)(i)(A)(1) and (2) of this section to the categories in the standard specified in §170.207(f)(1).

(B) Preferred language. Enable preferred language to be recorded in accordance with the standard specified in §170.207(g)(2) and whether a patient declines to specify a preferred language.

(C) Sex. Enable sex to be recorded in accordance with the standard specified in §170.207(n)(1).

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

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

(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) Problem list. Enable a user to record, change, and access a patient's active problem list:

(i) Ambulatory setting only. Over multiple encounters in accordance with, at a minimum, the version of the standard specified in §170.207(a)(4).

(ii) Inpatient setting only. For the duration of an entire hospitalization in accordance with, at a minimum, the version of the standard specified in §170.207(a)(4).

(7) Medication list. Enable a user to record, change, and access a patient's active medication list as well as medication history:

(i) Ambulatory setting only. Over multiple encounters.

(ii) Inpatient setting only. For the duration of an entire hospitalization.

(8) Medication allergy list. Enable a user to record, change, and access a patient's active medication allergy list as well as medication allergy history:

(i) Ambulatory setting only. Over multiple encounters.

(ii) Inpatient setting only. For the duration of an entire hospitalization.

(9) Clinical decision support (CDS)—(i) CDS intervention interaction. Interventions provided to a user must occur when a user is interacting with technology.

(ii) CDS configuration. (A) Enable interventions and reference resources specified in paragraphs (a)(9)(iii) and (iv) of this section to be configured by a limited set of identified users (e.g., system administrator) based on a user's role.

(B) Enable interventions:

(1) Based on the following data:

(i) Problem list;

(ii) Medication list;

(iii) Medication allergy list;

(iv) At least one demographic specified in paragraph (a)(5)(i) of this section;

(v) Laboratory tests; and

(vi) Vital signs.

(2) When a patient's medications, medication allergies, and problems are incorporated from a transition of care/referral summary received and pursuant to paragraph (b)(2)(iii)(D) of this section.

(iii) Evidence-based decision support interventions. Enable a limited set of identified users to select (i.e., activate) electronic CDS interventions (in addition to drug-drug and drug-allergy contraindication checking) based on each one and at least one combination of the data referenced in paragraphs (a)(9)(ii)(B)(1)(i) through (vi) of this section.

(iv) Linked referential CDS. (A) Identify for a user diagnostic and therapeutic reference information in accordance at least one of the following standards and implementation specifications:

(1) The standard and implementation specifications specified in §170.204(b)(3).

(2) The standard and implementation specifications specified in §170.204(b)(4).

(B) For paragraph (a)(9)(iv)(A) of this section, 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 data referenced in paragraphs (a)(9)(ii)(B)(1)(i), (ii), and (iv) of this section.

(v) Source attributes. Enable a user to review the attributes as indicated for all CDS resources:

(A) For evidence-based decision support interventions under paragraph (a)(9)(iii) of this section:

(1) Bibliographic citation of the intervention (clinical research/guideline);

(2) Developer of the intervention (translation from clinical research/guideline);

(3) Funding source of the intervention development technical implementation; and

(4) Release and, if applicable, revision date(s) of the intervention or reference source.

(B) For linked referential CDS in paragraph (a)(9)(iv) of this section and drug-drug, drug-allergy interaction checks in paragraph (a)(4) of this section, the developer of the intervention, and where clinically indicated, the bibliographic citation of the intervention (clinical research/guideline).

(10) Drug-formulary and preferred drug list checks. The requirements specified in one of the following paragraphs (that is, paragraphs (a)(10)(i) and (a)(10)(ii) of this section) must be met to satisfy this certification criterion:

(i) Drug formulary checks. Automatically check whether a drug formulary exists for a given patient and medication.

(ii) Preferred drug list checks. Automatically check whether a preferred drug list exists for a given patient and medication.

(11) Smoking status. Enable a user to record, change, and access the smoking status of a patient.

(12) 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 standard in §170.207(a)(4).

(13) Patient-specific education resources. (i) Identify patient-specific education resources based on data included in the patient's problem list and medication list in accordance with at least one of the following standards and implementation specifications:

(A) The standard and implementation specifications specified in §170.204(b)(3).

(B) The standard and implementation specifications specified in §170.204(b)(4).

(ii) Optional. Request that patient-specific education resources be identified in accordance with the standard in §170.207(g)(2).

(14) Implantable device list. (i) Record Unique Device Identifiers associated with a patient's Implantable Devices.

(ii) Parse the following identifiers from a Unique Device Identifier:

(A) Device Identifier; and

(B) The following identifiers that compose the Production Identifier:

(1) The lot or batch within which a device was manufactured;

(2) The serial number of a specific device;

(3) The expiration date of a specific device;

(4) The date a specific device was manufactured; and

(5) For an HCT/P regulated as a device, the distinct identification code required by 21 CFR 1271.290(c).

(iii) Obtain and associate with each Unique Device Identifier:

(A) A description of the implantable device referenced by at least one of the following:

(1) The “GMDN PT Name” attribute associated with the Device Identifier in the Global Unique Device Identification Database.

(2) The “SNOMED CT® Description” mapped to the attribute referenced in in paragraph (a)(14)(iii)(A)(1) of this section.

(B) The following Global Unique Device Identification Database attributes:

(1) “Brand Name”;

(2) “Version or Model”;

(3) “Company Name”;

(4) “What MRI safety information does the labeling contain?”; and

(5) “Device required to be labeled as containing natural rubber latex or dry natural rubber (21 CFR 801.437).”

(iv) Display to a user an implantable device list consisting of:

(A) The active Unique Device Identifiers recorded for the patient;

(B) For each active Unique Device Identifier recorded for a patient, the description of the implantable device specified by paragraph (a)(14)(iii)(A) of this section; and

(C) A method to access all Unique Device Identifiers recorded for a patient.

(v) For each Unique Device Identifier recorded for a patient, enable a user to access:

(A) The Unique Device Identifier;

(B) The description of the implantable device specified by paragraph (a)(14)(iii)(A) of this section;

(C) The identifiers associated with the Unique Device Identifier, as specified by paragraph (a)(14)(ii) of this section; and

(D) The attributes associated with the Unique Device Identifier, as specified by paragraph (a)(14)(iii)(B) of this section.

(vi) Enable a user to change the status of a Unique Device Identifier recorded for a patient.

(15) Social, psychological, and behavioral data. Enable a user to record, change, and access the following patient social, psychological, and behavioral data:

(i) Financial resource strain. Enable financial resource strain to be recorded in accordance with the standard specified in §170.207(p)(1) and whether a patient declines to specify financial resource strain.

(ii) Education. Enable education to be recorded in accordance with the standard specified in §170.207(p)(2) and whether a patient declines to specify education.

(iii) Stress. Enable stress to be recorded in accordance with the standard specified in §170.207(p)(3) and whether a patient declines to specify stress.

(iv) Depression. Enable depression to be recorded in accordance with the standard specified in §170.207(p)(4) and whether a patient declines to specify depression.

(v) Physical activity. Enable physical activity to be recorded in accordance with the standard specified in §170.207(p)(5) and whether a patient declines to specify physical activity.

(vi) Alcohol use. Enable alcohol use to be recorded in accordance with the standard specified in §170.207(p)(6) and whether a patient declines to specify alcohol use.

(vii) Social connection and isolation. Enable social connection and isolation to be recorded in accordance the standard specified in §170.207(p)(7) and whether a patient declines to specify social connection and isolation.

(viii) 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(p)(8) and whether a patient declines to specify exposure to violence (intimate partner violence).

(b) Care coordination—(1) Transitions of care—(i) Send and receive via edge protocol—(A) Send transition of care/referral summaries through a method that conforms to the standard specified in §170.202(d) and that leads to such summaries being processed by a service that has implemented the standard specified in §170.202(a)(2); and

(B) Receive transition of care/referral summaries through a method that conforms to the standard specified in §170.202(d) from a service that has implemented the standard specified in §170.202(a)(2).

(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) when the technology is also being certified using an SMTP-based edge protocol.

(ii) Validate and display—(A) Validate C-CDA conformance—system performance. Demonstrate the ability to detect valid and invalid transition of care/referral summaries received and formatted in accordance with the standards specified in §170.205(a)(3) and §170.205(a)(4) for the Continuity of Care Document, Referral Note, and (inpatient setting only) Discharge Summary document templates. This includes the ability to:

(1) Parse each of the document types.

(2) Detect errors in corresponding “document-templates,” “section-templates,” and “entry-templates,” including invalid vocabulary standards and codes not specified in the standards adopted in §170.205(a)(3) and §170.205(a)(4).

(3) Identify valid document-templates and process the data elements required in the corresponding section-templates and entry-templates from the standards adopted in §170.205(a)(3) and §170.205(a)(4).

(4) Correctly interpret empty sections and null combinations.

(5) Record errors encountered and allow a user through at least one of the following ways to:

(i) Be notified of the errors produced.

(ii) Review the errors produced.

(B) Display. 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 §170.205(a)(4).

(C) Display section views. Allow for the individual display of each section (and the accompanying document header information) that is included in a transition of care/referral summary received and formatted in accordance with the standards adopted in §170.205(a)(3) and §170.205(a)(4) in a manner that enables the user to:

(1) Directly display only the data within a particular section;

(2) Set a preference for the display order of specific sections; and

(3) Set the initial quantity of sections to be displayed.

(iii) Create. Enable a user to create a transition of care/referral summary formatted in accordance with the standard specified in §170.205(a)(4) using the Continuity of Care Document, Referral Note, and (inpatient setting only) Discharge Summary document templates that includes, at a minimum:

(A) The Common Clinical Data Set.

(B) Encounter diagnoses. Formatted according to at least one of the following standards:

(1) The standard specified in §170.207(i).

(2) At a minimum, the version of the standard specified in §170.207(a)(4).

(C) Cognitive status.

(D) Functional status.

(E) Ambulatory setting only. The reason for referral; and referring or transitioning provider's name and office contact information.

(F) Inpatient setting only. Discharge instructions.

(G) Patient matching data. First name, last name, previous name, middle name (including middle initial), suffix, date of birth, address, phone number, and sex. The following constraints apply:

(1) Date of birth constraint—(i) The year, month and day of birth must be present for a date of birth. The technology must include a null value when the date of birth is unknown.

(ii) Optional. When the hour, minute, and second are associated with a date of birth the technology must demonstrate that the correct time zone offset is included.

(2) Phone number constraint. Represent phone number (home, business, cell) in accordance with the standards adopted in §170.207(q)(1). All phone numbers must be included when multiple phone numbers are present.

(3) Sex constraint. Represent sex in accordance with the standard adopted in §170.207(n)(1).

(2) Clinical information reconciliation and incorporation—(i) General requirements. Paragraphs (b)(2)(ii) and (iii) of this section must be completed based on the receipt of a transition of care/referral summary formatted in accordance with the standards adopted in §170.205(a)(3) and §170.205(a)(4) using the Continuity of Care Document, Referral Note, and (inpatient setting only) Discharge Summary document templates.

(ii) Correct patient. Upon receipt of a transition of care/referral summary formatted according to the standards adopted §170.205(a)(3) and §170.205(a)(4), technology must be able to demonstrate that the transition of care/referral summary received 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 each of the following: Medications; medication allergies; and problems.

(C) Enable a user to review and validate the accuracy of a final set of data.

(D) Upon a user's confirmation, automatically update the list, and incorporate the following data expressed according to the specified standard(s):

(1) Medications. At a minimum, the version of the standard specified in §170.207(d)(3);

(2) Medication allergies. At a minimum, the version of the standard specified in §170.207(d)(3); and

(3) Problems. At a minimum, the version of the standard specified in §170.207(a)(4).

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

(3) Electronic prescribing. (i) Enable a user to perform all of the following prescription-related electronic transactions in accordance with the standard specified in §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).

(F) Request and receive medication history information (RXHREQ, RXHRES).

(ii) For each transaction listed in paragraph (b)(3)(i) of this section, the technology must be able to receive and transmit the reason for the prescription using the diagnosis elements in DRU Segment.

(iii) Optional. For each transaction listed in paragraph (b)(3)(i) of this section, the technology must be able to receive and transmit the reason for the prescription using the indication elements in the SIG Segment.

(iv) Limit a user's ability to prescribe all oral liquid medications in only metric standard units of mL (i.e., not cc).

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

(4) Common Clinical Data Set summary record—create. Enable a user to create a transition of care/referral summary formatted in accordance with the standard specified in §170.205(a)(4) using the Continuity of Care Document, Referral Note, and (inpatient setting only) Discharge Summary document templates that includes, at a minimum:

(i) The Common Clinical Data Set.

(ii) Encounter diagnoses. Formatted according to at least one of the following standards:

(A) The standard specified in §170.207(i).

(B) At a minimum, the version of the standard specified in §170.207(a)(4).

(iii) Cognitive status.

(iv) Functional status.

(v) Ambulatory setting only. The reason for referral; and referring or transitioning provider's name and office contact information.

(vi) Inpatient setting only. Discharge instructions.

(vii) Patient matching data. First name, last name, previous name, middle name (including middle initial), suffix, date of birth, address, phone number, and sex. The following constraints apply:

(A) Date of birth constraint—(1) The year, month and day of birth must be present for a date of birth. The technology must include a null value when the date of birth is unknown.

(2) Optional. When the hour, minute, and second are associated with a date of birth the technology must demonstrate that the correct time zone offset is included.

(B) Phone number constraint. Represent phone number (home, business, cell) in accordance with the standards adopted in §170.207(q)(1). All phone numbers must be included when multiple phone numbers are present.

(C) Sex constraint. Represent sex in accordance with the standard adopted in §170.207(n)(1).

(5) Common Clinical Data Set summary record—receive—(i) Enable a user to receive a transition of care/referral summary formatted in accordance with the standards adopted in §170.205(a)(3) and §170.205(a)(4) using the Continuity of Care Document, Referral Note, and (inpatient setting only) Discharge Summary document templates that includes, at a minimum:

(A) The Common Clinical Data Set.

(B) Encounter diagnoses. Formatted according to at least one of the following standards:

(1) The standard specified in §170.207(i).

(2) At a minimum, the standard specified in §170.207(a)(4).

(C) Cognitive status.

(D) Functional status.

(E) Ambulatory setting only. The reason for referral; and referring or transitioning provider's name and office contact information.

(F) Inpatient setting only. Discharge instructions.

(ii) Validate and display. Demonstrate the following functionalities for the document received in accordance with paragraph (b)(5)(i) of this section:

(A) Validate C-CDA conformance—system performance. Detect valid and invalid transition of care/referral summaries including the ability to:

(1) Parse each of the document types formatted according to the following document templates: Continuity of Care Document, Referral Note, and (inpatient setting only) Discharge Summary.

(2) Detect errors in corresponding “document-templates,” “section-templates,” and “entry-templates,” including invalid vocabulary standards and codes not specified in the standards adopted in §170.205(a)(3) and §170.205(a)(4).

(3) Identify valid document-templates and process the data elements required in the corresponding section-templates and entry-templates from the standards adopted in §170.205(a)(3) and §170.205(a)(4).

(4) Correctly interpret empty sections and null combinations.

(5) Record errors encountered and allow a user through at least one of the following ways to:

(i) Be notified of the errors produced.

(ii) Review the errors produced.

(B) Display. 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 §170.205(a)(4).

(C) Display section views. Allow for the individual display of each section (and the accompanying document header information) that is included in a transition of care/referral summary received and formatted in accordance with the standards adopted in §170.205(a)(3) and §170.205(a)(4) in a manner that enables the user to:

(1) Directly display only the data within a particular section;

(2) Set a preference for the display order of specific sections; and

(3) Set the initial quantity of sections to be displayed.

(6) Data export—(i) General requirements for export summary configuration. (A) Enable a user to set the configuration options specified in paragraphs (b)(6)(iii) and (iv) of this section when creating an export summary as well as a 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.

(B) Limit the ability of users who can create export summaries in at least one of these two ways:

(1) To a specific set of identified users.

(2) As a system administrative function.

(ii) Creation. Enable a user to create export summaries formatted in accordance with the standard specified in §170.205(a)(4) using the Continuity of Care Document document template that includes, at a minimum:

(A) The Common Clinical Data Set.

(B) Encounter diagnoses. Formatted according to at least one of the following standards:

(1) The standard specified in §170.207(i).

(2) At a minimum, the version of the standard specified in §170.207(a)(4).

(C) Cognitive status.

(D) Functional status.

(E) Ambulatory setting only. The reason for referral; and referring or transitioning provider's name and office contact information.

(F) Inpatient setting only. Discharge instructions.

(iii) Timeframe configuration. (A) Enable a user to set the date and time period within which data would be used to create the export summaries. This must include the ability to enter in a start and end date and time range.

(B) Consistent with the date and time period specified in paragraph (b)(6)(iii)(A) of this section, enable a user to do each of the following:

(1) Create export summaries in real-time;

(2) Create export summaries based on a relative date and time (e.g., the first of every month at 1:00 a.m.); and

(3) Create export summaries based on a specific date and time (e.g., on 10/24/2015 at 1:00 a.m.).

(iv) Location configuration. Enable a user to set the storage location to which the export summary or export summaries are intended to be saved.

(7) Data segmentation for privacy—send. Enable a user to create a summary record formatted in accordance with the standard adopted in §170.205(a)(4) that is document-level tagged as restricted and subject to restrictions on re-disclosure according to the standard adopted in §170.205(o)(1).

(8) Data segmentation for privacy—receive. Enable a user to:

(i) Receive a summary record that is formatted in accordance with the standard adopted in §170.205(a)(4) that is document-level tagged as restricted and subject to restrictions on re-disclosure according to the standard adopted in §170.205(o)(1);

(ii) Sequester the document-level tagged document from other documents received; and

(iii) View the restricted document without incorporating any of the data from the document.

(9) Care plan. Enable a user to record, change, access, create, and receive care plan information in accordance with the Care Plan document template, including the Health Status Evaluations and Outcomes Section and Interventions Section (V2), in the standard specified in §170.205(a)(4).

(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 at any time the user chooses and without subsequent developer assistance to operate:

(A) Formatted in accordance with the standard specified in §170.205(h)(2);

(B) Ranging from one to multiple patients; and

(C) That includes all of the data captured for each and every CQM to which technology was certified under paragraph (c)(1)(i) of this section.

(2) Clinical quality measures—import and calculate—(i) Import. Enable a user to import a data file in accordance with the standard specified in §170.205(h)(2) for one or multiple patients and use such data to perform the capability specified in paragraph (c)(2)(ii) of this section. A user must be able to execute this capability at any time the user chooses and without subsequent developer assistance to operate.

(ii) Calculate each and every clinical quality measure for which it is presented for certification.

(3) Clinical quality measures—report. Enable a user to electronically create a data file for transmission of clinical quality measurement data:

(i) At a minimum, in accordance with the standards specified in §170.205(h)(2) and §170.205(k)(1) and (2).

(ii) Optional. That can be electronically accepted by CMS.

(4) Clinical quality measures—filter. (i) Record the data listed in paragraph (c)(4)(iii) of this section in accordance with the identified standards, where specified.

(ii) Filter CQM results at the patient and aggregate levels by each one and any combination of the data listed in paragraph (c)(4)(iii) of this section and be able to:

(A) Create a data file of the filtered data in accordance with the standards adopted in §170.205(h)(2) and §170.205(k)(1) and (2); and

(B) Display the filtered data results in human readable format.

(iii) Data.

(A) Taxpayer Identification Number.

(B) National Provider Identifier.

(C) Provider type in accordance with, at a minimum, the standard specified in §170.207(r)(1).

(D) Practice site address.

(E) Patient insurance in accordance with the standard specified in §170.207(s)(1).

(F) Patient age.

(G) Patient sex in accordance with the version of the standard specified in §170.207(n)(1).

(H) Patient race and ethnicity in accordance with, at a minimum, the version of the standard specified in §170.207(f)(2).

(I) Patient problem list data in accordance with, at a minimum, the version of the standard specified in §170.207(a)(4).

(d) Privacy and security—(1) Authentication, access control, and authorization. (i) Verify against a unique identifier(s) (e.g., username or number) that a user 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 paragraph (d)(1)(i) of this section, and the actions the user is permitted to perform with the technology.

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

(ii) Default setting. Technology must be set by default to perform the capabilities specified in paragraph (d)(2)(i)(A) of this section and, where applicable, paragraphs (d)(2)(i)(B) and (d)(2)(i)(C) of this section.

(iii) When disabling the audit log is permitted. For each capability specified in paragraphs (d)(2)(i)(A) through (C) of this section 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 paragraph (d)(2)(i) of this section 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.

(3) Audit report(s). 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 standards in §170.210(e).

(4) Amendments. Enable a user to select the record affected by a patient's request for amendment and perform the capabilities specified in paragraph (d)(4)(i) or (ii) of this section.

(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 in at least one of the following ways:

(A) To the affected record.

(B) Include a link that indicates this information's location.

(5) Automatic access time-out. (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.

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

(7) End-user device encryption. The requirements specified in one of the following paragraphs (that is, paragraphs (d)(7)(i) and (d)(7)(ii) of this section) 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 the technology on those devices stops.

(A) Electronic health information that is stored must be encrypted in accordance with the standard specified in §170.210(a)(2).

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

(ii) Technology is designed to prevent electronic health information from being locally stored on end-user devices after use of the technology on those devices stops.

(8) Integrity. (i) Create a message digest in accordance with the standard specified in §170.210(c)(2).

(ii) Verify in accordance with the standard specified in §170.210(c)(2) upon receipt of electronically exchanged health information that such information has not been altered.

(9) Trusted connection. Establish a trusted connection using one of the following methods:

(i) Message-level. Encrypt and integrity protect message contents in accordance with the standards specified in §170.210(a)(2) and (c)(2).

(ii) Transport-level. Use a trusted connection in accordance with the standards specified in §170.210(a)(2) and (c)(2).

(10) Auditing actions on health information. (i) By default, be set to record actions related to electronic health information in accordance with the standard specified in §170.210(e)(1).

(ii) If technology permits auditing to be disabled, the ability to do so must be restricted to a limited set of users.

(iii) Actions recorded related to electronic health information must not be capable of being changed, overwritten, or deleted by the technology.

(iv) Technology must be able to detect whether the audit log has been altered.

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

(e) Patient engagement—(1) View, download, and transmit to 3rd party. (i) Patients (and their authorized representatives) must be able to use internet-based technology to view, download, and transmit their health information to a 3rd party in the manner specified below. Such access must be consistent and in accordance with the standard adopted in §170.204(a)(1) and may alternatively be demonstrated in accordance with the standard specified in §170.204(a)(2).

(A) View. Patients (and their authorized representatives) must be able to use health IT to view, 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; and 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 the following formats:

(i) Human readable format; and

(ii) The format specified in accordance to the standard specified in §170.205(a)(4) following the CCD document template.

(2) When downloaded according to the standard specified in §170.205(a)(4) following the CCD document template, 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 specified in paragraph (e)(1)(i)(A)(1), (2), (4), and (5) of this section.

(ii) Inpatient setting only. All of the data specified in paragraphs (e)(1)(i)(A)(1), and (3) through (5) of this section.

(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 certification criterion specified in paragraph (b)(1) of this section).

(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 paragraph (e)(1)(i)(B)(2) of this section in accordance with both of the following ways:

(i) Email transmission to any email address; and

(ii) An encrypted method of electronic transmission.

(2) Inpatient setting only. Transmit transition of care/referral summaries (as a result of a transition of care/referral as referenced by (e)(1)(i)(B)(3)) of this section selected by the patient (or their authorized representative) in both of the ways referenced (e)(1)(i)(C)(1)(i) and (ii) of this section).

(D) Timeframe selection. With respect to the data available to view, download, and transmit as referenced paragraphs (e)(1)(i)(A), (B), and (C) of this section, patients (and their authorized representatives) must be able to:

(1) Select data associated with a specific date (to be viewed, downloaded, or transmitted); and

(2) Select data within an identified date range (to be viewed, downloaded, or transmitted).

(ii) Activity history log. (A) When any of the capabilities included in paragraphs (e)(1)(i)(A) through (C) of this section are used, the following information must be recorded and made accessible to the patient (or his/her authorized representative):

(1) The action(s) (i.e., view, download, transmission) that occurred;

(2) The date and time each action occurred in accordance with the standard specified in §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 paragraph (e)(1)(ii)(A) of this section if it is also certified to the certification criterion specified in §170.315(d)(2) and the information required to be recorded in paragraph (e)(1)(ii)(A) of this section is accessible by the patient (or his/her authorized representative).

(2) Secure messaging. Enable a user to send messages to, and receive messages from, a patient in a secure manner.

(3) Patient health information capture. Enable a user to:

(i) Identify, record, and access information directly and electronically shared by a patient (or authorized representative).

(ii) Reference and link to patient health information documents.

(f) Public health—(1) Transmission to immunization registries. (i) 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.

(C) At a minimum, the version of the standard specified in §170.207(e)(4) for administered vaccines.

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

(2) Transmission to public health agencies—syndromic surveillance. 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).

(3) Transmission to public health agencies—reportable laboratory tests and values/results. Create reportable laboratory tests and values/results for electronic transmission in accordance with:

(i) The standard (and applicable implementation specifications) specified in §170.205(g).

(ii) At a minimum, the versions of the standards specified in §170.207(a)(3) and (c)(2).

(4) Transmission to cancer registries. Create cancer case information for electronic transmission in accordance with:

(i) The standard (and applicable implementation specifications) specified in §170.205(i)(2).

(ii) At a minimum, the versions of the standards specified in §170.207(a)(4) and (c)(3).

(5) Transmission to public health agencies—electronic case reporting. (i) Consume and maintain a table of trigger codes to determine which encounters may be reportable.

(ii) Match a patient visit or encounter to the trigger code based on the parameters of the trigger code table.

(iii) Case report creation. Create a case report for electronic transmission:

(A) Based on a matched trigger from paragraph (f)(5)(ii).

(B) That includes, at a minimum:

(1) The Common Clinical Data Set.

(2) Encounter diagnoses. Formatted according to at least one of the following standards:

(i) The standard specified in §170.207(i).

(ii) At a minimum, the version of the standard specified in §170.207(a)(4).

(3) The provider's name, office contact information, and reason for visit.

(4) An identifier representing the row and version of the trigger table that triggered the case report.

(6) Transmission to public health agencies—antimicrobial use and resistance reporting. Create antimicrobial use and resistance reporting information for electronic transmission in accordance with the standard specified in §170.205(r)(1).

(7) Transmission to public health agencies—health care surveys. Create health care survey information for electronic transmission in accordance with the standard specified in §170.205(s)(1).

(g) Design and performance—(1) Automated numerator recording. For each EHR Incentive Programs 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.

(2) Automated measure calculation. For each EHR Incentive Programs 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 measure.

(3) Safety-enhanced design. (i) User-centered design processes must be applied to each capability technology includes that is specified in the following certification criteria: Paragraphs (a)(1) through (9) and (14), (b)(2) and (3) of this section.

(ii) Number of test participants. A minimum of 10 test participants must be used for the testing of each capability identified in paragraph (g)(3)(i) of this section.

(iii) One of the following must be submitted on the user-centered design processed used:

(A) Name, description and citation (URL and/or publication citation) for an industry or federal government standard.

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

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

(A) Name and product version; 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) The specific metrics captured during the testing of each user task performed in (g)(3)(iv)(C) of this section, which must include: 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) or an alternative acceptable user satisfaction measure;

(E) Test results for each task using the metrics identified above in paragraph (g)(3)(iv)(D) of this section; and

(F) Results and data analysis narrative, including: Major test finding; effectiveness; efficiency; satisfaction; and areas for improvement.

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

(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 satisfies one of the following ways:

(A) The QMS used is established by the Federal government or a standards developing organization.

(B) The QMS used is mapped to one or more QMS established by the Federal government or standards developing organization(s).

(ii) When a single QMS was used for applicable capabilities, it would only need to be identified once.

(iii) When different QMS were applied to specific capabilities, each QMS applied would need to be identified.

(5) 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) When a single accessibility-centered design standard or law was used for applicable capabilities, it would only need to be identified once.

(ii) When 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) When no accessibility-centered design standard or law was applied to all applicable capabilities such a response is acceptable to satisfy this certification criterion.

(6) Consolidated CDA creation performance. The following technical and performance outcomes must be demonstrated related to Consolidated CDA creation. The capabilities required under paragraphs (g)(6)(i) through (iv) of this section can be demonstrated in tandem and do not need to be individually addressed in isolation or sequentially. This certification criterion's scope includes only data expressed within the Common Clinical Data Set definition.

(i) Reference C-CDA match. Create a data file formatted in accordance with the standard adopted in §170.205(a)(4) that matches a gold-standard, reference data file.

(ii) Document-template conformance. Create a data file formatted in accordance with the standard adopted in §170.205(a)(4) that demonstrates a valid implementation of each document template applicable to the certification criterion or criteria within the scope of the certificate sought.

(iii) Vocabulary conformance. Create a data file formatted in accordance with the standard adopted in §170.205(a)(4) that demonstrates the required vocabulary standards (and value sets) are properly implemented.

(iv) Completeness verification. Create a data file for each of the applicable document templates referenced in paragraph (g)(6)(ii) of this section without the omission of any of the data included in the Common Clinical Data Set definition.

(7) Application access—patient selection. The following technical outcome and conditions must be met through the demonstration of an application programming interface (API).

(i) Functional requirement. The technology must be able to receive a request with sufficient information to uniquely identify a patient and return an ID or other token that can be used by an application to subsequently execute requests for that patient's data.

(ii) Documentation—(A) 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).

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

(B) The documentation used to meet paragraph (g)(7)(ii)(A) of this section must be available via a publicly accessible hyperlink.

(8) Application access—data category request. The following technical outcome and conditions must be met through the demonstration of an application programming interface.

(i) Functional requirements. (A) Respond to requests for patient data (based on an ID or other token) 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 a computable format.

(B) Respond to requests for patient data associated with a specific date as well as requests for patient data within a specified date range.

(ii) Documentation—(A) 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).

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

(B) The documentation used to meet paragraph (g)(8)(ii)(A) of this section must be available via a publicly accessible hyperlink.

(9) Application access—all data request. The following technical outcome and conditions must be met through the demonstration of an application programming interface.

(i) Functional requirements. (A) Respond to requests for patient data (based on an ID or other token) 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 specified in §170.205(a)(4) following the CCD document template.

(B) Respond to requests for patient data associated with a specific date as well as requests for patient data within a specified date range.

(ii) Documentation—(A) 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).

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

(B) The documentation used to meet paragraph (g)(9)(ii)(A) of this section must be available via a publicly accessible hyperlink.

(h) Transport methods and other protocols—(1) Direct Project—(i) Applicability Statement for Secure Health Transport. Able to send and receive health information in accordance with the standard specified in §170.202(a)(2), including formatted only as a “wrapped” message.

(ii) Delivery Notification in Direct. Able to send and receive health information in accordance with the standard specified in §170.202(e)(1).

(2) Direct Project, Edge Protocol, and XDR/XDM—(i) Able to send and receive health information in accordance with:

(A) The standard specified in §170.202(a)(2), including formatted only as a “wrapped” message;

(B) The standard specified in §170.202(b), including support for both limited and full XDS metadata profiles; and

(C) Both edge protocol methods specified by the standard in §170.202(d).

(ii) Delivery Notification in Direct. Able to send and receive health information in accordance with the standard specified in §170.202(e)(1).

[80 FR 62747, Oct. 16, 2015, as amended at 80 FR 76871, Dec. 11, 2015]

return arrow Back to Top

Subpart D [Reserved]

return arrow Back to Top

Subpart E—ONC Health IT Certification Program

Source: 76 FR 1325, Dec. 7, 2011, unless otherwise noted.

Editorial Note: Nomenclature changes to subpart E of part 170 appear at 80 FR 62755, Oct. 16, 2015.

return arrow Back to Top

§170.500   Basis and scope.

This subpart implements section 3001(c)(5) of the Public Health Service Act and sets forth the rules and procedures related to the ONC Health IT Certification Program for health information technology (health IT) administered by the National Coordinator for Health Information Technology.

[76 FR 1325, Dec. 7, 2011, as amended at 77 FR 54291, Sept. 4, 2012]

return arrow Back to Top

§170.501   Applicability.

(a) This subpart establishes the processes that applicants for ONC-ACB status must follow to be granted ONC-ACB status by the National Coordinator; the processes the National Coordinator will follow when assessing applicants and granting ONC-ACB status; the requirements that ONC-ACBs must follow to maintain ONC-ACB status; and the requirements of ONC-ACBs for certifying Complete EHRs, Health IT Module(s), and other types of health IT in accordance with the applicable certification criteria adopted by the Secretary in subpart C of this part.

(b) This subpart establishes the processes that applicants for ONC-ATL status must follow to be granted ONC-ATL status by the National Coordinator; the processes the National Coordinator will follow when assessing applicants and granting ONC-ATL status; the requirements that ONC-ATLs must follow to maintain ONC-ATL status; and the requirements of ONC-ATLs for testing Complete EHRs and Health IT Modules in accordance with the applicable certification criteria adopted by the Secretary in subpart C of this part.

(c) This subpart establishes the processes accreditation organizations must follow to request approval from the National Coordinator to be an ONC-AA and that the National Coordinator will follow to approve an accreditation organization under the ONC Health IT Certification Program as well as certain ongoing responsibilities for an ONC-AA.

(d) This subpart establishes the processes the National Coordinator will follow when exercising direct review of certified health IT and related requirements for ONC-ACBs, ONC-ATLs, and developers of health IT certified under the ONC Health IT Certification Program.

[81 FR 72464, Oct. 19, 2016]

return arrow Back to Top

§170.502   Definitions.

For the purposes of this subpart:

Applicant means a single organization or a consortium of organizations that seeks to become an ONC-ACB or ONC-ATL by submitting an application to the National Coordinator for such status.

Deployment site means the physical location where a Complete EHR, Health IT Module(s) or other type of health IT resides or is being or has been implemented.

Development site means the physical location where a Complete EHR, Health IT Module(s) or other type of health IT was developed.

Gap certification means the certification of a previously certified Complete EHR or Health IT Module(s) to:

(1) All applicable new and/or revised certification criteria adopted by the Secretary at subpart C of this part based on test results issued by a NVLAP-accredited testing laboratory under the ONC Health IT Certification Program or an ONC-ATL; and

(2) All other applicable certification criteria adopted by the Secretary at subpart C of this part based on the test results used to previously certify the Complete EHR or Health IT Module(s) under the ONC Health IT Certification Program.

ONC-Approved Accreditor or ONC-AA means an accreditation organization that the National Coordinator has approved to accredit certification bodies under the ONC Health IT Certification Program.

ONC-Authorized Certification Body or ONC-ACB means an organization or a consortium of organizations that has applied to and been authorized by the National Coordinator pursuant to this subpart to perform the certification of Complete EHRs, Health IT Module(s), and/or other types of health IT under the ONC Health IT Certification Program.

ONC-Authorized Testing Lab or ONC-ATL means an organization or a consortium of organizations that has applied to and been authorized by the National Coordinator pursuant to this subpart to perform the testing of Complete EHRs and Health IT Modules to certification criteria adopted by the Secretary at subpart C of this part.

Providing or provide an updated certification means the action taken by an ONC-ACB to ensure that the developer of a previously certified Health IT Module(s) shall update the information required by §170.523(k)(1)(i), after the ONC-ACB has verified that the certification criterion or criteria to which the Health IT Module(s) was previously certified have not been revised and that no new certification criteria are applicable to the Health IT Module(s).

Remote certification means the use of methods, including the use of web-based tools or secured electronic transmissions, that do not require an ONC-ACB to be physically present at the development or deployment site to conduct certification.

[76 FR 1325, Dec. 7, 2011, as amended at 77 FR 54291, Sept. 4, 2012; 81 FR 72464, Oct. 19, 2016]

return arrow Back to Top

§170.503   Requests for ONC-AA status and ONC-AA ongoing responsibilities.

(a) The National Coordinator may approve only one ONC-AA at a time.

(b) Submission. The National Coordinator will publish a notice in the Federal Register to announce the 30-day period during which requests for ONC-AA status may be submitted. In order to be considered for ONC-AA status, an accreditation organization must submit a timely request in writing to the National Coordinator along with the following information to demonstrate its ability to serve as an ONC-AA:

(1) A detailed description of the accreditation organization's conformance to ISO/IEC17011 (incorporated by reference in §170.599) and experience evaluating the conformance of certification bodies to ISO/IEC 17065 (incorporated by reference in §170.599).

(2) A detailed description of the accreditation organization's accreditation, requirements as well as how those requirements would complement the Principles of Proper Conduct for ONC-ACBs and ensure the surveillance approaches used by ONC-ACBs include the use of consistent, objective, valid, and reliable methods;

(3) Detailed information on the accreditation organization's procedures that would be used to monitor ONC-ACBs;

(4) Detailed information, including education and experience, about the key personnel who review organizations for accreditation; and

(5) Procedures for responding to, and investigating, complaints against ONC-ACBs.

(c) Preliminary selection. (1) The National Coordinator is permitted up to 60 days from the end of the submission period to review all timely submissions that were received and determine which accreditation organization is best qualified to serve as the ONC-AA.

(2) The National Coordinator's determination will be based on the information provided, the completeness of an accreditation organization's description of the elements listed in paragraph (b) of this section, and each accreditation organization's overall accreditation experience.

(3) The accreditation organization that is determined to be the best qualified will be notified that it has been selected as the ONC-AA on a preliminary basis, subject to the resolution of the reconsideration process in §170.504. All other accreditation organizations will be notified that their requests for ONC-AA status have been denied. The accreditation organization that is selected on a preliminary basis shall not represent itself as the ONC-AA or perform accreditation(s) under the ONC Health IT Certification Program unless and until it receives written notice from the National Coordinator that it has been approved as the ONC-AA on a final basis pursuant to paragraph (d) of this section.

(4) Any accreditation organization that submits a timely request for ONC-AA status and is denied may request reconsideration in accordance with §170.504.

(d) Final approval. (1) If the National Coordinator determines that an accreditation organization has met the standard specified in §170.504(b), then that organization will be approved as the ONC-AA on a final basis. The accreditation organization that was selected as the ONC-AA on a preliminary basis pursuant to paragraph (c) of this section will be notified of this final decision and cannot request reconsideration or further review.

(2) If the National Coordinator determines that no accreditation organization has met the standard specified in §170.504(b), then the organization that was selected as the ONC-AA on a preliminary basis pursuant to paragraph (c) of this section will be approved as the ONC-AA on a final basis.

(e) ONC-AA ongoing responsibilities. An ONC-AA must:

(1) Maintain conformance with ISO/IEC 17011 (incorporated by reference in §170.599);

(2) Verify that the certification bodies it accredits and ONC-ACBs conform to, at a minimum:

(i) For fiscal years 2014 and 2015, ISO/IEC Guide 65 (incorporated by reference in §170.599); and

(ii) For fiscal year 2016 and subsequent years, ISO/IEC 17065 (incorporated by reference in §170.599).

(3) Ensure the surveillance approaches used by ONC-ACBs include the use of consistent, objective, valid, and reliable methods;

(4) Verify that ONC-ACBs are performing surveillance as required by and in accordance with §§170.556, 170.523(k), and their respective annual plans; and

(5) Review ONC-ACB surveillance results to determine if the results indicate any substantive non-conformance by ONC-ACBs with the conditions of their respective accreditations.

(f) ONC-AA status. (1) An accreditation organization has not been granted ONC-AA status unless and until it is notified by the National Coordinator that it has been approved as the ONC-AA on a final basis pursuant to paragraph (d) of this section.

(2) An ONC-AA's status will expire not later than 3 years from the date its status was granted by the National Coordinator.

(3) The National Coordinator will accept requests for ONC-AA status, in accordance with paragraph (b) of this section, at least 180 days before the current ONC-AA's status is set to expire.

[76 FR 1325, Dec. 7, 2011, as amended at 76 FR 72642, Nov. 25, 2011; 77 FR 54291, Sept. 4, 2012; 79 FR 54479, Sept. 11, 2014; 80 FR 62755, Oct. 16, 2015]

return arrow Back to Top

§170.504   Reconsideration process for requests for ONC-AA status.

(a) An accreditation organization that submits a timely request for ONC-AA status in accordance with §170.503 and is denied may request reconsideration of the decision to deny its request for ONC-AA status.

(b) Submission requirement. To request reconsideration, an accreditation organization is required to submit to the National Coordinator, within 15 days of receipt of a denial notice, a written statement with supporting documentation contesting the decision to deny its request for ONC-AA status. The submission must demonstrate that clear, factual errors were made in the review of its request for ONC-AA status and that the accreditation organization would have been selected as the ONC-AA pursuant to §170.503(c) if those errors had been corrected. If the National Coordinator does not receive an accreditation organization's submission within the specified timeframe, then its request for reconsideration may be denied.

(c) Review of submissions. The National Coordinator is permitted up to 30 days to review all timely submissions that were received and determine whether an accreditation organization has met the standard specified in paragraph (b) of this section.

(d) Decision. (1) If the National Coordinator determines that an accreditation organization has met the standard specified in paragraph (b) of this section, then that organization will be approved as the ONC-AA on a final basis. All other accreditation organizations will be notified that their requests for reconsideration have been denied.

(2) Final decision. A reconsideration decision issued by the National Coordinator is final and not subject to further review.

return arrow Back to Top

§170.505   Correspondence.

(a) Correspondence and communication with ONC or the National Coordinator shall be conducted by email, unless otherwise necessary or specified. The official date of receipt of any email between ONC or the National Coordinator and an accreditation organization requesting ONC-AA status, the ONC-AA, an applicant for ONC-ACB status, an applicant for ONC-ATL status, an ONC-ACB, an ONC-ATL, health IT developer, or a party to any proceeding under this subpart is the date on which the email was sent.

(b) In circumstances where it is necessary for an accreditation organization requesting ONC-AA status, the ONC-AA, an applicant for ONC-ACB status, an applicant for ONC-ATL status, an ONC-ACB, an ONC-ATL, health IT developer, or a party to any proceeding under this subpart to correspond or communicate with ONC or the National Coordinator by regular, express, or certified mail, the official date of receipt for all parties will be the date of the delivery confirmation to the address on record.

[81 FR 72464, Oct. 19, 2016]

return arrow Back to Top

§170.510   Authorization scope for ONC-ACB status.

Applicants for ONC-ACB status may seek authorization from the National Coordinator to perform the following types of certification:

(a) Complete EHR certification; and/or

(b) Health IT Module certification; and/or

(c) Certification of other types of health IT for which the Secretary has adopted certification criteria under subpart C of this part.

[76 FR 1325, Dec. 7, 2011, as amended at 81 FR 72464, Oct. 19, 2016]

return arrow Back to Top

§170.511   Authorization scope for ONC-ATL status.

Applicants may seek authorization from the National Coordinator to perform the testing of Complete EHRs or Health IT Modules to a portion of a certification criterion, one certification criterion, or many or all certification criteria adopted by the Secretary under subpart C of this part.

[81 FR 72464, Oct. 19, 2016]

return arrow Back to Top

§170.520   Application.

(a) ONC-ACB application. Applicants must include the following information in an application for ONC-ACB status and submit it to the National Coordinator for the application to be considered complete.

(1) The type of authorization sought pursuant to §170.510. For authorization to perform Health IT Module certification, applicants must indicate the specific type(s) of Health IT Module(s) they seek authorization to certify. If qualified, applicants will only be granted authorization to certify the type(s) of Health IT Module(s) for which they seek authorization.

(2) General identifying, information including:

(i) Name, address, city, state, zip code, and Web site of applicant; and

(ii) Designation of an authorized representative, including name, title, phone number, and email address of the person who will serve as the applicant's point of contact.

(3) Documentation that confirms that the applicant has been accredited by the ONC-AA.

(4) An agreement, properly executed by the applicant's authorized representative, that it will adhere to the Principles of Proper Conduct for ONC-ACBs.

(b) ONC-ATL application. Applicants must include the following information in an application for ONC-ATL status and submit it to the National Coordinator for the application to be considered complete.

(1) The authorization scope sought pursuant to §170.511.

(2) General identifying, information including:

(i) Name, address, city, state, zip code, and Web site of applicant; and

(ii) Designation of an authorized representative, including name, title, phone number, and email address of the person who will serve as the applicant's point of contact.

(3) Documentation that confirms that the applicant has been accredited by NVLAP to the ONC Health IT Certification Program, including to ISO/IEC 17025 (incorporated by reference, see §170.599).

(4) An agreement, properly executed by the applicant's authorized representative, that it will adhere to the Principles of Proper Conduct for ONC-ATLs.

[81 FR 72464, Oct. 19, 2016]

return arrow Back to Top

§170.523   Principles of proper conduct for ONC-ACBs.

An ONC-ACB shall:

(a) Maintain its accreditation, or if a new ONC-AA is approved by the National Coordinator, obtain accreditation from the new ONC-AA within 12 months or a reasonable period specified by the National Coordinator and maintain such accreditation;

(b) Attend all mandatory ONC training and program update sessions;

(c) Maintain a training program that includes documented procedures and training requirements to ensure its personnel are competent to certify health IT;

(d) Report to ONC within 15 days any changes that materially affect its:

(1) Legal, commercial, organizational, or ownership status;

(2) Organization and management including key certification personnel;

(3) Policies or procedures;

(4) Location;

(5) Personnel, facilities, working environment or other resources;

(6) ONC authorized representative (point of contact); or

(7) Other such matters that may otherwise materially affect its ability to certify health IT.

(e) Allow ONC, or its authorized agent(s), to periodically observe on site (unannounced or scheduled), during normal business hours, any certifications performed to demonstrate compliance with the requirements of the ONC Health IT Certification Program;

(f) Provide ONC, no less frequently than weekly, a current list of Health IT Modules, Complete EHRs, and/or EHR Modules that have been certified that includes, at a minimum:

(1) For the 2015 Edition health IT certification criteria and subsequent editions of health IT certification criteria:

(i) The Health IT Module developer name; product name; product version; developer Web site, physical address, email, phone number, and contact name;

(ii) The ONC-ACB Web site, physical address, email, phone number, and contact name, contact function/title;

(iii) The ATL Web site, physical address, email, phone number, and contact name, contact function/title;

(iv) Location and means by which the testing was conducted (e.g., remotely with health IT developer at its headquarters location);

(v) The date(s) the Health IT Module was tested;

(vi) The date the Health IT Module was certified;

(vii) The unique certification number or other specific product identification;

(viii) The certification criterion or criteria to which the Health IT Module has been certified, including the test procedure and test data versions used, test tool version used, and whether any test data was altered (i.e., a yes/no) and for what purpose;

(ix) The way in which each privacy and security criterion was addressed for the purposes of certification;

(x) The standard or mapping used to meet the quality management system certification criterion;

(xi) The standard(s) or lack thereof used to meet the accessibility-centered design certification criterion;

(xii) Where applicable, the hyperlink to access an application programming interface (API)'s documentation and terms of use;

(xiii) Where applicable, which certification criteria were gap certified;

(xiv) Where applicable, if a certification issued was a result of an inherited certified status request;

(xv) Where applicable, the clinical quality measures to which the Health IT Module has been certified;

(xvi) Where applicable, any additional software a Health IT Module relied upon to demonstrate its compliance with a certification criterion or criteria adopted by the Secretary;

(xvii) Where applicable, the standard(s) used to meet a certification criterion where more than one is permitted;

(xviii) Where applicable, any optional capabilities within a certification criterion to which the Health IT Module was tested and certified;

(xix) Where applicable, and for each applicable certification criterion, all of the information required to be submitted by Health IT Module developers to meet the safety-enhanced design certification criterion. Each user-centered design element required to be reported must be at a granular level (e.g., task success/failure));

(xx) A hyperlink to the disclosures required by §170.523(k)(1) for the Health IT Module;

(xxi) The attestation required by §170.523(k)(2);

(xxii) When applicable, for each instance in which a Health IT Module failed to conform to its certification and for which corrective action was instituted under §170.556 (provided no provider or practice site is identified):

(A) The specific certification requirements to which the technology failed to conform, as determined by the ONC-ACB;

(B) A summary of the deficiency or deficiencies identified by the ONC-ACB as the basis for its determination of non-conformity;

(C) When available, the health IT developer's explanation of the deficiency or deficiencies;

(D) The dates surveillance was initiated and completed;

(E) The results of randomized surveillance, including pass rate for each criterion in instances where the Health IT Module is evaluated at more than one location;

(F) The number of sites that were used in randomized surveillance;

(G) The date of the ONC-ACB's determination of non-conformity;

(H) The date on which the ONC-ACB approved a corrective action plan;

(I) The date corrective action began (effective date of approved corrective action plan);

(J) The date by which corrective action must be completed (as specified by the approved corrective action plan);

(K) The date corrective action was completed; and

(L) A description of the resolution of the non-conformity or non-conformities.

(2) For the 2014 Edition EHR certification criteria:

(i) The Complete EHR or EHR Module developer name (if applicable);

(ii) The date certified;

(iii) The product version;

(iv) The unique certification number or other specific product identification;

(v) The clinical quality measures to which a Complete EHR or EHR Module has been certified;

(vi) Where applicable, any additional software a Complete EHR or EHR Module relied upon to demonstrate its compliance with a certification criterion or criteria adopted by the Secretary;

(vii) Where applicable, the certification criterion or criteria to which each EHR Module has been certified; and

(viii) A hyperlink to the test results used to certify the Complete EHRs and/or EHR Modules that can be accessed by the public.

(ix) A hyperlink to the disclosures required by §170.523(k)(1) for the Complete EHRs and/or EHR Modules; and

(x) The attestation required by §170.523(k)(2); and

(xi) When applicable, for each instance in which a Complete EHR or EHR Module failed to conform to its certification and for which corrective action was instituted under §170.556 (provided no provider or practice site is identified):

(A) The specific certification requirements to which the technology failed to conform, as determined by the ONC-ACB;

(B) A summary of the deficiency or deficiencies identified by the ONC-ACB as the basis for its determination of non-conformity;

(C) When available, the health IT developer's explanation of the deficiency or deficiencies;

(D) The dates surveillance was initiated and completed;

(E) The results of randomized surveillance, including pass rate for each criterion in instances where the Complete EHR or EHR Module is evaluated at more than one location;

(F) The number of sites that were used in randomized surveillance;

(G) The date of the ONC-ACB's determination of non-conformity;

(H) The date on which the ONC-ACB approved a corrective action plan;

(I) The date corrective action began (effective date of approved corrective action plan);

(J) The date by which corrective action must be completed (as specified by the approved corrective action plan);

(K) The date corrective action was completed; and

(L) A description of the resolution of the non-conformity or non-conformities.

(g) Records retention. (1) Retain all records related to the certification of Complete EHRs and Health IT Modules to an edition of certification criteria for a minimum of 3 years from the effective date that removes the applicable edition from the Code of Federal Regulations; and

(2) Make the records available to HHS upon request during the retention period described in paragraph (g)(1) of this section;

(h) Only certify health IT (Complete EHRs and/or Health IT Modules) that has been tested, using test tools and test procedures approved by the National Coordinator, by a/an:

(1) ONC-ATL;

(2) NVLAP-accredited testing laboratory under the ONC Health IT Certification Program for no longer than six months from December 19, 2016; or

(3) ONC-ATL, NVLAP-accredited testing laboratory under the ONC Health IT Certification Program, and/or an ONC-ATCB for the purposes of:

(i) Certifying previously certified Complete EHRs and/or Health IT Module(s) if the certification criterion or criteria to which the Complete EHRs and/or Health IT Module(s) was previously certified have not been revised and no new certification criteria are applicable to the Complete EHRs and/or Health IT Module(s); or

(ii) Performing gap certification.

(i) Conduct surveillance of certified health IT in accordance with its accreditation, §170.556, and the following requirements:

(1) Submit an annual surveillance plan to the National Coordinator.

(2) Report, at a minimum, on a quarterly basis to the National Coordinator the results of its surveillance, including surveillance results that identify:

(i) The names of health IT developers;

(ii) Names of products and versions;

(iii) Certification criteria and ONC Health IT Certification Program requirements surveilled;

(iv) The type of surveillance (i.e., reactive or randomized);

(v) The dates surveillance was initiated and completed; and

(vi) As applicable, the number of sites that were used in randomized surveillance.

(3) Annually submit a summative report of surveillance results to the National Coordinator.

(j) Promptly refund any and all fees received for:

(1) Requests for certification that are withdrawn while its operations are suspended by the National Coordinator;

(2) Certifications that will not be completed as a result of its conduct; and

(3) Previous certifications that it performed if its conduct necessitates the recertification of Complete EHRs and/or Health IT Module(s);

(k) Ensure adherence to the following requirements when issuing any certification and during surveillance of Complete EHRs and Health IT Modules the ONC-ACB has certified.

(1) Mandatory disclosures. A Health IT developer must conspicuously include the following on its Web site and in all marketing materials, communications statements, and other assertions related to the Complete EHR or Health IT Module's certification:

(i) The disclaimer “This [Complete EHR or Health IT Module] is [specify Edition of EHR certification criteria] compliant and has been certified by an ONC-ACB in accordance with the applicable certification criteria adopted by the Secretary of Health and Human Services. This certification does not represent an endorsement by the U.S. Department of Health and Human Services.”

(ii) The following information an ONC-ACB is required to report to the National Coordinator:

(A) For a Health IT Module certified to 2015 Edition health IT certification criteria, the information specified by paragraphs (f)(1)(i), (vi), (vii), (viii), (xv), and (xvi) of this section as applicable for the specific Health IT Module.

(B) For a Complete EHR or EHR Module certified to 2014 Edition health IT certification criteria, the information specified by paragraphs (f)(2)(i) through (vii) of this section as applicable for the specific Complete EHR or EHR Module.

(iii) In plain language, a detailed description of all known material information concerning:

(A) Additional types of costs that a user may be required to pay to implement or use the Complete EHR or Health IT Module's capabilities, whether to meet meaningful use objectives and measures or to achieve any other use within the scope of the health IT's certification.

(B) Limitations that a user may encounter in the course of implementing and using the Complete EHR or Health IT Module's capabilities, whether to meet meaningful use objectives and measures or to achieve any other use within the scope of the health IT's certification.

(iv) The types of information required to be disclosed under paragraph (k)(iii) of this section include but are not limited to:

(A) Additional types of costs or fees (whether fixed, recurring, transaction-based, or otherwise) imposed by a health IT developer (or any third-party from whom the developer purchases, licenses, or obtains any technology, products, or services in connection with its certified health IT) to purchase, license, implement, maintain, upgrade, use, or otherwise enable and support the use of capabilities to which health IT is certified; or in connection with any data generated in the course of using any capability to which health IT is certified.

(B) Limitations, whether by contract or otherwise, on the use of any capability to which technology is certified for any purpose within the scope of the technology's certification; or in connection with any data generated in the course of using any capability to which health IT is certified.

(C) Limitations, including but not limited to technical or practical limitations of technology or its capabilities, that could prevent or impair the successful implementation, configuration, customization, maintenance, support, or use of any capabilities to which technology is certified; or that could prevent or limit the use, exchange, or portability of any data generated in the course of using any capability to which technology is certified.

(v) Health IT self-developers are excluded from the requirements of paragraph (k)(1)(iii) of this section.

(2) Transparency attestation. As a condition of a Complete EHR or Health IT Module's certification to any certification criterion, a health IT developer must make one of the following attestations:

(i) An attestation that it will voluntarily and timely provide, in plain writing and in a manner calculated to inform, any part (including all of) the information required to be disclosed under paragraph (k)(1) of this section,

(A) to all customers, prior to providing or entering into any agreement to provide any certified health IT or related product or service (including subsequent updates, add-ons, or additional products or services during the course of an on-going agreement);

(B) to any person who requests or receives a quotation, estimate, description of services, or other assertion or information from the developer in connection with any certified health IT or any capabilities thereof; and

(C) to any person, upon request.

(ii) An attestation by the developer that it has been asked to make the voluntary transparency attestation described by paragraph (k)(2)(i) of this section and has elected not to make such attestation.

(3) A certification issued to a pre-coordinated, integrated bundle of Health IT Modules shall be treated the same as a certification issued to a Complete EHR for the purposes of paragraph (k)(1) of this section, except that the certification must also indicate each Health IT Module that is included in the bundle; and

(4) A certification issued to a Complete EHR or Health IT Module based solely on the applicable certification criteria adopted by the Secretary at subpart C of this part must be separate and distinct from any other certification(s) based on other criteria or requirements.

(l) Display the ONC Certified health IT Certification and Design Mark on all certifications issued under the ONC Health IT Certification Program in a manner that complies with the Criteria and Terms of Use for the ONC Certified health IT Certification and Design Mark, and ensure that use of the mark by health IT developers whose products are certified under the ONC Health IT Certification Program is compliant with the Criteria and Terms of Use for the ONC Certified health IT Certification and Design Mark.

(m) Adaptations and updates. On a quarterly basis each calendar year, obtain a record of:

(1) All adaptations of certified Complete EHRs and certified Health IT Modules; and

(2) All updates made to certified Complete EHRs and certified Health IT Modules affecting the capabilities in certification criteria to which the “safety-enhanced design” criteria apply.

(n) Complaints reporting. Submit a list of complaints received to the National Coordinator on a quarterly basis each calendar year that includes the number of complaints received, the nature/substance of each complaint, and the type of complainant for each complaint.

(o) Be prohibited from reducing the scope of a Complete EHR or Health IT Module's certification when it is under surveillance or under a corrective action plan.

[76 FR 1325, Dec. 7, 2011, as amended at 76 FR 72642, Nov. 25, 2011; 77 FR 54291, Sept. 4, 2012; 79 FR 54479, Sept. 11, 2014; 80 FR 62755, Oct. 16, 2015; 80 FR 76872, Dec. 11, 2015; 81 FR 72465, Oct. 19, 2016]

return arrow Back to Top

§170.524   Principles of proper conduct for ONC-ATLs.

An ONC-ATL shall:

(a) Maintain its NVLAP accreditation for the ONC Health IT Certification Program, including accreditation to ISO/IEC 17025 (incorporated by reference, see §170.599);

(b) Attend all mandatory ONC training and program update sessions;

(c) Maintain a training program that includes documented procedures and training requirements to ensure its personnel are competent to test health IT;

(d) Report to ONC within 15 days any changes that materially affect its:

(1) Legal, commercial, organizational, or ownership status;

(2) Organization and management including key testing personnel;

(3) Policies or procedures;

(4) Location;

(5) Personnel, facilities, working environment or other resources;

(6) ONC authorized representative (point of contact); or

(7) Other such matters that may otherwise materially affect its ability to test health IT.

(e) Allow ONC, or its authorized agent(s), to periodically observe on site (unannounced or scheduled), during normal business hours, any testing performed pursuant to the ONC Health IT Certification Program;

(f) Records retention:

(1) Retain all records related to the testing of Complete EHRs and/or Health IT Modules to an edition of certification criteria for a minimum of 3 years from the effective date that removes the applicable edition from the Code of Federal Regulations; and

(2) Make the records available to HHS upon request during the retention period described in paragraph (f)(1) of this section;

(g) Only test health IT using test tools and test procedures approved by the National Coordinator; and

(h) Promptly refund any and all fees received for:

(1) Requests for testing that are withdrawn while its operations are suspended by the National Coordinator;

(2) Testing that will not be completed as a result of its conduct; and

(3) Previous testing that it performed if its conduct necessitates the retesting of Complete EHRs and/or Health IT Modules.

[81 FR 72465, Oct. 19, 2016]

return arrow Back to Top

§170.525   Application submission.

(a) An applicant for ONC-ACB or ONC-ATL status must submit its application either electronically via email (or Web site submission if available), or by regular or express mail.

(b) An application for ONC-ACB or ONC-ATL status may be submitted to the National Coordinator at any time.

[81 FR 72465, Oct. 19, 2016]

return arrow Back to Top

§170.530   Review of application.

(a) Method of review and review timeframe. (1) Applications will be reviewed in the order they are received.

(2) The National Coordinator is permitted up to 30 days from receipt to review an application that is submitted for the first time.

(b) Application deficiencies. (1) If the National Coordinator identifies an area in an application that requires the applicant to clarify a statement or correct an error or omission, the National Coordinator may contact the applicant to make such clarification or correction without issuing a deficiency notice. If the National Coordinator has not received the requested information after five days, the National Coordinator may issue a deficiency notice to the applicant.

(2) If the National Coordinator determines that deficiencies in the application exist, the National Coordinator will issue a deficiency notice to the applicant and return the application. The deficiency notice will identify the areas of the application that require additional information or correction.

(c) Revised application. (1) An applicant is permitted to submit a revised application in response to a deficiency notice. An applicant may request from the National Coordinator an extension for good cause of the 15-day period provided in paragraph (c)(2) of this section to submit a revised application.

(2) In order for an applicant to continue to be considered for ONC-ACB or ONC-ATL status, the applicant's revised application must address the specified deficiencies and be received by the National Coordinator within 15 days of the applicant's receipt of the deficiency notice, unless the National Coordinator grants an applicant's request for an extension of the 15-day period based on a finding of good cause. If a good cause extension is granted, then the revised application must be received by the end of the extension period.

(3) The National Coordinator is permitted up to 15 days to review a revised application once it has been received and may request clarification of statements and the correction of errors or omissions in a revised application during this time period.

(4) If the National Coordinator determines that a revised application still contains deficiencies, the applicant will be issued a denial notice indicating that the applicant cannot reapply for ONC-ACB or ONC-ATL status for a period of six months from the date of the denial notice. An applicant may request reconsideration of this decision in accordance with §170.535.

(d) Satisfactory application. (1) An application will be deemed satisfactory if it meets all the application requirements, as determined by the National Coordinator.

(2) The National Coordinator will notify the applicant's authorized representative of its satisfactory application and its successful achievement of ONC-ACB or ONC-ATL status.

(3) Once notified by the National Coordinator of its successful achievement of ONC-ACB or ONC-ATL status, the applicant may represent itself as an ONC-ACB or ONC-ATL (as applicable) and begin certifying or testing (as applicable) health information technology consistent with its authorization.

[76 FR 1325, Dec. 7, 2011, as amended at 81 FR 72465, Oct. 19, 2016]

return arrow Back to Top

§170.535   ONC-ACB and ONC-ATL application reconsideration.

(a) Basis for reconsideration request. An applicant may request that the National Coordinator reconsider a denial notice only if the applicant can demonstrate that clear, factual errors were made in the review of its application and that the errors' correction could lead to the applicant obtaining ONC-ACB or ONC-ATL status.

(b) Submission requirement. An applicant is required to submit, within 15 days of receipt of a denial notice, a written statement to the National Coordinator contesting the decision to deny its application and explaining with sufficient documentation what factual error(s) it believes can account for the denial. If the National Coordinator does not receive the applicant's reconsideration request within the specified timeframe, its reconsideration request may be rejected.

(c) Reconsideration request review. If the National Coordinator receives a timely reconsideration request, the National Coordinator is permitted up to 15 days from the date of receipt to review the information submitted by the applicant and issue a decision.

(d) Decision. (1) If the National Coordinator determines that clear, factual errors were made during the review of the application and that correction of the errors would remove all identified deficiencies, the applicant's authorized representative will be notified of the National Coordinator's determination and the applicant's successful achievement of ONC-ACB or ONC-ATL status.

(2) If, after reviewing an applicant's reconsideration request, the National Coordinator determines that the applicant did not identify factual errors or that the correction of the factual errors would not remove all identified deficiencies in the application, the National Coordinator may reject the applicant's reconsideration request.

(3) Final decision. A reconsideration decision issued by the National Coordinator is final and not subject to further review.

[76 FR 1325, Dec. 7, 2011, as amended at 81 FR 72466, Oct. 19, 2016]

return arrow Back to Top

§170.540   ONC-ACB and ONC-ATL status.

(a) Acknowledgement and publication. The National Coordinator will acknowledge and make publicly available the names of ONC-ACBs and ONC-ATLs, including the date each was authorized and the type(s) of certification or scope of testing, respectively, each has been authorized to perform.

(b) Representation. Each ONC-ACB or ONC-ATL must prominently and unambiguously identify the scope of its authorization on its Web site and in all marketing and communications statements (written and oral) pertaining to its activities under the ONC Health IT Certification Program.

(c) Renewal. An ONC-ACB or ONC-ATL is required to renew its status every three years. An ONC-ACB or ONC-ATL is required to submit a renewal request, containing any updates to the information requested in §170.520, to the National Coordinator 60 days prior to the expiration of its status.

(d) Expiration. An ONC-ACB's or ONC-ATL's status will expire three years from the date it was granted by the National Coordinator unless it is renewed in accordance with paragraph (c) of this section.

[81 FR 72466, Oct. 19, 2016]

return arrow Back to Top

§170.545   Complete EHR certification.

(a) When certifying Complete EHRs, an ONC-ACB must certify in accordance with all applicable certification criteria adopted by the Secretary at subpart C of this part.

(b) An ONC-ACB must provide the option for a Complete EHR to be certified solely to the applicable certification criteria adopted by the Secretary at subpart C of this part.

(c) Gap certification. An ONC-ACB may provide the option for and perform gap certification of previously certified Complete EHRs.

(d) Inherited certified status. An ONC-ACB must accept requests for a newer version of a previously certified Complete EHR to inherit the certified status of the previously certified Complete EHR without requiring the newer version to be recertified.

(1) Before granting certified status to a newer version of a previously certified Complete EHR, an ONC-ACB must review an attestation submitted by the developer of the Complete EHR to determine whether any change in the newer version has adversely affected the Complete EHR's capabilities for which certification criteria have been adopted.

(2) An ONC-ACB may grant certified status to a newer version of a previously certified Complete EHR if it determines that the capabilities for which certification criteria have been adopted have not been adversely affected.

(e) An ONC-ACB that has been authorized to certify Complete EHRs is also authorized to certify all Health IT Modules under the ONC Health IT Certification Program.

[76 FR 1325, Dec. 7, 2011, as amended at 77 FR 54291, Sept. 4, 2012]

return arrow Back to Top

§170.550   Health IT Module certification.

(a) When certifying Health IT Module(s), an ONC-ACB must certify in accordance with the applicable certification criteria adopted by the Secretary at subpart C of this part.

(b) An ONC-ACB must provide the option for an Health IT Module(s) to be certified solely to the applicable certification criteria adopted by the Secretary at subpart C of this part.

(c) Gap certification. An ONC-ACB may provide the option for and perform gap certification of previously certified Health IT Module(s).

(d) An ONC-ACB may provide an updated certification to a previously certified Health IT Module(s).

(e) [Reserved]

(f) When certifying an Health IT Module to the 2014 Edition EHR certification criteria, an ONC-ACB must certify the Health IT Module in accordance with the certification criteria at:

(1) Section 170.314(g)(1) or (2) if the Health IT Module has capabilities presented for certification that would support a meaningful use objective with a percentage-based measure;

(2) Section 170.314(g)(3) if the Health IT Module is presented for certification to one or more listed certification criteria in §170.314(g)(3); and

(3) Section 170.314(g)(4).

(g) When certifying a Health IT Module to the 2015 Edition health IT certification criteria, an ONC-ACB must certify the Health IT Module in accordance with the certification criteria at:

(1) Section 170.315(g)(3) if the Health IT Module is presented for certification to one or more listed certification criteria in §170.315(g)(3);

(2) Section 170.315(g)(4);

(3) Section 170.315(g)(5); and

(4) Section 170.315(g)(6) if the Health IT Module is presented for certification with C-CDA creation capabilities within its scope. If the scope of certification sought includes multiple certification criteria that require C-CDA creation, §170.315(g)(6) need only be tested in association with one of those certification criteria and would not be expected or required to be tested for each. If the scope of certification sought includes multiple certification criteria that require C-CDA creation, §170.315(g)(6) need only be tested in association with one of those certification criteria and would not be expected or required to be tested for each so long as all applicable C-CDA document templates have been evaluated as part of §170.315(g)(6) for the scope of the certification sought.

(h) Privacy and security certification framework—(1) General rule. When certifying a Health IT Module to the 2015 Edition health IT certification criteria, an ONC-ACB can only issue a certification to a Health IT Module if the privacy and security certification criteria in paragraphs (h)(3)(i) through (viii) of this section have also been met (and are included within the scope of the certification).

(2) In order to be issued a certification, a Health IT Module would only need to be tested once to each applicable privacy and security criterion in paragraphs (h)(3)(i) through (viii) of this section so long as the health IT developer attests that such privacy and security capabilities apply to the full scope of capabilities included in the requested certification, except for the following:

(i) A Health IT Module presented for certification to §170.315(e)(1) must be separately tested to §170.315(d)(9); and

(ii) A Health IT Module presented for certification to §170.315(e)(2) must be separately tested to §170.315(d)(9).

(3) Applicability. (i) Section 170.315(a) is also certified to the certification criteria specified in §170.315(d)(1) through (7);

(ii) Section 170.315(b) is also certified to the certification criteria specified in §170.315(d)(1) through (3) and (d)(5) through (8);

(iii) Section 170.315(c) is also certified to the certification criteria specified in §170.315(d)(1) through (3), and (5);

(iv) Section 170.315(e)(1) is also certified to the certification criteria specified in §170.315(d)(1) through (3), (5), (7), and (9);

(v) Section 170.315(e)(2) and (3) is also certified to the certification criteria specified in §170.315(d)(1) through (3), (5), and (9);

(vi) Section 170.315(f) is also certified to the certification criteria specified in §170.315(d)(1) through (3) and (7);

(vii) Section 170.315(g)(7), (8) and (9) is also certified to the certification criteria specified in §170.315(d)(1) and (9); and (d)(2) or (10);

(viii) Section 170.315(h) is also certified to the certification criteria specified in §170.315(d)(1) through (3); and

(4) Methods to demonstrate compliance with each privacy and security criterion. One of the following methods must be used to meet each applicable privacy and security criterion listed in paragraph (h)(3) of this section:

(i) Directly, by demonstrating a technical capability to satisfy the applicable certification criterion or certification criteria; or

(ii) Demonstrate, through system documentation sufficiently detailed to enable integration, 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.

(i) [Reserved]

(j) Direct Project transport method. An ONC-ACB can only issue a certification to a Health IT Module for §170.315(h)(1) if the Health IT Module's certification also includes §170.315(b)(1).

(k) Inherited certified status. An ONC-ACB must accept requests for a newer version of a previously certified Health IT Module(s) to inherit the certified status of the previously certified Health IT Module(s) without requiring the newer version to be recertified.

(1) Before granting certified status to a newer version of a previously certified Health IT Module(s), an ONC-ACB must review an attestation submitted by the developer(s) of the Health IT Module(s) to determine whether any change in the newer version has adversely affected the Health IT Module(s)' capabilities for which certification criteria have been adopted.

(2) An ONC-ACB may grant certified status to a newer version of a previously certified Health IT Module(s) if it determines that the capabilities for which certification criteria have been adopted have not been adversely affected.

[76 FR 1325, Dec. 7, 2011, as amended at 77 FR 54291, Sept. 4, 2012; 79 FR 54480, Sept. 11, 2014; 80 FR 62757, Oct. 16, 2015]

return arrow Back to Top

§170.553   [Reserved]

return arrow Back to Top

§170.555   Certification to newer versions of certain standards.

(a) ONC-ACBs may certify Complete EHRs and/or Health IT Module(s) to a newer version of certain identified minimum standards specified at subpart B of this part, unless the Secretary prohibits the use of a newer version for certification.

(b) Applicability of a newer version of a minimum standard. (1) ONC-ACBs are not required to certify Complete EHRs and/or Health IT Module(s) according to newer versions of standards identified as minimum standards in subpart B of this part, unless and until the incorporation by reference of a standard is updated in the Federal Register with a newer version.

(2) A certified Complete EHR or certified Health IT Module may be upgraded to comply with newer versions of standards identified as minimum standards in subpart B of this part without adversely affecting its certification status, unless the Secretary prohibits the use of a newer version for certification.

[77 FR 54291, Sept. 4, 2012]

return arrow Back to Top

§170.556   In-the-field surveillance and maintenance of certification for Health IT.

(a) In-the-field surveillance. Consistent with its accreditation to ISO/IEC 17065 and the requirements of this subpart, an ONC-ACB must initiate surveillance “in the field” as necessary to assess whether a certified Complete EHR or certified Health IT Module continues to conform to the requirements of its certification once the certified Complete EHR or certified Health IT Module has been implemented and is in use in a production environment.

(1) Production environment. An ONC-ACB's assessment of a certified capability in the field must be based on the use of the capability in a production environment, which means a live environment in which the capability has been implemented and is in use.

(2) Production data. An ONC-ACB's assessment of a certified capability in the field must be based on the use of the capability with production data unless the use of test data is specifically approved by the National Coordinator.

(b) Reactive surveillance. An ONC-ACB must initiate surveillance (including, as necessary, in-the-field surveillance required by paragraph (a) of this section) whenever it becomes aware of facts or circumstances that would cause a reasonable person to question a certified Complete EHR or certified Health IT Module's continued conformity to the requirements of its certification.

(1) Review of required disclosures. When an ONC-ACB performs reactive surveillance under this paragraph, it must verify that the requirements of §170.523(k)(1) have been followed as applicable to the issued certification.

(2) [Reserved]

(c) Randomized surveillance. During each calendar year surveillance period, an ONC-ACB must conduct in-the-field surveillance for certain randomly selected Complete EHRs and Health IT Modules to which it has issued a certification.

(1) Scope. When an ONC-ACB selects a certified Complete EHR or certified Health IT Module for randomized surveillance under this paragraph, its evaluation of the certified Complete EHR or certified Health IT Module must include all certification criteria prioritized by the National Coordinator that are part of the scope of the certification issued to the Complete EHR or Health IT Module.

(2) Minimum number of products selected per year. 2% of the Complete EHRs and Health IT Modules to which an ONC-ACB has issued a certification must be subject to randomized surveillance.

(3) Selection method. An ONC-ACB must randomly select (subject to appropriate weighting and sampling considerations) certified Complete EHRs and certified Health IT Modules for surveillance under this paragraph.

(4) Number and types of locations for in-the-field surveillance. For each certified Compete EHR or certified Health IT Module selected for randomized surveillance under this paragraph, an ONC-ACB must:

(i) Evaluate the certified Complete EHR or certified Health IT Module's capabilities at one or more locations where the certified Complete EHR or certified Health IT Module is implemented and in use in the field.

(ii) Ensure that the locations are selected at random (subject to appropriate weighting and sampling considerations) from among all locations where the certified Complete EHR or certified Health IT Module is implemented and in use in the field.

(5) Exclusion and exhaustion. An ONC-ACB must make a good faith effort to complete in-the-field surveillance of a certified Complete EHR or certified Health IT Module at each location selected under paragraph (c)(4) of this section. If the ONC-ACB is unable to complete surveillance at a location due to circumstances beyond its control, the ONC-ACB may substitute a different location that meets the requirements of paragraph (c)(4) of this section. If no such location exists, the ONC-ACB may exclude the certified Complete EHR or certified Health IT Module and substitute a different randomly selected Complete EHR or Health IT Module to which it has issued a certification.

(6) Prohibition on consecutive selection for randomized surveillance. An ONC-ACB is prohibited from selecting a certified Complete EHR or certified Health IT Module for randomized surveillance under this paragraph more than once during any consecutive 12 month period. This limitation does not apply to reactive and other forms of surveillance required under this subpart and the ONC-ACB's accreditation.

(d) Corrective action plan and procedures. (1) When an ONC-ACB determines, through surveillance under this section or otherwise, that a Complete EHR or Health IT Module does not conform to the requirements of its certification, the ONC-ACB must notify the developer of its findings and require the developer to submit a proposed corrective action plan for the applicable certification criterion, certification criteria, or certification requirement.

(2) The ONC-ACB shall provide direction to the developer as to the required elements of the corrective action plan.

(3) The ONC-ACB shall verify the required elements of the corrective action plan, consistent with its accreditation and any elements specified by the National Coordinator. At a minimum, any corrective action plan submitted by a developer to an ONC-ACB must include:

(i) A description of the identified non-conformities or deficiencies;

(ii) An assessment of how widespread or isolated the identified non-conformities or deficiencies may be across all of the developer's customers and users of the certified Complete EHR or certified Health IT Module;

(iii) How the developer will address the identified non-conformities or deficiencies, both at the locations under which surveillance occurred and for all other potentially affected customers and users;

(iv) How the developer will ensure that all affected and potentially affected customers and users are alerted to the identified non-conformities or deficiencies, including a detailed description of how the developer will assess the scope and impact of the problem, including identifying all potentially affected customers; how the developer will promptly ensure that all potentially affected customers are notified of the problem and plan for resolution; how and when the developer will resolve issues for individual affected customers; and how the developer will ensure that all issues are in fact resolved.

(v) The timeframe under which corrective action will be completed.

(vi) An attestation by the developer that it has completed all elements of the approved corrective action plan.

(4) When the ONC-ACB receives a proposed corrective action plan (or a revised proposed corrective action plan), the ONC-ACB shall either approve the corrective action plan or, if the plan does not adequately address the elements described by paragraph (d)(3) of this section and other elements required by the ONC-ACB, instruct the developer to submit a revised proposed corrective action plan.

(5) Suspension. Consistent with its accreditation to ISO/IEC 17065 and procedures for suspending a certification, an ONC-ACB shall initiate suspension procedures for a Complete EHR or Health IT Module:

(i) 30 days after notifying the developer of a non-conformity pursuant to paragraph (d)(1) of this section, if the developer has not submitted a proposed corrective action plan;

(ii) 90 days after notifying the developer of a non-conformity pursuant to paragraph (d)(1) of this section, if the ONC-ACB cannot approve a corrective action plan because the developer has not submitted a revised proposed corrective action plan in accordance with paragraph (d)(4) of this section; and

(iii) Immediately, if the developer has not completed the corrective actions specified by an approved corrective action plan within the time specified therein.

(6) Withdrawal. If a certified Complete EHR or certified Health IT Module's certification has been suspended, an ONC-ACB is permitted to initiate certification withdrawal procedures for the Complete EHR or Health IT Module (consistent with its accreditation to ISO/IEC 17065 and procedures for withdrawing a certification) when the health IT developer has not completed the actions necessary to reinstate the suspended certification.

(e) Reporting of surveillance results requirements—(1) Rolling submission of in-the-field surveillance results. The results of in-the-field surveillance under this section must be submitted to the National Coordinator, at a minimum, on a quarterly basis in accordance with §170.523(i)(2).

(2) Confidentiality of locations evaluated. The contents of an ONC-ACB's surveillance results submitted to the National Coordinator must not include any information that would identify any user or location that participated in or was subject to surveillance.

(3) Reporting of corrective action plans. When a corrective action plan is initiated for a Complete EHR or Health IT Module, an ONC-ACB must report the Complete EHR or Health IT Module and associated product and corrective action information to the National Coordinator in accordance with §170.523(f)(1)(xxii) or (f)(2)(xi), as applicable.

(f) Relationship to other surveillance requirements. Nothing in this section shall be construed to limit or constrain an ONC-ACB's duty or ability to perform surveillance, including in-the-field surveillance, or to suspend or terminate the certification, of any certified Complete EHR or certified Health IT Module as required or permitted by this subpart and the ONC-ACB's accreditation to ISO/IEC 17065.

[80 FR 62758, Oct. 16, 2015, as amended at 80 FR 76872, Dec. 11, 2015; 81 FR 72466, Oct. 19, 2016]

return arrow Back to Top

§170.557   Authorized testing and certification methods.

(a) ONC-ATL applicability. An ONC-ATL must provide remote testing for both development and deployment sites.

(b) ONC-ACB applicability. An ONC-ACB must provide remote certification for both development and deployment sites.

[81 FR 72466, Oct. 19, 2016]

return arrow Back to Top

§170.560   Good standing as an ONC-ACB or ONC-ATL.

(a) ONC-ACB good standing. An ONC-ACB must maintain good standing by:

(1) Adhering to the Principles of Proper Conduct for ONC-ACBs;

(2) Refraining from engaging in other types of inappropriate behavior, including an ONC-ACB misrepresenting the scope of its authorization, as well as an ONC-ACB certifying Complete EHRs and/or Health IT Module(s) for which it does not have authorization; and

(3) Following all other applicable federal and state laws.

(b) ONC-ATL good standing. An ONC-ATL must maintain good standing by:

(1) Adhering to the Principles of Proper Conduct for ONC-ATLs;

(2) Refraining from engaging in other types of inappropriate behavior, including an ONC-ATL misrepresenting the scope of its authorization, as well as an ONC-ATL testing health IT for which it does not have authorization; and

(3) Following all other applicable federal and state laws.

[81 FR 72466, Oct. 19, 2016]

return arrow Back to Top

§170.565   Revocation of ONC-ACB or ONC-ATL status.

(a) Type-1 violations. The National Coordinator may revoke an ONC-ATL or ONC-ACB's status for committing a Type-1 violation. Type-1 violations include violations of law or ONC Health IT Certification Program policies that threaten or significantly undermine the integrity of the ONC Health IT Certification Program. These violations include, but are not limited to: False, fraudulent, or abusive activities that affect the ONC Health IT Certification Program, a program administered by HHS or any program administered by the federal government.

(b) Type-2 violations. The National Coordinator may revoke an ONC-ATL or ONC-ACB's status for failing to timely or adequately correct a Type-2 violation. Type-2 violations constitute noncompliance with §170.560.

(1) Noncompliance notification. If the National Coordinator obtains reliable evidence that an ONC-ATL or ONC-ACB may no longer be in compliance with §170.560, the National Coordinator will issue a noncompliance notification with reasons for the notification to the ONC-ATL or ONC-ACB requesting that the ONC-ATL or ONC-ACB respond to the alleged violation and correct the violation, if applicable.

(2) Opportunity to become compliant. After receipt of a noncompliance notification, an ONC-ATL or ONC-ACB is permitted up to 30 days to submit a written response and accompanying documentation that demonstrates that no violation occurred or that the alleged violation has been corrected.

(i) If the ONC-ATL or ONC-ACB submits a response, the National Coordinator is permitted up to 30 days from the time the response is received to evaluate the response and reach a decision. The National Coordinator may, if necessary, request additional information from the ONC-ATL or ONC-ACB during this time period.

(ii) If the National Coordinator determines that no violation occurred or that the violation has been sufficiently corrected, the National Coordinator will issue a memo to the ONC-ATL or ONC-ACB confirming this determination.

(iii) If the National Coordinator determines that the ONC-ATL or ONC-ACB failed to demonstrate that no violation occurred or to correct the area(s) of non-compliance identified under paragraph (b)(1) of this section within 30 days of receipt of the noncompliance notification, then the National Coordinator may propose to revoke the ONC-ATL or ONC-ACB's status.

(c) Proposed revocation. (1) The National Coordinator may propose to revoke an ONC-ATL or ONC-ACB's status if the National Coordinator has reliable evidence that the ONC-ATL or ONC-ACB has committed a Type-1 violation; or

(2) The National Coordinator may propose to revoke an ONC-ATL or ONC-ACB's status if, after the ONC-ATL or ONC-ACB has been notified of a Type-2 violation, the ONC-ATL or ONC-ACB fails to:

(i) Rebut the finding of a violation with sufficient evidence showing that the violation did not occur or that the violation has been corrected; or

(ii) Submit to the National Coordinator a written response to the noncompliance notification within the specified timeframe under paragraph (b)(2) of this section.

(d) Suspension of an ONC-ATL or ONC-ACB's operations. (1) The National Coordinator may suspend the operations of an ONC-ATL or ONC-ACB under the ONC Health IT Certification Program based on reliable evidence indicating that:

(i) Applicable to both ONC-ACBs and ONC-ATLs. The ONC-ATL or ONC-ACB committed a Type-1 or Type-2 violation;

(ii) Applicable to ONC-ACBs. The continued certification of Complete EHRs or Health IT Modules by the ONC-ACB could have an adverse impact on the health or safety of patients.

(iii) Applicable to ONC-ATLs. The continued testing of Complete EHRs or Health IT Modules by the ONC-ATL could have an adverse impact on the health or safety of patients.

(2) If the National Coordinator determines that the conditions of paragraph (d)(1) of this section have been met, an ONC-ATL or ONC-ACB will be issued a notice of proposed suspension.

(3) Upon receipt of a notice of proposed suspension, an ONC-ATL or ONC-ACB will be permitted up to 3 days to submit a written response to the National Coordinator explaining why its operations should not be suspended.

(4) The National Coordinator is permitted up to 5 days from receipt of an ONC-ATL or ONC-ACB's written response to a notice of proposed suspension to review the response and make a determination.

(5) The National Coordinator may make one of the following determinations in response to the ONC-ATL or ONC-ACB's written response or if the ONC-ATL or ONC-ACB fails to submit a written response within the timeframe specified in paragraph (d)(3) of this section:

(i) Rescind the proposed suspension; or

(ii) Suspend the ONC-ATL or ONC-ACB's operations until it has adequately corrected a Type-2 violation; or

(iii) Propose revocation in accordance with paragraph (c) of this section and suspend the ONC-ATL or ONC-ACB's operations for the duration of the revocation process.

(6) A suspension will become effective upon an ONC-ATL or ONC-ACB's receipt of a notice of suspension.

(e) Opportunity to respond to a proposed revocation notice. (1) An ONC-ATL or ONC-ACB may respond to a proposed revocation notice, but must do so within 10 days of receiving the proposed revocation notice and include appropriate documentation explaining in writing why its status should not be revoked.

(2) Upon receipt of an ONC-ATL or ONC-ACB's response to a proposed revocation notice, the National Coordinator is permitted up to 30 days to review the information submitted by the ONC-ACB or ONC-ATL and reach a decision.

(f) Good standing determination. If the National Coordinator determines that an ONC-ATL or ONC-ACB's status should not be revoked, the National Coordinator will notify the ONC-ATL or ONC-ACB's authorized representative in writing of this determination.

(g) Revocation. (1) The National Coordinator may revoke an ONC-ATL or ONC-ACB's status if:

(i) A determination is made that revocation is appropriate after considering the information provided by the ONC-ATL or ONC-ACB in response to the proposed revocation notice; or

(ii) The ONC-ATL or ONC-ACB does not respond to a proposed revocation notice within the specified timeframe in paragraph (e)(1) of this section.

(2) A decision to revoke an ONC-ATL or ONC-ACB's status is final and not subject to further review unless the National Coordinator chooses to reconsider the revocation.

(h) Extent and duration of revocation—(1) Effectuation. The revocation of an ONC-ATL or ONC-ACB is effective as soon as the ONC-ATL or ONC-ACB receives the revocation notice.

(2) ONC-ACB provisions. (i) A certification body that has had its ONC-ACB status revoked is prohibited from accepting new requests for certification and must cease its current certification operations under the ONC Health IT Certification Program.

(ii) A certification body that has had its ONC-ACB status revoked for a Type-1 violation is not permitted to reapply for ONC-ACB status under the ONC Health IT Certification Program for a period of 1 year.

(iii) The failure of a certification body that has had its ONC-ACB status revoked to promptly refund any and all fees for certifications of Complete EHRs and Health IT Module(s) not completed will be considered a violation of the Principles of Proper Conduct for ONC-ACBs and will be taken into account by the National Coordinator if the certification body reapplies for ONC-ACB status under the ONC Health IT Certification Program.

(3) ONC-ATL provisions. (i) A testing lab that has had its ONC-ATL status revoked is prohibited from accepting new requests for testing and must cease its current testing operations under the ONC Health IT Certification Program.

(ii) A testing lab that has had its ONC-ATL status revoked for a Type-1 violation is not permitted to reapply for ONC-ATL status under the ONC Health IT Certification Program for a period of 1 year.

(iii) The failure of a testing lab that has had its ONC-ATL status revoked to promptly refund any and all fees for testing of health IT not completed will be considered a violation of the Principles of Proper Conduct for ONC-ATLs and will be taken into account by the National Coordinator if the testing lab reapplies for ONC-ATL status under the ONC Health IT Certification Program.

[81 FR 72466, Oct. 19, 2016]

return arrow Back to Top

§170.570   Effect of revocation on the certifications issued to Complete EHRs and EHR Module(s).

(a) The certified status of Complete EHRs and/or Health IT Module(s) certified by an ONC-ACB or tested by an ONC-ATL that had its status revoked will remain intact unless a Type-1 violation was committed by the ONC-ACB and/or ONC-ATL that calls into question the legitimacy of the certifications issued.

(b) If the National Coordinator determines that a Type-1 violation was committed by an ONC-ACB and/or ONC-ATL that called into question the legitimacy of certifications issued to health IT, then the National Coordinator would:

(1) Review the facts surrounding the revocation of the ONC-ACB's or ONC-ATL's status; and

(2) Publish a notice on ONC's Web site if the National Coordinator believes that the Complete EHRs and/or Health IT Module(s) certifications were based on unreliable testing and/or certification.

(c) If the National Coordinator determines that Complete EHRs and/or Health IT Module(s) certifications were based on unreliable testing and/or certification, the certification status of affected Complete EHRs and/or Health IT Module(s) would only remain intact for 120 days after the National Coordinator publishes the notice.

(1) The certification status of affected Complete EHRs and/or Health IT Module(s) can only be maintained after the 120-day timeframe by being re-tested by an ONC-ATL in good standing, as necessary, and re-certified by an ONC-ACB in good standing.

(2) The National Coordinator may extend the time that the certification status of affected Complete EHRs and/or Health IT Module(s) remains intact as necessary for the proper retesting and recertification of the affected health IT.

[81 FR 72467, Oct. 19, 2016]

return arrow Back to Top

§170.575   Removal of the ONC-AA.

(a) Conduct violations. The National Coordinator may remove the ONC-AA for committing a conduct violation. Conduct violations include violations of law or ONC Health IT Certification Program policies that threaten or significantly undermine the integrity of the ONC Health IT Certification Program. These violations include, but are not limited to: false, fraudulent, or abusive activities that affect the ONC Health IT Certification Program, a program administered by HHS, or any program administered by the Federal government.

(b) Performance violations. The National Coordinator may remove the ONC-AA for failing to timely or adequately correct a performance violation. Performance violations constitute a failure to adequately perform the ONC-AA's responsibilities as specified in §170.503(e).

(1) Noncompliance notification. If the National Coordinator obtains reliable evidence that the ONC-AA may no longer be adequately performing its responsibilities specified in §170.503(e), the National Coordinator will issue a noncompliance notification with reasons for the notification to the ONC-AA requesting that the ONC-AA respond to the alleged violation and correct the violation, if applicable.

(2) Opportunity to become compliant. The ONC-AA is permitted up to 30 days from receipt of a noncompliance notification to submit a written response and accompanying documentation that demonstrates that no violation occurred or that the alleged violation has been corrected.

(i) If the ONC-AA submits a response, the National Coordinator is permitted up to 60 days from the time the response is received to evaluate the response and reach a decision. The National Coordinator may, if necessary, request additional information from the ONC-AA during this time period.

(ii) If the National Coordinator determines that no violation occurred or that the violation has been sufficiently corrected, the National Coordinator will issue a memo to the ONC-AA confirming this determination. Otherwise, the National Coordinator may propose to remove the ONC-AA in accordance with paragraph (c) of this section.

(c) Proposed removal. (1) The National Coordinator may propose to remove the ONC-AA if the National Coordinator has reliable evidence that the ONC-AA has committed a conduct violation; or

(2) The National Coordinator may propose to remove the ONC-AA if, after the ONC-AA has been notified of an alleged performance violation, the ONC-AA fails to:

(i) Rebut the alleged violation with sufficient evidence showing that the violation did not occur or that the violation has been corrected; or

(ii) Submit to the National Coordinator a written response to the noncompliance notification within the specified timeframe under paragraph (b)(2) of this section.

(d) Opportunity to respond to a proposed removal notice. (1) The ONC-AA may respond to a proposed removal notice, but must do so within 20 days of receiving the proposed removal notice and include appropriate documentation explaining in writing why it should not be removed as the ONC-AA.

(2) Upon receipt of the ONC-AA's response to a proposed removal notice, the National Coordinator is permitted up to 60 days to review the information submitted by the ONC-AA and reach a decision.

(e) Retention of ONC-AA status. If the National Coordinator determines that the ONC-AA should not be removed, the National Coordinator will notify the ONC-AA in writing of this determination.

(f) Removal. (1) The National Coordinator may remove the ONC-AA if:

(i) A determination is made that removal is appropriate after considering the information provided by the ONC-AA in response to the proposed removal notice; or

(ii) The ONC-AA does not respond to a proposed removal notice within the specified timeframe in paragraph (d)(1) of this section.

(2) A decision to remove the ONC-AA is final and not subject to further review unless the National Coordinator chooses to reconsider the removal.

(g) Extent and duration of removal. (1) The removal of the ONC-AA is effective upon the date specified in the removal notice provided to the ONC-AA.

(2) An accreditation organization that is removed as the ONC-AA must cease all activities under the ONC Health IT Certification Program, including accepting new requests for accreditation under the ONC Health IT Certification Program.

(3) An accreditation organization that is removed as the ONC-AA is prohibited from being considered for ONC-AA status for a period of 1 year from the effective date of its removal as the ONC-AA.

[76 FR 72643, Nov. 25, 2011, as amended at 77 FR 54291, Sept. 4, 2012]

return arrow Back to Top

§170.580   ONC review of certified health IT.

(a) Direct review—(1) Purpose. ONC may directly review certified health IT to determine whether it conforms to the requirements of the ONC Health IT Certification Program.

(2) Circumstances that may trigger review—(i) Unsafe conditions. ONC may initiate direct review under this section if it has a reasonable belief that certified health IT may not conform to the requirements of the Program because the certified health IT may be causing or contributing to conditions that present a serious risk to public health or safety, taking into consideration—

(A) The potential nature, severity, and extent of the suspected conditions;

(B) The need for an immediate or coordinated governmental response; and

(C) If applicable, information that calls into question the validity of the health IT's certification or maintenance thereof under the Program.

(ii) Impediments to ONC-ACB oversight. ONC may initiate direct review under this section if it has a reasonable belief that certified health IT may not conform to requirements of the Program and the suspected non-conformity presents issues that—

(A) May require access to confidential or other information that is not available to an ONC-ACB;

(B) May require concurrent or overlapping review by two or more ONC-ACBs; or

(C) May exceed an ONC-ACB's resources or expertise.

(3) Relationship to ONC-ACBs and ONC-ATLs. (i) ONC's review of certified health IT is independent of, and may be in addition to, any surveillance conducted by an ONC-ACB.

(ii) ONC may assert exclusive review of certified health IT as to any matters under review by ONC and any similar matters under surveillance by an ONC-ACB.

(iii) ONC's determination on matters under its review is controlling and supersedes any determination by an ONC-ACB on the same matters.

(iv) An ONC-ACB and ONC-ATL shall provide ONC with any available information that ONC deems relevant to its review of certified health IT.

(v) ONC may end all or any part of its review of certified health IT under this section at any time and refer the applicable part of the review to the relevant ONC-ACB(s) if ONC determines that doing so would serve the effective administration or oversight of the ONC Health IT Certification Program.

(b) Notice—(1) Notice of potential non-conformity—(i) Circumstances that may trigger notice of potential non-conformity. At any time during its review of certified health IT under paragraph (a) of this section, ONC may send a notice of potential non-conformity if it has a reasonable belief that certified health IT may not conform to the requirements of the ONC Health IT Certification Program.

(ii) Health IT developer response. (A) The health IT developer must respond to the notice of potential non-conformity by:

(1) Cooperating with ONC and/or a third party acting on behalf of ONC;

(2) Providing ONC and/or a third party acting on behalf of ONC access, including in accordance with paragraph (b)(3) of this section, to the certified health IT under review;

(3) Providing ONC with a written explanation and all supporting documentation addressing the potential non-conformity within 30 days, or within the adjusted timeframe set in accordance with paragraph (b)(1)(ii)(B) of this section.

(B) ONC may adjust the 30-day timeframe specified in paragraph (b)(1)(ii)(A)(3) of this section to be shorter or longer based on factors including, but not limited to:

(1) The type of certified health IT and certification in question;

(2) The type of potential non-conformity to be corrected;

(3) The time required to correct the potential non-conformity; and

(4) Issues of public health or safety.

(iii) ONC determination. After receiving the health IT developer's written explanation and supporting documentation as required by paragraph (b)(1)(ii)(A)(3) of this section, ONC shall do one of the following:

(A) Issue a written determination ending its review.

(B) Request additional information and continue its review in accordance with a new timeframe ONC establishes under (b)(1)(ii)(A)(3) and (b)(1)(ii)(B) of this section.

(C) Substantiate a non-conformity and issue a notice of non-conformity.

(D) Issue a notice of proposed termination.

(2) Notice of non-conformity—(i) Circumstances that may trigger notice of non-conformity. At any time during its review of certified health IT under paragraph (a) of this section, ONC may send a notice of non-conformity to the health IT developer if it determines that certified health IT does not conform to the requirements of the ONC Health IT Certification Program.

(ii) Health IT developer response. (A) The health IT developer must respond to the notice of non-conformity by:

(1) Cooperating with ONC and/or a third party acting on behalf of ONC;

(2) Providing ONC and/or a third party acting on behalf of ONC access, including in accordance with paragraph (b)(3) of this section, to the certified health IT under review;

(3) Providing ONC with a written explanation and all supporting documentation addressing the non-conformity within 30 days, or within the adjusted timeframe set in accordance with paragraph (b)(1)(ii)(B) of this section; and

(4) Providing a proposed corrective action plan consistent with paragraph (c) of this section.

(B) ONC may adjust the 30-day timeframe specified in paragraph (b)(2)(ii)(A)(3) of this section to be shorter or longer based on factors including, but not limited to:

(1) The type of certified health IT and certification in question;

(2) The type of non-conformity to be corrected;

(3) The time required to correct the non-conformity; and

(4) Issues of public health or safety.

(iii) ONC determination. After receiving the health IT developer's response provided in accordance with paragraph (b)(2)(ii) of this section, ONC shall either issue a written determination ending its review or continue with its review under the provisions of this section.

(3) Records access. In response to a notice of potential non-conformity or notice of non-conformity, a health IT developer shall make available to ONC and for sharing within HHS, with other federal departments, agencies, and offices, and with appropriate entities including, but not limited to, third-parties acting on behalf of ONC:

(i) All records related to the development, testing, certification, implementation, maintenance and use of its certified health IT; and

(ii) Any complaint records related to the certified health IT.

(c) Corrective action plan and procedures. (1) If ONC determines that certified health IT does not conform to requirements of the ONC Health IT Certification Program, ONC shall notify the health IT developer of its determination and require the health IT developer to submit a proposed corrective action plan.

(2) ONC shall provide direction to the health IT developer as to the required elements of the corrective action plan, which shall include such required elements as ONC determines necessary to comprehensively and expeditiously resolve the identified non-conformity(ies). The corrective action plan shall, in all cases, at a minimum include the following required elements:

(i) An assessment and description of the nature, severity, and extent of the non-conformity;

(ii) Identification of all potentially affected customers;

(iii) A detailed description of how the health IT developer will promptly ensure that all potentially affected customers are notified of the non-conformity and plan for resolution;

(iv) A detailed description of how and when the health IT developer will resolve the identified non-conformity and all issues, both at the locations where the non-conformity was identified and for all affected customers;

(v) A detailed description of how the health IT developer will ensure that the identified non-conformity and all issues are resolved;

(vi) A detailed description of the supporting documentation that will be provided to demonstrate that the identified non-conformity and all issues are resolved; and

(vii) The timeframe under which all elements of the corrective action plan will be completed.

(viii) An explanation of, and agreement to execute, the steps that will be prevent the non-conformity from re-occurring.

(3) When ONC receives a proposed corrective action plan (or a revised proposed corrective action plan), it shall either approve the proposed corrective action plan or, if the plan does not adequately address all required elements, instruct the health IT developer to submit a revised proposed corrective action plan within a specified period of time.

(4) The health IT developer is responsible for ensuring that a proposed corrective action plan submitted in accordance with paragraph (b)(2)(ii)(A)(4) of this section or a revised corrective action plan submitted in accordance with paragraph (c)(3) of this section adequately addresses all required elements as determined by ONC no later than 90 days after the health IT developer's receipt of a notice of non-conformity.

(5) Health IT developers may request extensions for the submittal and/or completion of corrective action plans. In order to make these requests, health IT developers must submit a written statement to ONC that explains and justifies the extension request. ONC will evaluate each request individually and will make decisions on a case-by-case basis.

(6) Upon fulfilling all of its obligations under the corrective action plan, the health IT developer must submit an attestation to ONC, which serve as a binding official statement by the health IT developer that it has fulfilled all of its obligations under the corrective action plan.

(7) ONC may reinstitute a corrective action plan if it later determines that a health IT developer has not fulfilled all of its obligations under the corrective action plan as attested in accordance with paragraph (c)(6) of this section.

(d) Suspension. (1) ONC may suspend the certification of a Complete EHR or Health IT Module at any time if ONC has a reasonable belief that the certified health IT may present a serious risk to public health or safety.

(2) When ONC decides to suspend a certification, ONC will notify the health IT developer of its determination through a notice of suspension.

(i) The notice of suspension will include, but may not be limited to:

(A) An explanation for the suspension;

(B) Information supporting the determination;

(C) The consequences of suspension for the health IT developer and the Complete EHR or Health IT Module under the ONC Health IT Certification Program; and

(D) Instructions for appealing the suspension.

(ii) A suspension of a certification will become effective upon the date specified in the notice of suspension.

(3) The health IT developer must notify all potentially affected customers of the identified non-conformity(ies) and suspension of certification in a timely manner.

(4) When a certification is suspended, the health IT developer must cease and desist from any marketing, licensing, and sale of the suspended Complete EHR or Health IT Module as “certified” under the ONC Health IT Certification Program from that point forward until such time ONC cancels the suspension in accordance with paragraph (d)(6) of this section.

(5) The certification of any health IT produced by a health IT developer that has the certification of one of its Complete EHRs or Health IT Modules suspended under the Program is prohibited, unless ONC cancels a suspension in accordance with paragraph (d)(6) of this section.

(6) ONC may cancel a suspension at any time if ONC no longer has a reasonable belief that the certified health IT presents a serious risk to public health or safety.

(e) Proposed termination. (1) ONC may propose to terminate a certification issued to a Complete EHR and/or Health IT Module if:

(i) The health IT developer fails to timely respond to any communication from ONC, including, but not limited to:

(A) Fact-finding;

(B) A notice of potential non-conformity within the timeframe established in accordance with paragraph (b)(1)(ii)(A)(3) of this section;

(C) A notice of non-conformity within the timeframe established in accordance with paragraph (b)(2)(ii)(A)(3) of this section; or

(D) A notice of suspension.

(ii) The information or access provided by the health IT developer in response to any ONC communication, including, but not limited to: Fact-finding, a notice of potential non-conformity, or a notice of non-conformity is insufficient or incomplete;

(iii) The health IT developer fails to cooperate with ONC and/or a third party acting on behalf of ONC;

(iv) The health IT developer fails to timely submit in writing a proposed corrective action plan;

(v) The health IT developer fails to timely submit a corrective action plan that adequately addresses the elements required by ONC as described in paragraph (c) of this section;

(vi) The health IT developer does not fulfill its obligations under the corrective action plan developed in accordance with paragraph (c) of this section; or

(vii) ONC concludes that a certified health IT's non-conformity(ies) cannot be cured.

(2) When ONC decides to propose to terminate a certification, ONC will notify the health IT developer of the proposed termination through a notice of proposed termination.

(i) The notice of proposed termination will include, but may not be limited to:

(A) An explanation for the proposed termination;

(B) Information supporting the proposed termination; and

(C) Instructions for responding to the proposed termination.

(3) The health IT developer may respond to a notice of proposed termination, but must do so within 10 days of receiving the notice of proposed termination and must include appropriate documentation explaining in writing why its certification should not be terminated.

(4) Upon receipt of the health IT developer's written response to a notice of proposed termination, ONC has up to 30 days to review the information submitted by the health IT developer and make a determination. ONC may extend this timeframe if the complexity of the case requires additional time for ONC review. ONC will, as applicable:

(i) Notify the health IT developer in writing that it has ceased all or part of its review of the health IT developer's certified health IT.

(ii) Notify the health IT developer in writing of its intent to continue all or part of its review of the certified health IT under the provisions of this section.

(iii) Proceed to terminate the certification of the health IT under review consistent with paragraph (f) of this section.

(f) Termination. (1) The National Coordinator may terminate a certification if:

(i) A determination is made that termination is appropriate after considering the information provided by the health IT developer in response to the proposed termination notice; or

(ii) The health IT developer does not respond in writing to a proposed termination notice within the timeframe specified in paragraph (e)(3) of this section.

(2) When ONC decides to terminate a certification, ONC will notify the health IT developer of its determination through a notice of termination.

(i) The notice of termination will include, but may not be limited to:

(A) An explanation for the termination;

(B) Information supporting the determination;

(C) The consequences of termination for the health IT developer and the Complete EHR or Health IT Module under the ONC Health IT Certification Program; and

(D) Instructions for appealing the termination.

(ii) A termination of a certification will become effective after the following applicable occurrence:

(A) The expiration of the 10-day period for filing a statement of intent to appeal in paragraph (g)(3)(i) of this section if the health IT developer does not file a statement of intent to appeal.

(B) The expiration of the 30-day period for filing an appeal in paragraph (g)(3)(ii) of this section if the health IT developer files a statement of intent to appeal, but does not file a timely appeal.

(C) A final determination to terminate the certification per paragraph (g)(7) of this section if a health IT developer files an appeal.

(3) The health IT developer must notify all potentially affected customers of the identified non-conformity(ies) and termination of certification in a timely manner.

(4) ONC may rescind a termination determination before the termination becomes effective if ONC determines that termination is no longer appropriate.

(g) Appeal—(1) Basis for appeal. A health IT developer may appeal an ONC determination to suspend or terminate a certification issued to a Complete EHR or Health IT Module if the health IT developer asserts:

(i) ONC incorrectly applied ONC Health IT Certification Program requirements for suspension or termination; or

(ii) ONC's determination was not sufficiently supported by the information provided by ONC with its determination.

(2) Method and place for filing an appeal. A statement of intent to appeal followed by a request for appeal must be submitted to ONC in writing by an authorized representative of the health IT developer whose Complete EHR or Health IT Module was subject to the determination being appealed. The statement of intent to appeal and request for appeal must be filed in accordance with the requirements specified in the notice of termination or notice of suspension.

(3) Time for filing a request for appeal. (i) A statement of intent to appeal must be filed within 10 days of a health IT developer's receipt of the notice of suspension or notice of termination.

(ii) An appeal, including all supporting documentation, must be filed within 30 days of the filing of the intent to appeal.

(4) Effect of appeal on suspension and termination. (i) A request for appeal stays the termination of a certification issued to a Complete EHR or Health IT Module, but the Complete EHR or Health IT Module is prohibited from being marketed, licensed, or sold as “certified” during the stay.

(ii) A request for appeal does not stay the suspension of a Complete EHR or Health IT Module.

(5) Appointment of a hearing officer. The National Coordinator will assign the case to a hearing officer to adjudicate the appeal on his or her behalf.

(i) The hearing officer may not review an appeal in which he or she participated in the initial suspension or termination determination or has a conflict of interest in the pending matter.

(ii) The hearing officer must be trained in a nationally recognized ethics code that articulates nationally recognized standards of conduct for hearing officers/officials.

(6) Adjudication. (i) The hearing officer may make a determination based on:

(A) The written record, which includes the:

(1) ONC determination and supporting information;

(2) Information provided by the health IT developer with the appeal filed in accordance with paragraphs (g)(1) through (3) of this section; and

(3) Information ONC provides in accordance with paragraph (g)(6)(v) of this section; or

(B) All the information provided in accordance with paragraph (g)(6)(i)(A) and any additional information from a hearing conducted in-person, via telephone, or otherwise.

(ii) The hearing officer will have the discretion to conduct a hearing if he/she:

(A) Requires clarification by either party regarding the written record under paragraph (g)(6)(i)(A) of this section;

(B) Requires either party to answer questions regarding the written record under paragraph (g)(6)(i)(A) of this section; or

(C) Otherwise determines a hearing is necessary.

(iii) The hearing officer will neither receive witness testimony nor accept any new information beyond what was provided in accordance with paragraph (g)(6)(i) of this section.

(iv) The default process will be a determination in accordance with paragraph (g)(6)(i)(A) of this section.

(v) ONC will have an opportunity to provide the hearing officer with a written statement and supporting documentation on its behalf that clarifies, as necessary, its determination to suspend or terminate the certification.

(A) The written statement and supporting documentation must be included as part of the written record and provided to the health IT developer within 15 days of the health IT developer's filing of an intent to appeal.

(B) Failure of ONC to submit a written statement does not result in any adverse findings against ONC and may not in any way be taken into account by the hearing officer in reaching a determination.

(7) Determination by the hearing officer. (i) The hearing officer will issue a written determination to the health IT developer within 30 days of receipt of the appeal or within a timeframe agreed to by the health IT developer and ONC and approved by the hearing officer, unless ONC cancels the suspension or rescinds the termination determination.

(ii) The National Coordinator's determination on appeal, as issued by the hearing officer, is final and not subject to further review.

[81 FR 72468, Oct. 19, 2016]

return arrow Back to Top

§170.581   Certification ban.

(a) Ban. The certification of any of a health IT developer's health IT is prohibited when the certification of one or more of the health IT developer's Complete EHRs or Health IT Modules is:

(1) Terminated by ONC under the ONC Health IT Certification Program;

(2) Withdrawn from the ONC Health IT Certification Program by an ONC-ACB because the health IT developer requested it to be withdrawn when the health IT developer's health IT was the subject of a potential non-conformity or non-conformity as determined by ONC;

(3) Withdrawn by an ONC-ACB because of a non-conformity with any of the certification criteria adopted by the Secretary under subpart C of this part; or

(4) Withdrawn by an ONC-ACB because the health IT developer requested it to be withdrawn when the health IT developer's health IT was the subject of surveillance for a certification criterion or criteria adopted by the Secretary under subpart C of this part, including notice of pending surveillance.

(b) Reinstatement. The certification of a health IT developer's health IT subject to the prohibition in paragraph (a) of this section may commence once the following conditions are met.

(1) A health IT developer must request ONC's permission in writing to participate in the ONC Health IT Certification Program.

(2) The request must demonstrate that the customers affected by the certificate termination or withdrawal have been provided appropriate remediation.

(3) ONC is satisfied with the health IT developer's demonstration under paragraph (b)(2) of this section that all affected customers have been provided with appropriate remediation and grants reinstatement into the ONC Health IT Certification Program.

[81 FR 72471, Oct. 19, 2016]

return arrow Back to Top

§170.599   Incorporation by reference.

(a) Certain material is incorporated by reference into this subpart with the approval of the Director of the Federal Register under 5 U.S.C. 552(a) and 1 CFR part 51. To enforce any edition other than that specified in this section, the Department of Health and Human Services must publish a document in the Federal Register and the material must be available to the public. All approved material is available for inspection at U.S. Department of Health and Human Services, Office of the National Coordinator for Health Information Technology, 330 C Street SW., Washington, DC 20201, call ahead to arrange for inspection at 202-690-7151, and is available from the source listed below. It is also available for inspection at the National Archives and Records Administration (NARA). For information on the availability of this material at NARA, call 202-741-6030 or go to http://www.archives.gov/federal_register/code_of_federal_regulations/ibr_locations.html.

(b) International Organization for Standardization, Case postale 56, CH·1211, Geneve 20, Switzerland, telephone +41-22-749-01-11, http://www.iso.org.

(1) ISO/IEC GUIDE 65:1996—General Requirements for Bodies Operating Product Certification Systems (First Edition), 1996, “ISO/IEC Guide 65,” IBR approved for §170.503.

(2) ISO/IEC 17011:2004 Conformity Assessment—General Requirements for Accreditation Bodies Accrediting Conformity Assessment Bodies (Corrected Version), February 15, 2005, “ISO/IEC 17011,” IBR approved for §170.503.

(3) ISO/IEC 17025:2005(E)—General requirements for the competence of testing and calibration laboratories (Second Edition), 2005-05-15, “ISO/IEC 17025,” IBR approved for §§170.520(b) and 170.524(a).

(4) ISO/IEC 17065:2012(E)—Conformity assessment—Requirements for bodies certifying products, processes and services (First Edition), 2012, “ISO/IEC 17065,” IBR approved for §170.503.

[81 FR 72471, Oct. 19, 2016]

return arrow Back to Top

Need assistance?