PART 170—HEALTH INFORMATION TECHNOLOGY STANDARDS, IMPLEMENTATION SPECIFICATIONS, AND CERTIFICATION CRITERIA AND CERTIFICATION PROGRAMS FOR HEALTH INFORMATION TECHNOLOGY 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. Subpart A—General Provisions § 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] § 170.101 Applicability. (a) The standards, implementation specifications, and certification criteria adopted in this part apply to health information technology and the testing and certification of Health IT Modules. (b) If any provision of this part is held to be invalid or unenforceable facially, or as applied to any person, plaintiff, or circumstance, it shall be construed to give maximum effect to the provision permitted by law, unless such holding shall be one of utter invalidity or unenforceability, in which case the provision shall be severable from this part and shall not affect the remainder thereof or the application of the provision to other persons not similarly situated or to other dissimilar circumstances. [89 FR 101809, Dec. 16, 2024] § 170.102 Definitions. For the purposes of this part: Base EHR (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 healthcare 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 all of the following: (i) Section 170.315(a)(1), (2), or (3); (a)(5) and (14), (b)(1), (c)(1), and (g)(7), (9), (10); and (h)(1) or (2). (ii) Section 170.315(a)(9) or (b)(11) for the period up to and including December 31, 2024. (iii) Section 170.315(b)(11) on and after January 1, 2025. (iv) Section 170.315(b)(4) on and after January 1, 2028. Certification 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 (1) Patient name. (2) Sex: (3) Date of birth. (4) Race: (i) The standard specified in § 170.207(f)(2); and (ii) 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)(2); and (ii) The standard specified in § 170.207(f)(1) for each ethnicity identified in accordance § 170.207(f)(2). (6) Preferred language: (7) Smoking status. (8) Problems: (9) Medications: (10) Medication allergies: (11) Laboratory test(s): (12) Laboratory value(s)/result(s). (13) Vital signs: (i) 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 (ii) 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). (iii) Optional: (14) Procedures: (i) At a minimum, the version of the standard specified in § 170.207(a)(4) or § 170.207(b)(2); or (ii) For technology primarily developed to record dental procedures, the standard specified in § 170.207(b)(3). (iii) Optional: (15) Care team member(s). (16) Immunizations: (17) 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). (18) Assessment and plan of treatment: (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). (19) Goals: (20) Health concerns: Day or Days Device identifier Disclosure Electronic health information Fee Global Unique Device Identification Database (GUDID) Health information technology Health IT Module Human readable format Implantable device Implementation specification Interoperability (1) Enables the secure exchange of electronic health information with, and use of electronic health information from, other health information technology without special effort on the part of the user; (2) Allows for complete access, exchange, and use of all electronically accessible health information for authorized use under applicable State or Federal law; and (3) Does not constitute information blocking as defined in § 171.103 of this subchapter. Interoperability element ONC certification criteria for health IT Predictive Decision Support Intervention or Predictive DSI Production identifier Provide Qualified EHR (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. Revised certification criterion (or criteria) (1) Has added or changed the capabilities described in the existing criterion in this part; (2) Has an added or changed standard or implementation specification referenced in the existing criterion in this part; or (3) Is specified through notice and comment rulemaking as an iterative or replacement version of an existing criterion in this part. Standard Unique device identifier [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; 85 FR 25939, May 1, 2020; 85 FR 70082, Nov. 4, 2020; 89 FR 1426, Jan. 9, 2024; 90 FR 37208, Aug. 4, 2025] Subpart B—Standards and Implementation Specifications for Health Information Technology Source: 75 FR 44649, July 28, 2010, unless otherwise noted. § 170.200 Applicability. The standards and implementation specifications adopted in this part apply with respect to Health Information technology. [85 FR 70082, Nov. 4, 2020] § 170.202 Transport standards and other protocols. The Secretary adopts the following transport standards: (a) Direct Project. (2) Standard. (b) Standard. (c) Standard. (d) Standard. (e) Delivery notification Standard. (2) [Reserved] [77 FR 54284, Sept. 4, 2012, as amended at 79 FR 54478, Sept. 11, 2014; 80 FR 62743, Oct. 16, 2015; 85 FR 25940, May 1, 2020] § 170.204 Functional standards. The Secretary adopts the following functional standards: (a) Accessibility Standard. (2) Standard. (b) Reference source. Standard. (1)-(2) [Reserved] (3) Standard. Implementation specifications. (4) Standard. Implementation specifications. [77 FR 54284, Sept. 4, 2012, as amended at 80 FR 62743, Oct. 16, 2015; 85 FR 25940, May 1, 2020] § 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. (2) [Reserved] (3) Standard. (4) Standard. (5) Standard. (6) Standard. (b) Electronic prescribing Standard. (2) Standard. (c) Real-time prescription benefit Standard. (2) [Reserved] (d) Electronic submission to public health agencies for surveillance or reporting. (2) Standard. (3) [Reserved] (4) Standard. Implementation specifications. (e) Electronic submission to immunization registries. (2)-(3) [Reserved] (4) Standard. Implementation specifications. (f) [Reserved] (g) Electronic transmission of lab results to public health agencies. Standard. Implementation specifications. (h) Clinical quality measure data import, export and reporting. (2) Standard. (3) Standard. (i) Cancer information. (2) Standard. Implementation specifications. © © (j) [Reserved] (k) Clinical quality measure aggregate reporting Standard. (2) Standard. (3) Standard. (l)-(n) [Reserved] (o) Data segmentation for privacy Standard. (2) [Reserved] (p) XDM package processing Standard. (2) [Reserved] (q) [Reserved] (r) Public health—antimicrobial use and resistance information Standard. (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 Standard. (2) [Reserved] (t) Public health—electronic case reporting Standard. (2) Standard. (3) Standard. (4) Standard. (u) Formulary and benefit Standard. (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; 85 FR 25940, May 1, 2020; 85 FR 70082, Nov. 4, 2020; 89 FR 1426, Jan. 9, 2024; 89 FR 51265, June 17, 2024] § 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) Standard. (2)-(3) [Reserved] (4) Standard. (b) Procedures. (2) Standard. (3) Standard. (4) Standard. (c) Laboratory tests. (1) Standard. (2) [Reserved] (3) Standard. (d) Medications Clinical drugs Standard. (ii) Standard. (iii) Standard. (2) Standard. National Drug Codes. (3)-(4) [Reserved] (e) Immunizations. (1) Standard. (2) Standard. (3) Standard. (4) Standard. (f) Race and Ethnicity Standard. (2) Standard. (3) Standard. (g) Preferred language. (2) Standard. (h) [Reserved] (i) Encounter diagnoses. Standard. (j)-(l) [Reserved] (m) Numerical references Standard. (2) Standard. (n) Sex Standard. (i) Male. M; (ii) Female. F; (iii) Unknown. NullFlavor UNK. (2) Standard. (3) Standard. (o) Sexual orientation and gender information Standard. (i) Lesbian, gay or homosexual. (ii) Straight or heterosexual. (iii) Bisexual. (iv) Something else, please describe. (v) Don't know. (vi) Choose not to disclose. (2) Standard. (i) Male. (ii) Female. (iii) Female-to-Male (FTM)/Transgender Male/Trans Man. (iv) Male-to-Female (MTF)/Transgender Female/Trans Woman. (v) Genderqueer, neither exclusively male nor female. (vi) Additional gender category or other, please specify. (vii) Choose not to disclose. (3) Standard. (4) Standard. (p) Social, psychological, and behavioral data Financial resource strain. (2) Education. (3) Stress. (4) Depression. (5) Physical activity. (6) Alcohol use. (7) Social connection and isolation. (8) Exposure to violence (intimate partner violence). (q) Patient matching Phone number standard. (2) [Reserved] (r) Provider type Standard. (2) Standard. (s) Patient insurance Standard. (2) Standard. [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; 85 FR 25940, May 1, 2020; 89 FR 1426, Jan. 9, 2024; 90 FR 37208, Aug. 4, 2025] § 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. (2) General. (b) [Reserved] (c) Hashing of electronic health information. (2) Standard. (d) Record treatment, payment, and health care operations disclosures. (e) Record actions related to electronic health information, audit log status, and encryption of end-user devices. (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.1.1 and 7.1.7 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.1.1 and 7.1.7 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. (g) Synchronized clocks. (h) Audit log content. [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; 85 FR 25940, May 1, 2020; 85 FR 70082, Nov. 4, 2020; 89 FR 1428, Jan. 9, 2024] § 170.213 United States Core Data for Interoperability. The Secretary adopts the following versions of the United States Core Data for Interoperability standard: (a) Standard. (b) Standard. [89 FR 1428, Jan. 9, 2024] § 170.215 Application Programming Interface Standards. Link to an amendment published at 91 FR 50367, Aug. 4, 2026. The Secretary adopts the following standards and associated implementation specifications as the available standards for application programming interfaces (API): (a) API base standard. (1) Standard. (2) [Reserved] (b) API constraints and profiles. (1) United States Core Data Implementation Guides Implementation specification. (ii) Implementation Specification. (2) [Reserved] (c) Application access and launch. (1) Implementation specification. (2) Implementation specification. (d) Bulk export and data transfer standards. (1) Implementation specification. (2) [Reserved] (e) API authentication, security, and privacy. (1) Standard. (2) [Reserved] (f) API-based workflow triggers. (1) Implementation specification. (2) [Reserved] (g) [Reserved] (h) API-based event notifications. (1) FHIR Subscriptions: Implementation specification. (2) [Reserved] (i) [Reserved] (j) Prior authorization Coverage requirements discovery Implementation specification. (ii) [Reserved] (2) Prior authorization documentation Implementation specification. (ii) [Reserved] (3) Prior authorization submission Implementation specification. (ii) [Reserved] (k) Payer data exchange Blue button Implementation specification. (ii) [Reserved] (2) Payer data exchange Implementation specification. (ii) [Reserved] (l) [Reserved] (m) Drug formulary Implementation specification. (2) [Reserved] (n) Directory information Implementation specification. (2) [Reserved] [89 FR 1428, Jan. 9, 2024, as amended at 90 FR 37208, Aug. 4, 2025] § 170.299 Incorporation by reference. Link to an amendment published at 91 FR 50367, Aug. 4, 2026. (a) Certain material is incorporated by reference into this part with the approval of the Director of the Federal Register under 5 U.S.C. 552(b) and 1 CFR part 51. All approved incorporation by reference (IBR) material is available for inspection at the U.S. Department of Health and Human Services (HHS) and at the National Archives and Records Administration (NARA). Contact HHS 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. For information on the availability of this material at NARA, visit www.archives.gov/federal-register/cfr/ibr-locations [email protected]. (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-18 Standard Specification for Audit and Disclosure Logs for Use in Health Information Systems, approved May 1, 2018, IBR approved for § 170.210(h). (2)-(3) [Reserved] (d) Centers for Disease Control and Prevention, 2500 Century Parkway, Mailstop E-78, Atlanta, GA 30333; phone: (800) 232-4636); website: www.cdc.gov/cdc-info/index.html (1) HL7 Standard Code Set CVX—Vaccines Administered, July 30, 2009, IBR approved for § 170.207. (2) [Reserved] (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)-(8) [Reserved] (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). (17) HL7® Standard Code Set CVX—Vaccines Administered, dated June 15, 2022; IBR approved for § 170.207(e). (18) National Drug Code Directory (NDC)—Vaccine NDC Linker, dated July 19, 2022; IBR approved for § 170.207(e). (19) CDC Race and Ethnicity Code Set version 1.2 (July 08, 2021); IBR approved for § 170.207(f). (e) Centers for Medicare & Medicaid Services, Office of Clinical Standards and Quality, 7500 Security Boulevard, Baltimore, Maryland 21244; phone: (410) 786-3000; website: www.cms.gov. (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). (4) CMS Implementation Guide for Quality Reporting Document Architecture: Category I; Hospital Quality Reporting Implementation Guide for 2020; published December 3, 2019, IBR approved for § 170.205(h). (5) CMS Implementation Guide for Quality Reporting Document Architecture: Category III; Eligible Clinicians and Eligible Professionals Programs Implementation Guide for 2020; published April 30, 2020, IBR approved for § 170.205(k). (6) Medicare Provider and Supplier Taxonomy Crosswalk, 2021; IBR approved for § 170.207(r). (f) Council of State and Territorial Epidemiologists, 2635 Century Parkway NE, Suite 700, Atlanta, GA 30345; phone: (770) 458-3811; website: www.cste.org/ (1) Reportable Conditions Trigger Codes Value Set for Electronic Case Reporting. RCTC OID: 2.16.840.1.114222.4.11.7508, Release March 29, 2022; IBR approved for § 170.205(t). (2) [Reserved] (g) Health Level Seven, 3300 Washtenaw Avenue, Suite 227, Ann Arbor, MI 48104; phone: (734) 677-7777; website: 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) [Reserved] (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)-(7) [Reserved] (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)-(11) [Reserved] (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 © (23) HL7 CDA © (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). (30) HL7® CDA® R2 Implementation Guide: C-CDA Templates for Clinical Notes R2.1 Companion Guide, Release 2-US Realm, October 2019, IBR approved for § 170.205(a). (31) HL7 FHIR® Bulk Data Access (Flat FHIR®) (v1.0.0: STU 1), August 22, 2019, IBR approved for § 170.215(a). (32) HL7 FHIR SMART Application Launch Framework Implementation Guide Release 1.0.0, November 13, 2018, IBR approved for § 170.215(a). (33) HL7 Fast Healthcare Interoperability Resources Specification (FHIR®) Release 4, Version 4.0.1: R4, October 30, 2019, including Technical Correction #1, November 1, 2019, IBR approved for § 170.215(a). (34) HL7 FHIR® US Core Implementation Guide STU3 Release 3.1.1, August 28, 2020, IBR approved for § 170.215(a). (35) HL7 CDA® R2 Implementation Guide: C-CDA Templates for Clinical Notes STU Companion Guide, Release 4.1 (US Realm) Standard for Trial Use, Specification Version: 4.1.1, June 2023 (including appendices A and B); IBR approved for § 170.205(a). (36) HL7 FHIR® Implementation Guide: Electronic Case Reporting (eCR)—US Realm, Version 2.1.0—STU 2 US (HL7 FHIR eCR IG), August 31, 2022; IBR approved for § 170.205(t). (37) HL7 CDA® R2 Implementation Guide: Public Health Case Report—the Electronic Initial Case Report (eICR) Release 2, STU Release 3.1—US Realm (HL7 CDA eICR IG), July 2022, volumes 1 and 2; IBR approved for § 170.205(t). (38) HL7 CDA® R2 Implementation Guide: Reportability Response, Release 1, STU Release 1.1—US Realm (HL7 CDA RR IG), July 2022, volumes 1 through 4; IBR approved for § 170.205(t). (39) HL7 FHIR US Core Implementation Guide Version 6.1.0—STU 6, June 19, 2023; IBR approved for § 170.215(b). (40) HL7 FHIR® SMART App Launch [Implementation Guide], 2.0.0—Standard for Trial Use, November 26, 2021; IBR approved for § 170.215(c). (41) HL7 FHIR® Da Vinci—Coverage Requirements Discovery (CRD) Implementation Guide, Version 2.0.1—STU 2, January 8, 2024, IBR approved for § 170.215(j). (42) HL7 FHIR® Da Vinci—Documentation Templates and Rules (DTR) Implementation Guide, Version 2.0.1—STU 2, January 11, 2024, IBR approved for § 170.215(j). (43) HL7 FHIR® Da Vinci Prior Authorization Support (PAS) FHIR Implementation Guide, Version 2.0.1—STU 2, December 1, 2023, IBR approved for § 170.215(j). (44) HL7 FHIR® CARIN Consumer Directed Payer Data Exchange (CARIN IG for Blue Button®) Implementation Guide, Version 2.0.0—STU 2 US, November 28, 2022, IBR approved for § 170.215(k). (45) HL7 FHIR® Da Vinci Payer Data Exchange (PDex) Implementation Guide, Version 2.1.0—STU 2.1, June 18, 2025, IBR approved for § 170.215(k). (46) HL7 FHIR® Da Vinci Payer Data Exchange (PDex) US Drug Formulary Implementation Guide, Version 2.0.1—STU 2, December 1, 2023, IBR approved for § 170.215(m). (47) HL7 FHIR® Da Vinci Payer Data Exchange (PDex) Plan Net Implementation Guide, Version 1.1.0—STU 1.1 US, April 4, 2022, IBR approved for § 170.215(n). (48) HL7 FHIR® Subscriptions R5 Backport Implementation Guide, Version 1.1.0—Standard for Trial Use, draft as of January 11, 2023, IBR approved for § 170.215(h). (49) HL7 FHIR® CDS Hooks Implementation Guide, Version 2.0.1—STU 2 Release 2, March 12, 2025, IBR approved for § 170.215(f). (h) Integrating the Healthcare Enterprise (IHE), 820 Jorie Boulevard, Oak Brook, IL, Telephone (630) 481-1004, 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] (i) 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) [Reserved] (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). (j) 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). (k) National Council for Prescription Drug Programs (NCPDP), Incorporated, 9240 E Raintree Drive, Scottsdale, AZ 85260-7518; phone (480) 477-1000; fax: (480) 767-1042: website: www.ncpdp.org. (1) NCPDP SCRIPT Standard, Implementation Guide, Version 2017071, ANSI-approved July 28, 2017; IBR approved for § 170.205(b). (2) NCPDP SCRIPT Standard, Implementation Guide, Version 2023011, ANSI-approved January 17, 2023; IBR approved for § 170.205(b). (3) NCPDP Real-Time Prescription Benefit Standard, Implementation Guide, Version 13, ANSI-approved May 19, 2022; IBR approved for § 170.205(c). (4) NCPDP Formulary and Benefit Standard, Implementation Guide, Version 60, ANSI-approved April 12, 2023; IBR approved for § 170.205(u). (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) [Reserved] (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; phone: (202) 690-7151; website: https://healthit.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. (5) United States Core Data for Interoperability (USCDI), Version 1, July 2020 Errata, IBR approved for § 170.213; available at https://www.healthit.gov/USCDI. (6) United States Core Data for Interoperability (USCDI), Version 3 (v3), October 2022 Errata; IBR approved for § 170.213(b). (n) OpenID Foundation, 2400 Camino Ramon, Suite 375, San Ramon, CA 94583, Telephone +1 925-275-6639, http://openid.net/ (1) OpenID Connect Core 1.0 Incorporating errata set 1, November 8, 2014, IBR approved for § 170.215(b). (2) [Reserved] (o) Public Health Data Standards Consortium, 111 South Calvert Street, Suite 2700, Baltimore, MD 21202; phone: (801) 532-2299; website: www.Ph.D.sc.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) Users Guide for Source of Payment Typology, Version 9.2, December 2020; IBR approved for § 170.207(s). (p) Regenstrief Institute, Inc., LOINC® c/o Regenstrief Center for Biomedical Informatics, Inc., 410 West 10th Street, Suite 2000, Indianapolis, IN 46202-3012; phone: (317) 274-9000; website: https://loinc.org/ https://ucum.org/ucum. (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. (5) Logical Observation Identifiers Names and Codes (LOINC®) Database Version 2.72, February 2022; IBR approved for § 170.207(c). (6) The Unified Code for Units of Measure, Version 2.1, November 21, 2017; IBR approved for § 170.207(m). (q) 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). (r) U.S. National Library of Medicine, 8600 Rockville Pike, Bethesda, MD 20894; phone (301) 594-5983; website: 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)-(5) [Reserved] (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). (8) SNOMED CT® [Systematized Nomenclature of Medicine Clinical Terms] U.S. Edition, March 2022 Release; IBR approved for § 170.207(a). (9) RxNorm, Full Update Release, July 5, 2022; IBR approved for § 170.207(d). (10) RxNorm, December 4, 2023, Full Update Release, IBR approved for § 170.207(d). (s) 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; 85 FR 25941, May 1, 2020; 85 FR 70082, Nov. 4, 2020; 89 FR 1428, Jan. 9, 2024; 89 FR 51265, June 17, 2024; 90 FR 37209, Aug. 4, 2025] Subpart C—Certification Criteria for Health Information Technology Source: 75 FR 44651, July 28, 2010, unless otherwise noted. § 170.300 Applicability. (a) The certification criteria adopted in this subpart apply to the testing and certification of Health IT 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) Health 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.315, all certification criteria and all capabilities specified within a certification criterion have general applicability ( i.e., [75 FR 44649, July 28, 2010, as amended at 77 FR 54286, Sept. 4, 2012; 80 FR 62747, Oct. 16, 2015; 85 FR 25941, May 1, 2020; 85 FR 70083, Nov. 4, 2020] §§ 170.302-170.306 [Reserved] § 170.314 [Reserved] § 170.315 ONC certification criteria for Health IT. The Secretary adopts the following certification criteria for health IT. Health IT must be able to electronically perform the following capabilities in accordance with applicable standards and implementation specifications adopted in this part. For all criteria in this section, a health IT developer with a Health IT Module certified to any revised certification criterion, as defined in § 170.102, shall update the Health IT Module and shall provide such update to their customers in accordance with the dates identified for each revised certification criterion and for each applicable standard in 45 CFR part 170 subpart B. (a) Clinical Computerized provider order entry—medications. (ii) Optional. (2) Computerized provider order entry—laboratory. (ii) Optional. (3) Computerized provider order entry—diagnostic imaging. (ii) Optional. (4) Drug-drug, drug-allergy interaction checks for CPOE Interventions. (ii) Adjustments. (B) Limit the ability to adjust severity levels in at least one of these two ways: ( 1 ( 2 (5) Patient demographics and observations. (A) Race and ethnicity. 1 ( 2 ( 3 1 2 (B) Preferred language. (C) Sex. (D) Sexual orientation. (E) Gender identity. (F) Sex Parameter for Clinical Use. (G) Name to Use. (H) Pronouns. (ii) Inpatient setting only. (6)-(8) [Reserved] (9) Clinical decision support (CDS) CDS intervention interaction. (ii) CDS configuration. e.g. (B) Enable interventions: ( 1 ( i ( ii ( iii ( iv ( v ( vi ( 2 (iii) Evidence-based decision support interventions. i.e. 1 i vi (iv) Linked referential CDS. ( 1 ( 2 (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 iv (v) Source attributes. (A) For evidence-based decision support interventions under paragraph (a)(9)(iii) of this section: ( 1 ( 2 ( 3 ( 4 (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). (vi) Expiration of criterion. (10)-(11) [Reserved] (12) Family health history. (13) [Reserved] (14) Implantable device list. (ii) Parse the following identifiers from a Unique Device Identifier: (A) Device Identifier; and (B) The following identifiers that compose the Production Identifier: ( 1 ( 2 ( 3 ( 4 ( 5 (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 ( 2 1 (B) The following Global Unique Device Identification Database attributes: ( 1 ( 2 ( 3 ( 4 ( 5 (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. (i) Financial resource strain. (ii) Education. (iii) Stress. (iv) Depression. (v) Physical activity. (vi) Alcohol use. (vii) Social connection and isolation. (viii) Exposure to violence (intimate partner violence). (b) Care coordination Transitions of care Send and receive via edge protocol. (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. (ii) Validate and display Validate C-CDA conformance—system performance. ( 1 ( 2 ( 3 ( 4 ( 5 ( i ( ii (B) Display. (C) Display section views. ( 1 ( 2 ( 3 (iii) Create. (A)( 1 3 i iii ( 2 3 i iii ( 3 ( i Assessment and plan of treatment. ( ii Goals. ( iii Health concerns. ( iv Unique device identifier(s) for a patient's implantable device(s). (B) Encounter diagnoses. ( 1 ( 2 (C) Cognitive status. (D) Functional status. (E) Ambulatory setting only. (F) Inpatient setting only. (G) Patient matching data. ( 1 Date of birth constraint. i ( ii Optional. ( 2 Phone number constraint. ( 3 Sex Constraint: (2) Clinical information reconciliation and incorporation General requirements. (ii) Correct patient. (iii) Reconciliation. (A) Simultaneously display ( i.e., (B) Enable a user to create a single reconciled list of each of the following: Medications; Allergies and Intolerances; 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 standards: ( 1 Medications. ( 2 Allergies and intolerance. ( 3 Problems. (iv) System verification. (iv) System verification. (3) Electronic prescribing. (ii) For technology certified subsequent to June 30, 2020: (A)( 1 3 ( i ( ii ( 2 3 ( i ( ii ( 3 ( i ( ii ( iii ( iv ( v ( vi ( vii ( viii ( ix ( x (B) Enable a user to exchange race and ethnicity information when performing the following prescription-related electronic transactions, if using the standard in § 170.205(b)(2): ( 1 ( 2 ( 3 ( 4 (C) For the following prescription-related transactions, the technology must be able to receive and transmit the diagnosis or diagnoses that are the reason for prescription: ( 1 ( i ( ii ( iii ( iv ( v ( vi ( vii ( 2 (D) [Reserved] (E) Limit a user's ability to prescribe all oral liquid medications in only metric standard units of mL (that is, not cc). (F) 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) Real-time prescription benefit Send and receive information. (A) Request patient-specific prescription benefit information, estimated cost information, and alternative products, in accordance with the RTPBRequest transaction. (B) Receive patient-specific prescription benefit information, estimated cost information, and alternative products in response to a request, in accordance with the RTPBResponse transaction. (ii) Display. (5)-(6) [Reserved] (7) Security tags—summary of care—send. (8) Security tags—summary of care—receive. (ii) Preserve privacy markings to ensure fidelity to the tagging based on consent and with respect to sharing and re-disclosure restrictions. (9) Care plan. (i) 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); and (ii) The standard in § 170.205(a)(5) for the time period up to and including December 31, 2025; or § 170.205(a)(6). (10) Electronic Health Information export Single patient electronic health information export. (B) A user must be able to execute this capability at any time the user chooses and without subsequent developer assistance to operate. (C) Limit the ability of users who can create export file(s) in at least one of these two ways: ( 1 ( 2 (D) The export file(s) created must be electronic and in a computable format. (E) The publicly accessible hyperlink of the export's format must be included with the exported file(s). (ii) Patient population electronic health information export. (A) The export created must be electronic and in a computable format. (B) The publicly accessible hyperlink of the export's format must be included with the exported file(s). (iii) Documentation. (11) Decision support interventions— (i) Decision support intervention interaction. (ii) Decision support configuration. (B) Enable interventions when a patient's medications, allergies and intolerance, and problems are incorporated from a transition of care or referral summary received and pursuant to paragraph (b)(2)(iii)(D) of this section. (C) Enable a user to provide electronic feedback data for evidence-based decision support interventions selected via the capability provided in paragraph (b)(11)(iii)(A) of this section and make available such feedback data to a limited set of identified users for export, in a computable format, including at a minimum the intervention, action taken, user feedback provided (if applicable), user, date, and location. (iii) Decision support intervention selection. i.e., (A) Evidence-based decision support interventions and use any data based on the following data expressed in the standards in § 170.213: ( 1 ( 2 ( 3 ( 4 ( 5 ( 6 ( 7 ( 8 (B) Predictive Decision Support Interventions and use any data expressed in the standards in § 170.213. (iv) Source attributes. (A) For evidence-based decision support interventions: ( 1 ( 2 ( 3 ( 4 ( 5 ( 6 ( 7 ( 8 ( 9 ( 10 ( 11 ( 12 ( 13 (B) For Predictive Decision Support Interventions: ( 1 ( i ( ii ( iii ( iv ( 2 ( i ( ii ( iii ( iv e.g., ( 3 ( i ( ii ( 4 ( i ( ii 5 13 ( iii 5 13 ( iv ( 5 ( i ( ii ( 6 ( i ( ii ( iii 5 13 ( iv ( 7 ( i ( ii ( iii ( iv ( v ( 8 ( i ( ii ( iii ( iv ( 9 ( i ( ii (v) Source attribute access and modification Access. 1 ( 2 6 7 iii iv v 8 ii iv 9 (B) Modify. 1 ( 2 (vi) Intervention risk management. (A) Risk analysis. (B) Risk mitigation. (C) Governance. (c) Clinical quality measures Clinical quality measures—record and export Record. (ii) Export. (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 Import. (ii) Calculate each and every clinical quality measure for which it is presented for certification. (3) Clinical quality measures—report. (i) In accordance with the applicable implementation specifications specified by the CMS implementation guides for Quality Reporting Document Architecture (QRDA), category I, for inpatient measures in § 170.205(h)(3) and CMS implementation guide for QRDA, category III for ambulatory measures in § 170.205 (k)(3); or (ii) In accordance with the standards specified in § 170.205(h)(2) and § 170.205(k)(1) and (2) for the period before December 31, 2022. (4) Clinical quality measures—filter. (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)(2). (D) Practice site address. (E) Patient insurance in accordance with the standard specified in § 170.207(s)(2). (F) Patient age. (G) Patient sex in accordance with the version of the standard specified in § 170.207(n)(2). (H) Patient race and ethnicity in accordance with, at a minimum, the version of the standard specified in § 170.207(f)(3). (I) Patient problem list data in accordance with, at a minimum, the version of the standard specified in § 170.207(a)(1). (d) Privacy and security Authentication, access control, and authorization. e.g. (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 Record actions. (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. (iii) When disabling the audit log is permitted. (iv) Audit log protection. (v) Detection. (3) Audit report(s). (4) Amendments. (i) Accepted amendment. (ii) Denied amendment. (A) To the affected record. (B) Include a link that indicates this information's location. (5) Automatic access time-out. (ii) Require user authentication in order to resume or regain the access that was stopped. (6) Emergency access. (7) End-user device encryption. (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. (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. (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. (i) Message-level. (ii) Transport-level. (10) Auditing actions on health information. (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. (12) Encrypt authentication credentials. (i) Yes—the Health IT Module encrypts stored authentication credentials in accordance with standards adopted in § 170.210(a)(2). (ii) No—the Health IT Module does not encrypt stored authentication credentials. When attesting “no,” the health IT developer may explain why the Health IT Module does not support encrypting stored authentication credentials. (13) Multi-factor authentication. (i) Yes—the Health IT Module supports the authentication, through multiple elements, of the user's identity with the use of industry-recognized standards. When attesting “yes,” the health IT developer must describe the use cases supported. (ii) No—the Health IT Module does not support authentication, through multiple elements, of the user's identity with the use of industry-recognized standards. When attesting “no,” the health IT developer may explain why the Health IT Module does not support authentication, through multiple elements, of the user's identity with the use of industry-recognized standards. (e) Patient engagement View, download, and transmit to 3rd party. (A) View. ( 1 i.e., 3 i iii ( 2 i.e., 3 i iii ( 3 ( i Assessment and plan of treatment. ( ii Goals. ( iii Health concerns. ( iv Unique device identifier(s) for a patient's implantable device(s). ( 4 ( 5 ( 6 ( i ( ii ( iii ( 7 (B) Download. 1 ( i ( ii ( 2 ( i Ambulatory setting only. 1 2 4 5 ( ii Inpatient setting only. 1 3 5 ( 3 Inpatient setting only. (C) Transmit to third party. ( 1 2 ( i ( ii ( 2 Inpatient setting only. 3 1 i ii (D) Timeframe selection. ( 1 ( 2 (ii) Activity history log. ( 1 i.e. ( 2 ( 3 ( 4 (B) [Reserved] (iii) Request for restrictions. (2) [Reserved] (3) Patient health information capture. (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 Transmission to immunization registries. (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)(1) for historical vaccines. (C) At a minimum, the version of the standard specified in § 170.207(e)(2) 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. (3) Transmission to public health agencies—reportable laboratory tests and values/results. (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)(1) and (c)(1). (4) Transmission to cancer registries. (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)(1) and (c)(1). (5) Transmission to public health agencies electronic case reporting. (i) Functional electronic case reporting. (A) Consume and maintain a table of trigger codes to determine which encounters may be reportable. (B) Match a patient visit or encounter to the trigger code based on the parameters of the trigger code table. (C) Case report creation. ( 1 ( 2 ( i ( ii ( iii ( iv (ii) Standards-based electronic case reporting. (A) Consume and process case reporting trigger codes and identify a reportable patient visit or encounter based on a match from the Reportable Conditions Trigger Code value set in § 170.205(t)(4). (B) Create a case report consistent with at least one of the following standards: ( 1 ( 2 (C) Receive, consume, and process a case report response that is formatted to either the reportability response profile of the HL7 FHIR eCR IG in § 170.205(t)(1) or the HL7 CDA RR IG in § 170.205(t)(3) as determined by the standard used in (f)(5)(ii)(B) of this section. (D) Transmit a case report electronically to a system capable of receiving a case report. (6) Transmission to public health agencies—antimicrobial use and resistance reporting. (7) Transmission to public health agencies—health care surveys. (g) Design and performance Automated numerator recording. (2) Automated measure calculation. (3) Safety-enhanced design. (ii) Number of test participants. (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. (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. (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. (i) This certification criterion's scope includes: (A) The data classes expressed in the standards in § 170.213 in accordance with § 170.205(a)(4) and (a)(5) and paragraphs (g)(6)(i)(C)( 1 4 (B) The data classes expressed in the standards in § 170.213, and in accordance with § 170.205(a)(4) and (6) and paragraphs (g)(6)(i)(C)( 1 3 (C) The following data classes: ( 1 Assessment and plan of treatment. ( 2 Goals. ( 3 Health concerns. ( 4 Unique device identifier(s) for a patient's implantable device(s). (ii) Reference C-CDA match. (B) For health IT certified to (g)(6)(i)(B) of this section, create a data file formatted in accordance with the standard adopted in § 170.205(a)(4) that matches a gold-standard, reference data file. (iii) Document-template conformance. (B) For health IT certified to (g)(6)(i)(B) of this section, 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. (iv) Vocabulary conformance. (B) For health IT certified to (g)(6)(i)(B) of this section, 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. (v) Completeness verification. (7) Application access—patient selection. (i) Functional requirement. (ii) Documentation. ( 1 ( 2 (B) The documentation used to meet paragraph (g)(7)(ii)(A) of this section must be available via a publicly accessible hyperlink. (8) [Reserved] (9) Application access—all data request. (i) Functional requirements. 1 3 i iv ( 2 3 i iv ( 3 ( i Assessment and plan of treatment. ( ii Goals. ( iii Health concerns. ( iv Unique device identifier(s) for a patient's implantable device(s). (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 ( 1 ( 2 (B) The documentation used to meet paragraph (g)(9)(ii)(A) of this section must be available via a publicly accessible hyperlink. (10) Standardized API for patient and population services. (i) Data response. (B) Respond to requests for multiple patients' data as a group according to the standards and implementation specifications adopted in § 170.215(a), (b)(1), and (d), for each of the data included in the standards adopted in § 170.213. All data elements indicated as “mandatory” and “must support” by the standards and implementation specifications must be supported. (ii) Supported search operations. (B) Respond to search requests for multiple patients' data consistent with the search criteria included in the implementation specification adopted in § 170.215(d). (iii) Application registration. (iv) Secure connection. (B) Establish a secure and trusted connection with an application that requests data for system scopes in accordance with the implementation specification adopted in § 170.215(d). (v) Authentication and authorization Authentication and authorization for patient and user scopes 1 First time connections. i ( ii ( iii ( 2 Subsequent connections. i ( ii (B) Authentication and authorization for system scopes. Authentication and authorization must occur during the process of granting an application access to patient data in accordance with the “SMART Backend Services: Authorization Guide” section of the implementation specification adopted in § 170.215(d) and the application must be issued a valid access token. (vi) Patient authorization revocation. (vii) Token introspection. (viii) Documentation. ( 1 ( 2 ( 3 (B) The documentation used to meet paragraph (g)(10)(viii)(A) of this section must be available via a publicly accessible hyperlink without any preconditions or additional steps. (11)-(30) [Reserved] (31) Provider prior authorization API—coverage requirements discovery. (i) Coverage discovery. (A) Registration. (B) CDS Hooks support. (C) CRD Client capabilities. (ii) Documentation. (32) Provider prior authorization API—documentation templates and rules. (i) Registration. (ii) Authentication and authorization. (iii) Full DTR EHR capabilities. (33) Provider prior authorization API—prior authorization support. (i) Prior authorization submission. (A) Registration. (B) Authentication and authorization. (C) Prior authorization transactions. ( 1 ( 2 ( 3 (ii) Documentation. (h) Transport methods and other protocols Direct Project Applicability Statement for Secure Health Transport. (ii) Delivery Notification in Direct. (2) Direct Project, Edge Protocol, and XDR/XDM. (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. (i) [Reserved] (j) Modular API capabilities. (1)-(19) [Reserved] (20) Workflow triggers for decision support interventions—clients. (i) Registration. (ii) Authentication and authorization. (A) Support for client authentication using JSON web tokens (JWT). (B) Support for data access authorization of a “CDS Service” using access tokens. (iii) Workflow triggers. (iv) Information exchange. (A) Resource access via API. (B) Receive and display response. (21) Subscriptions—client. (i) Support the requirements in section “Topic-Based Subscriptions—FHIR R4.” (ii) Support the “R4/B Topic-Based Subscription” profile. (iii) Support the accompanying client capabilities for the minimum requirements included in the “R4 Topic-Based Subscription Server Capability Statement,” including support for “create,” “update,” and “delete” interactions for Subscription Resources. (iv) Receive subscription notifications according to section “Topic-Based Subscriptions—FHIR R4,” including support for consuming notifications via the “REST-Hook” channel as specified in the “Channels” section. [80 FR 62747, Oct. 16, 2015, as amended at 80 FR 76871, Dec. 11, 2015; 85 FR 25941, May 1, 2020; 85 FR 47099, Aug. 4, 2020; 85 FR 70083, Nov. 4, 2020; 85 FR 78236, Dec. 4, 2020; 89 FR 1429, Jan. 9, 2024; 89 FR 8548, Feb. 8, 2024; 89 FR 16470, Mar. 7, 2024; 89 FR 101809, Dec. 16, 2024; 90 FR 37210, Aug. 4, 2025] Subpart D—Conditions and Maintenance of Certification Requirements for Health IT Developers Source: 85 FR 25945, May 1, 2020, unless otherwise noted. § 170.400 Basis and scope. This subpart implements section 3001(c)(5)(D) of the Public Health Service Act by setting forth certain Conditions and Maintenance of Certification requirements for health IT developers participating in the ONC Health IT Certification Program. § 170.401 Information blocking. (a) Condition of Certification requirement. (b) [Reserved] [85 FR 25945, May 1, 2020, as amended at 85 FR 70084, Nov. 4, 2020] § 170.402 Assurances. (a) Condition of Certification requirement. (2) A health IT developer must ensure that its health IT certified under the ONC Health IT Certification Program conforms to the full scope of the certification criteria. (3) A health IT developer must not take any action that could interfere with a user's ability to access or use certified capabilities for any purpose within the full scope of the technology's certification. (4) A health IT developer of a certified Health IT Module that is part of a health IT product which electronically stores EHI must certify to the certification criterion in § 170.315(b)(10). (5) A health IT developer must not inhibit its customer's timely access to interoperable health IT certified under the Program. (b) Maintenance of Certification requirements. (i) A period of 10 years beginning from the date a developer's Health IT Module(s) is first certified under the Program; or (ii) If for a shorter period of time, a period of 3 years from the effective date that removes all of the certification criteria to which the developer's health IT is certified from the Code of Federal Regulations. (2)(i) By December 31, 2023, a health IT developer that must comply with the requirements of paragraph (a)(4) of this section must provide all of its customers of certified health IT with the health IT certified to the certification criterion in § 170.315(b)(10). (ii) On and after December 31, 2023, a health IT developer that must comply with the requirements of paragraph (a)(4) of this section must provide all of its customers of certified health IT with the health IT certified to the certification criterion in § 170.315(b)(10). (3)(i) Update. (ii) Provide. (iii) Timeliness. (A) Consistent with the timeframes specified in part 170; or (B) If the developer obtains new customers of health IT certified to the revised criterion after the effective date of the final rule adopting the revised criterion or criteria, then the health IT developer must provide the health IT certified to the revised criterion to such customers within whichever of the following timeframes that expires last: ( 1 ( 2 (4) For developers of Health IT Modules certified to § 170.315(b)(11), starting January 1, 2025, and on an ongoing basis thereafter, review and update as necessary source attribute information in § 170.315(b)(11)(iv)(A) and (B), intervention risk management practices described in § 170.315(b)(11)(vi), and summary information provided through § 170.523(f)(1)(xxi). [85 FR 25945, May 1, 2020, as amended at 85 FR 70084, Nov. 4, 2020; 85 FR 70084, Nov. 4, 2020; 89 FR 1433, Jan. 9, 2024] § 170.403 Communications. (a) Condition of Certification requirements. (i) The usability of its health IT; (ii) The interoperability of its health IT; (iii) The security of its health IT; (iv) Relevant information regarding users' experiences when using its health IT; (v) The business practices of developers of health IT related to exchanging electronic health information; and (vi) The manner in which a user of the health IT has used such technology. (2) A health IT developer must not engage in any practice that prohibits or restricts a communication regarding the subject matters enumerated in paragraph (a)(1) of this section, unless the practice is specifically permitted by this paragraph and complies with all applicable requirements of this paragraph. (i) Unqualified protection for certain communications. (A) Making a disclosure required by law; (B) Communicating information about adverse events, hazards, and other unsafe conditions to government agencies, health care accreditation organizations, and patient safety organizations; (C) Communicating information about cybersecurity threats and incidents to government agencies; (D) Communicating information about information blocking and other unlawful practices to government agencies; or (E) Communicating information about a health IT developer's failure to comply with a Condition of Certification requirement, or with any other requirement of this part, to ONC or an ONC-ACB. (ii) Permitted prohibitions and restrictions. (A) Developer employees and contractors. 1 ( 2 (B) Non-user-facing aspects of health IT. (C) Intellectual property. (D) Screenshots and video. ( 1 ( 2 ( 3 ( i ( ii (E) Pre-market testing and development. (b) Maintenance of Certification requirements Notice. (2) Contracts and agreements. (ii) If a health IT developer has a contract or agreement in existence as of June 30, 2020, that contravenes paragraph (a) of this section, then the developer must amend the contract or agreement to remove or void the contractual provision that contravenes paragraph (a) of this section whenever the contract is next modified for other reasons or renewed. (c) Communication, defined. [85 FR 25945, May 1, 2020, as amended at 85 FR 43711, July 20, 2020; 85 FR 70084, Nov. 4, 2020] § 170.404 Application programming interfaces. The following Condition and Maintenance of Certification requirements apply to developers of Health IT Modules certified to any of the certification criteria adopted in § 170.315(g)(7) through (10), and (31) through (g)(33) unless otherwise specified in this section. (a) Condition of certification requirements General. (2) Transparency conditions Complete business and technical documentation. (ii) Terms and conditions Material information. ( 1 ( 2 ( 3 ( 4 ( 5 ( 6 (B) API fees. ( 1 ( 2 ( 3 (3) Fees conditions General conditions All fees. (B) Permitted fees requirements. ( 1 ( 2 ( 3 ( 4 (C) Prohibited fees. ( 1 ( 2 ( 3 (D) Record-keeping requirements. (ii) Permitted fee—development, deployment, and upgrades. (iii) Permitted fee—recovering API usage costs. (iv) Permitted fee—value-added services. (4) Openness and pro-competitive conditions; general condition. ( i Non-discrimination. (B) The terms on which a Certified API Developer provides certified API technology must be based on objective and verifiable criteria that are uniformly applied to all substantially similar or similarly situated classes of persons and requests. (C) A Certified API Developer must not offer different terms or services based on: ( 1 ( 2 (ii) Rights to access and use certified API technology Rights that must be granted. ( 1 ( 2 ( 3 (B) Prohibited conduct. ( 1 ( 2 ( 3 ( 4 ( 5 ( 6 ( 7 (iii) Service and support obligations. (A) Changes and updates to API technology. (B) Changes to terms and conditions. (b) Maintenance of certification requirements Authenticity verification and registration for production use. (i) Authenticity verification. (ii) Registration for production use. (2) Service base URL publication. (i) Service base URLs must be publicly published in Endpoint resource format according to the standard adopted in § 170.215(a). (ii) Organization details for each service base URL must be publicly published in Organization resource format according to the standard adopted in § 170.215(a). Each Organization resource must contain: (A) A reference, in the Organization.endpoint element, to the Endpoint resources containing service base URLs managed by this organization. (B) The organization's name, location, and facility identifier. (iii) Endpoint and Organization resources must be: (A) Collected into a Bundle resource formatted according to the standard adopted in § 170.215(a) for publication; and (B) Reviewed quarterly and, as necessary, updated. (3) Rollout of (g)(10)-certified APIs. (4) Compliance for existing certified API technology. (c) Definitions. API Information Source API User Certified API Developer Certified API technology [85 FR 25945, May 1, 2020, as amended at 85 FR 70084, Nov. 4, 2020; 89 FR 1433, Jan. 9, 2024; 90 FR 37211, Aug. 4, 2025] § 170.405 Real world testing. (a) Condition of Certification requirement. (b) Maintenance of Certification requirements Real world testing plan submission. (i) The plan must be approved by a health IT developer authorized representative capable of binding the health IT developer for execution of the plan and include the representative's contact information. (ii) The plan must include all health IT certified to any one or more of the criteria referenced in paragraph (a) of this section as of August 31 of the year in which the plan is submitted, and address the real world testing to be conducted in the calendar year immediately following plan submission. (iii) The plan must address the following for each of the certification criteria identified in paragraph (a) of this section that are included in each Health IT Module's scope of certification: (A) The testing method(s)/methodology(ies) that will be used to demonstrate real world interoperability and conformance to the full scope of the certification criterion's requirements, including scenario- and use case-focused testing; (B) The care setting(s) that will be tested for real world interoperability and an explanation for the health IT developer's choice of care setting(s) to test; (C) For any standards and implementation specifications referenced by the criterion that the developer has chosen to certify to National Coordinator-approved newer versions pursuant to paragraph (b)(8) or (9) of this section, a description of how the developer will test and demonstrate conformance to all requirements of the criterion using all versions of the adopted standards to which each Health IT Module was certified as of August 31 of the year in which the real world testing plan is due. (D) A schedule of key real world testing milestones; (E) A description of the expected outcomes of real world testing; (F) At least one measurement/metric associated with the real world testing; and (G) A justification for the health IT developer's real world testing approach. (2) Real world testing results reporting. (ii) For real world testing activities conducted during the immediately preceding calendar year, a health IT developer must submit to its ONC-ACB an annual real world testing results report addressing each of its certified Health IT Modules that include certification criteria referenced in paragraph (a) of this section by a date determined by the ONC-ACB that enables the ONC-ACB to publish a publicly available hyperlink to the results report on CHPL no later than March 15 of each calendar year, beginning in 2023. For certified Health IT Modules included in paragraph (a) of this section that are updated using Inherited Certified Status after August 31 of the year in which the plan is submitted, a health IT developer must include the newer version of the certified Health IT Module(s) in its annual real world testing results report. The real world testing results must report the following for each of the certification criteria identified in paragraph (a) of this section that are included in the Health IT Module's scope of certification: (A) The method(s) that was used to demonstrate real world interoperability; (B) The care setting(s) that was tested for real world interoperability; (C) The voluntary updates to standards and implementation specifications that the National Coordinator has approved through the Standards Version Advancement Process; (D) A list of the key milestones met during real world testing; (E) The outcomes of real world testing including a description of any challenges encountered during real world testing; and (F) At least one measurement/metric associated with the real world testing. (3)-(7) [Reserved] (8) Standards Version Advancement Process voluntary updates of certified health IT to newer versions of standards and implementation specifications. (i) Provide advance notice to all affected customers and its ONC-ACB— (A) Expressing its intent to update the certified Health IT Module(s) to the National Coordinator-approved advanced version of the standard implementation specification; (B) The developer's expectations for how the update(s) will affect real world interoperability for the Health IT Module(s); (C) Whether the developer intends to continue to support the certificate(s) for the existing certified Health IT Module(s) version(s) for some period of time and how long or if the existing certified Health IT Module(s) version(s) will be deprecated; and (ii) Successfully demonstrate conformance with approved more recent versions of the standard(s) or implementation specification(s) included in each certification criterion under which the developer chooses to update its certified Health IT Module(s). (iii) Maintain the updated certified Health IT Module(s) in full conformance with all applicable Program requirements. (9) Standards Version Advancement Process—voluntary certification to newer versions of standards and implementation specifications. (10) [Reserved] [85 FR 25945, May 1, 2020, as amended at 85 FR 43711, July 20, 2020; 85 FR 70084, Nov. 4, 2020; 85 FR 78236, Dec. 4, 2020; 89 FR 1434, Jan. 9, 2024; 90 FR 37211, Aug. 4, 2025] § 170.406 Attestations. (a) Condition of Certification requirement. (1) Section 170.401; (2) Section 170.402, but only for § 170.402(a)(4) and (b)(2) if the health IT developer certified a Health IT Module(s) that is part of a health IT product which can store electronic health information; (3) Section 170.403; (4) Section 170.404 if the health IT developer has a Health IT Module(s) certified to any of the certification criteria adopted in § 170.315(g)(7) through (10); and such health IT developer must also ensure that health IT allows for health information to be exchanged, accessed, and used, in the manner described in § 170.404; and (5) Section 170.405 if a health IT developer has a Health IT Module(s) certified to any one or more ONC Certification Criteria for Health IT in § 170.315(b), (c)(1) through (3), (e)(1), (f), (g)(7) through (10), and (h). (b) Maintenance of Certification requirement. (2) [Reserved]
[85 FR 25945, May 1, 2020, as amended at 89 FR 8549, Feb. 8, 2024] § 170.407 Insights Condition and Maintenance of Certification. (a) Condition of Certification Measure responses. (i) Responses for the measures specified in this section, which must include: (A) Data aggregated at the product level (across versions); (B) Documentation related to the data sources and methodology used to generate measures; and (C) Percentage of total customers ( e.g., (ii) A response (attestation) that it does not: (A) Meet the minimum reporting qualifications requirement in paragraph (a)(2) of this section; or (B) Have health IT certified to the certification criteria specified in each measure in paragraphs (a)(3)(i) through (vii) of this section; or (C) Have any users using the certified health IT specified in each measure in paragraphs (a)(3)(i) through (vii) of this section during the reporting period. (2) Minimum reporting qualifications requirement. (3) Measures Individuals' access to electronic health information through certified health IT. (ii) Consolidated clinical document architecture (C-CDA) problems, medications, and allergies reconciliation and incorporation through certified health IT. (A) Encounters; (B) Unique patients with an encounter; (C) C-CDA documents obtained (unique and overall); and (D) C-CDA documents reconciled and incorporated both through manual and automated processes. (iii) Applications supported through certified health IT. (A) Application Name(s); (B) Application Developer Name(s); (C) Intended Purpose(s) of Application; (D) Intended Application User(s); and (E) Application Status. (iv) Use of FHIR in apps through certified health IT. (A) User type; (B) FHIR resource; and (C) US Core Implementation Guide version. (v) Use of FHIR bulk data access through certified health IT. (vi) Immunization administrations electronically submitted to immunization information systems through certified health IT. (A) IIS; and (B) Age group. (vii) Immunization history and forecasts through certified health IT. (A) IIS. (B) [Reserved] (b) Maintenance of Certification. (i) A health IT developer must provide responses for measures specified in: (A) Paragraphs (a)(3)(i), (iii), (iv)(A) and (B), and (vi) of this section beginning July 2027; (B) Paragraphs (a)(3)(ii)(A) through (C), (iv)(C), (v), (vi)(A) and (B), and (vii) of this section beginning July 2028; and (C) Paragraph (a)(3)(ii)(D), (vii)(A) of this section beginning July 2029. (ii) [Reserved] (2) [Reserved] [89 FR 1434, Jan. 9, 2024; 89 FR 16470, Mar. 7, 2024] 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. § 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] § 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 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 Health IT Modules in accordance with the applicable certification criteria adopted by the Secretary in subpart C of this part. (c) [Reserved] (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, as amended at 85 FR 25950, May 1, 2020] § 170.502 Definitions. For the purposes of this subpart: Applicant Deployment site Development site Gap certification (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 Health IT Module(s) under the ONC Health IT Certification Program. ONC-Authorized Certification Body or ONC-ACB ONC-Authorized Testing Lab or ONC-ATL Providing or provide an updated certification Remote certification [76 FR 1325, Dec. 7, 2011, as amended at 77 FR 54291, Sept. 4, 2012; 81 FR 72464, Oct. 19, 2016; 85 FR 25950, May 1, 2020; 89 FR 101809, Dec. 16, 2024] §§ 170.503-170.504 [Reserved] § 170.505 Correspondence. (a) Correspondence and communication with ONC or the National Coordinator shall be conducted by email, unless otherwise necessary or specified. (1) Consideration for providing notice beyond email, such as by regular, express, or certified mail, will be based on, but not limited to, whether: The party requests use of correspondence beyond email; the party has responded via email to our communications; we have sufficient information from the party to ensure appropriate delivery of any other method of notice; and the matter involves an alleged violation within ONC's purview under § 170.580 that indicates a serious violation under the ONC Health IT Certification Program with potential consequences of suspension, certification termination, or a certification ban. (2) The official date of receipt of any email between ONC or the National Coordinator and 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 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. [85 FR 25950, May 1, 2020] § 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) Health IT Module certification; and/or (b) 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; 85 FR 25950, May 1, 2020] § 170.511 Authorization scope for ONC-ATL status. Applicants may seek authorization from the National Coordinator to perform the testing of 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. [89 FR 101809, Dec. 16, 2024] § 170.520 Application. (a) ONC-ACB application. (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 to ISO/IEC 17065 (for availability, see § 170.599), with an appropriate scope, by any accreditation body that is a signatory to the Multilateral Recognition Arrangement (MLA) with the International Accreditation Forum (IAF). (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. (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 (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, as amended at 85 FR 25950, May 1, 2020] § 170.523 Principles of proper conduct for ONC-ACBs. An ONC-ACB shall: (a) Accreditation. (b) Mandatory training. (c) Training program. (d) Reporting. (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) Onsite observation. (f) Certified product listing. (1) For the ONC Certification Criteria for Health IT: (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. (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. (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, (xiii) Where applicable, (xiv) Where applicable, (xv) Where applicable, (xvi) Where applicable, (xvii) Where applicable, (xviii) Where applicable, (xix) Where applicable, e.g. (xx) A hyperlink to the disclosures required by § 170.523(k)(1) for the Health IT Module; (xxi) Where applicable, summary information of the intervention risk management practices listed in § 170.315(b)(11)(vi) is submitted by the health IT developer via publicly accessible hyperlink that allows any person to access the summary information directly without any preconditions or additional steps. (xxii) When applicable, (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) [Reserved] (g) Records retention. (2) Make the records available to HHS upon request during the retention period described in paragraph (g)(1) of this section; (h) Certification decision. (1) Tested, using test tools and test procedures approved by the National Coordinator, by an: (i) ONC-ATL; (ii) ONC-ATL, National Voluntary Laboratory Accreditation Program-accredited testing laboratory under the ONC Health IT Certification Program, and/or an ONC-ATCB for the purposes of performing gap certification; or (2) Evaluated by it for compliance with a conformance method approved by the National Coordinator. (i) Surveillance. (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., (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) Refunds. (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 Health IT Module(s). (k) Disclosures. (1) Mandatory Disclosures. (i) The disclaimer “This Health IT Module is compliant with the ONC Certification Criteria for Health IT 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) For a Health IT Module certified to the ONC Certification Criteria for Health IT, the information specified by paragraphs (f)(1)(i), (vi) through (viii), (xv), and (xvi) of this section as applicable for the specific Health IT Module. (iii) In plain language, a detailed description of all known material information concerning additional types of costs or fees that a user may be required to pay to implement or use the Health IT Module's capabilities, whether to meet provisions of HHS programs requiring the use of certified health IT or to achieve any other use within the scope of the health IT's certification. The additional types of costs or fees required to be disclosed include but are not limited to 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. (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)-(C) [Reserved] (v) Health IT self-developers are excluded from the requirements of paragraph (k)(1)(iii) of this section. (2)-(3) [Reserved] (4) A certification issued to a Health IT Module based solely on the applicable certification criteria adopted by the ONC Health IT Certification Program must be separate and distinct from any other certification(s) based on other criteria or requirements. (l) Certification and Design Mark. (m) Adaptations and updates. (1) All adaptations of certified Health IT Modules; (2) All updates made to certified Health IT Modules affecting the capabilities in certification criteria to which the “safety-enhanced design” criteria apply; (3) All uses cases for § 170.315(d)(13); (4) All updates made to certified Health IT Modules in compliance with § 170.405(b)(3); and (5) All updates to certified Health IT Modules and all certifications of Health IT Modules issued including voluntary use of newer standards versions per § 170.405(b)(8) or (9). Record of these updates may be obtained by aggregation of ONC-ACB documentation of certification activity. (n) Complaints reporting. (o) Scope reduction. (p) Real world testing. (2) Review and confirm that applicable health IT developers submit real world testing results in accordance with § 170.405(b)(2). (3) Submit real world testing plans by December 15 of each calendar year and results by March 15 of each calendar year to ONC for public availability. (q) Attestations. (r) Test results from ONC-ATLs. (1) In good standing under the ONC Health IT Certification Program, and (2) Compliant with its ISO/IEC 17025 accreditation requirements as required by 170.524(a). (s) Information for direct review. (t) Health IT Module voluntary standards and implementation specifications updates notices. (1) Maintain a record of the date of issuance and the content of developers' § 170.405(b)(8) notices; and (2) Timely post content or make publicly accessible via the CHPL each § 170.405(b)(8) notice received, publicly on the CHPL attributed to the certified Health IT Module(s) to which it applies. (u) Insights. [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; 85 FR 25950, May 1, 2020; 85 FR 70084, Nov. 4, 2020; 89 FR 1435, Jan. 9, 2024; 89 FR 101809, Dec. 16, 2024] § 170.524 Principles of proper conduct for ONC-ATLs. An ONC-ATL shall: (a) Accreditation. see (b) Mandatory training. (c) Training program. (d) Reporting. (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) Onsite observation. (f) Records retention. (2) Make the records available to HHS upon request during the retention period described in paragraph (f)(1) of this section; (g) Approved testing methods. (h) Refunds. (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 Health IT Modules. [81 FR 72465, Oct. 19, 2016, as amended at 85 FR 25951, May 1, 2020; 89 FR 1435, Jan. 9, 2024] § 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] § 170.530 Review of application. (a) Method of review and review timeframe. (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. (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. (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. (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] § 170.535 ONC-ACB and ONC-ATL application reconsideration. (a) Basis for reconsideration request. (b) Submission requirement. (c) Reconsideration request review. (d) Decision. (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. [76 FR 1325, Dec. 7, 2011, as amended at 81 FR 72466, Oct. 19, 2016] § 170.540 ONC-ACB and ONC-ATL status. (a) Acknowledgement and publication. (b) Representation. (c) Renewal. (d) Expiration. [81 FR 72466, Oct. 19, 2016] § 170.545 [Reserved] § 170.550 Health IT Module certification. (a) Certification scope. (b) Health IT product scope options. (c) Gap certification. (d) Upgrades and enhancements. (e) Standards updates. (f) [Reserved] (g) Health IT Module dependent criteria. (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. (5) Section 170.315(b)(10) when a health IT developer presents a Health IT Module for certification that can store electronic health information at the time of certification by the product, of which the Health IT Module is a part. (6) Section 170.315(b)(4) if the Health IT Module is presented for certification to the certification criteria in § 170.315(b)(3). (h) Privacy and security certification framework General rule. (2) Testing. (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. (ii) Section 170.315(a)(4), (10), and (13) and, on and after January 1, 2028, (b)(11), are also certified to the certification criteria specified in § 170.315(d)(1) through (3), (5) through (7), and (12), and, for the time period up to and including December 31, 2027, (d)(13). (iii) Section 170.315(b)(1) through (3) and (6) through (9) are also certified to the certification criteria specified in § 170.315(d)(1) through (3) and (d)(5) through (8), (12), and (13); (iv) Section 170.315(c) is also certified to the certification criteria specified in § 170.315(d)(1), (d)(2)(i)(A), (B), (d)(2)(ii) through (v), (d)(3), (5), (12), and (13); (v) Section 170.315(e)(1) is also certified to the certification criteria specified in § 170.315(d)(1) through (3), (5), (7), (9), (12), and (13); (vi) Section 170.315(e)(2) and (3) is also certified to the certification criteria specified in § 170.315(d)(1), (d)(2)(i)(A) and (B), (d)(2)(ii) through (v), (d)(3), (5), (9), (12), and (13); (vii) Section 170.315(f) is also certified to the certification criteria specified in § 170.315(d)(1) through (3), (7), (12), and (13); (viii) Section 170.315(g)(7) through (10) is also certified to the certification criteria specified in § 170.315(d)(1), (9), (12), and (13); and (d)(2)(i)(A) and (B), (d)(2)(ii) through (v), or (d)(10); (ix) Section 170.315(h) is also certified to the certification criteria specified in § 170.315(d)(1), (d)(2)(i)(A) and (B), (d)(2)(ii) through (v), (d)(3), (12), and (13); and (4) Methods to demonstrate compliance with each privacy and security criterion. (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. (k) Inherited certified status. (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. (l) Conditions of certification attestations. [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; 85 FR 25952, May 1, 2020; 85 FR 70085, Nov. 4, 2020; 89 FR 1435, Jan. 9, 2024; 89 FR 8549, Feb. 8, 2024; 89 FR 101810, Dec. 16, 2024; 90 FR 37211, Aug. 4, 2025] § 170.553 [Reserved] § 170.555 Certification to newer versions of certain standards. (a) ONC-ACBs may certify 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. (i) The National Coordinator approves a newer version for use in certification and a health IT developer voluntarily elects to seek certification of its health IT in accordance with § 170.405(b)(9) or update its certified health IT to the newer version in accordance with § 170.405(b)(8); or (ii) The new version is incorporated by reference in § 170.299. (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, as amended at 85 FR 25952, May 1, 2020] § 170.556 In-the-field surveillance and maintenance of certification for Health IT. (a) In-the-field surveillance. (1) Production environment. (2) Production data. (b) Reactive surveillance. (1) Review of required disclosures. (2) [Reserved] (c) Randomized surveillance. (1) Scope. (2) [Reserved] (3) Selection method. (4) Number and types of locations for in-the-field surveillance. (i) Evaluate the certified Health IT Module's capabilities at one or more locations where the 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 Health IT Module is implemented and in use in the field. (d) Corrective action plan and procedures. (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 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. (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. (e) Reporting of surveillance results requirements Rolling submission of in-the-field surveillance results. (2) Confidentiality of locations evaluated. (3) Reporting of corrective action plans. (f) Relationship to other surveillance requirements. [80 FR 62758, Oct. 16, 2015, as amended at 80 FR 76872, Dec. 11, 2015; 81 FR 72466, Oct. 19, 2016; 85 FR 25952, May 1, 2020] § 170.557 Authorized testing and certification methods. (a) ONC-ATL applicability. (b) ONC-ACB applicability. [81 FR 72466, Oct. 19, 2016] § 170.560 Good standing as an ONC-ACB or ONC-ATL. (a) ONC-ACB good standing. (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 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. (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; 85 FR 25953, May 1, 2020] § 170.565 Revocation of ONC-ACB or ONC-ATL status. (a) Type-1 violations. (b) Type-2 violations. (1) Noncompliance notification. (2) Opportunity to become compliant. (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. (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. (i) Applicable to both ONC-ACBs and ONC-ATLs. (ii) Applicable to ONC-ACBs. (iii) Applicable to ONC-ATLs. (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. (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. (g) Revocation. (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 Effectuation. (2) ONC-ACB provisions. (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 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. (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, as amended at 85 FR 25953, May 1, 2020] § 170.570 Effect of revocation on the certifications issued to Complete EHRs and EHR Module(s). (a) The certified status of 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 Health IT Module(s) certifications were based on unreliable testing and/or certification. (c) If the National Coordinator determines that Health IT Module(s) certifications were based on unreliable testing and/or certification, the certification status of affected Health IT Module(s) would only remain intact for 120 days after the National Coordinator publishes the notice. (1) The certification status of affected 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 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, as amended at 85 FR 25953, May 1, 2020] § 170.575 [Reserved] § 170.580 ONC review of certified health IT. (a) Direct review Purpose. (2) Circumstances that may trigger review Certified health IT causing or contributing to unsafe conditions. (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 of certified health IT. (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. (iii) Noncompliance with a Condition and Maintenance of Certification requirement. (3) Relationship to ONC-ACBs and ONC-ATLs. (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 or a health IT developer's actions or practices. (v) ONC may end all or any part of its review of certified health IT or a health IT developer's actions or practices 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. (4) Coordination with the Office of Inspector General. (ii) ONC may rely on Office of Inspector General findings to form the basis of a direct review action. (b) Notice Notice of potential non-conformity Circumstances that may trigger notice of potential non-conformity. (ii) Health IT developer response. ( 1 ( 2 ( 3 (B) ONC may adjust the 30-day timeframe specified in paragraph (b)(1)(ii)(A)( 3 ( 1 ( 2 ( 3 ( 4 (iii) ONC determination. 3 (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 (C) Substantiate a non-conformity and issue a notice of non-conformity. (D) Issue a notice of proposed termination if the health IT is under review in accordance with paragraph (a)(2)(i) or (ii) of this section. (2) Notice of non-conformity Circumstances that may trigger notice of non-conformity. (ii) Health IT developer response. ( 1 ( 2 ( 3 ( 4 (B) ONC may adjust the 30-day timeframe specified in paragraph (b)(2)(ii)(A)( 3 ( 1 ( 2 ( 3 ( 4 (iii) ONC determination. (3) Records access. (i) All records related to the development, testing, certification, implementation, maintenance and use of its certified health IT; (ii) Any complaint records related to the certified health IT; (iii) All records related to the Condition(s) and Maintenance of Certification requirements, including marketing and distribution records, communications, and contracts; and (iv) Any other relevant information. (c) Corrective action plan and procedures Applicability. (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 (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. (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 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 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 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 Applicability. (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 (C) A notice of non-conformity within the timeframe established in accordance with paragraph (b)(2)(ii)(A)( 3 (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 Applicability. (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; (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; or (iii) A determination is made that the health IT developer is noncompliant with a Condition or Maintenance of Certification requirement under subpart D of this part or for the following circumstances when ONC exercises direct review under paragraph (a)(2)(iii) of this section: (A) The health IT developer fails to timely respond to any communication from ONC, including, but not limited to: ( 1 ( 2 3 ( 3 3 (B) 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; (C) The health IT developer fails to cooperate with ONC and/or a third party acting on behalf of ONC; (D) The health IT developer fails to timely submit in writing a proposed corrective action plan; (E) 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; (F) The health IT developer does not fulfill its obligations under the corrective action plan developed in accordance with paragraph (c) of this section; or (G) ONC concludes that the non-conformity(ies) cannot be cured. (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 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 Basis for appeal. (i) ONC incorrectly applied ONC Health IT Certification Program requirements for a: (A) Suspension; (B) Termination; or (C) Certification ban under § 170.581(a)(2). (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. (i) Termination; (ii) Suspension; or (iii) Certification ban under § 170.581(a)(2). (3) Time for filing a request for appeal. (A) Suspension; (B) Termination; or (C) Certification ban under § 170.581(a)(2). (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. (ii) A request for appeal does not stay the suspension of a Health IT Module. (iii) A request for appeal stays a certification ban issued under § 170.581(a)(2). (5) Appointment of a hearing officer. (i) The hearing officer may not review an appeal in which he or she participated in the initial suspension, termination, or certification ban 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. (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 or issue a certification ban. (7) Determination by the hearing officer. (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, as amended at 85 FR 25953, May 1, 2020] § 170.581 Certification ban. (a) Circumstances that may trigger a certification ban. (1) The certification of one or more of the health IT developer's Health IT Modules is: (i) Terminated by ONC under the ONC Health IT Certification Program; (ii) Withdrawn from the ONC Health IT Certification Program by an ONC-ACB because the health IT developer requested it to be withdrawn (for reasons other than to comply with Program requirements) when the health IT developer's health IT was the subject of a potential non-conformity or non-conformity as determined by ONC; (iii) 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; (iv) Withdrawn by an ONC-ACB because the health IT developer requested it to be withdrawn (for reasons other than to comply with Program requirements) 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; or (2) ONC determines a certification ban is appropriate per its review under § 170.580(a)(2)(iii). (b) Notice of certification ban. (1) An explanation of the certification ban; (2) Information supporting the certification ban; (3) Instructions for appealing the certification ban if banned in accordance with paragraph (a)(2) of this section; and (4) Instructions for requesting reinstatement into the ONC Health IT Certification Program, which would lift the certification ban. (c) Effective date of certification ban. (2) For certification bans issued under paragraph (a)(2) of this section, the ban will be effective immediately after the following applicable occurrence: (i) The expiration of the 10-day period for filing a statement of intent to appeal in § 170.580(g)(3)(i) if the health IT developer does not file a statement of intent to appeal. (ii) The expiration of the 30-day period for filing an appeal in § 170.580(g)(3)(ii) if the health IT developer files a statement of intent to appeal, but does not file a timely appeal. (iii) A final determination to issue a certification ban per § 170.580(g)(7) if a health IT developer files an appeal timely. (d) Reinstatement. (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, certificate withdrawal, or noncompliance with a Condition or Maintenance of Certification requirement have been provided appropriate remediation. (3) For noncompliance with a Condition or Maintenance of Certification requirement, the noncompliance must be resolved. (4) ONC is satisfied with the health IT developer's demonstration under paragraph (d)(2) of this section that all affected customers have been provided with appropriate remediation and grants reinstatement into the ONC Health IT Certification Program. [85 FR 25954, May 1, 2020] § 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 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 17025:2017(E)—General requirements for the competence of testing and calibration laboratories (Third Edition), 2017-11, “ISO/IEC 17025,” IBR approved for §§ 170.520(b), and 170.524(a). (5) 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 and 170.523(a). [81 FR 72471, Oct. 19, 2016, as amended at 85 FR 25955, May 1, 2020]