21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program, 25642-25961 [2020-07419]

Download as PDF 25642 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations DEPARTMENT OF HEALTH AND HUMAN SERVICES Office of the Secretary 45 CFR Parts 170 and 171 RIN 0955–AA01 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program Office of the National Coordinator for Health Information Technology (ONC), Department of Health and Human Services (HHS). ACTION: Final rule. AGENCY: This final rule implements certain provisions of the 21st Century Cures Act, including Conditions and Maintenance of Certification requirements for health information technology (health IT) developers under the ONC Health IT Certification Program (Program), the voluntary certification of health IT for use by pediatric health care providers, and reasonable and necessary activities that do not constitute information blocking. The implementation of these provisions will advance interoperability and support the access, exchange, and use of electronic health information. The rule also finalizes certain modifications to the 2015 Edition health IT certification criteria and Program in additional ways to advance interoperability, enhance health IT certification, and reduce burden and costs. DATES: Effective date: This final rule is effective on June 30, 2020. Incorporation by reference: The incorporation by reference of certain publications listed in the rule was approved by the Director of the Federal Register as of June 30, 2020. Compliance date: Compliance with 45 CFR 170.401, 170.402(a)(1), and 45 CFR part 171 is required by November 2, 2020. FOR FURTHER INFORMATION CONTACT: Michael Lipinski, Office of Policy, Office of the National Coordinator for Health Information Technology, 202– 690–7151. SUPPLEMENTARY INFORMATION: SUMMARY: Table of Contents I. Executive Summary A. Purpose of Regulatory Action B. Summary of Major Provisions and Clarifications 1. Deregulatory Actions for Previous Rulemakings 2. Updates to the 2015 Edition Certification Criteria VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 a. Adoption of the United States Core Data for Interoperability (USCDI) as a Standard b. Electronic Prescribing c. Clinical Quality Measures—Report d. Electronic Health Information (EHI) Export e. Application Programming Interfaces f. Privacy and Security Transparency Attestations g. Security Tags and Consent Management 3. Modifications To the ONC Health IT Certification Program 4. Health IT for the Care Continuum 5. Conditions and Maintenance of Certification Requirements 6. Information Blocking C. Costs and Benefits II. Background A. Statutory Basis 1. Standards, Implementation Specifications, and Certification Criteria 2. Health IT Certification Program(s) B. Regulatory History C. General Comments on the Proposed Rule III. Deregulatory Actions for Previous Rulemakings A. Background 1. History of Burden Reduction and Regulatory Flexibility 2. Executive Orders 13771 and 13777 B. Deregulatory Actions 1. Removal of Randomized Surveillance Requirements 2. Removal of the 2014 Edition From the Code of Federal Regulations 3. Removal of the ONC-Approved Accreditor From the Program 4. Removal of Certain 2015 Edition Certification Criteria and Standards a. 2015 Edition Base EHR Definition Certification Criteria b. Drug-Formulary and Preferred Drug Lists c. Patient-Specific Education Resources d. Common Clinical Data Set Summary Record—Create; and Common Clinical Data Set Summary Record—Receive e. Secure Messaging 5. Removal of Certain ONC Health IT Certification Program Requirements a. Limitations Disclosures b. Transparency and Mandatory Disclosures Requirements 6. Recognition of Food and Drug Administration Processes a. FDA Software Precertification Pilot Program b. Development of Similar Independent Program Processes—Request for Information IV. Updates To the 2015 Edition Certification Criteria A. Standards and Implementation Specifications 1. National Technology Transfer and Advancement Act 2. Compliance With Adopted Standards and Implementation Specifications 3. ‘‘Reasonably Available’’ to Interested Parties B. Revised and New 2015 Edition Criteria 1. The United States Core Data for Interoperability Standard (USCDI) a. USCDI 2015 Edition Certification Criteria PO 00000 Frm 00002 Fmt 4701 Sfmt 4700 b. USCDI Standard—Data Classes Included c. USCDI Standard—Relationship to Content Exchange Standards and Implementation Specifications 2. Clinical Notes C-CDA Implementation Specification 3. Unique Device Identifier(s) for a Patient’s Implantable Device(s) C-CDA Implementation Specification 4. Electronic Prescribing Criterion a. Electronic Prescribing Standard and Certification Criterion b. Electronic Prescribing Transactions 5. Clinical Quality Measures—Report Criterion 6. Electronic Health Information (EHI) Export Criterion a. Single Patient Export To Support Patient Access b. Patient Population Export to Support Transitions Between Health IT Systems c. Scope of Data Export d. Export Format e. Initial Step Towards Real-Time Access f. Timeframes g. 2015 Edition ‘‘Data Export’’ Criterion in § 170.315(b)(6) 7. Standardized API for Patient and Population Services Criterion 8. Privacy and Security Transparency Attestations Criteria a. Encrypt Authentication Credentials b. Multi-Factor Authentication 9. Security Tags and Consent Management Criteria a. Implementation With the Consolidated CDA Release 2.1 b. Implementation With the Fast Healthcare Interoperability Resources (FHIRr) Standard 10. Auditable Events and TamperResistance, Audit Reports, and Auditing Actions on Health Information C. Unchanged 2015 Edition Criteria— Promoting Interoperability Programs Reference Alignment V. Modifications To the ONC Health IT Certification Program A. Corrections 1. Auditable Events and Tamper Resistance 2. Amendments 3. View, Download, and Transmit to 3rd Party 4. Integrating Revised and New Certification Criteria Into the 2015 Edition Privacy and Security Certification Framework B. Principles of Proper Conduct for ONCACBs 1. Records Retention 2. Conformance Methods for Certification Criteria 3. ONC-ACBs To Accept Test Results From Any ONC-ATL in Good Standing 4. Mandatory Disclosures and Certifications C. Principles of Proper Conduct for ONCATLs—Records Retention VI. Health IT for the Care Continuum A. Health IT for Pediatric Setting 1. Background and Stakeholder Convening 2. Recommendations for the Voluntary Certification of Health IT for Use in Pediatric Care a. 2015 Edition Certification Criteria b. New or Revised Certification Criteria E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations B. Health IT and Opioid Use Disorder Prevention and Treatment—Request for Information VII. Conditions and Maintenance of Certification Requirements for Health IT Developers A. Implementation B. Provisions 1. Information Blocking 2. Assurances a. Full Compliance and Unrestricted Implementation of Certification Criteria Capabilities b. Certification to the ‘‘Electronic Health Information Export’’ Criterion c. Records and Information Retention d. Trusted Exchange Framework and the Common Agreement—Request for Information 3. Communications a. Background and Purpose b. Condition of Certification Requirements c. Maintenance of Certification Requirements 4. Application Programming Interfaces a. Statutory Interpretation and API Policy Principles b. API Standards and Implementation Specifications c. Standardized API for Patient and Population Services d. API Condition of Certification Requirements e. API Maintenance of Certification Requirements 5. Real World Testing a. Unit of Analysis at which Testing Requirements Apply b. Applicability of Real World Testing Condition and Maintenance of Certification Requirements c. Testing Plans, Methods, and Results Reporting d. Submission Dates e. Real World Testing Pilot Year f. Health IT Modules Certified But Not Yet Deployed g. Standards Version Advancement Process (SVAP) h. Updating Already Certified Health IT Leveraging SVAP Flexibility i. Health IT Modules Presented for Certification Leveraging SVAP Flexibility j. Requirements Associated With All Health IT Modules Certified Leveraging SVAP Flexibility k. Advanced Version Approval for SVAP l. Real World Testing Principles of Proper Conduct for ONC-ACBs m. Health IT Module Certification & Certification to Newer Versions of Certain Standards 6. Attestations 7. EHR Reporting Criteria Submission C. Compliance D. Enforcement 1. ONC Direct Review of the Conditions and Maintenance of Certification Requirements 2. Review and Enforcement Only by ONC 3. Review Processes a. Initiating Review and Health IT Developer Notice b. Relationship With ONC-ACBs and ONCATLs VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 c. Records Access d. Corrective Action e. Certification Ban and Termination f. Appeal g. Suspension h. Proposed Termination 4. Public Listing of Certification Ban and Terminations 5. Effect on Existing Program Requirements and Processes 6. Coordination With the Office of Inspector General 7. Applicability of Conditions and Maintenance of Certification Requirements for Self-Developers VIII. Information Blocking A. Statutory Basis B. Legislative Background and Policy Considerations 1. Purpose of the Information Blocking Provision 2. Policy Considerations and Approach to Information Blocking 3. General Comments Regarding Information Blocking Exceptions C. Relevant Statutory Terms and Provisions 1. ‘‘Required by Law’’ 2. Health Care Providers, Health IT Developers, Exchanges, and Networks a. Health Care Providers b. Health IT Developers of Certified Health IT c. Health Information Networks and Health Information Exchanges 3. Electronic Health Information 4. Price Information—Request for Information 5. Interests Promoted by the Information Blocking Provision a. Access, Exchange, and Use of EHI b. Interoperability Elements 6. Practices That May Implicate the Information Blocking Provision a. Prevention, Material Discouragement, and Other Interference b. Likelihood of Interference c. Examples of Practices Likely to Interfere With Access, Exchange, or Use of EHI 7. Applicability of Exceptions a. Reasonable and Necessary Activities b. Treatment of Different Types of Actors c. Establishing That Activities and Practices Meet the Conditions of an Exception D. Exceptions to the Information Blocking Definition 1. Exceptions That Involve not Fulfilling Requests To Access, Exchange, or Use EHI a. Preventing Harm Exception—When will an actor’s practice that is likely to interfere with the access, exchange, or use of EHI in order to prevent harm not be considered information blocking? b. Privacy Exception—When will an actor’s practice of not fulfilling a request to access, exchange, or use EHI in order to protect an individual’s privacy not be considered information blocking? c. Security Exception—When will an actor’s practice that is likely to interfere with the access, exchange, or use of EHI in order to protect the security of EHI not be considered information blocking? d. Infeasibility Exception—When will an actor’s practice of not fulfilling a request PO 00000 Frm 00003 Fmt 4701 Sfmt 4700 25643 to access, exchange, or use EHI due to the infeasibility of the request not be considered information blocking? e. Health IT Performance Exception— When will an actor’s practice that is implemented to maintain or improve health IT performance and that is likely to interfere with the access, exchange, or use of EHI not be considered information blocking? 2. Exceptions That Involve Procedures for Fulfilling Requests To Access, Exchange, or Use EHI a. Content and Manner Exception—When will an actor’s practice of limiting the content of its response to or the manner in which it fulfills a request to access, exchange, or use EHI not be considered information blocking? b. Fees Exception—When will an actor’s practice of charging fees for accessing, exchanging, or using EHI not be considered information blocking? c. Licensing Exception—When will an actor’s practice to license interoperability elements in order for EHI to be accessed, exchanged, or used not be considered information blocking? E. Additional Exceptions—Request for Information 1. Exception for Complying With Common Agreement for Trusted Exchange 2. New Exceptions F. Complaint Process G. Disincentives for Health Care Providers—Request for Information IX. Registries Request for Information X. Patient Matching Request for Information XI. Incorporation by Reference XII. Collection of Information Requirements A. ONC–ACBs B. Health IT Developers XIII. Regulatory Impact Analysis A. Statement of Need B. Alternatives Considered C. Overall Impact 1. Executive Orders 12866 and 13563— Regulatory Planning and Review Analysis 2. Executive Order 13771—Reducing Regulation and Controlling Regulatory Costs a. Costs and Benefits b. Accounting Statement and Table 3. Regulatory Flexibility Act 4. Executive Order 13132—Federalism 5. Unfunded Mandates Reform Act of 1995 Regulation Text I. Executive Summary A. Purpose of Regulatory Action ONC is responsible for the implementation of key provisions in Title IV of the 21st Century Cures Act (Cures Act) that are designed to advance interoperability; support the access, exchange, and use of electronic health information (EHI); and address occurrences of information blocking. This final rule implements certain provisions of the Cures Act, including Conditions and Maintenance of Certification requirements for health information technology (health IT) E:\FR\FM\01MYR3.SGM 01MYR3 25644 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations developers, the voluntary certification of health IT for use by pediatric health providers, and reasonable and necessary activities that do not constitute information blocking. The final rule also implements parts of section 4006(a) of the Cures Act to support patients’ access to their EHI in a form convenient for patients, such as making a patient’s EHI more electronically accessible through the adoption of standards and certification criteria and the implementation of information blocking policies that support patient electronic access to their health information at no cost. Additionally, the final rule modifies the 2015 Edition health IT certification criteria and ONC Health IT Certification Program (Program) in other ways to advance interoperability, enhance health IT certification, and reduce burden and costs. In addition to fulfilling the Cures Act’s requirements, the final rule contributes to fulfilling Executive Order (E.O.) 13813. The President issued E.O. 13813 on October 12, 2017, to promote health care choice and competition across the United States. Section 1(c) of the E.O., in relevant part, states that government rules affecting the United States health care system should reinject competition into health care markets by lowering barriers to entry and preventing abuses of market power. Section 1(c) also states that government rules should improve access to and the quality of information that Americans need to make informed health care decisions. For example, as mentioned above, the final rule establishes application programming interface (API) requirements, including for patients’ access to their health information without special effort. The API approach also supports health care providers’ independence to choose the ‘‘provider-facing’’ third-party services they want to use to interact with the certified API technology they have acquired. In addition, the final rule provides the Secretary of Health and Human Services’ (Secretary) interpretation of the information blocking definition as established in the Cures Act and the application of the information blocking provision by identifying reasonable and necessary activities that would not constitute information blocking. Many of these activities focus on improving patient and health care provider access to EHI and promoting competition. VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 B. Summary of Major Provisions and Clarifications 1. Deregulatory Actions for Previous Rulemakings Since the inception of the Program, we have aimed to implement and administer the Program in the least burdensome manner that supports our policy goals. Throughout the years, we have worked to improve the Program with a focus on ways to reduce burden, offer flexibility to both developers and providers, and support innovation. This approach has been consistent with the principles of E.O. 13563 on Improving Regulation and Regulatory Review (February 2, 2011), which instructs agencies to ‘‘periodically review its existing significant regulations and determine whether any such regulations should be modified, streamlined, expanded, or repealed so as to make the agency’s regulatory program more effective or less burdensome in achieving the regulatory objectives.’’ To that end, we have historically, where feasible and appropriate, taken measures to reduce burden within the Program and make the Program more effective, flexible, and streamlined. We reviewed and evaluated existing regulations and identified ways to administratively reduce burden and implement deregulatory actions through guidance. In this final rule, we have finalized new deregulatory actions that will reduce burden for health IT developers, providers, and other stakeholders. We have finalized five deregulatory actions in section III.B: (1) Removal of a requirement to conduct randomized surveillance on a set percentage of certified products, allowing ONC-Authorized Certification Bodies (ONC–ACBs) more flexibility to identify the right approach for surveillance actions; (2) removal of the 2014 Edition from the Code of Federal Regulations (CFR); (3) removal of the ONC-Approved Accreditor (ONC–AA) from the Program; (4) removal of certain 2015 Edition certification criteria; and (5) removal of certain Program requirements. We have not finalized a sixth deregulatory action we proposed, related to recognition of the Food and Drug Administration (FDA) Software Precertification Program, as comments and the early stage of development of the FDA program indicate finalization would be premature at this time. 2. Updates to the 2015 Edition Certification Criteria This final rule updates the 2015 Edition to remove several certification criteria. It also updates some certification criteria to reflect standard PO 00000 Frm 00004 Fmt 4701 Sfmt 4700 and implementation specification updates. In consideration of public comments, the final rule adds only two new technical certification criteria and two new attestation-structured privacy and security certification criteria. a. Adoption of the United States Core Data for Interoperability (USCDI) as a Standard We noted in the Proposed Rule that, as part of continued efforts to ensure the availability of a minimum baseline of data classes that could be commonly available for interoperable exchange, ONC adopted the 2015 Edition ‘‘Common Clinical Data Set’’ (CCDS) definition and used the CCDS shorthand in several certification criteria. However, the CCDS definition also began to be used colloquially for many different purposes. As the CCDS definition’s relevance grew outside of its regulatory context, it was often viewed as a ceiling to the industry’s collective data set for access, exchange, and use. In addition, we noted in the NPRM that as we continue to move toward valuebased care, the inclusion of additional data classes beyond the CCDS would be necessary. In order to advance interoperability, we proposed to remove the CCDS definition and its references from the 2015 Edition and replace it with the ‘‘United States Core Data for Interoperability 1’’ (USCDI). We proposed to adopt the USCDI as a standard, naming USCDI Version 1 (USCDI v1) in § 170.213 and incorporating it by reference in § 170.299. The USCDI standard would establish a set of data classes and constituent data elements required to support interoperability nationwide. To achieve the goals set forth in the Cures Act, we indicated that we intended to establish and follow a predictable, transparent, and collaborative process to expand the USCDI, including providing stakeholders with the opportunity to comment on the USCDI’s expansion. We also noted that once the USCDI is adopted by the Secretary in regulation, health IT developers would be allowed to take advantage of a new proposed flexibility we called the ‘‘Standards Version Advancement Process’’ (SVAP) (see 84 FR 7497 through 7500, see also section VII.B.5 of this final rule). In order to advance interoperability, we have finalized the adoption of the USCDI standard. Because the USCDI is adopted as a standard and the SVAP is finalized, the SVAP will allow a developer to voluntarily have their products certified to newer, National Coordinator approved versions of the 1 https://www.healthit.gov/uscdi. E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations USCDI in the future without waiting for rulemaking to update the version of the USCDI listed in the regulations. b. Electronic Prescribing We have finalized an update to the electronic prescribing National Council for Prescription Drug Programs (NCPDP) SCRIPT standard in 45 CFR 170.205(b) from NCPDP SCRIPT standard version 10.6 to NCPDP SCRIPT standard version 2017071 for the electronic prescribing certification criterion (§ 170.315(b)(3)). ONC and the Centers for Medicare & Medicaid Services (CMS) have historically maintained aligned e-Rx and medication history (MH) standards to ensure that the current standard for certification to the electronic prescribing criterion supports use of the current Part D e-Rx and MH standards. This helps advance alignment with CMS’ program standards. In a final rule published April 16, 2018, CMS finalized its update of its Part D standards to NCPDP SCRIPT standard version 2017071 for e-Rx and MH, effective January 1, 2020 (83 FR 16440). In addition to continuing to reference the transactions previously included in § 170.315(b)(3), and in keeping with CMS’ final rule, we have adopted all of the additional NCPDP SCRIPT standard version 2017071 transactions that CMS adopted in 42 CFR 423.160(b)(2)(iv). Furthermore, we have adopted the same electronic Prior Authorization (ePA) request and response transactions supported by NCPDP SCRIPT standard 2017071 proposed by CMS in the Medicare Program; Secure Electronic Prior Authorization for Medicare Part D proposed rule (84 FR 28450). Some adopted transactions are required to demonstrate conformance to the updated § 170.315(b)(3) criterion, while other transactions are optional. c. Clinical Quality Measures—Report In this final rule, we have removed the Health Level 7 (HL7®) Quality Reporting Document Architecture (QRDA) standard requirements in the 2015 Edition ‘‘Clinical Quality Measures—report’’ criterion in § 170.315(c)(3) and, in their place, required Health IT Modules to support the CMS QRDA Implementation Guide (IGs).2 This will help reduce the burden for health IT developers and remove certification requirements that do not support quality reporting for CMS programs. 2 https://ecqi.healthit.gov/qrda-quality-reportingdocument-architecture. VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 d. Electronic Health Information (EHI) Export We proposed to adopt a new 2015 Edition certification criterion, referred to as ‘‘EHI export’’ in § 170.315(b)(10) in the Proposed Rule. The criterion’s proposed conformance requirements were intended to provide a means to export the entire EHI a certified health IT product produced and electronically managed to support two contexts: (1) Single patient EHI export and (2) for patient EHI export when a health care provider is switching health IT systems. The proposals did not require the exported data to be in a specific standardized format. Rather, we proposed to require that such an export be in a computable, electronic format made available via a publicly accessible hyperlink. We noted that this transparency would facilitate the subsequent interpretation and use of the exported information. We have finalized the criterion with modifications in response to public comment. We have refined the scope of data a Health IT Module certified to § 170.315(b)(10) must export, and aligned the criterion to the definition of EHI we finalized in § 170.102 and § 171.102. The finalized criterion requires a certified Health IT Module to electronically export all of the EHI, as defined in § 171.102, that can be stored at the time of certification by the product, of which the Health IT Module is a part. We finalized the 2015 Edition Cures Update ‘‘EHI export’’ criterion in § 170.315(b)(10) but did not finalize its inclusion in the 2015 Edition Base Electronic Health Record (EHR) definition, as proposed. Our intention with this criterion, in combination with other criteria set forth in this final rule, is to advance the interoperability of health IT as defined in section 4003 the Cures Act, including the ‘‘complete access, exchange, and use of all electronically accessible health information.’’ e. Application Programming Interfaces (APIs) We have adopted a new API certification criterion in § 170.315(g)(10) to replace the ‘‘application access—data category request’’ certification criterion (§ 170.315(g)(8)), and added it to the updated 2015 Edition Base EHR definition. This new ‘‘standardized API for patient and population services’’ certification criterion focuses on supporting two types of API-enabled services: (1) Services for which a single patient’s data is the focus and (2) services for which multiple patients’ PO 00000 Frm 00005 Fmt 4701 Sfmt 4700 25645 data are the focus. The API certification criterion requires the use of the Health Level 7 (HL7®) Fast Healthcare Interoperability Resources (FHIR®) standard Release 4 and references several standards and implementation specifications adopted in § 170.213 and § 170.215 to support standardization and interoperability. This certification criterion will align industry efforts around FHIR Release 4 and advance interoperability of API-enabled ‘‘read’’ services for single and multiple patients. f. Privacy and Security Transparency Attestations We have adopted two new privacy and security certification criteria requiring transparency attestations from developers of certified health IT as part of the updated 2015 Edition privacy and security certification framework. The attestations will serve to identify whether or not certified health IT supports encrypting authentication credentials and/or multi-factor authentication (MFA). While these criteria provide increased transparency, they do not require new development or implementation to take place. As part of ONC’s ongoing commitment to advance transparency about certified health IT products, ONC will list the developers’ attestation responses on the Certified Health IT Product List (CHPL). g. Security Tags and Consent Management In the 2015 Edition final rule (80 FR 62646, Oct. 16, 2015), we adopted two ‘‘data segmentation for privacy’’ (DS4P) certification criteria, one for creating a summary record according to the DS4P standard (§ 170.315(b)(7)) and one for receiving a summary record according to the DS4P standard (§ 170.315(b)(8)). Certification to these 2015 Edition DS4P criteria only required security tagging of Consolidated-Clinical Document Architecture (C–CDA) documents at the document level. As noted in the 2015 Edition final rule (80 FR 62646), certification to these criteria is not linked to meeting the Certified EHR Technology definition (CEHRT) used in CMS programs. Since the 2015 Edition final rule, the health care industry has engaged in additional field testing and implementation of the DS4P standard. Stakeholders also shared with ONC— through public forums, listening sessions, and correspondence—that only tagging C–CDA documents at the document level did not permit providers the flexibility to address more complex use cases for representing patient privacy preferences. Based on public comment, in this final rule, we E:\FR\FM\01MYR3.SGM 01MYR3 25646 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations have changed the names of the two current 2015 Edition DS4P criteria to Security tags—Summary of Care (send) and Security tags—Summary of Care (receive). We also updated the requirements for these criteria to support security tagging at the document, section, and entry levels. This change better reflects the purpose of these criteria and enables adopters to support a more granular approach to security tagging clinical documents for exchange. In finalizing this more granular approach for security tagging Consolidated Clinical Document Architecture (C–CDA) documents, we note that we do not specify rules or requirements for the disposition of tagged data or any requirements on health care providers related to data segmentation for privacy. The use cases for which health IT certified to these criteria might be implemented would be driven by other applicable Federal, State, local, or tribal law and are outside the scope of the certification criteria. We recognize that the tagging of documents is not a fully automated segmentation of the record but rather a first, technological step or tool to support health IT developers implementing technology solutions for health care providers to replace burdensome manual processes for tagging sensitive information. We also proposed to adopt a new 2015 Edition certification criterion, ‘‘consent management for APIs’’ in § 170.315(g)(11), to support data segmentation and consent management through an API in accordance with the Consent Implementation Guide (IG). However, in response to comments, we have chosen not to finalize our proposal for this criterion at this time. 3. Modifications to the ONC Health IT Certification Program In this final rule, we have finalized corrections to the 2015 Edition privacy and security certification framework (80 FR 62705) and relevant regulatory provisions. We also have finalized corrections to the relevant current Certification Companion Guides (CCGs). We have adopted new and revised Principles of Proper Conduct (PoPC) for ONC–ACBs. We have finalized clarification that the records retention provision includes the ‘‘life of the edition’’ as well as three years after the retirement of an edition related to the certification of Complete EHRs and Health IT Modules. We also have finalized revisions to the PoPC in § 170.523(h) to clarify the basis for certification, including to permit a certification decision to be based on an VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 evaluation conducted by the ONC–ACB for Health IT Modules’ compliance with certification criteria by use of conformity methods approved by the National Coordinator for Health Information Technology (National Coordinator). We also have finalized the addition of § 170.523(r) to require ONC– ACBs to accept test results from any ONC-Authorized Testing Laboratory (ONC–ATL) in good standing under the Program and compliant with the ISO/ IEC 17025 accreditation requirements consistent with the requirements set forth in §§ 170.520(b)(3) and 170.524(a). We believe these new and revised PoPC provide necessary clarifications for ONC–ACBs and promote stability among the ONC–ACBs. We also have finalized the update of § 170.523(k) to broaden the requirements beyond just the Medicare and Medicaid EHR Incentive Programs (now renamed the Promoting Interoperability (PI) Programs and referenced as such hereafter) and provided other necessary clarifications. We have finalized a revised PoPC for ONC–ATLs. The finalized revision clarifies that the records retention provision includes the ‘‘life of the edition’’ as well as three years after the retirement of an edition related to the certification of Complete EHRs and Health IT Modules. 4. Health IT for the Care Continuum Section 4001(b) of the Cures Act includes two provisions related to supporting health IT across the care continuum. The first instructs the National Coordinator to encourage, keep, or recognize through existing authorities the voluntary certification of health IT for use in medical specialties and sites of service where more technological advancement or integration is needed. The second outlines a provision related to the voluntary certification of health IT for use by pediatric health providers to support the health care of children. These provisions align closely with our core purpose to promote interoperability and to support care coordination, patient engagement, and health care quality improvement initiatives. Advancing health IT that promotes and supports patient care when and where it is needed continues to be a primary goal of the Program. This means health IT should support patient populations, specialized care, transitions of care, and practice settings across the care continuum. We have explored how we might work with the health IT industry and with specialty organizations to collaboratively develop and promote health IT that supports medical PO 00000 Frm 00006 Fmt 4701 Sfmt 4700 specialties and sites of service. Over time, we have taken steps to make the Program modular, more open and accessible to different types of health IT, and better able to advance functionality that is generally applicable to a variety of care and practice settings. We considered a wide range of factors specific to the provisions in the Cures Act to support providers of health care for children. These include: The evolution of health IT across the care continuum, the costs and benefits associated with health IT, the potential regulatory burden and compliance timelines, and the need to help advance health IT that benefits multiple medical specialties and sites of service involved in the care of children. In consideration of these factors, and to advance implementation of section 4001(b) of the Cures Act specific to pediatric care, we held a listening session where stakeholders could share their clinical knowledge and technical expertise in pediatric care and pediatric sites of service. Through the information learned at this listening session and our analysis of the health IT landscape for pediatric settings, we identified existing 2015 Edition criteria, as well as new or revised 2015 Edition criteria proposed in the Proposed Rule, that could benefit providers of pediatric care and pediatric settings. In this final rule, we have identified the already existing 2015 Edition certification criteria and the new or revised 2015 Edition criteria adopted in this final rule that support the voluntary certification of health IT for pediatric care and pediatric settings. We also elaborate on our next steps to support pediatric care and pediatric settings through the development, adoption, certification, and use of health IT, including the continued support of a pediatrics health IT web page on www.healthit.gov/pediatrics and the future development of informational resources. We also recognize the significance of the opioid epidemic confronting our nation and the importance of helping to support the health IT needs of health care providers committed to preventing inappropriate access to prescription opioids and to providing safe, appropriate treatment. Therefore, we requested public comment on how our existing Program requirements and the proposals in the Proposed Rule may support use cases related to Opioid Use Disorder (OUD) prevention and treatment and if there were additional areas that we should consider for effective implementation of health IT to help address OUD prevention and treatment. We received over 100 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations comments in responses to this RFI, which we are actively reviewing. 5. Conditions and Maintenance of Certification Requirements We have established in this final rule, certain Conditions and Maintenance of Certification requirements for health IT developers based on the Conditions and Maintenance of Certification requirements outlined in section 4002 of the Cures Act. The Program’s Conditions and Maintenance of Certification requirements express initial requirements for health IT developers and their certified Health IT Module(s) as well as ongoing requirements that must be met by both health IT developers and their certified Health IT Module(s) under the Program. In this regard, we have implemented the Cures Act Conditions of Certification requirements with further specificity as it applies to the Program and implemented any accompanying Maintenance of Certification requirements as standalone requirements to ensure that the Conditions of Certification requirements are not only met but continually being met through the Maintenance of Certification requirements. In this rule, we capitalize ‘‘Conditions of Certification’’ and ‘‘Maintenance of Certification’’ when referring to Conditions and Maintenance of Certification requirements established for the Program under section 4002 of the Cures Act for ease of reference and to distinguish from other conditions. Information Blocking Section 4002 of the Cures Act requires that a health IT developer, as a Condition and Maintenance of Certification requirement under the Program, not take any action that constitutes information blocking as defined in section 3022(a) of the Public Health Service Act (PHSA). We have adopted the information blocking Condition of Certification requirement in § 170.401 as proposed. As finalized, the Condition of Certification requirement prohibits any health IT developer under the Program from taking any action that constitutes information blocking as defined by section 3022(a) of the PHSA. We have also finalized that definition in § 171.103. Assurances Section 4002 of the Cures Act also requires that a health IT developer, as a Condition of Certification requirement under the Program, provide assurances to the Secretary that, unless for legitimate purpose(s) as specified by the VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 Secretary, the developer will not take any action that constitutes information blocking as defined in section 3022(a) of the PHSA or any other action that may inhibit the appropriate exchange, access, and use of EHI. We have finalized our proposed implementation of this provision through several Conditions of Certification and accompanying Maintenance of Certification requirements, which are set forth in § 170.402. We have also adopted more specific Conditions and Maintenance of Certification requirements, which are also set forth in § 170.402, for certified health IT developers to provide assurances to the Secretary that it does not take any other action that may inhibit the appropriate exchange, access, and use of EHI. These requirements serve to provide further clarity under the Program as to how health IT developers must meet our requirements as promulgated under the Cures Act. Communications The Cures Act also requires as a Condition and Maintenance of Certification requirement under the Program that health IT developers do not prohibit or restrict communications about certain aspects of the performance of health IT and the developers’ related business practices. We have finalized (in § 170.403) provisions that permit developers to impose certain types of limited prohibitions and restrictions that strike a balance between the need to promote open communication about health IT, and related developer business practices, with the need to protect the legitimate business interests of health IT developers and others. The provisions identify certain narrowlydefined types of communications, such as communications required by law, made to a government agency, or made to a defined category of safety organization, which will receive ‘‘unqualified protection’’ under our Program. Under this policy, developers will be prohibited from imposing any prohibitions or restrictions on such protected communications. Based on public comment received, we have also finalized provisions that allow health IT developers certified under the Program to place limitations on certain types of communications, including screenshots and video. We have adopted Maintenance of Certification requirements proposed in § 170.403(b) with modifications. A health IT developer must not impose or enforce any contractual requirement that contravenes the requirements of this Condition of Certification. Furthermore, if a health IT developer PO 00000 Frm 00007 Fmt 4701 Sfmt 4700 25647 has contracts/agreements in existence that contravene the requirements of this Condition of Certification, the developer must notify all affected customers, other persons, or entities that the prohibition or restriction within the contract/ agreement will not be enforced by the health IT developer. In response to comments, we have finalized in § 170.403(b)(2)(ii) that health IT developers are required to amend their contracts/agreements to remove or make void such provisions only when the contracts/agreements are next modified for other purposes and not within the proposed period of time from the effective date of this final rule. Application Programming Interfaces (APIs) As a Condition of Certification requirement in section 4002 of the Cures Act requires health IT developers to publish APIs that allow ‘‘health information from such technology to be accessed, exchanged, and used without special effort through the use of APIs or successor technology or standards, as provided for under applicable law.’’ The Cures Act’s API Condition of Certification requirement also states that a developer must, through an API, ‘‘provide access to all data elements of a patient’s electronic health record to the extent permissible under applicable privacy laws.’’ The Cures Act’s API Condition of Certification requirement in section 4002 includes several key phrases and requirements for health IT developers that go beyond the technical functionality of the Health IT Modules they present for certification. This final rule captures both the technical functionality and behaviors necessary to implement the Cures Act API Condition of Certification requirement. Specifically, we have adopted new standards, new implementation specifications, a new certification criterion, and have modified the Base EHR definition. In addition, we have finalized detailed Condition and Maintenance of Certification requirements for health IT developers. Real World Testing The Cures Act also added a new Condition and Maintenance of Certification requirement that health IT developers must successfully test the real world use of health IT for interoperability in the type(s) of setting(s) in which such technology would be marketed. This provision is critical to advancing transparency regarding Health IT Modules’ performance and to users having information that could be crucial to E:\FR\FM\01MYR3.SGM 01MYR3 25648 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations their decisions to acquire certified health IT. As discussed in section VII.B.5 of this final rule, we have established in § 170.405 real world testing Condition and Maintenance of Certification requirements that include Maintenance of Certification requirements to update Health IT Modules certified to certain certification criteria (see § 170.405(b)(3) through (7) and section IV.B of this final rule preamble) to ensure this certified technology meets its users’ needs for widespread and continued interoperability. As finalized, real world testing Condition and Maintenance of Certification requirements apply to health IT developers with one or more Health IT Module(s) certified to specific certification criteria focused on interoperability and data exchange that are listed in § 170.405(a), as discussed in section VII.B.5 of this final rule. Under these Condition and Maintenance of Certification requirements, health IT developers must submit publicly available annual real world testing plans as well as annual real world testing results for health IT certified to the criteria identified in § 170.405(a). We have also finalized a flexibility that we have named the Standards Version Advancement Process (SVAP). Under this flexibility, health IT developers will have the option to update their health IT that is certified to the criteria identified in § 170.405(a) to use more advanced version(s) of the adopted standard(s) or implementation specification(s) included in the criteria, provided such versions are approved by the National Coordinator for use in health IT certified under the Program. Similarly, we have finalized our proposal (84 FR 7497 through 7500) that health IT developers presenting health IT for initial certification to one of the criteria listed in § 170.405(a) would have the option to certify to National Coordinator-approved newer version(s) of one or more of the Secretary-adopted standards or implementation specifications applicable to the criterion. All health IT developers voluntarily opting to avail themselves of the SVAP flexibility must ensure that their annual real world testing plans and real world testing results submissions address all the versions of all the standards and implementation specifications to which each Health IT Module is certified. In addition, we have finalized in § 170.405(b)(8)(i) the requirement that health IT developers with existing certifications to criteria listed in § 170.405(a) who wish to avail themselves of the SVAP flexibility must notify both their ONC–ACB and their VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 affected customers of their plans to update their certified health IT, and the update’s anticipated impact on their existing certified health IT and customers, specifically including but not limited to whether, and if so for how long, the health IT developer intends to continue supporting the prior version(s) 3 of the standard(s) to which the Health IT Module has already been certified, in addition to the National Coordinator-approved newer version(s) included in a planned update. We have finalized our proposal (84 FR 7501) to establish in § 170.523(p) a new PoPC for ONC–ACBs that requires ONC–ACBs to review and confirm that each health IT developer with one or more Health IT Module(s) certified to any one or more of the criteria listed in § 170.405(a) submits real world testing plans and real world results on a timeframe that allows for the ONC–ACB to confirm completeness of all plans and results by applicable annual due dates. The specific annual due dates finalized in § 170.523(p) differ from those proposed as, and for the reasons, discussed in section VII.B.5 of this final rule preamble. Once completeness is confirmed, ONC–ACBs must make the plans available to ONC and the public via the Certified Health IT Product List (CHPL).4 We have also finalized, with clarifying revisions, the PoPC proposed in § 170.523(m) to require ONC–ACBs to aggregate and report to ONC no less than quarterly all updates successfully made to support National Coordinatorapproved newer versions of Secretaryadopted standards in certified health IT pursuant to the developers having voluntarily opted to avail themselves of the SVAP flexibility. We also finalize in § 170.523(t) the new PoPC for ONC– ACBs that requires them to ensure that developers seeking to take advantage of the SVAP flexibility provide the advance notice required in § 170.405(b)(8) to all affected customers and its ONC–ACB, and comply with all other applicable requirements. Attestations Section 4002(a) of the Cures Act requires that a health IT developer, as 3 In the near term, many of these prior versions are likely to be the same versions adopted by the Secretary and incorporated by reference in subpart B of 45 CFR part 170. Over time, however, we anticipate increasing frequency of prior versions certified including National Coordinator-approved newer versions of these Secretary-adopted standards. 4 Although real world testing plans and results will not be immediately available upon publication of this final rule, an overview of the CHPL is available at https://chpl.healthit.gov/#/resources/ overview (last accessed 07/12/2019). For additional information on how to navigate the CHPL, please refer to the CHPL Public User Guide. PO 00000 Frm 00008 Fmt 4701 Sfmt 4700 Condition and Maintenance of Certification requirements under the Program, provide to the Secretary an attestation to all of the other Conditions of Certification required in section 3001(c)(5)(D) of the PHSA, except for the ‘‘EHR reporting criteria submission’’ Condition of Certification requirement in § 3001(c)(5)(D)(vii). We have finalized regulation text implementing the Cures Act’s ‘‘attestations’’ Condition of Certification requirement in § 170.406. Under § 170.406 as finalized by this rule, health IT developers will attest twice a year to compliance with the Conditions and Maintenance of Certification requirements (except for the EHR reporting criteria submission requirement, which would be metrics reporting requirements separately implemented through a future rulemaking). We believe requiring attestations every six months under § 170.406(b) will properly balance the need to support appropriate enforcement with our desire to limit the burden on health IT developers. In this regard, we have also identified methods to make the process as simple and efficient for health IT developers as possible (e.g., 30-day attestation window, web-based form submissions, and attestation alert reminders). We have also finalized that attestations will be submitted to ONC– ACBs. We have finalized a new PoPC in § 170.523(q) that an ONC–ACB must review these submissions for completion and share the health IT developers’ attestations with us. We would then make the attestations publicly available through the CHPL. EHR Reporting Criteria Submission The Cures Act specifies that health IT developers be required, as Condition and Maintenance of Certification requirements under the Program, to submit reporting criteria on certified health IT in accordance with the EHR Reporting Program established under section 3009A of the PHSA, as added by the Cures Act. We have not yet established an EHR Reporting Program. Once we establish such program, we will undertake rulemaking to propose and implement the associated Condition and Maintenance of Certification requirements for health IT developers. Enforcement Section 4002(a) of the Cures Act adds (in section 3001(c)(5)(D) of the PHSA) Program requirements aimed at addressing health IT developers’ actions and business practices through the Conditions and Maintenance of Certification requirements, which expands the current focus of the E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations Program requirements beyond the certified health IT itself. Equally important, Cures Act section 4002(a) also provides that the Secretary may encourage compliance with the Conditions and Maintenance of Certification requirements and take action to discourage noncompliance. We, therefore, have finalized our proposed enforcement framework for the Conditions and Maintenance of Certification requirements in §§ 170.580 and 170.581 to encourage consistent compliance with the requirements. More specifically, we have finalized our proposed corrective action process in § 170.580 for ONC to review potential or known instances where a Condition or Maintenance of Certification requirement under the Program has not been met or is not being met by a health IT developer. We have also finalized in §§ 170.580 and 170.581 our proposal to utilize, with minor modifications, the processes previously established for ONC direct review of certified health IT in the enforcement of the Conditions and Maintenance of Certification requirements. Where we identify noncompliance, our first priority will be to work with the health IT developer to remedy the matter through a corrective action process. However, under certain circumstances, ONC may ban a health IT developer from the Program and/or terminate the certification of one or more of its Health IT Modules. 6. Information Blocking Section 4004 of the Cures Act added section 3022 of the PHSA (42 U.S.C. 300jj–52, ‘‘the information blocking provision’’). Section 3022(a)(1) of the PHSA defines practices that constitute information blocking when engaged in by a health care provider, or a health information technology developer, exchange, or network. Section 3022(a)(3) authorizes the Secretary to identify, through notice and comment rulemaking, reasonable and necessary activities that do not constitute information blocking for purposes of the definition set forth in section 3022(a)(1). We identify eight reasonable and necessary activities as exceptions to the information blocking definition, each of which does not constitute information blocking for purposes of section 3022(a)(1) of the PHSA. The exceptions apply to certain activities that are likely to interfere with, prevent, or materially discourage the access, exchange, or use of EHI, but that would be reasonable and necessary if certain conditions are met. In developing and finalizing the final exceptions, we were guided by three overarching policy considerations. First, VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 the exceptions are limited to certain activities that we believe are important to the successful functioning of the U.S. health care system, including promoting public confidence in health IT infrastructure by supporting the privacy and security of EHI, and protecting patient safety and promoting competition and innovation in health IT and its use to provide health care services to consumers. Second, each exception is intended to address a significant risk that regulated individuals and entities (i.e., health care providers, health IT developers of certified health IT, health information networks, and health information exchanges) will not engage in these reasonable and necessary activities because of potential uncertainty regarding whether they would be considered information blocking. Third, and last, each exception is intended to be tailored, through appropriate conditions, so that it is limited to the reasonable and necessary activities that it is designed to exempt. The eight exceptions are set forth in section VIII.D of this final rule. The five exceptions finalized in §§ 171.201–205, and discussed in section VIII.D.1.a–e of this final rule, involve not fulfilling requests to access, exchange, or use EHI. These exceptions are intended to prevent harm and protect patient safety, promote the privacy and security of EHI, excuse an actor from responding to requests that are infeasible, and address activities that are reasonable and necessary to promote the performance of health IT. The three exceptions finalized in §§ 171.301–303, and discussed in section VIII.D.2.a–c of this final rule, involve procedures for fulfilling requests to access, exchange, or use EHI. These exceptions describe when an actor’s practice of limiting the content of its response to or the manner in which it responds to a request to access, exchange, or use EHI will not be considered information blocking; when an actor’s practice of charging fees, including fees that result in a reasonable profit margin, for accessing, exchanging, or using EHI will not be considered information blocking; and when an actor’s practice to license interoperability elements for EHI to be accessed, exchanged, or used will not be considered information blocking. An actor will not be subject to enforcement actions under the information blocking provision for civil monetary penalties (CMP) or appropriate disincentives if the actor’s practice satisfies at least one exception. In order to satisfy an exception, each relevant practice by an actor at all relevant times must meet all of the PO 00000 Frm 00009 Fmt 4701 Sfmt 4700 25649 applicable conditions of the exception. However, failure to meet the conditions of an exception does not automatically mean a practice constitutes information blocking. A practice failing to meet all conditions of an exception only means that the practice would not have guaranteed protection from CMPs or appropriate disincentives. The practice would instead be evaluated on a caseby-case basis to assess the specific facts and circumstances (e.g., whether the practice would be considered to rise to the level of an interference, and whether the actor acted with the requisite intent) to determine whether information blocking has occurred. In addition to establishing the exceptions, we have defined and interpreted terms that are present in section 3022 of the PHSA (such as the types of individuals and entities covered by the information blocking provision). We have also finalized new terms and definitions that are necessary to implement the information blocking provision. We have codified the information blocking section in a new part of title 45 of the Code of Federal Regulations, part 171. C. Costs and Benefits Executive Orders 12866 on Regulatory Planning and Review (September 30, 1993), and 13563 on Improving Regulation and Regulatory Review (February 2, 2011), direct agencies to assess all costs and benefits of available regulatory alternatives and, if regulation is necessary, to select regulatory approaches that maximize net benefits (including potential economic, environmental, public health and safety effects, distributive impacts, and equity). A regulatory impact analysis (RIA) must be prepared for major rules with economically significant effects ($100 million or more in any one year). OMB has determined that this final rule is an economically significant rule as the costs associated with this final rule could be greater than $100 million per year. Accordingly, we have prepared an RIA that to the best of our ability presents the costs and benefits of this final rule. We have estimated the potential monetary costs and benefits of this final rule for health IT developers, health care providers, patients, ONC–ACBs, ONC–ATLs, and the Federal Government (i.e., ONC), and have broken those costs and benefits out into the following categories: (1) Deregulatory actions (no associated costs); (2) updates to the 2015 Edition health IT certification criteria; (3) Conditions and Maintenance of Certification requirements for a health E:\FR\FM\01MYR3.SGM 01MYR3 25650 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations IT developer; (4) oversight for the Conditions and Maintenance of Certification requirements; and (5) information blocking. We note that we have rounded all estimates to the nearest dollar and all estimates are expressed in 2017 dollars as it is the most recent data available to address all cost and benefit estimates consistently. We also note that we did not have adequate data to quantify some of the costs and benefits within this RIA. In those situations, we have described the non-quantified costs and benefits of our provisions; however, such costs and benefits have not been accounted for in the monetary cost and benefit totals below. We estimated that the total cost for this final rule for the first year after it is finalized (including one-time costs), based on the cost estimates outlined above and throughout this RIA, would, on average, range from $953 million to $2.6 billion with an average annual cost of $1.8 billion. We estimate that the total perpetual cost for this final rule (starting in year two), based on the cost estimates outlined above, would, on average, range from $366 million to $1.3 billion with an average annual cost of $840 million. We estimated the total annual benefit for this final rule, based on the benefit estimates outlined above, would range from $1.2 billion to $5.0 billion with primary estimated annual benefit of $3.1 billion. II. Background A. Statutory Basis The Health Information Technology for Economic and Clinical Health (HITECH) Act, Title XIII of Division A and Title IV of Division B of the American Recovery and Reinvestment Act of 2009 (the Recovery Act) (Pub. L. 111–5), was enacted on February 17, 2009. The HITECH Act amended the Public Health Service Act (PHSA) and created ‘‘Title XXX—Health Information Technology and Quality’’ (Title XXX) to improve health care quality, safety, and efficiency through the promotion of health IT and electronic health information (EHI) exchange. The 21st Century Cures Act (hereinafter the ‘‘Cures Act’’) was enacted on December 13, 2016, to accelerate the discovery, development, and delivery of 21st century cures, and for other purposes. The Cures Act, Pub. L. 114–255, included Title IV—Delivery, which amended portions of the HITECH Act (Title XIII of Division A of Pub. L. 111–5) by modifying or adding certain provisions to the PHSA relating to health IT. VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 1. Standards, Implementation Specifications, and Certification Criteria The HITECH Act established two new Federal advisory committees, the HIT Policy Committee (HITPC) and the HIT Standards Committee (HITSC). Each was responsible for advising the National Coordinator for Health Information Technology (National Coordinator) on different aspects of standards, implementation specifications, and certification criteria. Section 3002 of the PHSA, as amended by section 4003(e) of the Cures Act, replaced the HITPC and HITSC with one committee, the Health Information Technology Advisory Committee (HIT Advisory Committee or HITAC). After that change, section 3002(a) of the PHSA established that the HITAC would advise and recommend to the National Coordinator on different aspects of standards, implementation specifications, and certification criteria, relating to the implementation of a health IT infrastructure, nationally and locally, that advances the electronic access, exchange, and use of health information. Further described in section 3002(b)(1)(A) of the PHSA, this included providing the National Coordinator with recommendations on a policy framework to advance interoperable health IT infrastructure, updating recommendations to the policy framework, and making new recommendations, as appropriate. Section 3002(b)(2)(A) identified that in general, the HITAC would recommend to the National Coordinator, for purposes of adoption under section 3004 of the PHSA, standards, implementation specifications, and certification criteria and an order of priority for the development, harmonization, and recognition of such standards, specifications, and certification criteria. Similar to the process previously required of the former HITPC and HITSC, the HITAC will develop a schedule for the assessment of policy recommendations for the Secretary to publish in the Federal Register. Section 3004 of the PHSA identifies a process for the adoption of health IT standards, implementation specifications, and certification criteria and authorizes the Secretary to adopt such standards, implementation specifications, and certification criteria. As specified in section 3004(a)(1), the Secretary is required, in consultation with representatives of other relevant Federal agencies, to jointly review standards, implementation specifications, and certification criteria endorsed by the National Coordinator PO 00000 Frm 00010 Fmt 4701 Sfmt 4700 under section 3001(c), and subsequently determine whether to propose the adoption of any grouping of such standards, implementation specifications, or certification criteria. The Secretary is required to publish all determinations in the Federal Register. Section 3004(b)(3) of the PHSA, which is titled Subsequent Standards Activity, provides that the Secretary shall adopt additional standards, implementation specifications, and certification criteria as necessary and consistent with the schedule published by the HITAC. We consider this provision in the broader context of the HITECH Act and Cures Act to continue to grant the Secretary the authority and discretion to adopt standards, implementation specifications, and certification criteria that have been recommended by the HITAC and endorsed by the National Coordinator, as well as other appropriate and necessary health IT standards, implementation specifications, and certification criteria. 2. Health IT Certification Program(s) Under the HITECH Act, section 3001(c)(5) of the PHSA provides the National Coordinator with the authority to establish a program or programs for the voluntary certification of health IT. Specifically, section 3001(c)(5)(A) specifies that the National Coordinator, in consultation with the Director of the National Institute of Standards and Technology (NIST), shall keep or recognize a program or programs for the voluntary certification of health IT that is in compliance with applicable certification criteria adopted under this subtitle (i.e., certification criteria adopted by the Secretary under section 3004 of the PHSA). The certification program(s) must also include, as appropriate, testing of the technology in accordance with section 13201(b) of the HITECH Act. Overall, section 13201(b) of the HITECH Act requires that with respect to the development of standards and implementation specifications, the Director of National Institute of Standards and Technology (NIST) shall support the establishment of a conformance testing infrastructure, including the development of technical test beds. The same HITECH Act provision (section 13201(b)) also indicates that the development of this conformance testing infrastructure may include a program to accredit independent, non-Federal laboratories to perform testing. Section 4001 of the Cures Act amended section 3001(c)(5) of the PHSA to instruct the National Coordinator to encourage, keep, or recognize, through E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations existing authorities, the voluntary certification of health IT under the program for use in medical specialties and sites of service for which no such technology is available or where more technological advancement or integration is needed. Section 3001(c)(5)(C)(iii) in particular identifies that the Secretary, in consultation with relevant stakeholders, shall make recommendations for the voluntary certification of health IT for use by pediatric health providers to support the care of children, as well as adopt certification criteria under section 3004 to support the voluntary certification of health IT for use by pediatric health providers. The Cures Act further amended section 3001(c)(5) of the PHSA by adding section 3001(c)(5)(D), which provides the Secretary with the authority to require, through notice and comment rulemaking, Conditions and Maintenance of Certification requirements for the Program. B. Regulatory History The Secretary issued an interim final rule with request for comments on January 13, 2010, (75 FR 2014), which adopted an initial set of standards, implementation specifications, and certification criteria. On March 10, 2010, we published a proposed rule (75 FR 11328) that proposed both a temporary and permanent certification program for the purposes of testing and certifying health IT. A final rule establishing the temporary certification program was published on June 24, 2010, (75 FR 36158), and a final rule establishing the permanent certification program was published on January 7, 2011, (76 FR 1262). We have issued multiple rulemakings since these initial rulemakings to update standards, implementation specifications, certification criteria, and the certification program, a history of which can be found in the October 16, 2015 final rule titled, ‘‘2015 Edition Health Information (Health IT) Certification Criteria, 2015 Edition Base Electronic Health Record (EHR) Definition, and ONC Health IT Certification Program Modifications’’ (80 FR 62602) (‘‘2015 Edition final rule’’). A final rule corrections and clarifications notice was published for the 2015 Edition final rule on December 11, 2015, (80 FR 76868), to correct preamble and regulatory text errors and clarify requirements of the Common Clinical Data Set (CCDS), the 2015 Edition privacy and security certification framework, and the mandatory disclosures for health IT developers. The 2015 Edition final rule established a new edition of VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 certification criteria (‘‘2015 Edition health IT certification criteria’’ or ‘‘2015 Edition’’) and a new 2015 Edition Base EHR definition. The 2015 Edition established the capabilities and specified the related standards and implementation specifications that CEHRT would need to include to, at a minimum, support the achievement of ‘‘meaningful use’’ by eligible clinicians, eligible hospitals, and critical access hospitals under the Medicare and Medicaid EHR Incentive Programs (EHR Incentive Programs) (now referred to as the Promoting Interoperability (PI) Programs) 5 when the 2015 Edition is required for use under these and other programs referencing the CEHRT definition. The 2015 Edition final rule also made changes to the ONC HIT Certification Program. The final rule adopted a proposal to change the Program’s name to the ‘‘ONC Health IT Certification Program’’ from the ONC HIT Certification Program, modified the Program to make it more accessible to other types of health IT beyond EHR technology and for health IT that supports care and practice settings beyond the ambulatory and inpatient settings, and adopted new and revised PoPC for ONC–ACBs. After issuing a proposed rule on March 2, 2016, (81 FR 11056), we published a final rule titled, ‘‘ONC Health IT Certification Program: Enhanced Oversight and Accountability’’ (81 FR 72404) (‘‘EOA final rule’’) on October 19, 2016. The EOA final rule finalized modifications and new requirements under the Program, including provisions related to our role in the Program. The final rule created a regulatory framework for our direct review of health IT certified under the Program, including, when necessary, requiring the correction of non-conformities found in health IT certified under the Program and suspending and terminating certifications issued to Complete EHRs and Health IT Modules. The final rule also sets forth processes for us to authorize and oversee accredited testing laboratories under the Program. In addition, it includes provisions for expanded public availability of certified health IT surveillance results. On March 4, 2019, the Secretary published a proposed rule titled, ‘‘21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program’’ (84 FR 7424) (‘‘Proposed Rule’’). The Proposed Rule proposed to implement certain provisions of the Cures Act that would 5 https://www.federalregister.gov/d/2018-16766/ p-4. PO 00000 Frm 00011 Fmt 4701 Sfmt 4700 25651 advance interoperability and support the access, exchange, and use of electronic health information and is the subject of this final rule. C. General Comments on the Proposed Rule Comments. Numerous commenters expressed support for the overall direction of the Proposed Rule. Numerous commenters also expressed support for the policy goals expressed in the Proposed Rule, including: Reduced health care costs; improved public health surveillance; improved care coordination, continuity of care, and shared access of data between patient and provider; improved quality and patient safety; increased cost and quality transparency; greater efficiencies; and better health outcomes for patients. A few commenters also commended our interest in ways to use health IT to address opioid use disorders. Many commenters also appreciated detailed context for the provisions in the Proposed Rule. Many commenters stated that the proposed provisions and standards will provide opportunities for innovation as well as increase the ability of health care providers to connect new tools and services to their systems. A number of commenters commended our responsiveness to the health care community, including patients, in drafting the rule. A few commenters suggested that the existing language in the rule should remain mostly unchanged as ONC drafts the final rule. Many commenters commended us for collaborating with public- and privatesector partners in developing the Proposed Rule. Specifically, some commenters expressed appreciation for our work with CMS and their companion Interoperability and Patient Access Proposed Rule. A number of commenters shared that they look forward to working with us and CMS as the health care industry progresses toward an interoperable system, making it easier for small independent practices and providers to move to value-based care. Response. We appreciate the support expressed by many commenters. This final rule maintains the direction of the Proposed Rule, and we too look forward to ongoing collaboration with public and private sector partners as we implement the provisions of this final rule. Comments. A few commenters recommended that the final rule include additional resources to assist with readability and ease of understanding. Response. We thank commenters for their feedback. As we did with the E:\FR\FM\01MYR3.SGM 01MYR3 25652 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations Proposed Rule, we are providing resources such as infographics, fact sheets, webinars, and other forms of educational materials and outreach. Many of the education materials can be found on www.HealthIT.gov/curesrule. Comments. Several commenters expressed the opinion that the use of EHRs—and health IT, more generally— has negatively affected the quality of health care delivery and that the Proposed Rule will exacerbate this issue. Some of these commenters stated that the need to input information into EHRs during office visits has resulted in clinicians spending less time communicating with patients, and some noted the impact of data entry on clinician burnout. A few commenters made a similar point that use of EHRs has reduced productivity and, as a result, increased health care spending. Response. We thank commenters for their feedback. We are aware of the challenges stakeholders have experienced in using EHRs and health IT more broadly. In the Cures Act, Congress identified the importance of easing regulatory and administrative burdens associated with the use of EHRs and health IT. Specifically, through section 4001(a) of the Cures Act, Congress directed the Department of Health and Human Services to establish a goal, develop a strategy, and provide recommendations to reduce EHR-related burdens that affect care delivery. To that end, on November 28, 2018, we, in partnership with CMS, released a draft Strategy on Reducing Regulatory and Administrative Burden Relating to the Use of Health IT and EHRs 6 for public comment. This draft strategy reflects input HHS received through several wide-reaching listening sessions, written input, and stakeholder outreach. We released the final report on February 21, 2020. Reflective of public comment, the final Strategy on Reducing Regulatory and Administrative Burdens Relating to the Use of Health IT and EHRs 7 targets burdens tied to regulatory and administrative requirements that HHS can directly impact through the rulemaking process. The report’s strategies, recommendations, and policy shifts aim to give clinicians more time to focus on what matters—caring for their patients. Based on stakeholder input, the final strategy outlines three overarching goals designed to reduce clinician burden: (1) Reduce the effort 6 https://www.healthit.gov/sites/default/files/ page/2018–11/Draft%20Strategy %20on%20Reducing%20Regulatory %20and%20Administrative %20Burden%20Relating.pdf. 7 https://www.healthit.gov/sites/default/files/ page/2020-02/BurdenReport_0.pdf. VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 and time required to record health information in EHRs for clinicians; (2) reduce the effort and time required to meet regulatory reporting requirements for clinicians, hospitals, and health care organizations; and (3) improve the functionality and intuitiveness (ease of use) of EHRs. In addition to the final strategy mentioned above, we refer readers to section III of this final rule, Deregulatory Actions for Previous Rulemakings, for more information on how we have worked to improve the Program with a focus on ways to reduce burden, offer flexibility to both health IT developers and providers, and support innovation. Comments. We received several comments from a variety of stakeholders to extend the 60-day comment period for the Proposed Rule, stating that due to the depth and complexity of the policies proposed, it would be critical for the public to have extended time to provide sufficient and thoughtful comments to advance shared goals and shape the interoperability landscape. Response. In response to stakeholder inquiries to extend the 60-day public comment period and based on the stated goals of the Proposed Rule to improve interoperability and patient access to health information for the purposes of promoting competition and better care, we extended the comment period for the Proposed Rule for an additional 30 days which ended on June 3, 2019. Comments. A number of commenters recommended delaying the final rule by issuing an Interim Final Rule (IFR) with comment. Commenters noted that many organizations are providing comments that include new information blocking exceptions and that we will not be able to incorporate such suggestions into the final rule without an opportunity for comment. Several commenters stated that an IFR was appropriate due to the significance and breadth of the Proposed Rule, as well the magnitude of changes proposed and that an IFR would allow for additional opportunity for stakeholder comment. Several commenters recommended that ONC consider issuing a Supplemental Notice of Proposed Rulemaking (SNPRM) to seek additional comments on the information blocking provisions. Some of these commenters stated that new definitions and terms introduced in the Proposed Rule need additional clarification and an SNPRM would enable ONC to propose such clarifications and seek feedback on modified proposals. Response. We recognize the importance of allowing enough time for comment given the breadth of the Proposed Rule and acknowledge the PO 00000 Frm 00012 Fmt 4701 Sfmt 4700 comments requesting the issuance of an IFR or a SNPRM. We believe that the advance posting of the Proposed Rule on the ONC website, the initial 60-day comment period, and the 30-day extension, provided adequate time for comment, especially given the large volume of comments received. As discussed in the information blocking section of the Proposed Rule (84 FR 7508), after hearing from stakeholders and based on our findings from our 2015 Report to Congress,8 we concluded that information blocking is a serious problem and recommended that Congress prohibit information blocking and provide penalties and enforcement mechanisms to deter these harmful practices. Congress responded by enacting the Cures Act on December 13, 2016, with many provisions specifying a need for swift implementation. It has been three years since the Cures Act was enacted and information blocking remains a serious concern. This final rule includes provisions that will address information blocking and cannot be further delayed. We have taken multiple actions to address some expressed concerns regarding the timing of the Conditions and Maintenance of Certification requirements as well as the comprehensiveness of the information blocking proposals. These actions include some burden reduction by removing certain certification criteria, narrowing the scope of certain certification criteria, and increasing the compliance timeline with criteria. For purposes of information blocking, we have established compliance date for 45 CFR part 171 that is six months, rather than sixty days, after the date this final rule publishes in the Federal Register. We have also focused the scope of EHI, and provided new and revised exceptions that are actionable and reduce burden. One of these new exceptions (see § 171.301(a) and section VIII.D.2.a of this final rule) includes a provision by which, until 24 months after this rule is published in the Federal Register, an actor’s conduct can satisfy the conditions of the Content and Manner Exception (§ 171.301) if they provide at least the content that is within the USCDI in response to a request for access, exchange, or use of EHI. Because of these reasons and those noted above, we decline to issue an IFR or SNPRM. Rather, we have issued this final rule to support interoperability, empower patient control of their health care, and instill competition in health care markets. 8 https://www.healthit.gov/sites/default/files/ reports/info_blocking_040915.pdf. E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations III. Deregulatory Actions for Previous Rulemakings A. Background 1. History of Burden Reduction and Regulatory Flexibility Since the inception of the ONC Health IT Certification Program (Program), we have aimed to implement and administer the Program in the least burdensome manner that supports our policy goals. Through the years, we have worked to improve the Program with a focus on ways to reduce burden, offer flexibility, and support innovation. This approach has been consistent with the principles of Executive Order (E.O.) 13563 on Improving Regulation and Regulatory Review (February 2, 2011), which instructs agencies to periodically review its existing significant regulations and ‘‘determine whether any such regulations should be modified, streamlined, expanded, or repealed so as to make the agency’s regulatory program more effective or less burdensome in achieving the regulatory objectives.’’ To that end, we have historically taken measures where feasible and appropriate to reduce burden within the Program and make the Program more effective, flexible, and streamlined. For example, in the 2014 Edition final rule (77 FR 54164, Sept. 4, 2012), we revised the certified electronic health record technology (CEHRT) definition to provide flexibility and create regulatory efficiencies by narrowing required functionality to a core set of capabilities (i.e., the Base EHR definition) plus the additional capabilities each eligible clinician, eligible hospital, and critical access hospital needed to successfully achieve the applicable objective and measures under the EHR Incentive Programs (now referred to as the Promoting Interoperability (PI) Programs). ONC has also supported more efficient testing and certification methods and reduced regulatory burden through the adoption of a gap certification policy. As explained in the 2014 Edition final rule (77 FR 54254) and the 2015 Edition final rule (80 FR 62681), as modified by the 2015 final rule with corrections and clarifications at 80 FR 76868, where applicable, gap certification allows for the use of a previously certified health IT product’s test results for certification criteria identified as unchanged. Developers have been able to use gap certification for more efficient certification of their health IT when updating from the 2011 Edition to the 2014 Edition and from the 2014 Edition to the 2015 Edition. VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 ONC introduced further means to reduce regulatory burden, increase regulatory flexibility, and promote innovation in the 2014 Edition Release 2 final rule (79 FR 54430) published on September 11, 2014. The 2014 Edition Release 2 final rule established a set of optional 2014 Edition certification criteria that provided flexibility and alternative certification pathways for health IT developers and providers based on their specific circumstances. The 2014 Edition Release 2 final rule also simplified the Program by discontinuing the use of the ‘‘Complete EHR’’ certification concept beginning with the 2015 Edition (79 FR 54443). In the 2015 Edition final rule, we did not ‘‘carry forward’’ certain 2014 Edition certification criteria into the 2015 Edition, such as the ‘‘image results,’’ ‘‘patient list creation,’’ and ‘‘electronic medication administration record’’ criteria. We determined that these criteria did not advance functionality or support interoperability (80 FR 62682 through 62684). We also did not require all health IT to be certified to the ‘‘meaningful use measurement’’ certification criteria for ‘‘automated numerator recording’’ and ‘‘automated measure calculation’’ (80 FR 62604 and 62605), which the 2014 Edition had previously required. Based on stakeholder feedback and Program administration observations, we also permitted testing efficiencies for the 2015 Edition ‘‘automated numerator recording’’ and ‘‘automated measure calculation’’ criteria by removing the live demonstration requirement of recording data and generating reports (80 FR 62703). Health IT developers may now self-test their Health IT Modules’ capabilities and submit the resulting reports to the ONC-Authorized Testing Laboratory (ONC–ATL) to verify compliance with the ‘‘meaningful use measurement’’ criterion.9 In order to further reduce burden for health IT developers, in our 2015 Edition final rule, we adopted a more straightforward approach to privacy and security certification requirements and clarified which requirements apply to each criterion within the regulatory functional areas (80 FR 62605). 2. Executive Orders 13771 and 13777 On January 30, 2017, the President issued E.O. 13771 on Reducing Regulation and Controlling Regulatory Costs, which requires agencies to identify deregulatory actions. This order 9 https://www.healthit.gov/test-method/ automated-numerator-recording and https:// www.healthit.gov/test-method/automated-measurecalculation. PO 00000 Frm 00013 Fmt 4701 Sfmt 4700 25653 was followed by E.O. 13777, titled ‘‘Enforcing the Regulatory Reform Agenda’’ (February 24, 2017). E.O. 13777 provides further direction on implementing regulatory reform by identifying a process by which agencies must review and evaluate existing regulations and make recommendations for repeal or simplification. In order to implement these regulatory reform initiatives and policies, ONC reviewed and evaluated existing regulations in the year leading to the issuance of the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program Proposed Rule (Proposed Rule) (84 FR 7424 through 7610). During our review, we sought to identify ways to further reduce administrative burden, to implement deregulatory actions through guidance, and to put forth deregulatory actions in this final rule that will reduce burden for health IT developer, providers, and other stakeholders. Prior to publishing the Proposed Rule, on August 21, 2017, ONC issued Relied Upon Software Program Guidance.10 Health IT developers are permitted to use ‘‘relied upon software’’ 11 to demonstrate compliance with certification criteria adopted at 45 CFR part 170, subpart C. Historically, in cases where a Health IT Module is paired with multiple ‘‘relied upon software’’ products for the same capability, health IT developers were required to demonstrate compliance for the same certification criterion with each of those ‘‘relied upon software’’ products in order for the products to be listed on the Certified Health IT Product List (CHPL). With the guidance issued on August 21, 2017, health IT developers could demonstrate compliance with only one ‘‘relied upon software’’ product for a criterion/ capability. Once the health IT developer demonstrates compliance with a minimum of one ‘‘relied upon software’’ product, the developer can have multiple, additional ‘‘relied upon software’’ products for the same criterion/capability listed on the CHPL (https://chpl.healthit.gov/). This approach reduces burden for health IT developers, ONC–ATLs, and ONCAuthorized Certification Bodies (ONC– ACBs). On September 21, 2017, ONC announced a deregulatory action to reduce the overall burden for testing 10 https://www.healthit.gov/sites/default/files/ relieduponsoftwareguidance.pdf. 11 ‘‘Relied upon’’ software is defined in the 2011 final rule establishing the permanent certification program (76 FR 1276). E:\FR\FM\01MYR3.SGM 01MYR3 25654 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations health IT to the 2015 Edition certification criteria.12 ONC reviewed the 2015 Edition test procedures and changed 30 of the 2015 Edition test procedures from requiring ONC–ATL evaluation to requiring only attestation by health IT developers that their product has capabilities conformant with those specified in the associated certification criterion/criteria.13 This deregulatory action reduced burden and costs program-wide, while still maintaining the Program’s high level of integrity and assurances. The total testing cost savings for health IT developers have been estimated between $8.34 and $9.26 million. ONC– ATLs also benefitted by having more time and resources to focus on toolbased testing (for interoperabilityoriented criteria) and being responsive to any retesting requirements that may arise from ONC–ACB surveillance activities. Health care providers and other users of certified health IT did not lose confidence in the Program because health IT developers were still required to meet certification criteria requirements and maintain their products’ conformance to the full scope of the associated criteria, including when implemented in the field and in production use. ONC and ONC–ACBs continue to conduct surveillance activities and respond to end-user complaints. B. Deregulatory Actions In the Proposed Rule, we proposed (84 FR 7434 through 7439) and sought comment on six specific deregulatory actions. Having considered the comments received on the proposals, which are summarized below, we have decided to finalize five of the six proposed deregulatory actions and not to finalize the proposal to recognize the FDA Software Precertification Pilot Program. We refer readers to section XIII (Regulatory Impact Analysis) of this final rule for a discussion of the estimated cost savings from these finalized deregulatory actions. 1. Removal of Randomized Surveillance Requirements ONC–ACBs are required under § 170.556 to conduct surveillance of certified health IT to ensure that health IT continues to conform with and function as required by the full scope of the certification requirements. Surveillance is categorized as either 12 https://www.healthit.gov/buzz-blog/healthitcertification/certification-program-updates-supportefficiency-reduce-burden/. 13 https://www.healthit.gov/sites/default/files/ policy/selfdeclarationapproachprogramguidance1704.pdf. VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 reactive surveillance (for example, complaint-based surveillance) or randomized surveillance. Previously finalized regulations in § 170.556(c)(2) required ONC–ACBs to proactively surveil two percent of the certificates they issue annually. As discussed in the Proposed Rule, in the time since the two percent randomized surveillance requirement was finalized, stakeholders had expressed concern that the benefits of in-the-field, randomized surveillance may not outweigh the time commitment required by providers, particularly if no non-conformities are found (84 FR 7434). We noted in the Proposed Rule that, in general, health care providers had expressed that reactive surveillance (e.g., surveillance based on user complaints) is a more logical and economical approach to surveillance. Consistent with our September 21, 2017, exercise of enforcement discretion on implementation of randomized surveillance by ONC–ACBs,14 we proposed in the Proposed Rule to eliminate certain regulatory randomized surveillance requirements (84 FR 7434). In the Proposed Rule, we specifically proposed to revise § 170.556(c) by changing the requirement that ONC– ACBs must conduct in-the-field, randomized surveillance to specify that ONC–ACBs may conduct in-the-field, randomized surveillance (84 FR 7434). We further proposed to remove § 170.556(c)(2), which specified that ONC–ACBs must conduct randomized surveillance for a minimum of two percent of certified health IT products per year. We also proposed to remove the requirements in § 170.556(c)(5) regarding the exclusion and exhaustion of selected locations for randomized surveillance. Additionally, we proposed to remove the requirements in § 170.556(c)(6) regarding the consecutive selection of certified health IT for randomized surveillance. As noted in the Proposed Rule, without these regulatory requirements, ONC– ACBs would still be required to perform reactive surveillance, and would be permitted to conduct randomized surveillance of their own accord, using the methodology identified by ONC with respect to scope (§ 170.556(c)(1)), selection method (§ 170.556(c)(3)), and the number and types of locations for in-the-field surveillance (§ 170.556(c)(4)). Comments. A substantial number of commenters supported removing the requirements for randomized surveillance. Many commenters 14 https://www.healthit.gov/sites/default/files/ ONC_Enforcement_Discretion_Randomized_ Surveillance_8-30-17.pdf. PO 00000 Frm 00014 Fmt 4701 Sfmt 4700 supported the proposal to revise § 170.556(c) by changing the requirement that ONC–ACBs must conduct in-the-field, randomized surveillance to specify that ONC–ACBs may conduct in-the-field, randomized surveillance, including the removal of § 170.556(c)(2). Commenters noted that since ONC–ACBs would still be required to perform reactive surveillance, and would be permitted to conduct randomized surveillance of their own accord, the regulatory requirement to conduct randomized surveillance on a specified portion of certified health IT would be unnecessary. Commenters supporting this proposal praised the deregulatory action as allowing more flexibility for ONC–ACBs. A number of commenters were generally supportive of the proposal and applied the caveat that if an ONC–ACB did voluntarily conduct randomized surveillance, they should not do so repeatedly on the same Health IT Module. These commenters indicated a preference that the requirements in § 170.556(c)(6) regarding the consecutive selection of certified health IT for randomized surveillance remain. Several commenters were supportive of removing randomized surveillance requirements and indicated they found this appropriate in view of the Conditions and Maintenance of Certification enhancements to the Program as directed by the Cures Act, while others noted that reactive surveillance may be more effective in surfacing and correcting nonconformities. A number of commenters did not support the proposal, with many expressing concerns that this could be or be perceived to be a reduction in oversight of developers or could reduce providers’ confidence that certified Health IT Modules would meet their needs. While a majority of commenters speaking to surveillance burdens on health care providers indicated the removal of mandatory randomized surveillance would, on the whole, reduce burden on health care providers, several expressed concerns about whether providers can discern when a product does not meet certification requirements or know where and how to report their concerns about their certified health IT’s conformance to Program requirements. A few commenters suggested that the increased emphasis on reactive surveillance (particularly in some commenters’ view because ONC is removing randomized surveillance requirements in advance of the full implementation of the EHR Reporting Program called for by section 4002 of E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations the Cures Act) indicates a need for additional guidance to help providers and particularly clinicians understand how to recognize and report potential non-conformities in the certified health IT they use. Response. We thank commenters for their input and reiterate our continued commitment to sustaining the integrity of our Program, including ensuring robust oversight of certified health IT products while avoiding unnecessary burdens on all program stakeholders. Having considered all comments received, in context of the totality of updates we proposed to the Program, we have concluded that the removal of the regulatory requirements for ONC–ACBs to conduct randomized surveillance is consistent with enhancing Program efficiency while maintaining its efficacy. We leave ONC–ACBs the option to conduct randomized surveillance as they determine necessary or appropriate to support continued conformance to Program requirements by Health IT Modules they have certified. We also note that ONC– ACBs that choose to conduct randomized surveillance will still be required to use the methodology identified by ONC with respect to scope (§ 170.556(c)(1)), selection method (§ 170.556(c)(3)), and the number and types of locations for in-the-field surveillance (§ 170.556(c)(4)). While we appreciate concerns that removal of requirements in § 170.556(c)(6) regarding the consecutive selection of certified health IT creates a potential that the same Health IT Module(s) could be selected for randomized surveillance in consecutive years, we are unaware of evidence suggesting that ONC–ACBs choosing to implement randomized surveillance would do so in a manner that would tend to erode its efficacy by over-sampling some products at the expense of under-sampling others. Rather than retain a regulatory provision intended to counterbalance a regulatory requirement for randomized surveillance of a required minimum percent of certified products each year, we believe it is more appropriate at this time to remove the restriction on consecutive selection of the same Health IT Module(s) or location(s) for randomized surveillance and monitor the results of this and other Program enhancements finalized in this rule for any indication that we may need to further adjust regulatory requirements in the future. We thank commenters for bringing to our attention that health care providers may be uncertain about how or where they can engage the ONC Health IT Certification Program for assistance VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 when the certified health IT they rely on is not performing its certified functions as they expect and their health IT developer is unresponsive or fails to resolve non-conformities with Program requirements. Reactive surveillance by ONC–ACBs, informed and focused by end-user complaints, has always been an essential component of the Program’s oversight and assurance of continued conformity of certified Health IT Modules when deployed in the field. While we encourage users to begin seeking troubleshooting and issue resolution support from the developer of their health IT—because the developer is often in the best position to act most promptly to resolve problems with their products’ performance—we also encourage the user to share their concerns with the ONC–ACB that certified the health IT in question when the developer has not addressed users’ concerns that their certified health IT is not performing as it is certified to perform. As we recognize that users may in some circumstances need, or for purposes potentially including but not limited to their own preferences may wish, to share their concerns about their certified health IT’s performance or other health IT matters directly with ONC, we invite health IT users and all other interested parties to share their health IT-related feedback or concerns with ONC through the Health IT Feedback Form on our HealthIT.gov website.15 Depending on the nature of a specific feedback message, we may contact the submitter for additional information and, in some instances, may share the information provided with other appropriate entities—such as but not limited to the ONC–ACBs who certify the products about which we receive feedback, as they are often in the best position to assess and respond to feedback expressing concerns about conformance of specific certified criteria used by Health IT Modules in production environments. All information submitted through the Health IT Feedback Form is carefully reviewed and helps us to improve our awareness and ability to address health IT-related issues and challenges. Also, we note for clarity that persons sharing health IT-related concerns with ONC via the Health IT Feedback Form have the option to remain anonymous and this option has been chosen by some submitters. However, we wish to note that anonymous submissions will prevent us from acquiring additional information to fully follow up on a matter if the submission does not 15 https://www.healthit.gov/form/healthitfeedback-form. PO 00000 Frm 00015 Fmt 4701 Sfmt 4700 25655 include sufficient detail on which to act. In general, submitters should provide as much detail as possible about the developer, product name, and version of the certified health IT as well as their specific concerns about the certified health IT’s performance. 2. Removal of the 2014 Edition From the Code of Federal Regulations In the March 4, 2019 Proposed Rule, we also proposed to remove the 2014 Edition from the Code of Federal Regulations (CFR), which includes standards and functionality now significantly outmoded (84 FR 7434). We noted that removal of the 2014 Edition would make the 2015 Edition the new baseline for health IT certification. The 2015 Edition, including the additional certification criteria, standards, and requirements adopted in this final rule, will better enable interoperability and the access, exchange, and use of electronic health information, as discussed in the Proposed Rule (84 FR 7434), and its adoption and implementation by providers is expected to yield the estimated costs savings described (84 FR 7563 and 7564) within the Regulatory Impact Analysis (section XIV) of the Proposed Rule and in the Regulatory Impact Analysis section (section XIII) of this final rule. To implement the removal of the 2014 Edition from the CFR, we proposed (84 FR 7434 and 7435) to remove the 2014 Edition certification criteria (§ 170.314) and related standards, terms, and requirements from the CFR. In regard to terms, we proposed to retire the 2014 Edition-related definitions found in § 170.102, including the ‘‘2014 Edition Base EHR,’’ ‘‘2014 Edition EHR certification criteria,’’ and ‘‘Complete EHR, 2014 Edition.’’ As explained in the 2015 Edition final rule (80 FR 62719), the ability to maintain Complete EHR certification is only permitted with health IT certified to the 2014 Edition certification criteria. Because this concept was discontinued for the 2015 Edition, we proposed (84 FR 7435) to remove § 170.545 and any references to Complete EHR from the regulation text in conjunction with the removal of the 2014 Edition. We also proposed (84 FR 7435) to remove references to the 2014 Edition from the Common Clinical Data Set (CCDS) definition and effectively replace it with a new governmentunique standard, the United States Core Data for Interoperability (USCDI). We proposed (84 FR 7435) to remove the standards and implementation specifications found in §§ 170.200, 170.202, 170.204, 170.205, 170.207, 170.210, and 170.299 that are only E:\FR\FM\01MYR3.SGM 01MYR3 25656 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations referenced in the 2014 Edition certification criteria. Adopted standards that are also referenced in the 2015 Edition would remain. Finally, we proposed (84 FR 7435) to remove requirements in § 170.550(f) and any other requirements in subpart E, §§ 170.500 through 170.599, which are specific to the 2014 Edition and do not apply to the 2015 Edition. As discussed in the Proposed Rule (84 FR 7435), in order to avoid regulatory conflicts, we took into consideration the final rule released by CMS on November 16, 2017, titled ‘‘Medicare Program; CY 2018 Updates to the Quality Payment Program; and Quality Payment Program: Extreme and Uncontrollable Circumstance Policy for the Transition Year’’ (82 FR 53568). This Quality Payment Program (QPP) final rule permits eligible clinicians to use EHR technology certified to either the 2014 or 2015 Edition certification criteria, or a combination of the two for the CY 2018 performance period. This QPP final rule also states that the 2015 Edition certified EHR technology (CEHRT) will be required starting with the CY 2019 QPP program year (82 FR 53671). Therefore, we proposed (84 FR 7435) the effective date of removal of the 2014 Edition certification criteria and related standards, terms, and requirements from the CFR would be the effective date of this final rule. Comments. The majority of the comments received supported removing the 2014 Edition certification criteria from the Code of Federal Regulations. Commenters supporting the removal noted that it will reduce confusion and acknowledges that standards and functionality in the 2014 Edition are now significantly outmoded. Some commenters requested the removal be delayed until the end of CY 2019. Response. We thank commenters for their support. We have finalized the removal of the 2014 Edition from the CFR as proposed, including making the removal effective as of the effective date of this final rule (60 days after the rule is published in the Federal Register). The 2015 Edition was the sole edition permitted to meet the CEHRT definition beginning in the CY 2019 program year. This final rule is published in CY 2020. Therefore, the removal is not in conflict with CMS’ regulatory requirements for QPP. To finalize removal of the 2014 Edition from the CFR, we have removed, effective as of the effective date of this final rule, the 2014 Edition certification criteria in § 170.314. We also finalized removal of terms and definitions specific to the 2014 Edition from § 170.102, including the ‘‘2014 Edition VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 Base EHR,’’ ‘‘2014 Edition EHR certification criteria,’’ and ‘‘Complete EHR, 2014 Edition’’ definitions. As explained in the 2015 Edition final rule (80 FR 62719), the ‘‘Complete EHR’’ concept was discontinued for the 2015 Edition. Therefore, in conjunction with the removal of the 2014 Edition, we also remove in this final rule § 170.545 and all other references to ‘‘Complete EHR’’ from the regulation text. Moreover, in finalizing the removal of the 2014 Edition from the CFR, we also finalize removal of the standards and implementation specifications found in §§ 170.200, 170.202, 170.204, 170.205, 170.207, 170.210, and 170.299 that are referenced only in the 2014 Edition certification criteria. Adopted standards that are also referenced in the 2015 Edition, as modified by this final rule, remain in the CFR. We also retained the CCDS definition in § 170.102 but removed the standards and implementation specifications that reference the 2014 Edition. Additionally, we finalized the removal of requirements in § 170.550(f) and any other requirements in subpart E, §§ 170.500 through 170.599, that are specific to the 2014 Edition and do not apply to the 2015 Edition. 3. Removal of the ONC-Approved Accreditor From the Program We proposed to remove the ONC–AA from the Program (84 FR 7435). The ONC–AA’s role is to accredit certification bodies for the Program and to oversee the ONC–ACBs. However, years of experience and changes with the Program have led ONC to conclude that, in many respects, the role of the ONC–AA to oversee ONC–ACBs is now duplicative of ONC’s oversight. More specifically, ONC’s experience with administering the Principles of Proper Conduct (PoPC) for ONC–ACBs as well as issuing necessary regulatory changes (e.g., ONC–ACB surveillance and reporting requirements in the 2015 Edition final rule) has demonstrated that ONC on its own has the capacity to provide the appropriate oversight of ONC–ACBs. Therefore, we believe removal of the ONC–AA will reduce the Program’s administrative complexity and burden. Comments. All but one commenter specifically addressing this proposal were in support of removing the ONC– AA. The one commenter opposed to the proposal stated concerns related to decoupling accreditation to ISO/IEC 17065 standards (an internationally recognized standard for bodies certifying products, processes, and services to provide assurance of compliance with specified requirements such as initial testing, PO 00000 Frm 00016 Fmt 4701 Sfmt 4700 inspection, and quality management systems) from specific assessment of a certification body’s ability to apply their accredited ISO/IEC 17065 capabilities to the Program’s certification scheme requirements. The commenter noted that this might place a greater burden on ONC staff than did the Program structure that included an ONC–AA. Finally, one of the commenters in support of removing the ONC–AA from the Program requested additional clarification about criteria and processes that will be used for accreditation of certification bodies following removal of the ONC–AA from the Program. Response. We thank all commenters for their thoughtful feedback. Upon consideration of all comments received on this proposal, we have finalized it as proposed. As noted in the preamble to the Proposed Rule (84 FR 7435), ONC’s experience with administering the PoPC for ONC–ACBs as well as issuing necessary regulatory changes (e.g., ONC–ACB surveillance and reporting requirements in the 2015 Edition final rule) has demonstrated that ONC on its own has the capacity to provide the appropriate oversight of ONC–ACBs. Therefore, we believe removal of the ONC–AA will reduce the Program’s administrative complexity and burden while maintaining its effectiveness. We anticipate providing updated information about ONC’s updated processes for approval and oversight of certification bodies through familiar mechanisms including but not necessarily limited to the HealthIT.gov website prior to the effective date of this final rule, and on an ongoing basis as needed or otherwise appropriate to ensure effective transparency about this aspect of the Program. To finalize this deregulatory action, we have removed the definition for ‘‘ONC-Approved Accreditor or ONC– AA’’ from § 170.502. We also removed §§ 170.501(c), 170.503, and 170.504 regarding requests for ONC–AA status, ONC–AA ongoing responsibilities, and reconsideration for requests for ONC– AA status. Regarding correspondence and communication with ONC, we have revised § 170.505 to remove specific references to the ‘‘ONC–AA’’ and ‘‘accreditation organizations requesting ONC–AA status.’’ We also have finalized our proposal to sunset the policies reflected in the final rule titled ‘‘Permanent Certification Program for Health Information Technology; Revisions to ONC-Approved Accreditor Processes’’ (76 FR 72636), and to remove § 170.575, which established a process for addressing instances where the ONC–AA engages in improper conduct or does not perform its E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations responsibilities under the Program. Because the regulations promulgated in this prior final rule relate solely to the role of the ONC–AA, we have finalized the removal of those requirements. Accordingly, we also revised the application process for ONC–ACB status in § 170.520(a)(3) to require documentation, with an appropriate scope, that confirms that the applicant has been accredited to ISO/IEC 17065 by any accreditation body that is a signatory to the Multilateral Recognition Arrangement (MLA) with the International Accreditation Forum (IAF), in place of the ONC–AA accreditation documentation requirements. Similarly, instead of requiring the ONC–AA to evaluate the conformance of ONC–ACBs to ISO/IEC 17065, we revise § 170.523(a) to simply require ONC–ACBs to maintain accreditation in good standing to ISO/ IEC 17065. This means that ONC–ACBs would need to continue to comply with ISO/IEC 17065 and requirements specific to the ONC Health IT Certification Program scheme. 4. Removal of Certain 2015 Edition Certification Criteria and Standards Having reviewed and analyzed the 2015 Edition, we proposed to remove certain certification criteria and standards as discussed in the Proposed Rule (84 FR 7435 through 7437) and below. We stated (84 FR 7435) that we believe the removal of these criteria and standards will reduce burden and costs for health IT developers and health care providers by eliminating the need to: Design and meet specific certification functionalities; prepare, test, and certify health IT in certain instances; adhere to associated reporting and disclosure requirements; maintain and update certifications for certified functionalities, and participate in routine surveillance (84 FR 7435). Although we did not expressly state it in the Proposed Rule preamble, the burdens and costs reduced by removal of certain criteria from the 2015 Edition would be those associated with the needs we discussed in the preamble (84 FR 7435) specifically in connection to the criteria we proposed to remove, which are those that had been set forth in § 170.315(a)(6), (7) and (8), (10) and (11), and (13), (b)(4) and (5), and (e)(2) (as the text of 45 CFR part 170 stood prior to this final rule). a. 2015 Edition Base EHR Definition Certification Criteria We proposed to remove certain certification criteria from the 2015 Edition that had been included in the 2015 Edition Base EHR definition. As VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 discussed in the preamble to the Proposed Rule (84 FR 7435), the removal of these criteria supports burden and cost reductions for health IT developers and health care providers by eliminating the need to: Design and meet these specific certification functionalities; prepare, test, and certify health IT in certain instances; adhere to associated reporting and disclosure requirements; maintain and update certifications for these specific certified functionalities; and participate in surveillance of health IT certified to these criteria and standards. i. Problem List We proposed to remove the 2015 Edition ‘‘problem list’’ certification criterion (§ 170.315(a)(6)) from the 2015 Edition (84 FR 7436). As we noted in the Proposed Rule, the functionality in this criterion was first adopted as a 2011 Edition certification criterion to support the associated meaningful use Stage 1 objective and measure for recording problem list information. This 2015 Edition ‘‘problem list’’ criterion functionally remains relatively the same as the 2011 Edition and has exactly the same functionality as the 2014 Edition ‘‘problem list’’ criterion. We proposed to remove this criterion because the criterion no longer supports the ‘‘recording’’ objective and measure of the CMS PI Programs as such objective and measure no longer exist.16 Additionally, we stated the functionality is sufficiently widespread among health care providers since it has been part of certification and the Certified EHR Technology definition since the 2011 Edition and has not substantively changed with the 2015 Edition. Furthermore, we stated in the Proposed Rule that the functionality is essential to clinical care and would be in EHR systems absent certification, particularly considering the limited certification requirements. Comments. A number of commenters expressed support for removing the ‘‘problem list’’ certification criterion from the 2015 Edition and ‘‘Base EHR’’ definition. Several of those expressing support for the removal of this criterion specifically noted that the inclusion of the same data elements in the USCDI should suffice to ensure continued ability of certified health IT to record and facilitate access and exchange of 16 By stating in the NPRM that the objective and measure no longer exist, we meant in the CMS PI (formerly EHR Incentive) Programs. The authority citation for this statement is the December 15, 2015 CMS Final Rule ‘‘Medicare and Medicaid Programs; Electronic Health Record Incentive Program-Stage 3 and Modifications to Meaningful Use in 2015 Through 2017’’ (80 FR 62761 and 62785). PO 00000 Frm 00017 Fmt 4701 Sfmt 4700 25657 these data. However, a few commenters expressed concern that removing this and other requirements would be a disincentive to maintain the functionality in the future, and some commenters expressed concern about ONC’s ability to continue to provide effective oversight and require correction if developers do not ensure the functionalities perform safely and effectively. Commenters stated that while many developers will still continue to support the functionalities proposed for removal, eliminating the certification requirement may allow for developers to provide a ‘‘strippeddown’’ product at a lower price point and, in absence of CEHRT definition to guide the providers, mislead independent and small providers into unwittingly acquiring certified health IT that does not fully meet their needs. Response. As discussed in the preamble to the Proposed Rule, a criterion specific to the ‘‘problem list’’ functionality was first adopted in the 2011 Edition, specifically to ensure support for the associated meaningful use Stage 1 objective and the measure for recording problem list information under the CMS PI Programs. The ‘‘recording’’ objective and measure is no longer a part of the CMS PI Programs. However, the functionality remains widespread among EHR systems used by health care providers. While this prevalence may be due in part to its inclusion in the Certified EHR Technology definition, without substantive changes, since the 2011 Edition, we believe the more significant reason that this functionality is widely available is because it is essential to clinical care, and therefore, that the market will and should drive its continued presence in EHR systems regardless of certification requirements. While we also appreciate the concerns of commenters about the need for health IT to support the accurate recording of patients’ problems and the standardsbased exchange of that information, we reiterate that the interoperabilityfocused criteria that will remain in the Base EHR definition and reference the USCDI will ensure that any system of certified health IT meeting the Base EHR definition is capable of using and exchanging data on a patient’s problems using content, format, and other standards applicable to each mode of exchange (e.g., standardized API and C– CDA). Moreover, these interoperabilityfocused criteria will be subject not only to the Program’s familiar initial certification testing and in-the-field reactive surveillance requirements but also to the new Condition and E:\FR\FM\01MYR3.SGM 01MYR3 25658 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations Maintenance of Certification requirements for developers to test annually their certified Health IT Modules’ interoperability performance in the types of real world settings for which they are sold. After consideration of all comments received, and for the reasons noted in the preamble to the Proposed Rule and above, we have finalized the removal of the ‘‘problem list’’ certification criterion (§ 170.315(a)(6)). We further note that upon the effective date of this final rule, the ‘‘problem list’’ certification criterion is removed from the 2015 Edition and the criterion will no longer be included in the 2015 Edition ‘‘safety-enhanced design’’ criterion. This criterion, in § 170.315(g)(3), specifies the usercentered design testing that must be applied to particular EHR functionality submitted for certification. However, in response to specific commenters’ concerns about the impact of removing the functionally-based problem list criterion on our ability to take action where developers may retain the functionality, but fail to ensure it does not pose a danger to patient safety or public health, we note that our responsibility, pursuant to section 3001(b) of the PHSA, includes ensuring certified health IT does not pose a risk to patient safety or public health, and is not limited to measuring the conformity of the health IT to specific certification criteria. As discussed in the ‘‘ONC Health IT Certification Program: Enhanced Oversight and Accountability’’ (EOA) rule which was proposed in 81 FR 11056, and finalized in 81 FR 72404 in 2016, ONC has the authority to address suspected or confirmed non-conformities to the requirements under the ONC Health IT Certification Program if the certified health IT is causing or contributing to serious risks to public health or safety (81 FR 72406). The EOA final rule established in § 170.580 a regulatory framework for ONC’s direct review of health IT certified under the Program, which expressly addresses the potential for ONC to initiate direct review if we have a reasonable belief that certified health IT may not conform to the requirements of the Program because the certified health IT may be causing or contributing to conditions that present a serious risk to public health or safety. With respect to health care providers’ selection of certified health IT products, we would encourage all providers to consider the Base EHR or Certified EHR Technology (CEHRT) definition as a useful starting point. Certain health care payment programs, including the CMS PI Programs, require the use of certified health IT. CMS refers to the minimum VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 set of required certification functionalities that the health IT used by eligible clinicians must have in order to qualify for the CMS incentive programs as CEHRT. Using certified health IT improves care coordination through the electronic exchange of clinical-care documents. It provides a baseline assurance that the technology will perform clinical-care and data-exchange functions in accordance with interoperability standards and user-centered design. ii. Medication List We proposed to remove the 2015 Edition ‘‘medication list’’ certification criterion (§ 170.315(a)(7)) (84 FR 7436). As we noted in the Proposed Rule, the 2015 Edition ‘‘medication list’’ criterion remains functionally the same as the 2011 Edition and 2014 Edition ‘‘medication list’’ criteria. As also discussed in the Proposed Rule, a functionally-based ‘‘medication list’’ criterion was first adopted as a 2011 Edition certification criterion to support the associated meaningful use Stage 1 objective and measure for recording medication list information. The ‘‘medication list’’ criterion that we proposed to remove does not require use of a specific vocabulary standard to record medications. Comments. Comments on the proposal to remove the ‘‘medication list’’ criterion were somewhat mixed. While a number of comments expressed support for the removal of the ‘‘medication list’’ criterion from the 2015 Edition as duplicative of medication data included in the USCDI a number of commenters expressed concerns with, and a few commenters indicated opposition to, the removal of the ‘‘medication list’’ criterion. A few commenters raised concerns specific to elimination of the ‘‘medication list’’ criterion in view of the need to respond to the opioids crisis. One commenter expressed concern in the context of both the medication list and the drugformulary and preferred drug lists criteria as to whether the removal of these criteria could potentially impact patients’ drug costs. Several comments also expressed the same concerns for eliminating the ‘‘medication list’’ that were expressed in regard to removal of the ‘‘problem list’’ criterion, which are summarized above, regarding whether developers will continue to include the functionality and maintain its safe performance. Response. We thank commenters for their input. Upon consideration of all comments received on this proposal, we have finalized the removal of the ‘‘medication list’’ criterion PO 00000 Frm 00018 Fmt 4701 Sfmt 4700 (§ 170.315(a)(7)). The ‘‘recording’’ objective and measure of the CMS PI Programs that the ‘‘medication list’’ criterion was originally adopted to support has since been retired from the CMS Programs. However, the functionality remains widespread among EHR systems used by health care providers. While this prevalence may be due in part to its inclusion in the Certified EHR Technology definition since the 2011 Edition, we believe this functionality is widely available and used in more significant part because it is essential to clinical care and, therefore, the market will and should drive its continued presence in EHR systems regardless of certification requirements. While we also appreciate the concerns of commenters about the need for health IT to support clinicians’ ability to access, maintain, use, and exchange accurate and up-to-date information on their patients’ current medication lists and medication history, we repeat for clarity and emphasis that the interoperability-focused criteria that will remain in the Base EHR definition, and their inclusion of the USCDI, will ensure that any system of certified health IT meeting the Base EHR definition is capable of using and exchanging data on a patient’s medications using content, format, and other standards applicable to each mode of exchange (e.g., standardized API consistent with § 171.315(g)(10), or exchange of C–CDA documents using the transport standards and other protocols in § 171.202). We recognize the critical importance of providers’ and patients’ ability to have, use, and exchange medications information to avoid harms that can arise from interactions and duplications of therapeutic effects amongst newly prescribed drugs and those the patient may already be taking. While the clinical importance of maintaining and referencing current, reconciled medication lists is not limited to those medications with significant risks of misuse or dependency, we agree that it is highlighted by the urgent need to ensure opioids are prescribed and used only with due care when clinically necessary. We believe this clinical importance supports the expectation that the market will ensure this functionality is maintained and will drive innovations that improve its usability for the clinicians who use it in the course of caring for their patients. Moreover, the inclusion of medication information in interoperability-focused criteria in § 170.405(a) will ensure certified health IT can access, use, and exchange medications data according to E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations applicable content and formatting standards, which the ‘‘medication list’’ functionality did not ensure. This interoperability of the data is critical to reducing clinician burden related to manually entering updated drug lists and necessary to enable use of medication information by clinical decision support functionalities. The interoperability-focused criteria will also be subject not only to the Program’s familiar initial certification testing and in-the-field reactive surveillance requirements but also to the new Condition and Maintenance of Certification requirements for developers to test annually their certified Health IT Modules’ interoperability performance in the types of real world settings for which they are marketed. We note that once removed from the 2015 Edition, the criterion will no longer be included in the 2015 Edition ‘‘safety-enhanced design’’ criterion in § 170.315(g)(3). However, as noted above in context of the ‘‘problem list’’ criterion, ONC’s responsibility, pursuant to section 3001(b) of the PHSA, includes ensuring certified health IT does not pose a risk to patient safety or public health. Our responsibility for certified health IT and patient safety or public health is not limited to measuring the conformity of the health IT to specific certification criteria. As discussed in the EOA rule, ONC has the authority to address suspected or confirmed nonconformities to the requirements under the Health IT Certification Program if the certified health IT is causing or contributing to serious risks to public health or safety (81 FR 72406). The EOA final rule established in § 170.580 a regulatory framework for ONC’s direct review of health IT certified under the Program, which expressly addresses the potential for ONC to initiate direct review if we have a reasonable belief that certified health IT may not conform to the requirements of the Program because the certified health IT may be causing or contributing to conditions that present a serious risk to public health or safety. iii. Medication Allergy List We proposed to remove the 2015 Edition ‘‘medication allergy list’’ certification criterion (§ 170.315(a)(8)). The functionality in this criterion was first adopted as a 2011 Edition certification criterion to support the associated meaningful use Stage 1 objective and measure for recording medication allergies information. The criterion does not require use of a vocabulary standard to record VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 medication allergies, and does not directly support interoperability as the criterion does not require representation of medication allergies in standardized nomenclature. The criterion no longer supports a ‘‘recording’’ objective and measure of the CMS PI Programs as such objective and measure no longer exist. This 2015 Edition ‘‘medication allergy list’’ criterion remains functionally the same as the 2011 Edition and 2014 Edition ‘‘medication allergy list’’ criteria. The functionality is essential to clinical care and would be in EHR systems absent certification. Comments. Comments on the proposed removal of the ‘‘medication allergy list’’ criterion were mixed, with several commenters supportive of the removal noting that the criterion would be redundant now that medication allergy data will be included in the USCDI. Commenters expressed concern with the removal of the criterion and questioned the ubiquity of the medication allergy list functionality and whether health IT developers would continue to support the functionality if not required by ONC regulations. Response. We thank commenters for their input. Upon consideration of all comments received on this proposal, we have finalized the removal of the ‘‘medication allergy list’’ certification criterion (§ 170.315(a)(8)). The ‘‘recording’’ objective and measure of the CMS PI Programs that this criterion was originally adopted to support has since been retired from the CMS Programs. However, the functionality remains widespread among EHR systems. While this prevalence may be due in part to its inclusion in the Certified EHR Technology definition since the 2011 Edition, its importance to clinical care suggests the market will drive ongoing availability and enhancement of this functionality over time. Furthermore, because medication allergies are included in the USCDI, all systems of certified health IT meeting the Base EHR definition will be required to be able to exchange and use medication allergy information according to applicable content and formatting standards, which the ‘‘medication allergies’’ criterion did not ensure. This interoperability is critical to reducing clinician burden related to manually entering updated drug lists and necessary to enable use of medication information by clinical decision support functionalities. We believe that requiring the interoperability of medication allergy information will facilitate innovation and improvement in health IT’s ability to meet clinicians’ and patients’ needs more than would the continuation of the PO 00000 Frm 00019 Fmt 4701 Sfmt 4700 25659 ‘‘medication allergies’’ functionallybased criterion. We note that once removed from the 2015 Edition, the ‘‘medication allergy list’’ criterion will also no longer be included in the 2015 Edition ‘‘safetyenhanced design’’ criterion. However, as noted in context of removed criteria above, ONC’s responsibility, pursuant to section 3001(b) of the PHSA includes ensuring certified health IT does not pose a risk to patient safety or public health. Our responsibility for certified health IT and patient safety or public health is not limited to measuring the conformity of the health IT to specific certification criteria. As discussed in the EOA rule, ONC has the authority to address suspected or confirmed nonconformities to the requirements under the Health IT Certification Program if the certified health IT is causing or contributing to serious risks to public health or safety (81 FR 72406). The EOA final rule established in § 170.580 a regulatory framework for ONC’s direct review of health IT certified under the Program, which expressly addresses the potential for ONC to initiate direct review if we have a reasonable belief that certified health IT may not conform to the requirements of the Program because the certified health IT may be causing or contributing to conditions that present a serious risk to public health or safety. iv. Smoking Status We proposed to remove the 2015 Edition ‘‘smoking status’’ criterion (§ 170.315(a)(11)), which would include removing it from the 2015 Edition Base EHR definition (84 FR 7436). We had previously adopted a 2015 Edition ‘‘smoking status’’ certification criterion that does not reference a standard. However, the CCDS definition, which we proposed to remove from regulation in favor of adopting the new USCDI standard, required smoking status to be coded in accordance with a standard value set of eight SNOMED CT® codes defined in § 170.207(h). As with other functionality that was included in 2014 Edition, we believe this functionality is now widespread. Further, smoking status data will continue to be required to be available for access and exchange via the USCDI. Comments. Comments on this proposal were mixed, with a number of commenters expressing support for the removal of ‘‘smoking status’’ criterion in the Program and several noting that it is not needed or duplicative in the context of Program requirements to support the USCDI. A few commenters stated concerns that eliminating the requirement would provide a E:\FR\FM\01MYR3.SGM 01MYR3 25660 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations disincentive for developers to maintain the function in the future. Several commenters expressing concerns about removal of this criterion noted its importance to patient care and to public health, raising points such as the use of smoking status as a key determinant to classify cases of some reportable conditions, such as carbon monoxide poisoning. Concerns raised by commenters opposed to removing smoking status data from providers’ EHR systems included potential for additional provider burden, such as that related to providing complete case reporting data and responding to public health requests for additional information on patient smoking status during case investigation processes. Response. We thank commenters for their input. Upon consideration of the comments, we have finalized the removal of the ‘‘smoking status’’ criterion (§ 170.315(a)(11)). While we continue to believe that accurate, up-todate information on a patient’s smoking status and history has significant clinical value, we believe that its importance to clinical care provides adequate motivation for the market to drive ongoing availability and enhancement of this functionality over time. Because smoking status information is included in the USCDI, all systems of certified health IT meeting the Base EHR definition will now be required to be able to exchange and use smoking status information according to applicable content and formatting standards. The ‘‘smoking status’’ recording functionality criterion we have removed did not ensure smoking status information was captured in a structured, interoperable manner and interoperability of this data is critical to reducing clinician burden related to maintaining complete, current smoking status information. It is also necessary to enable use of smoking status information by clinical decision support and public health reporting functionalities. We believe that interoperability and exchange of smoking status information through the interoperability-focused certification criteria that reference the USCDI standard will better facilitate innovation and improvement in health IT’s ability to meet clinicians’ and patients’ needs than would continuation of the ‘‘smoking status’’ functionally-based recording criterion. Removal of Specific USCDI Smoking Status Code Set Along with the ‘‘smoking status’’ criterion, we proposed to remove the requirement to code smoking status according to the eight smoking status VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 SNOMED CT® codes referenced in the value set adopted in § 170.207(h). These eight codes reflected an attempt to capture smoking status in a consistent manner. Stakeholder feedback indicated that these eight codes do not appropriately and accurately capture all clinically relevant patient smoking statuses. Accordingly, we proposed to no longer require use of only the specific eight SNOMED CT® codes for representing smoking status and remove the value set standard by deleting and reserving § 170.207(h). Comments. Comments specifically addressing this proposal were generally supportive of removing the specific value set of eight SNOMED CT® codes, though many also noted the importance of continuing to require health IT certified under the Program to retain the ability to include or access, exchange, and use appropriately standardized smoking status information. Several comments made specific suggestions related to broadening or revising the vocabulary standard requirements for smoking status information going forward. Other commenters suggested adding other forms of tobacco use, including smokeless and second hand, as well as e-cigarette (vaping) use. Response. We appreciate all commenters’ input and note that no comments received raised concerns that are not addressed by inclusion of smoking status information in the USCDI, which all interoperabilityfocused criteria within the 2015 Edition Base EHR definition, as revised through this final rule, reference. As is the case with patient problems, medications, and medication allergies, we believe having smoking status information available for standards-based exchange is an important facilitator of better care and more effective public health reporting with less data-related burden on clinicians and less need for follow-up by public health professionals to compensate for case reporting data that is incomplete or is not fully interoperable. As is the case with the other removed criteria that were focused on internal recording capabilities, we believe the market can, will, and should be the primary driver for the ongoing maintenance and enhancement of functionalities for end users to record or modify these data. Furthermore, the Program’s focus is more appropriately spent on ensuring that certified health IT supports interoperable access, use, and exchange of these data as the key facilitator for more coordinated patient care and for ongoing innovation and improvement in both provider- and patient-facing functionalities. Because comments on revisions or PO 00000 Frm 00020 Fmt 4701 Sfmt 4700 enhancements to smoking status data standardization moving forward are outside the scope of this section, we will not address them in specific detail here. However, we note that the USCDI v1 references as the standard for smoking status information SNOMED CT®, U.S. Edition.17 Having considered all comments received on this proposal, we have finalized the removal of the eight-code value set standard and removed and reserved § 170.207(h). b. Drug-Formulary and Preferred Drug List Checks We proposed to remove the 2015 Edition ‘‘drug-formulary and preferred drug list checks’’ criterion in § 170.315(a)(10). Comments. Some commenters expressed concern that this criterion’s removal could negatively impact prescribers’ ability to help their patients manage their prescription drug expenses. Although several commenters supported the removal of this criterion in principle, a number of comments expressed concerns about the effect of removal of the ‘‘drug-formulary and preferred drug list checks’’ and other criteria from the Program on health care providers’ ability to comply with CMS and State-specific regulatory requirements for successful participation in the Medicare Quality Payment Program (QPP), or the Medicare or Medicaid PI Programs. One commenter, noting that the DrugFormulary and Preferred Drug List Checks criterion is associated with the CMS e-prescribing objective measures that CMS has finalized for 2019 and subsequent performance years specifically, recommended coordination with CMS to ensure alignment across the policies maintained by these two components of HHS. Response. We thank commenters for their input. As discussed in the Proposed Rule (84 FR 7437), the 2015 Edition ‘‘drug-formulary and preferred drug list checks’’ criterion does call for functionality to check drug formulary and preferred drug lists, but does not require use of any specific interoperability standards. The 2015 Edition ‘‘drug-formulary and preferred drug list checks’’ criterion does not include functionality or advance interoperability beyond what was required by the 2014 Edition ‘‘drugformulary checks’’ criterion. While we 17 For more information on finalized policy regarding adoption of the USCDI standard, see section IV.B.1 of this final rule. USCDI v1 can be accessed freely and directly in its entirety at https:// www.healthit.gov/isa/sites/isa/files/inline-files/ USCDIv12019revised2.pdf. E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations believe this functionality is fairly ubiquitous now due in part to the widespread adoption of health IT certified to the 2014 Edition, we do not believe it is necessary to continue to require certification to it under the Program in order to ensure it remains widely available. Instead, we believe, prescribers’ and patients’ interest in assuring patients can get the medications they need at the best available value will provide adequate motivation for the market to drive ongoing availability and enhancement of this functionality over time, including through increasing use of relevant interoperability standards essential to making this functionality more affordable and seamlessly reliable at scale than is feasible in the absence of interoperability driven by ubiquitous use of open standards. Because the ‘‘drug-formulary and preferred drug list checks’’ criterion we proposed to remove does not require use of standards or directly drive interoperability, we do not believe its continued inclusion in the Program would provide sufficient value to providers or patients to justify the burden on developers and providers of meeting Program compliance requirements specific to this criterion. We also recognize the importance of ensuring alignment between ONC Health IT Certification Program regulations and the CMS regulations that reference them. We have been and will continue to work in close partnership with our CMS colleagues to ensure that our regulations remain aligned, and that we provide affected stakeholders with the information they need to understand how the rules work together and how to succeed under CMS’ PI Programs using health IT certified under ONC’s Program. We, therefore, permit ONC–ACBs to issue certificates for this criterion up until January 1, 2022 to align with the requirements of the CMS Medicaid PI Program, as this criterion is associated with measures under the Medicaid program that will continue through 2021; after 2021 there will be no further incentives under the Medicaid Promoting Interoperability Program (84 FR 42592). We have not finalized our proposal to remove the criterion from the CFR but included a provision in § 170.550(m)(1) to only allow ONC– ACBs to issue certificates for this criterion until January 1, 2022. c. Patient-Specific Education Resources We proposed to remove the 2015 Edition ‘‘patient-specific education resources’’ certification criterion in § 170.315(a)(13) (84 FR 7437). We stated VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 that, based on the number of health IT products that have been certified for this functionality as part of 2014 Edition certification and already for 2015 Edition, we believe that health IT’s ability to identify appropriate patient education materials is widespread now among health IT developers and their customers (e.g., health care providers). We also noted that we have recently seen innovative advancements in this field, including the use of automation and algorithms to provide appropriate education materials to patients in a timely manner. These advancements help limit clinical workflow interruptions and demonstrate the use and promise of health IT to create efficiencies and improve patient care. As such, we stated that removal of this criterion would prevent certification from creating an unnecessary burden for developers and providers and an impediment to innovation. Comments. Some commenters expressed concern related to this functionality not yet being consistently used by all providers and to whether removal of this criterion may create a barrier to successful participation for providers in the Medicaid PI Program. One commenter noted that providers’ workflow changes to use this functionality are substantial and expressed concern related to providers potentially not undertaking such changes if the criteria were not required to be included in health IT and used by providers. Response. While we continue to recognize the importance of patient and provider interaction to promote positive health outcomes, we also believe that this criterion, narrowly focused on a specific functionality not connected to interoperability, is no longer the best way to encourage innovation and advancement in health IT’s ability to support clinician-patient interactions and relationships. Having reviewed all comments received on this proposal, we have decided not to remove the ‘‘patientspecific education resources’’ criterion from the Program at this time. We recognize the importance of ensuring alignment between ONC Health IT Certification Program regulations and the CMS regulations that reference them. We will continue to work in close partnership with our CMS colleagues to ensure that our regulations remain aligned and that we provide affected stakeholders with the information they need to understand how the rules work together and how to succeed under CMS incentive programs using health IT certified under ONC’s Program. CMS has identified this criterion as PO 00000 Frm 00021 Fmt 4701 Sfmt 4700 25661 supporting the patient electronic access to health information objective and measure, which is expected to remain operational for Medicaid until January 1, 2022; after 2021, there will be no further incentives under the Medicaid Promoting Interoperability Program (84 FR 42592). We, therefore, will permit ONC–ACBs to issue certificates for this criterion up until January 1, 2022, to align with the requirements of the CMS Medicaid PI Program (84 FR 42592). We have included a provision in § 170.550(m)(1) to only allow ONC– ACBs to issue certificates for this criterion until January 1, 2022. d. Common Clinical Data Set Summary Record—Create; and Common Clinical Data Set Summary Record—Receive As stated in the proposed rule (84 FR 7437), we assessed the number of products certified to the 2015 Edition ‘‘Common Clinical Data Set summary record—create’’ (§ 170.315(b)(4)) and ‘‘Common Clinical Data Set summary record—receive’’ (§ 170.315(b)(5)) criteria that have not also been certified to the 2015 Edition ‘‘transitions of care’’ criterion (§ 170.315(b)(1)) that also requires health IT be capable of creating and receiving Common Clinical Data Set (CCDS) Summary Records using the same interoperability standards. We explained that, based on our findings of only two unique products certified only to these criteria and not to the ‘‘transitions of care’’ criterion at the time of the drafting of the Proposed Rule, there appears to be little market demand for certification to 2015 Edition ‘‘Common Clinical Data Set summary record—create’’ (§ 170.315(b)(4)) and ‘‘Common Clinical Data Set summary record—receive’’ (§ 170.315(b)(5)) criteria alone. Therefore, we proposed to remove these certification criteria from the 2015 Edition. Comments. The comments we received on this proposal supported this removal. Response. We thank commenters for their support and have finalized removal of the 2015 Edition ‘‘Common Clinical Data Set summary record— create’’ (§ 170.315(b)(4)) and ‘‘Common Clinical Data Set summary record— receive’’ (§ 170.315(b)(5)) criteria. e. Secure Messaging We proposed to remove the 2015 Edition ‘‘secure messaging’’ criterion (§ 170.315(e)(2)). As explained in the Proposed Rule (84 FR 7437), ONC strongly supports patient and provider communication, as well as protecting the privacy and security of patient information, but no longer believes that a separate certification criterion focused E:\FR\FM\01MYR3.SGM 01MYR3 25662 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations on a health IT’s ability to send and receive secure messages between health care providers and patients is necessary. This criterion would also no longer be associated with an objective or measure under the CMS PI Programs based on proposals and determinations in recent CMS rulemakings (83 FR 41664; 83 FR 35929). Comments. Several comments specifically referencing this proposal were supportive of removing this criterion. A number of commenters expressed concern with the removal of the ‘‘secure messaging’’ criterion, including whether removal of this criterion may create a barrier to successful participation for providers in the CMS PI Programs. Other commenters expressed concerns about continued availability of secure digital endpoints for health care providers. Some commenters noted that some providers and patients might prefer to continue using ‘‘secure messaging’’ functionality in lieu of other options for a variety of purposes for which they currently use it, while others expressed concern that the separate ‘‘secure messaging’’ functionality will disappear from the market if no longer supported by ONC requirements. Commenters expressed that options for data access and exchange, such as portals and APIs, might satisfy providers’ and patients’ needs for interoperable communication. However, commenters expressed a concern that these options may not ensure continued availability to new market entrants’ health IT without requiring the technology to interact with developer- or system-specific interfaces. Response. We thank commenters for their input. Having reviewed all comments received on this proposal, we have decided not to remove the ‘‘secure messaging’’ criterion from the Program at this time. We recognize the importance of ensuring alignment between ONC Health IT Certification Program regulations and the CMS regulations that reference them. We will continue to work in close partnership with our CMS colleagues to ensure that our regulations remain aligned and that we provide affected stakeholders with the information they need to understand how the rules work together and how to succeed under CMS incentive programs using health IT certified under ONC’s Program. CMS has identified this criterion as supporting the coordination of care through patient engagement objective and measure, which is expected to remain operational for Medicaid until January 1, 2022; after 2021 there will be no further incentives under the Medicaid Promoting Interoperability Program (84 FR 42592). VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 We, therefore, will permit ONC–ACBs to issue certificates for this criterion up until January 1, 2022 to align with the requirements of the CMS Medicaid PI Program (84 FR 42592). We have included a provision in § 170.550(m)(1) to only allow ONC–ACBs to issue certificates for this criterion until January 1, 2022. Limiting certificates to this criterion for this period will help spur further innovations in patient engagement while helping to reduce regulatory burdens and costs for health IT developers and health care providers. The other 2015 Edition certification criteria that support patient engagement, such as the 2015 Edition ‘‘view, download, and transmit to 3rd party,’’ ‘‘API,’’ and ‘‘patient health information capture’’ certification criteria better support interoperability and innovation in patient engagement. We have seen developers integrate secure messaging functionality as part of other patient engagement features, such as patient portals, and integrate messaging with access to and exchange of clinical and administrative data. These integrated technologies currently in use offer more comprehensive options for providers and patients to interact and share information via a secure platform and may render the separate ‘‘secure messaging’’ criterion and functionality redundant to robust integrated options. We also believe removing the standalone ‘‘secure messaging’’ criterion will encourage the market to pursue other innovative means of offering patient engagement and interaction functionalities that providers and patients want, with the convenience and efficiency they demand. Thus, we believe that the removal of this criterion will help reduce burden and costs without negative impact on current or future innovations in patient engagement and secure information exchange. In response to the concern about new market entrants being able to receive data needed to serve their customers, we note that the ‘‘view, download, and transmit to 3rd party’’ criterion remains available for patients who wish to send their health information to a third party of the patient’s choice. Other remaining interoperability-focused criteria, such as ‘‘transitions of care,’’ ensure that systems of health IT certified to at least those criteria remaining in the ‘‘Base EHR’’ definition will remain capable of supporting providers’ use of new entrant and other third party health IT of their choosing without requiring that health IT to integrate or interface with their certified health IT. PO 00000 Frm 00022 Fmt 4701 Sfmt 4700 5. Removal of Certain ONC Health IT Certification Program Requirements We proposed to remove certain mandatory disclosure requirements and a related attestation requirement under the Program. As discussed in the Proposed Rule (84 FR 7437), we believe removal of these requirements will reduce costs and burden for Program stakeholders, particularly for health IT developers and ONC–ACBs. a. Limitations Disclosures We proposed to remove § 170.523(k)(1)(iii)(B), which requires ONC–ACBs to ensure that certified health IT includes a detailed description of all known material information concerning limitations that a user may encounter in the course of implementing and using the certified health IT, whether to meet ‘‘meaningful use’’ objectives and measures or to achieve any other use within the scope of the health IT’s certification. We proposed to remove § 170.523(k)(1)(iv)(B) and (C), which state that the types of information required to be disclosed include, but are not limited to: (B) Limitations, whether by contract or otherwise, on the use of any capability to which technology is certified for any purpose within the scope of the technology’s certification; or in connection with any data generated in the course of using any capability to which health IT is certified; (C) limitations, including but not limited to technical or practical limitations of technology or its capabilities, that could prevent or impair the successful implementation, configuration, customization, maintenance, support, or use of any capabilities to which technology is certified; or that could prevent or limit the use, exchange, or portability of any data generated in the course of using any capability to which technology is certified. Comments. Most of the comments specifically referencing this proposal were supportive. A few commenters raised concerns regarding the utility of mandatory disclosures to health care providers, their health information exchange partners, and ONC, with some commenters offering suggestions for how ONC could use disclosures information in the future. A few commenters’ concerns specifically referenced the disclosure of costs information. Response. We thank commenters for their input. We have finalized removal of § 170.523(k)(1)(iii)(B) and § 170.523(k)(1)(iv)(B) and (C), as proposed (84 FR 7437 and 7438). As E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations discussed in the Proposed Rule (84 FR 7438), these specific disclosure requirements are superseded by the Cures Act information blocking provision and Conditions of Certification requirements, which we proposed to implement in the same Proposed Rule (84 FR 7424). As also noted in the Proposed Rule (84 FR 7438), we proposed (84 FR 7465 and 7466) a complementary Condition of Certification requirement that developers would be prohibited from taking any action that could interfere with a user’s ability to access or use certified capabilities for any purpose within the scope of the technology’s certification discussed further in section VII.2. We also note here to ensure clarity that we did not propose, and have not finalized, a complete removal of the transparency requirements in § 170.523(k)(1). Requirements under § 170.523(k)(1) other than those specifically proposed for removal will remain in place. The transparency requirements remaining in place include: § 170.523(k)(1)(iii)(A), which describes the plain language detailed description of all known material information concerning additional types of costs that a user may be required to pay to implement or use the Complete EHR or Health IT Module’s capabilities, whether to meet meaningful use objectives and measures, or to achieve any other use within the scope of the health IT’s certification; and § 170.523(k)(1)(iv)(A) specification that the types of information required by § 170.523(k)(1)(iii) include, but are not limited to, 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. Transparency and Mandatory Disclosures Requirements We proposed to remove the Principle of Proper Conduct (PoPC) in § 170.523(k)(2), which requires ONC– ACBs to ensure health IT developers’ adherence to a requirement that the health IT developer submit an attestation that it will disclose all of the information in its mandatory VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 disclosures per § 170.523(k)(1) to specified parties (e.g., potential customers or anyone inquiring about a product quote or description of services). As discussed in the Proposed Rule (84 FR 7438), we believe this provision is no longer necessary and that its removal is appropriate to further reduce administrative burden for health IT developers and ONC–ACBs. Comments. The majority of commenters specifically discussing this proposal expressed support for the removal of the PoPC in § 170.523(k)(2). A few commenters expressed concern that the high degree of transparency ONC noted in the Proposed Rule might not be maintained as they noted a possibility that the PoPC requiring the ONC–ACBs to ensure the developers submitted an attestation, and, in turn, the developers’ obligation to make the attestation, may be driving the currently observed levels of transparency. Response. We thank commenters for their input. We have decided to finalize the removal of the PoPC in § 170.523(k)(2). We appreciate the importance of holding health IT developers accountable for meeting all requirements of participation in the Program, including meeting or exceeding the minimum required transparency disclosures. We believe that the needed transparency and accountability will be maintained and enhanced by certain Condition and Maintenance of Certification requirements we have finalized in this rule, which include the assurances and attestations specifically discussed in section VII.2 in relation to this proposed removal of § 170.523(k)(2). We believe that the removal of the PoPC requirements in § 170.523(k)(2) will likely aid in the avoidance of unnecessary costs and burden for Program stakeholders, particularly health IT developers and ONC–ACBs. 6. Recognition of Food and Drug Administration Processes Section 618 of the Food and Drug Administration Safety and Innovation Act (FDASIA), Public Law 112–144, required that the Food and Drug Administration (FDA), in consultation with ONC and the Federal Communications Commission (FCC) (collectively referred to as ‘‘the Agencies’’ 18 for this final rule), develop a report containing a proposed strategy and recommendations on an appropriate, risk-based regulatory framework pertaining to health IT, including mobile medical applications, 18 ONC is not an agency, but an office within the Department of Health and Human Services. PO 00000 Frm 00023 Fmt 4701 Sfmt 4700 25663 that promotes innovation, protects patient safety, and avoids regulatory duplication. The FDASIA Health IT Report of April 2014,19 contained a proposed strategy and recommendations on an appropriate, risk-based regulatory framework pertaining to health IT that promotes innovation, protects patient safety, and avoids regulatory duplication. Public comments, received prior to the report’s publication and after,20 recommended that health IT developers/manufacturers apply a single process that satisfies the requirements of all agencies, and existing safety and quality-related processes, systems, and standards should be leveraged for patient safety in health IT. On July 27, 2017, FDA announced a voluntary Software Precertification Pilot Program as part of a broader Digital Health Innovation Action Plan.21 It was developed in order to create a tailored approach toward recognizing the unique characteristics of digital technology by looking first at the firm, rather than primarily at each product of the firm, as is currently done for traditional medical products. The FDA plans to explore whether and how pre-certified companies that have demonstrated a culture of quality, patient safety, and organizational excellence could bring certain types of digital health products to market either without FDA premarket review or with a more streamlined FDA premarket review. a. FDA Software Precertification Pilot Program We proposed (84 FR 7438 and 7439) to establish processes that would provide health IT developers that can document holding pre-certification under the FDA Software Precertification Pilot Program with exemptions to the ONC Health IT Certification Program’s requirements for testing and certification of its health IT to the 2015 Edition ‘‘quality management systems’’ criterion (§ 170.315(g)(4)) and the 2015 Edition ‘‘safety-enhanced design’’ criterion (§ 170.315(g)(3)), as these criteria are applicable to the health IT developer’s health IT presented for 19 https://www.fda.gov/downloads/AboutFDA/ CentersOffices/ OfficeofMedicalProductsandTobacco/CDRH/ CDRHReports/UCM391521.pdf. 20 https://www.federalregister.gov/documents/ 2013/05/30/2013-12817/food-and-drugadministration-safety-and-innovation-act-fdasiarequest-for-comments-on-the, https://blogs.fda.gov/ fdavoice/index.php/2014/04/fda-seeks-commenton-proposed-health-it-strategy-that-aims-topromote-innovation/ and https:// www.regulations.gov/document?D=FDA-2014-N0339-0001. 21 https://www.fda.gov/MedicalDevices/ DigitalHealth/DigitalHealthPreCertProgram/ Default.htm. E:\FR\FM\01MYR3.SGM 01MYR3 25664 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations certification. We also stated that such a ‘‘recognition’’ could, depending on the final framework of the FDA Software Precertification Pilot Program, be applicable to the functionally-based 2015 Edition ‘‘clinical’’ certification criteria (§ 170.315(a)). We noted in the Proposed Rule that the proposed ‘‘recognition’’ could also be appropriate to address any or all of the following functionally-based 2015 Edition criteria in the event their proposed removal were not finalized: ‘‘problem list’’ (§ 170.315(a)(6)), ‘‘medication list’’ (§ 170.315(a)(7)), ‘‘medication allergy list’’ (§ 170.315(a)(8)), ‘‘drug-formulary and preferred drug list checks’’ (§ 170.315(a)(10)),’’ and ‘‘smoking status’’ (§ 170.315(a)(11)). We noted (84 FR 7439) that despite proffered benefits including alignment with both EOs 13563 and 13771 regarding deregulatory, less burdensome, and more effective regulatory schemes and programs, and serving as a regulatory relief for those health IT developers qualifying as small businesses under the Regulatory Flexibility Act (84 FR 7587 and 7588), there may be reasons not to adopt such a ‘‘recognition’’ approach. We noted as examples of such reasons that stakeholders may not agree that the FDA Software Precertification Program sufficiently aligns with our Program, and that stakeholders may have operational concerns. Accordingly, we welcomed comments on these and other aspects of our proposed ‘‘recognition’’ approach, including the 2015 Edition certification criteria that should be eligible for ‘‘recognition.’’ Comments. The majority of commenters commended ONC’s efforts to recognize the FDA Software Precertification Program. However, most commenters expressed concerns that FDA’s program was not yet mature enough to assess the degree of alignment to the ONC Health IT Certification Program. Many commenters expressed concerns that the FDA Software Precertification Pilot Program focuses on development and business practices, with a potential for streamlining requirements for pre-market clearance of specific functionalities, while ONC’s certification Program focuses less on development practices and more on certification of individual software products as meeting Program-specified requirements for functionality and interoperability, including conformance with specific interoperability standards. Many of these commenters indicated that until the FDA program is more fully mature they would prefer to reserve judgment on how recognition could or should be structured to satisfy the needs VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 of ONC’s Program at lower burden on those developers for whom dual participation is a need or an appealing option. Several commenters noted potential for recognition of developers who achieve precertification status under the FDA’s program to streamline or offer them a low-burden option for satisfying certain requirements under ONC’s Program. However, several commenters urged that obtaining FDA precertification status should not be the only way a developer could satisfy any requirement under ONC’s Program, noting that a developer of one or more certified Health IT Modules that is newer to the market or simply smaller and not engaged in development of software subject to FDA regulation could find the FDA Software Precertification Program’s requirements a higher hurdle to entering or remaining in the ONC-certified health IT market sector than the ONC requirements the recognition might replace. Response. Considering commenters’ concerns and the maturity of the FDA Software Precertification Program— which remains in a pilot phase at the time this final rule is being drafted—we have decided not to finalize recognition of the FDA Software Precertification Program at this time. However, we anticipate continuing to consult and coordinate with our colleagues at FDA and to monitor the details and experience of the FDA Software Precertification Program as it continues to mature. We continue to believe that there may be potential for recognition of the FDA Software Precertification Program to contribute in the future to our ongoing goals of reducing burden and promoting innovation while maintaining or enhancing the assurance that the ONC Health IT Certification Program provides, but we have not finalized our proposal at this time. b. Development of Similar Independent Program Processes—Request for Information In the Proposed Rule (84 FR 7439), we included a request for information (RFI) related to the development of similar independent processes to those of the FDA Software Precertification Program for purposes of our Program. We received 21 comments on this RFI and appreciate the input provided by commenters. We will continue to consider whether to develop similar independent processes and whether this should be included in future rulemaking. PO 00000 Frm 00024 Fmt 4701 Sfmt 4700 IV. Updates to the 2015 Edition Certification Criteria In order to capture and share patient data efficiently, health care providers need health IT that store data in structured formats. Structured data allows health care providers to easily retrieve and transfer patient information, and use health IT in ways that can aid patient care. We proposed to update the 2015 Edition by adopting a limited set of revised and new 2015 Edition certification criteria, including new standards, to support these objectives. Some of these criteria and standards are included in the Certified EHR Technology (CEHRT) definition used for participation in HHS Programs, such as the Promoting Interoperability (PI) Programs (formerly the EHR Incentive Programs), some are required to be met for participation in the ONC Health IT Certification Program, and some, though beneficial, are unassociated with the CEHRT definition and not required for participation in any HHS program, including the ONC Health IT Certification Program (Program). Comments. We received a few comments in support of our approach to modify the 2015 Edition health IT certification criteria. One commenter commended ONC for proposing logical updates to the 2015 Edition certification criteria, rather than overhauling the Program or establishing a new edition of certification, stating iterative changes will provide stability and allow the industry to adapt to new market forces. Commenters stated that this incremental approach best serves the health care provider and health IT developer community. One commenter applauded ONC for proposing logical updates to the 2015 Edition health IT certification criteria and recommended that ONC continue to seek to maximize the impact of these certification changes and pursue all opportunities to simplify existing criteria. However, a number of commenters requested that ONC put forth a new edition and suggested varied approaches to a new edition. Commenters suggested that ONC clearly delineate the difference between the editions by creating a new naming convention for the updated criteria, such as a version number. Others recommended a 2020 Edition or the corresponding year in which this rule is effective. Still other commenters recommended the proposed updated 2015 Edition be renamed to the 2021 Edition instead of renamed with a Release 2 at end of the existing name. Some commenters identified the scope of the proposed E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations changes as the reason ONC should establish the updates as a new edition of certification criteria rather than simply updating the 2015 Edition. However, the majority of commenters recommending a new edition based their concern on the potential confusion among providers who purchase and use certified health IT resulting from different products available under the same label. Response. We thank commenters for their input on the tradeoffs associated with modifying the current 2015 Edition versus creating a new edition. We considered a variety of factors when we framed our proposals. First, we reviewed the scope of each proposed update and the cumulative scope of the proposals overall for health IT developers and sought to identify whether it would be more appropriate to require health IT developers participating in the Program to implement updates to Health IT Modules certified to the 2015 Edition or to test and certify health IT products to an entirely new edition of certification criteria. Second, we considered the impact that either approach would have on health care providers, including how such updated Health IT Modules or products certified to a new edition would be implemented by providers participating in CMS programs. We have considered the impact on health IT developers related to the scope of the individual updates as well as the cumulative scope of all updates to the 2015 Edition adopted in this final rule (see also section XIII Regulatory Impact Analysis). In this final rule, we have only adopted two new technical certification criteria in § 170.315(b)(10) and § 170.315(g)(10) to which health IT developers seeking to upgrade their products will need to present Health IT Modules for certification. Unlike the new criteria introduced in prior certification edition rulemakings, both of these new criteria are an expansion or modification of existing criteria within the 2015 Edition which are currently in use in certified health IT. The new criteria in § 170.315(b)(10) relates to the 2015 Edition criteria in § 170.315(b)(6) with an expansion of the data and a removal of the specificity for the standard requirement. The new Standardized API criteria in § 170.315(g)(10) relates to the 2015 Edition API criteria with an expansion of security requirements and the addition of applicable standards. For the remainder of the updated criteria, a developer would not be required to present a Health IT Module for certification in order to update a certified product in accordance with VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 this final rule. Instead, a health IT developer would update their certified Health IT Module, notify the ONC–ACB that they have done so, and make the update available their customers. Additionally, unlike prior certification edition rulemakings, the certification criteria updated to address compliance with the USCDI do not include new functionality nor do they require a complete redesign of Health IT Modules certified to such certification criteria. As noted in the Proposed Rule, the updates to the CCDS to create the USCDI were intentionally limited to a modest expansion that most health IT developers already supported, were already working toward, or should be capable of updating their health IT to support in a timely manner. Please see Table 1 for a list of all certification criteria changes. In consideration of the impact our approach would have on health care providers, we note that impact and potential burden for providers is of particular importance given that CY2019 was the first performance year where eligible clinicians (ECs), eligible hospitals, dual-eligible hospitals, and critical access hospitals (CAHs) participating in CMS programs— including the CMS Promoting Interoperability Program and the Quality Payment Program/Merit-based Incentive Payment System—were required to use health information technology certified to the 2015 Edition to meet the requirements of the CMS CEHRT definition. If we were to adopt a new edition of certification criteria, CMS programs would have to consider establishing a new CEHRT definition and a subsequent requirement for program participants who have only recently completed a full edition update to their technology used for program participation. Historically, with a new edition of certification criteria, health IT developers have packaged Health IT Modules certified to new, modified, and unchanged criteria into a wholly new certified product. Historical data indicates that these complete updates to the edition are particularly challenging for both health IT developers seeking certification and for health care providers as they place deadlines for a significant number of health IT developers to support and implement new products for a significant number of health care providers simultaneously. As a result, the burden of updating the technology is compounded for both health IT developers and health care providers. While ONC does not itself place any such requirements on health care providers, we believe the risk of PO 00000 Frm 00025 Fmt 4701 Sfmt 4700 25665 such significant burden must be considered in health IT policy decisions. Further, we believe the scope of the updates and the impact on health IT developers and health care providers must be considered in tandem— meaning that an entirely new edition should only be established when the scope of the updates is significant enough to warrant the impacts of implementation. When the scope of updates does not warrant implementation of an entirely new edition of certification criteria, we believe it is appropriate to update the existing criteria. For example the 2015 Edition included new criteria that were neither built upon nor updated to existing criteria in the 2014 Edition, which was significantly different than the 2011 Edition. In contrast, health IT developers have been able to employ regular or cyclical updates without modifying all Health IT Modules certified to unchanged criteria in order to implement updates to existing certification criteria such as the annual updates to CMS eCQMs or for changes made to public health reporting standards. In such cases, the changes may be implemented by health IT developers in the manner most appropriate for their product and their customers, such as through routine service and maintenance rather than a completely new implementation. In order to understand the impact these updates would have on participants in the CMS programs which reference them for use by program participants, we compare these updates to the current definition of CEHRT established by CMS at 42 CFR 495.4 for eligible hospitals, CAHs and Medicaid eligible professionals and at 42 CFR 414.1305 for eligible clinicians in MIPS. For 2019 and subsequent years, the CMS CEHRT definition specifies the use of EHR technology certified to 2015 Edition including technology that meets the 2015 Edition Base EHR definition in § 170.102, as well as other certified technology necessary to be a meaningful user. The updates finalized in this final rule impact both certification criteria included in the Base EHR definition as well as criteria required for applicable objectives and measures. Specifically, this final rule updates several criteria currently applicable for certified Health IT Modules used by CMS program participants for the CMS objectives and measures necessary to be a meaningful user, including: • Revisions to the electronic prescribing criterion in § 170.315(b)(3) to reference an updated e-prescribing standard; E:\FR\FM\01MYR3.SGM 01MYR3 25666 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations • Revisions relating to the drugformulary and preferred drug list checks criterion in § 170.315(a)(10) to include at 170.550(m)(1) to only allow ONC– ACBs to issue certificates for this criterion until January 1, 2022; • Replacement of the API criterion in § 170.315(g)(8) with a new API criterion in § 170.315(g)(10) referencing an API standard and related security standards; • Revisions to several criteria to reference the USCDI and implement other standards updates (see Table 1 for specifics); and • Revisions to § 170.315(c)(3), to update quality reporting standards. In general, health IT developers have 24 months from the publication date of the final rule to make technology certified to these updated criteria available to their customers, and during this time developers may continue supporting technology certified to the prior version of certification criteria for use by their customers. For providers participating in CMS programs, this means they can continue to use the certified technology they have available to them to support program participation and can work with their developers to implement any updates in a manner that best meets their needs. For the revisions to electronic prescribing criterion in § 170.315(b)(3) and to the quality reporting standards, in § 170.315(c)(3), the updates adopted for certified health IT align specifically with changes already required by CMS for use by health care providers. This means health IT developers are already implementing and supporting these updates. The implementation of these updates is driven by other requirements and so repackaging such updates in a new edition (or a new product) would create a redundancy and could have unintended cost burden on health care providers. For the updates to the criteria referencing the USCDI, as noted previously, we based the USCDI on the existing CCDS with modest expansion that most health IT developers already supported, were already working toward, or should be capable of updating their health IT to support in a timely manner. Finally, for the removal of the drug-formulary and preferred drug list checks in § 170.315(a)(10), we note that the removal from the Program has negligible impact on health care providers. First, as discussed in past CMS regulations related to the use of these functionalities by participants in CMS programs, health care providers have noted that while formulary checks are a promising approach, the utility of the specific functionality that is certified is not necessarily consistently applicable VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 for all prescriptions (80 FR 62833). Second, as it does not remove the product from the market, any providers who are using the current functionality may continue to use the technology for their purposes. For the replacement of the API criterion in § 170.315(g)(8) with a new Standardized API criterion in § 170.315(g)(10) referencing an API standard and related security standards, we reiterate that health IT developers have 24 months from the date of publication of this final rule to update their technology and make such available to their customers. The 2015 Edition final rule adopted an API criterion in § 170.315(g)(8) which was implemented by many health IT developers using the underlying standard adopted in this final rule for the Standardized API criterion in § 170.315(g)(10). This common use impacted our decision to adopt the standard in our update to the 2015 Edition (see also section VII.B.4.c Standardized API for Patient and Population Services). We, therefore, believe that both the scope of the updates and the potential impact on health IT developers and health care providers do not constitute sufficient justification for the potential burden associated with adopting an entirely new edition of certification criteria. Instead, we believe it is most reasonable and effective for these updates to be part of the existing 2015 Edition as modified in this final rule. We acknowledge the concerns of commenters who expressed the potential risk of confusion about the updates among their customers and how to best communicate that a product meets the updated version of a given certification criterion. We strongly encourage health IT developers to work with their customers to promote understanding of these updates. In addition, we have taken several mitigating steps. First, we revisited our proposed regulatory structure and revised it so that the structure more clearly reflects if a change is updating the previously adopted standard, or a more significant change to the criterion such as adding a new standard. This maintains the prior 2015 Edition regulatory structure for the majority of the updates except for § 170.315(b)(10) and (g)(10) as discussed previously, and establishes a more clear sense of scope. Second, in order to support effective communication of the updates, we are implementing a practical approach to facilitate transparency using the Certified Health IT Product List PO 00000 Frm 00026 Fmt 4701 Sfmt 4700 (CHPL),22 which is the tool that health care providers and the general public may use to identify the specific certification status of a product at any given time, to explore any certification actions for a product, and to obtain a CMS Certification ID for a product used when participating in CMS programs. While we retain the overall 2015 Edition title, we will distinguish the 2015 Edition certification criteria from the new or revised criteria adopted in this final rule by referring to the new or revised criteria as the 2015 Edition Cures Update on the CHPL for products that are certified. The CHPL will also differentiate to what standards the health IT will be certified and will allow health care providers to identify if and when a specific Health IT Module has been updated. This will help to eliminate some of the confusion among providers who are seeking to understand the certification and update the status of the product they are currently using. It can also be a resource for providers who may be making a new purchase of certified health IT to make an informed decision about which products support the most up to date available standards and functionality. We further note that, while in the past ONC has largely relied on creating a new edition to implement changes to certification criteria, in each case, those changes included some updates to existing criteria, but also criteria containing functionality and standards that were entirely new and did not build on the prior edition. In addition, the Cures Act set in motion a shift for the ONC Health IT Certification Program by including Conditions and Maintenance of Certification requirements which allowed for processes such as the Standards Version Advancement Process (SVAP) flexibility within real world testing, which allows better alignment to industry efforts for standards advancement while maintaining accountability. These new provisions help to remove barriers for standards development and version updates, which limit a health IT developer’s ability to provide individually relevant, timely, and innovative solutions to their clients. This change is consistent with our approach to adopt incremental updates in this final rule rather than to adopt a complete new edition of certification criteria. This final rule is the first time we have executed on the concept of Maintenance of Certification requirements for existing certificates, and we foresee the potential for future 22 ONC Certified Health IT Product List: https:// chpl.healthit.gov. E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations rulemakings to include incremental updates to certification criteria when such updates are appropriate. 25667 Please see Table 1 for a list of all certification criteria changes. TABLE 1—2015 EDITION CURES UPDATE Certification criteria Reference New/revised/ removed/timelimited certification Problem list .................. § 170.315(a)(6) ..... Removed .............. Medication list .............. § 170.315(a)(7) ..... Removed .............. Medication allergy list .. § 170.315(a)(8) ..... Removed .............. Drug Formulary and Preferred Drug List Checks. § 170.315(a)(10) ... Time-limited Certification. Smoking status ............ § 170.315(a)(11) ... Removed .............. Patient-specific Education Resource. § 170.315(a)(13) ... Time-limited Certification. Transitions of Care ...... § 170.315(b)(1) ..... Revised ................ Update to USCDI/C–CDA companion guide within 24 months after the publication date of final rule. Clinical information reconciliation and incorporation. Electronic prescribing .. § 170.315(b)(2) ..... Revised ................ § 170.315(b)(3) ..... Revised ................ § 170.315(b)(4) ..... Removed .............. Update to USCDI/C–CDA companion guide within 24 months after the publication date of final rule. Update standard within 24 months after the publication of final rule. Effective date of final rule (60 days after publication). § 170.315(b)(5) ..... Removed .............. Effective date of final rule (60 days after publication). § 170.315(b)(6) ..... Time-limited Certification. Security tags—summary of care—send. § 170.315(b)(7) ..... Revised ................ Security tags—summary of care—receive. Care plan ..................... § 170.315(b)(8) ..... Revised ................ § 170.315(b)(9) ..... Revised ................ EHI export .................... § 170.315(b)(10) ... New ...................... Clinical quality measures (CQMs)—report. Auditable events and tamper-resistance. Audit report(s) .............. § 170.315(c)(3) ..... Revised ................ § 170.315(d)(2) ..... Revised ................ § 170.315(d)(3) ..... Revised ................ Auditing actions on health information. Encrypt authentication credentials. § 170.315(d)(10) ... Revised ................ § 170.315(d)(12) ... New ...................... Multi-factor authentication (MFA). § 170.315(d)(13) ... New ...................... View, Download, and Transmit to 3rd Party. § 170.315(e)(1) ..... Revised ................ Secure Messaging ....... § 170.315(e)(2) ..... Time-limited Certification. ONC–ACBs may only issue certificates until 36 months after the publication date of the final rule. Document, section, and entry (data element) level; or Document level for the period until 24 months after publication date of final rule. Document, section, and entry (data element) level; or Document level for the period until 24 months after publication date of final rule. Update to C–CDA companion guide within 24 months after publication date of final rule. Update within 36 months of publication date of final rule. Effective date of final rule (60 days after publication). Update to new ASTM standard within 24 months after publication date of final rule. Update to new ASTM standard within 24 months after publication date of final rule. Update to new ASTM standard within 24 months after publication date of final rule. Effective date of final rule (60 days after publication) (New and updated certifications only). Effective date of final rule (60 days after publication) (New and updated certifications only). Update to USCDI/C–CDA companion guide within 24 months after publication date of final rule. ONC–ACBs only permitted to issue certificates for this criterion until January 1, 2022. Transmission to public health agencies— electronic case reporting. Consolidated CDA creation performance. § 170.315(f)(5) ...... Revised ................ Update to USCDI/C–CDA companion guide within 24 months after publication date of final rule. § 170.315(g)(6) ..... Revised ................ Application Access— Data Category Request. § 170.315(g)(8) ..... Time-limited Certification. Update to USCDI/C–CDA companion guide within 24 months after publication date of final rule. 24 months after publication date of final rule ... Common Clinical Data Set summary record—create. Common Clinical Data Set summary record—receive. Data Export .................. VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 2015 Edition cures update—timing Impact on CMS promoting interoperability (PI) programs Effective date of final rule (60 days after publication). Effective date of final rule (60 days after publication). Effective date of final rule (60 days after publication). ONC–ACBs only permitted to issue certificates for this criterion until January 1, 2022. Removed from 2015 Edition Base EHR definition. Removed from 2015 Edition Base EHR definition. Removed from 2015 Edition Base EHR definition. PI Measures: —e-Rx —-Query of PDMP Operational for Medicaid until January 1, 2022. Removed from 2015 Edition Base EHR definition. Operational for Medicaid until January 1, 2022 Supports Patient Electronic Access to Health Information Objective Measure. PI Measures: —Support Electronic Referral Loops by Sending Health Information —Support Electronic Referral Loops by Receiving and Incorporating Health Information. PI Measures: —Support Electronic Referral Loops by Receiving and Incorporating Health Information. PI Measures: —e-Prescribing. Effective date of final rule (60 days after publication). ONC–ACBs only permitted to issue certificates for this criterion until January 1, 2022. Frm 00027 Fmt 4701 Sfmt 4700 Removed from 2015 Edition Base EHR definition effective date of the final rule (60 days after publication). PI Programs. PI Measure: —Provide Patients Electronic Access to Their Health Information. Operational for Medicaid until January 1, 2022 Supports the Coordination of Care through Patient Engagement Objective. PI Measure: —Electronic Case Reporting. PI Measure: —Provide Patients Electronic Access to Their Health Information. E:\FR\FM\01MYR3.SGM 01MYR3 25668 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations TABLE 1—2015 EDITION CURES UPDATE—Continued Certification criteria Reference New/revised/ removed/timelimited certification Application Access—All Data Request. § 170.315(g)(9) ..... Revised ................ Standardized API for patient and population services. § 170.315(g)(10) ... New ...................... 2015 Edition cures update—timing Impact on CMS promoting interoperability (PI) programs Update to USCDI/C–CDA companion guide within 24 months after publication date of final rule. Update within 24 months of publication date of final rule. PI Measure: —Provide Patients Electronic Access to Their Health Information. Added to the 2015 Edition Base EHR definition. Note: The CHPL will be updated to indicate the standards utilized for new or revised certification criteria, as well as denote criteria removed from the Program. A. Standards and Implementation Specifications 1. National Technology Transfer and Advancement Act The National Technology Transfer and Advancement Act (NTTAA) of 1995 (15 U.S.C. 3701 et. seq.) and the Office of Management and Budget (OMB) Circular A–119 23 require the use of, wherever practical, technical standards that are developed or adopted by voluntary consensus standards bodies to carry out policy objectives or activities, with certain exceptions. The NTTAA and OMB Circular A–119 provide exceptions to electing only standards developed or adopted by voluntary consensus standards bodies, namely when doing so would be inconsistent with applicable law or otherwise impractical. Agencies have the discretion to decline the use of existing voluntary consensus standards if determined that such standards are inconsistent with applicable law or otherwise impractical, and instead use a government-unique standard or other standard. In addition to the consideration of voluntary consensus standards, the OMB Circular A–119 recognizes the contributions of standardization activities that take place outside of the voluntary consensus standards process. Therefore, in instances where use of voluntary consensus standards would be inconsistent with applicable law or otherwise impracticable, other standards should be considered that meet the agency’s regulatory, procurement or program needs, deliver favorable technical and economic outcomes, and are widely utilized in the marketplace. Comments. A couple of commenters stated that they do not support Federal programs’ use of the NTTAA voluntary consensus standards exceptions, and asked that the involved Federal programs continue to utilize consensusbased standards developed through 23 https://www.whitehouse.gov/sites/ whitehouse.gov/files/omb/circulars/A119/revised_ circular_a-119_as_of_1_22.pdf. VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 work done by organizations such as HL7®. They noted that such work incorporates public health inputs, and stated that it is critical for there to be sufficient discussion and consideration of all stakeholder concerns in adopting such critical technologies such as FHIR®. Response. We thank commenters for their feedback. We clarify that many of the standards we adopt in this final rule are developed and/or adopted by voluntary consensus standards bodies, except where we found that a government unique standard is more appropriate. We are aware of no voluntary consensus standards that could serve as an alternative for the following purposes in this final rule. In this final rule, we use voluntary consensus standards except for: • The standard adopted in § 170.213, the United States Core Data for Interoperability (USCDI), Version 1 (v1), is a hybrid of government unique policy (i.e., determining which data to include in the USCDI) and voluntary consensus standards (i.e., the vocabulary and code set standards attributed to USCDI data elements). We have placed time limitations on the predecessor to this standard, the Common Clinical Data Set (CCDS) definition, under this rule, and replaced it with the USCDI in all applicable criteria except for the data export criterion in § 170.315(b)(6), on which we have also placed a time limit. We refer readers to the ‘‘Revised and New 2015 Edition Criteria’’ in section IV.B of this preamble. • The standards adopted in § 170.205(h)(3) and (k)(3). We replaced the current HL7® QRDA standards with government unique standards, the CMS Implementation Guide for Quality Reporting Document Architecture: Category I; Hospital Quality Reporting; Implementation Guide for 2019, and the CMS Implementation Guide for Quality Reporting Document Architecture: Category III; Eligible Clinicians and Eligible Professionals Programs; Implementation Guide for 2019, that will more effectively support the associated certification criterion’s use case, which is reporting electronic PO 00000 Frm 00028 Fmt 4701 Sfmt 4700 clinical quality measure (eCQM) data to CMS. 2. Compliance With Adopted Standards and Implementation Specifications In accordance with Office of the Federal Register regulations related to ‘‘incorporation by reference,’’ 1 CFR part 51, which we follow when we adopt proposed standards and/or implementation specifications in a final rule, the entire standard or implementation specification document is deemed published in the Federal Register when incorporated by reference therein with the approval of the Director of the Federal Register. Once published, compliance with the standard and/or implementation specification includes the entire incorporated document, unless we specify otherwise. For example, for the HL7® FHIR U.S. Core Implementation Guide (IG) STU 3.1.0 adopted in this final rule (see section VII.B.4), health IT certified to certification criteria referencing this IG would need to demonstrate compliance with all mandatory elements and requirements of the IG. If an element of the IG is optional or permissive in any way, it would remain that way for testing and certification unless we specified otherwise in regulation. In such cases, the regulatory text would preempt the permissiveness of the IG. 3. ‘‘Reasonably Available’’ to Interested Parties The Office of the Federal Register has established requirements for materials (e.g., standards and implementation specifications) that agencies propose to incorporate by reference in the Code of Federal Regulations (79 FR 66267; 1 CFR 51.5(b)). To comply with these requirements, in section XI (‘‘Incorporation by Reference’’) of this preamble, we provide summaries of, and uniform resource locators (URLs) to, the standards and implementation specifications we have adopted and subsequently incorporate by reference in the Code of Federal Regulations. To note, we also provide relevant information about these standards and implementation specifications E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations throughout the relevant preamble policy discussions and regulation text sections of the final rule. B. Revised and New 2015 Edition Criteria 1. The United States Core Data for Interoperability Standard (USCDI) As we noted in the Proposed Rule, the initial focus of the Program was to support the Medicare and Medicaid EHR Incentive Programs (76 FR 1294) now referred to as the Promoting Interoperability (PI) Programs. As such, the 2014 Edition certification criteria mirrored those functions specified by the CMS PI Programs objectives and measures for providers demonstrating meaningful use (MU) of certified health IT. In order to improve efficiency and streamline the common data within our Program’s certification criteria, we created a single definition for all the required data that could be referenced for all applicable certification criteria. We created the term ‘‘Common MU Data Set’’ to encompass the common set of MU data types/elements (and associated vocabulary standards) for which certification would be required across several certification criteria (77 FR 54170). The 2015 Edition final rule modified the Program to make it open and accessible to more types of health IT, and health IT that supports various care and practice settings beyond those included in the CMS PI Programs (80 FR 62604). In comparison to the previous editions, the 2015 Edition focused on identifying health IT components necessary to establish an interoperable nationwide health information infrastructure, fostering innovation and opening new market opportunities, and allowing for more health care provider and patient choices in electronic health information access and exchange. In order to align with this approach, we made changes in the 2015 Edition final rule that resulted in updated vocabulary and content standards to improve and advance interoperability and health information exchange (80 FR 62604). The 2015 Edition final rule further expanded accessibility and availability of data exchanged by updating the definition of Base EHR in the 2015 Edition to include enhanced data export, transitions of care, and application programming interface (API) capabilities, all of which previously required that, at a minimum, the CCDS be available (80 FR 62602 through 62604). We further noted in the Proposed Rule (84 FR 7440) that the regulatory approach to using and referencing a VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 ‘‘definition’’ to identify electronic health information, for access, exchange and use, including associated vocabulary codes, has had its drawbacks. While ONC’s ‘‘CCDS’’ definition served its designed purpose (to reduce repetitive text in each of the certification criteria in which it is referenced), the term CCDS, and the data set it represents, also began to be used by outside organizations such as the Argonaut Project 24 for additional use cases beyond the C–CDA and ONC’s Health IT Certification Program. As these organizations identified the need to expand the content of the CCDS, the CCDS definition in regulation became a limitation to developing additional data access, exchange, and uses outside of ONC’s programs. As we move towards value-based care and the inclusion of Data Classes that go beyond clinical data, and as part of ONC’s continued efforts to evaluate the availability of a minimum baseline of Data Classes that must be commonly available for interoperable exchange, we acknowledge the need to change and improve our regulatory approach to the CCDS. Therefore, in order to advance interoperability by adopting new data and vocabulary codes sets that support data exchange, we proposed to remove the ‘‘Common Clinical Data Set’’ in § 170.315(b)(4) and § 170.315(b)(5), and its references throughout the 2015 Edition and replace it with the ‘‘United States Core Data for Interoperability’’ (USCDI) standard. This first version of USCDI will be designated ‘‘version 1 (v1).’’ The USCDI standard aims to achieve the goals set forth in the Cures Act by specifying a common set of data classes and elements that have been designed to improve data usage and interoperable data exchange. We proposed to adopt the USCDI v1 as a standard defined in § 170.102. Here, ‘‘Standard’’ is defined as a ‘‘technical, functional, or performance-based rule, condition, requirement, or specification that stipulates instructions, fields, codes, data, materials, characteristics, or actions.’’ The USCDI standard would be composed of Data Classes, which may be further delineated into groupings of specific Data Element(s). For example, ‘‘patient demographics’’ is a Data Class, and within that Data Class there is ‘‘patient name,’’ which is a Data Element. As noted in section IV.B.1.b, for the overall structure and organization of the USCDI, please consult www.healthIT.gov/USCDI. We noted in the Proposed Rule (84 FR 7441) that ONC intended to establish and follow a predictable, transparent, 24 https://argonautwiki.hl7.org/Main_Page. PO 00000 Frm 00029 Fmt 4701 Sfmt 4700 25669 and collaborative process to expand the USCDI, including providing stakeholders with the opportunity to comment on the USCDI’s expansion. We indicated that once the Secretary adopts the first version of the USCDI through rulemaking, which we proposed in § 170.213 in the Proposed Rule, health IT developers would be allowed to take advantage of the ‘‘Standards Version Advancement Process’’ (SVAP) flexibility. The SVAP (which we proposed in § 170.405(b) and which is discussed in section VII.B.5, below) would permit health IT developers to voluntarily implement and use a newer version of a Secretary-adopted standard such as the USCDI, subject to certain conditions including a requirement that the newer version is approved for use by the National Coordinator, and does not conflict with requirements under other applicable law. We received a number of comments regarding these proposals, which are outlined in the subsections below. Comments. We received broad support for the adoption of version 1 of the USCDI as a new standard defining critical health care data to promote interoperability. Some commenters from health plans, while supportive of patient and provider access to health care data, voiced concerns about health plans being required to make data available in the USCDI standard. Other commenters noted that USCDI v1 does not include data classes and elements that pertain to all health care settings, including public health, and would therefore not be broadly applicable to all health care settings. Response. We thank commenters for their support of the adoption of USCDI v1 as a standard. We wish to clarify that the adoption of version 1 of the USCDI as a standard for our Program is not specific to a setting of care, a health care specialty, or a specific category of health IT user. Nor is the USCDI specific to a particular content exchange standard (e.g., HL7 C–CDA, HL7 FHIR, HL7 V2, and NCPDP SCRIPT). Rather, it applies to the certification of health IT and certified health IT’s ability to send and receive the Data Elements defined by USCDI without requirements regarding functionality, user interface, or the use of those Data Elements in exchange. While some users may find few opportunities to exchange these Data Elements, many will exchange these Data Elements frequently, and we believe that all health care providers should have certified health IT that can provide them with a means to appropriately share and access the USCDI data set when exchanging data with other providers. Accordingly, we E:\FR\FM\01MYR3.SGM 01MYR3 25670 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations seek to clarify a point with respect to our proposal regarding the USCDI and health IT certification. For the purposes of the ONC Health IT Certification Program, specific certification criteria are the way the USCDI comes into effect. For example, the USCDI is referenced as part of the data requirements in the updated ‘‘transitions of care’’ certification criterion (§ 170.315(b)(1)), which also specifies that for certification to that criterion, the C–CDA must be used as the syntax to hold all of the USCDI data. As we explained, we believe that the adoption of USCDI v1 for all certified health IT will advance interoperability by ensuring utilization of common data and vocabulary code sets, and that standardization will support both electronic exchange and usability of the data. Furthermore, because ONC will establish and follow a predictable, transparent, and collaborative process to expand future versions of USCDI, including providing stakeholders with the opportunity to comment on draft USCDI’s expansion, stakeholders will have ample opportunities to advance additional Data Classes and Data Elements relevant to a wide range of health care use cases. After consideration of these comments and the overall support of commenters, we have adopted the USCDI v1 as a standard in § 170.213. We have also extended the compliance timelines with which a health IT developer needs to update to the USCDI, therefore, we have not removed the CCDS definition from § 170.102 as proposed but revised it to remove references to 2014 Edition standards and provided time limitations for when health IT developers need to update to the USCDI. a. USCDI 2015 Edition Certification Criteria We proposed (84 FR 7441) to adopt the USCDI Version 1 (USCDI v1) in § 170.213.25 The USCDI is a standardized set of health Data Classes and constituent Data Elements that would be required to support nationwide electronic health 25 We note that USCDI v1 is an updated version and distinguished from the Draft United States Core Data for Interoperability (USCDI) previously made available for public review and comment in the course of its development as a prospective standard. The data classes and elements in the USCDI v1 were proposed in § 170.213 and defined in the Proposed Rule, and an additional USCDI v1 document with technical standards information was posted electronically concurrent with the publication of the Proposed Rule in order to provide the public adequate time to fully review and comment on both the proposed regulation and the USCDI v1 technical information. VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 information exchange. Once adopted in this final rule, health IT developers would be required to update their certified health IT to support the USCDI v1 for all certification criteria affected by this proposed change. We also proposed conforming changes in the sections below to update the following formerly CCDS-dependent 2015 Edition certification criteria to incorporate the USCDI standard: • ‘‘transitions of care’’ (§ 170.315(b)(1)); • ‘‘view, download, and transmit to 3rd party’’ (§ 170.315(e)(1)); • ‘‘transmission to public health agencies—electronic case reporting’’ (§ 170.315(f)(5)); • ‘‘consolidated CDA creation performance’’ (§ 170.315(g)(6)); and • ‘‘application access—all data request’’ (§ 170.315(g)(9)). We did not include the ‘‘data export’’ criterion (§ 170.315(b)(6)) in the proposed list of criteria that would be revised to include the USCDI standard because we proposed to remove the ‘‘data export’’ criterion (§ 170.315(b)(6)) and instead proposed to adopt a criterion that we referenced as ‘‘EHI export’’ in the Proposed Rule (§ 170.315(b)(10)). For similar reasons, we did not include the ‘‘application access—data category request’’ criterion (§ 170.315(g)(8)) because we proposed to replace it with the API certification criterion (§ 170.315(g)(10)) that derives its data requirements from the USCDI. We also proposed, as a Maintenance of Certification requirement (§ 170.405(b)(3)) for the real world testing Condition of Certification requirement (§ 170.405(a)), that health IT developers with health IT certified to the five above-identified certification criteria prior to the effective date of this final rule would have to update such certified health IT to the proposed revised standards (84 FR 7441 and 7596). We further proposed, as a Maintenance of Certification requirement (§ 170.405(b)(3)) for the real world testing Condition of Certification requirement (§ 170.405(a)), that health IT developers must provide the updated certified health IT to all their customers with health IT previously certified to the identified criteria no later than 24 months after the effective date of this final rule (84 FR 7441 and 84 FR 7596). For the purposes of meeting this compliance timeline, we noted that we expected health IT developers to update their certified health IT and notify their ONC–ACB on the date at which they have reached compliance. We noted that developers would also need to factor these updates into their next real world PO 00000 Frm 00030 Fmt 4701 Sfmt 4700 testing plan as discussed in section VII.B.5 of the Proposed Rule.26 Comments. The majority of commenters supported the proposed adoption of USCDI v1 and incorporation of the USCDI into the revised and new certification criteria. Some commenters expressed concern that incorporation of the USCDI into the ‘‘transmission to public health agencies—electronic case reporting’’ certification criteria could have a negative impact on data received by public health reporting programs. Some commenters stressed the need for reasonable adoption timelines. Some suggested a longer adoption and implementation timeline for incorporation of the USCDI as part of certified health IT. Response. ONC acknowledges that some entities, such as public health agencies, may need to consider what the expanded set of data the USCDI v1 offers may mean to their reporting programs and requirements. To be clear, the USCDI’s existence as a stand-alone standard will not impact or change public health reporting requirements. However, certain data now included in the USCDI, such as clinical notes, would now become more readily available for public health reporting and a State’s public health program’s policy may need to be revisited if a State seeks to make use of the ‘‘new’’ data the adoption of the USCDI stands to make more easily available, and more usable upon receipt. We also believe that the proposed 24-month timeline for updating certified health IT to comply with the new USCDI standard in § 170.213 is an adequate implementation timeline, based on other adoption timelines with similar technical complexities. We, therefore, have finalized revisions for the five above-identified formerly CCDSdependent 2015 Edition certification criteria to incorporate the USCDI standard. We have finalized a modification to the regulation text for these criteria based on public comment related to mitigating the risk of potential confusion caused by updates to existing criteria. As discussed earlier in this preamble (section IV), we received public comment requesting that all revised criteria be included in a new edition of certification criteria. At the start of section IV, we discuss in response to these comments that we do not believe the creation of a new edition is appropriate given that the scope of the updates to the 2015 Edition is tied 26 The finalized real world testing Condition and Maintenance of Certification requirements are discussed in section VII.B.5 of this final rule. E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations to standards updates required to keep pace with current industry practices. However, we do plan to distinguish the 2015 Edition certification criteria from the updated criteria in this final rule by referring to them as the 2015 Edition Cures Update on the CHPL. However, as Health IT Modules are updated to the new standards over time, there is a need to define what is required for certification and what is required for compliance to prior certification. Therefore, we have finalized that for criteria being updated from the CCDS to the USCDI, 24 months after publication date of the final rule shall be applicable for a transition from the CCDS to the USCDI. We have finalized that for the period until 24 months after the publication date of the final rule, the CCDS remains applicable for certified Health IT Modules until such Health IT Modules are updated to the USCDI. This means that upon the effective date of the rule, for the identified criteria the following apply for certification and compliance: • The USCDI, or • The CCDS for the period up to 24 months after the publication date of the final rule. This allows for developers to plan the transition for their products more effectively and supports certification continuity. We have finalized a modification to the regulation text to require the USCDI, or the CCDS for the period lasting until 24 months after the publication date of the final rule. We have finalized this modification to the regulation text for the following criteria: • ‘‘transitions of care’’ (§ 170.315(b)(1)); • ‘‘view, download, and transmit to 3rd party’’ (§ 170.315(e)(1)); • ‘‘transmission to public health agencies—electronic case reporting’’ (§ 170.315(f)(5)); • ‘‘consolidated CDA creation performance’’ (§ 170.315(g)(6)); and • ‘‘application access—all data request’’ (§ 170.315(g)(9)). We have finalized in § 170.405(b)(3), as a Maintenance of Certification requirement under the real world testing Condition of Certification requirement, that health IT developers with health IT certified to the five above-identified certification criteria prior to the effective date of this final rule, would have to update such certified health IT to the revisions within 24 months of the publication date of this rule. As of this final rule’s effective date, the ‘‘data export’’ criterion in § 170.315(b)(6) is no longer required as a part of the 2015 Edition Base EHR definition. ONC–ACB’s will not be VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 permitted to issue certificates to this certification criteria after 36 months after the publication date of this final rule. As discussed in the ‘‘EHI export’’ section below, we have retained § 170.315(b)(6) ‘‘as is,’’ without updates to the USCDI. Thus, health IT developers with health IT certified to the prior certification criterion in § 170.315(b)(6) do not have to update such certified health IT to the revisions listed above, but are permitted to maintain or seek new Health IT Module certification to this criterion should they desire this functionality. b. USCDI Standard—Data Classes Included As we noted in the Proposed Rule (84 FR 7441), the USCDI Version 1 (USCDI v1) and its constituent Data Elements incorporated recommendations we had accepted from public comments we had previously received on our Draft USCDI and Proposed Expansion Process,27 which we published January 5, 2018 as well as initial feedback on that draft from the Health IT Advisory Committee, both of which occurred prior to the publication of the Proposed Rule. The standard we proposed to adopt in § 170.213 also reflected and acknowledged the burden that rapidly expanding the USCDI v1 beyond the CCDS could cause. As a result, the USCDI v1 that we proposed was a modest expansion of the CCDS, which we indicated that most health IT developers already supported, were already working toward, or should be capable of updating their health IT to support in a timely manner. Therefore, in our Proposed Rule, we outlined only the delta between the CCDS and the USCDI v1. For the overall structure and organization of the USCDI standard, we urged stakeholders to consult www.healthIT.gov/USCDI. Comments. We received numerous comments proposing new Data Classes, Data Elements, and other changes within the USCDI beyond those we included in the Proposed Rule. Comments recommended including new Data Elements and/or classes within the USCDI v1 related to encounter data, financial transaction and insurance data, and specialty-specific Data Elements related to cancer treatment, social determinants of health, and more. Another commenter identified an error in the Procedures Data Class citing the wrong code set for dental procedures in the USCDI v1. Response. We thank the many commenters for their input on the 27 https://www.healthit.gov/sites/default/files/ draft-uscdi.pdf (January 5, 2018). PO 00000 Frm 00031 Fmt 4701 Sfmt 4700 25671 USCDI. We recognize that the USCDI v1 as proposed represents a modest change over the current CCDS definition. As we indicated in the Proposed Rule (84 FR 7441), we view this initial version of the USCDI standard as a starting point to support improved interoperability. We are also sensitive to requirements related to the development and implementation of adopting the USCDI standard. In the interests of maintaining our proposed implementation timeline of 24 months from the publication of this final rule, and after consideration of these comments and the overall support of commenters, we have finalized the adoption of the Data Classes and elements of the USCDI standard as proposed, with changes outlined in the subsections below. Additionally, in order to address the error pointed out to us via comments in the Procedures Data Class, as was stated in the draft USCDI v1,28 we clarified that the American Dental Association’s Code on Dental Procedures and Nomenclature (CDT) should be used for Dental Procedures in the USCDI v1, not SNODENT as was erroneously stated in the draft USCDI v1. With respect to the USCDI’s expansion in future years, ONC will establish and follow a predictable, transparent, and collaborative process to expand the USCDI, which will provide stakeholders with the opportunity to comment on the USCDI’s expansion and to advance additional Data Classes and Data Elements relevant to a wide range of use cases related to health care. Prior to this final rule, we published our initial thinking as well as examples of Data Classes and Data Elements that we believed could be appropriate to propose for adding to the USCDI.29 We have also solicited feedback and recommendations from the HITAC. As we evaluated public comments and conducted our own research prior to the issuance of this final rule, we also wanted to identify for stakeholders another potential source that could be used to focus efforts around new USCDI Data Classes and Data Elements. As is noted throughout this rule, the HL7® FHIR® standard represents health information in what are called ‘‘FHIR resources.’’ When it comes to logically organizing FHIR resources that relate to one another and share common properties, FHIR uses a concept called a ‘‘compartment.’’ Through the standards development process a ‘‘Patient Compartment’’ has been 28 https://www.healthit.gov/sites/default/files/ draft-uscdi.pdf. 29 https://www.healthit.gov/sites/default/files/ draft-uscdi.pdf. E:\FR\FM\01MYR3.SGM 01MYR3 25672 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations created, which lists all of the FHIR resources that are associated with a patient. The Patient Compartment ‘‘includes any resources where the subject of the resource is the patient, and some other resources that are directly linked to resources in the patient compartment.’’ This organizing framework provides a potentially rich set of a Data Classes and Data Elements to consider for inclusion in the USCDI, including clinical, encounter, specialty, and financial data. As ONC looks to make its own investments to advance the implementation experience associated with prospective USCDI Data Classes and Data Elements, we intend to leverage the Patient Compartment to guide our thinking. In addition, we will also look to and encourage industry to look at other organizing frameworks such as the Clinical Quality/Clinical Decision Support realms and the payerto-provider community (e.g., DaVinci Project 30) to help identify data that would be best to focus on for USCDI expansion. i. Updated Versions of Vocabulary Standard Code Sets We proposed (84 FR 7441) that the USCDI v1 would include the newest versions of the ‘‘minimum standard’’ code sets included in the CCDS available at publication of this final rule. We requested comment on that proposal and on whether it could result in any interoperability concerns. We also noted that criteria such as the 2015 Edition ‘‘family health history’’ criterion (§ 170.315(a)(12)), the 2015 Edition ‘‘transmission to immunization registries’’ criterion (§ 170.315(f)(1)), and the 2015 Edition ‘‘transmission to public health agencies—syndromic surveillance’’ criterion (§ 170.315(f)(2)) reference ‘‘minimum standard’’ code sets; however, we indicated that we were considering updating the versions of these standards listed and incorporated by reference in part 170 subpart B that are referenced by these criteria from the versions adopted in the 2015 Edition final rule. We also noted, for purposes of clarity, that consistent with § 170.555, unless the Secretary prohibits the use of a newer version of an identified minimum standard code set for certification, health IT could continue to be certified or upgraded by developers to a newer version of an identified minimum standard code set than that included in USCDI v1 or the most recent USCDI version that the National Coordinator has approved for use in the Program using the SVAP flexibility. 30 https://www.hl7.org/about/davinci/index.cfm. VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 Comments. There was general support from commenters for updating ‘‘minimum standard’’ code sets requirements to the newest versions of these code sets as part of the update from CCDS to the USCDI. One commenter recommended adopting the Data Class requirement first, followed by a delayed requirement of updated versions of the ‘‘minimum standards’’ code sets, in order to allow implementers more time to make changes to their systems. Response. We do not believe that adopting the corresponding ‘‘minimum standards’’ code sets that are updated in the USCDI v1 would impose a significant burden on implementers. In consideration of the overall support from commenters, we have finalized our proposal that the USCDI v1 include the newest versions of the ‘‘minimum standard’’ code sets available at the time of finalization of this final rule. We have not, however, finalized the proposal for the 2015 Edition ‘‘family health history’’ criterion (§ 170.315(a)(12)), the 2015 Edition ‘‘transmission to immunization registries’’ criterion (§ 170.315(f)(1)), and the 2015 Edition ‘‘transmission to public health agencies—syndromic surveillance’’ criterion (§ 170.315(f)(2)) to reference the newest versions of the ‘‘minimum standard’’ code sets for these criteria, because the flexibility already exists to use newer versions of code sets included in these criteria. We note that for these certification criteria, health IT developers may take advantage of the previously established 31 flexibility to seek certification to newer versions of the ‘‘minimum standards’’ code with § 170.555. ii. Address and Phone Number We proposed (84 FR 7442) new Data Elements in the USCDI v1 for ‘‘address’’ and ‘‘phone number.’’ We noted that the inclusion of ‘‘address’’ (to represent the postal location for the patient) and ‘‘phone number’’ (to represent the patient’s telephone number) would improve the comprehensiveness of health information for patient care. We further noted that the inclusion of these Data Elements was consistent with the list of patient matching Data Elements already specified in the 2015 Edition ‘‘transitions of care’’ certification criterion (§ 170.315(b)(1)(iii)(G)), which supports the exchange of patient health information between providers of patient care. Comments. Commenters unanimously supported the addition of address and phone numbers to the USCDI v1. The majority of commenters on this proposal 31 77 PO 00000 FR 54163, 54268–69 (September 4, 2012). Frm 00032 Fmt 4701 Sfmt 4700 recommended the use of the U.S. Postal Service address format to improve address data quality. Commenters also recommended additional elements of address and phone number indicating effective period (e.g., current address, former address); use (e.g., mobile phone number, landline, etc.), and email address. Response. We thank the commenters for their recommendations and agree that these additional Data Elements can be useful to provide better care and assist with patient matching. In consideration of these comments, we have finalized the addition of the following Data Elements within the Patient Demographics Data Class: • ‘‘current address’’; • ‘‘previous address’’; • ‘‘phone number’’; • ‘‘phone number type’’; and • ‘‘email address.’’ We further clarify that ‘‘phone number’’ and ‘‘phone number type’’ must be represented using the same standards, ITU–T E.123 (02/2001) and ITU–T E.164, as already adopted for this data in 45 CFR 170.207(q) and referenced in the 2015 Edition ‘‘transitions of care’’ certification criterion (§ 170.315(b)(1)(iii)(G)). We appreciate commenters’ recommendations to use the U.S. Postal Service Postal Addressing Standards, which include address formatting guidance and a variety of products to improve address quality, such as address element standardization and validation which are published and available for public use.32 The U.S. Postal Service Postal Addressing Standards include standardized names for common unit identifiers, line by line acceptance requirements for mail services, and overall address format guidance that has been specifically designed to support labelling of mail items for acceptance by the U.S. Postal Service automated sorting processes. We acknowledge the potential for its use within health IT to improve patient matching. However, while the U.S. Postal Service Postal Addressing Standards include a single representation for certain data elements (such as rendering apartment as apt, building as bldg, floor as fl, etc.) they also allow variations for other data elements, such as ‘‘acceptable’’ and ‘‘preferred’’ spellings and abbreviations for street and city names. This may result in multiple ‘‘valid’’ addresses. To reconcile this variation, the U.S. Postal Service provides a file listing preferred 32 U.S. Postal Service: Postal Addressing Standards (Publication 28) available at https:// pe.usps.com/text/pub28/welcome.htm. E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations city and State combinations as well as a file of street name and zip code combinations and the resulting aggregated address would then require manual reconciliation. We believe the U.S. Postal Service Postal Addressing Standards may be useful guidance for health IT developers. However, because of the variation, the required use of reference files, and the manual reconciliation necessary for implementation, we have not adopted the U.S. Postal Service Postal Addressing Standards as a required standard for the address Data Elements within the USCDI. We encourage the use of standardized elements to accurately represent patient address including use of standardized references in the U.S Post Service Postal Addressing Standards where applicable. In addition, we will continue to work with standards developing organizations to evaluate potential solutions to improve patient matching, including considering the potential adaptability of the U.S. Postal Service formats for health IT use cases. The U.S. Postal Service also maintains web based tools for address validation services and provides implementation guidance to integrate these tools into technical workflows for IT systems in ecommerce and other industries. We agree that these address validation tools have the potential to greatly improve address data quality, and we encourage health IT developers and other relevant health IT users such as health information networks to explore mechanisms by which such address validation might support patient matching. While not specifically designed for patient matching and other health care related applications, USPS address validation has been piloted in these settings. To adapt the address validation tool to a health care purpose requires the services of a third party with licensing of the tool and the development of a bespoke process to execute the tool. The aggregated patient address could then be compared against the USPS address on file and the patient data could be amended where inaccurate, appended where incomplete, or a linked record of secondary address data could be created depending on the percent of confidence in the specific match. This process would then require manual reconciliation. The results of these pilots indicate significant complexity and burden associated with implementation of this process. Given these burdens, we believe it would not be appropriate to require the integration of this distinct functionality into VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 certified health IT at this time. We again encourage the further development and use of standardized approaches for address validation and will continue to monitor and analyze such efforts for consideration in future rulemaking. iii. Pediatric Vital Signs As proposed (84 FR 7442), the USCDI v1 included the pediatric vital sign data elements, which are specified as optional health information in the 2015 Edition CCDS definition. The proposed pediatric vital signs included: head occipital-frontal circumference for children less than 3 years of age, BMI percentile per age and sex for youth 2– 20 years of age, weight for age per length and sex for children less than 3 years of age, and the reference range/scale or growth curve, as appropriate. As explained in section VI.A.2 of this final rule, the inclusion of pediatric vital sign Data Elements in the draft USCDI v1 align with the provisions of the Cures Act related to health IT to support the health care of children. Prior to the publication of the Proposed Rule, stakeholders emphasized the value of pediatric vital sign data elements to better support the safety and quality of care delivered to children. We also note in our Proposed Rule and in the 2015 Edition proposed rule (80 FR 16818 and 16819) that the Centers for Disease Control and Prevention (CDC) recommends as part of best practices the use of these pediatric vital signs for settings of care in which pediatric and adolescent patients are seen. The availability of a reference range/scale or growth curve would help with proper interpretation of the measurements for the BMI percentile per age and sex and weight for age per length and sex. Further, we noted our belief that the inclusion of this health information in the USCDI v1 was the appropriate next step after first specifying them as optional in the CCDS definition as part of the 2015 Edition rulemaking (80 FR 62695), and as a means of supporting patient access to their EHI in a longitudinal format through certified health IT (see section 3009(e)(2)(A)(i) of the PHSA as amended by the Cures Act). We recognized, however, that certain health IT developers and their customers may not find these capabilities and information useful. Therefore, we requested comment on the inclusion of pediatric vital signs in the USCDI v1, including the potential benefits and costs for all stakeholders stemming from its inclusion in the USCDI v1. Comments. Commenters generally supported the inclusion of the pediatric vital signs Data Elements in the USCDI PO 00000 Frm 00033 Fmt 4701 Sfmt 4700 25673 v1. Some commenters opposed their inclusion or believed the inclusion of these Data Elements should be optional since pediatric vital signs are not applicable to all specialties and would add implementation burden and cost without benefit. One commenter stated that only the measurements and associated metadata (units of measure, date/time measurement taken, method of measurement), not the calculated percentiles according to applicable pediatric growth charts, should be required as part of the exchange of patient data. One commenter recommended adding the nutritional status Data Element ‘‘mid-arm circumference.’’ Finally, several commenters suggested or requested clarification on the pediatric vital signs Data Elements we proposed (84 FR 7442). Specifically, stakeholders in the pediatric community asked for clarification of the proposed pediatric vital sign ‘‘weight for age per length and sex for children less than 3 years of age,’’ noting it does not correspond to any existing pediatric growth charts. Rather, they noted that there is a growth chart ‘‘weight-for-length’’ for children less than 3 years of age. Response. We recognize that the adoption of these Data Elements has the potential to add burden and cost for some health IT products, but we believe the inclusion of these Data Elements can contribute significantly to the longitudinal care of patients. Pediatric care is not isolated to a single specialty or setting of care, and clinicians providing health care for children— especially those providing care for children with complex conditions—may practice in a wide range of settings using a wide range of health IT systems. Many key stakeholders believe that the ability to capture, calculate, and transmit key pediatric growth data using health IT is critical to providing care to these populations as well as communicating with other providers, parent/guardians, and patients. We also note that adoption of the USCDI standard and its Data Classes and elements is not specific as to its usage within a setting of care, a health care specialty, or by a specific category of health IT user; rather it applies to certified health IT’s ability to send and receive those Data Elements without requirements regarding functionality, user interface, or the use of those Data Elements in exchange. While some users may find few opportunities to exchange these Data Elements, many will exchange these Data Elements frequently. As we have noted previously, we believe that the adoption E:\FR\FM\01MYR3.SGM 01MYR3 25674 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations of USCDI for all certified health IT will advance interoperability by ensuring compliance with new data and vocabulary codes sets that support the data. We also appreciate the commenter’s suggestion for an additional Data Element. As we have noted, ONC will establish and follow a predictable, transparent, and collaborative process to expand the USCDI, which will provide stakeholders with the opportunity to advance additional Data Classes and Data Elements relevant to a wide range of use cases related to health care. Regarding the request to clarify and better define these proposed pediatric vital signs, we note that these Data Elements, as written and proposed, were previously included as optional health information in the 2015 Edition CCDS definition. The discrepancy between the adopted pediatric vital signs and standardized pediatric growth charts was not identified previously. Therefore, we wish to clarify that the above-referenced pediatric vital signs include both the vital measurements and the percentiles used in the following growth charts currently recommended by the Centers for Disease Control and Prevention: 33 for infants birth to 36 months of age: Weight-forlength; and head occipital-frontal circumference for age; and for children 2–20 years of age: Body mass index (BMI) for age. In consideration of these comments, we have finalized the following pediatric Data Elements in the Vital Signs Data Class of the USCDI v1: Head occipital-frontal circumference percentile (Birth to 36 Months); weightfor-length percentile (Birth to 36 Months); body mass index (BMI) percentile (2–20 Years of Age); and the reference range/scale or growth curve, as appropriate. iv. Clinical Notes We proposed (84 FR 7442) to include in the USCDI v1 a new Data Class entitled ‘‘clinical notes.’’ ‘‘Clinical notes’’ was included in the proposed USCDI v1 based on significant feedback from the industry since the 2015 Edition final rule. We also received similar feedback during the Trusted Exchange Framework and Common Agreement (TEFCA) stakeholder sessions and public comment period. As we noted, ‘‘clinical notes’’ have been identified by stakeholders as highly desirable data for interoperable exchange. The free text portion of the clinical notes was most often relayed by clinicians as the data they sought, but were often missing 33 https://www.cdc.gov/growthcharts/index.htm. VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 during electronic health information exchange. We additionally noted that clinical notes can be composed of text generated from structured (pick-list and/ or check the box) fields as well as unstructured (free text) data. We explained that a clinical note may include the assessment, diagnosis, plan of care and evaluation of plan, patient teaching, and other relevant data points. We recognized that a number of different types of clinical notes could be useful for stakeholders. We indicated our understanding that work is being done in the community to focus on a subset of clinical notes. We considered three options for identifying the different ‘‘note types’’ to adopt in USCDI v1. The first option we considered allowed for the community to offer any and all recommended notes. The second option we considered set a minimum standard of eight note types. This option was derived from the eight note types identified by the Argonaut Project participants.34 The third option we identified looked to the eleven HL7 Consolidated Clinical Document Architecture (C–CDA) document types identified in the C–CDA Release 2.1, which also included the note types being identified by the Argonaut Project participants. We ultimately proposed the second option because it unites public and private interests toward the same goal. We indicated that the eight selected note types were a minimum bar and, in the future, the USCDI could be updated to include other clinical notes. Specifically, we proposed to include the following clinical note types for both inpatient and outpatient (primary care, emergency department, etc.) settings in USCDI v1 as a minimum standard: (1) Discharge Summary note; (2) History & Physical; (3) Progress Note; (4) Consultation Note; (5) Imaging Narrative; (6) Laboratory Report Narrative; (7) Pathology Report Narrative; and (8) Procedures Note (84 FR 7442). We requested comment on whether to include additional note types as part of the USCDI v1. Comments. Commenters broadly supported adding ‘‘clinical notes’’ as a new Data Class to the USCDI v1, in particular to enable the use of free text for data exchange. Several commenters requested clarity as to whether the proposal to adopt this new Data Class would require the capture and exchange of unstructured, or ‘‘raw’’ or ‘‘free’’ text, narrative clinical information or more comprehensive documents such as 34 Link to the Clinical Notes Argonaut Project identified (to clarify: Seven bullets are listed, however, we split laboratory and pathology note types into their own note) https://wiki.hl7.org/ index.php?title=201805_Clinical_Notes_Track. PO 00000 Frm 00034 Fmt 4701 Sfmt 4700 those defined by C–CDA. Some commenters recommended adding certain note types—including continuity of care, operative, and nursing notes— while others recommended removing some of the proposed note types. In particular, Laboratory/Pathology Report Narrative note types were thought to be duplicative of content in the Laboratory Data Class and element Value/Results. Some commenters recommended Imaging Narrative not be used, but added to a new Data Class, Diagnostic Tests, which would combine Laboratory and Radiology tests and results. Response. We thank commenters for their support and recommendations. While we recognize that there may be alternative methods of organizing different clinical note types, we believe there is value in grouping all clinical notes into a single Data Class within the USCDI. As we noted above and in the Proposed Rule, we have adopted the eight note types identified by the Argonaut Project participants because it unites public and private interests toward the same goal. As we indicated, the eight selected note types are a minimum bar and, in the future, the USCDI could be updated to include other clinical note types. The eight selected note types reflect the most clearly and consistently recommended set of clinical note type. While a variety of additional note types were recommended, there was no consensus for additional note types beyond these eight. In consideration of these comments, we have finalized the clinical notes as a Data Class in the USCDI v1, with only the following eight clinical note types for both inpatient and outpatient (primary care, emergency department, etc.) settings as a minimum standard as proposed: (1) Discharge Summary Note; (2) History & Physical; (3) Progress Note; (4) Consultation Note; (5) Imaging Narrative; (6) Laboratory Report Narrative; (7) Pathology Report Narrative; and (8) Procedures Note. We wish to further clarify that we have adopted the new Clinical Notes Data Class in order to enable capture and exchange of free text clinical information categorized by the above clinical note types. We refer commenters to our response in section IV.B.1.d of the final rule—Clinical Notes C–CDA Implementation Specification— that addresses the relationship of the clinical notes Data Class to C–CDA implementation specification. We also seek to clarify two points. First, that these clinical note types are content exchange standard agnostic. They should not be interpreted or associated with the specific C–CDA Document Templates that may share the E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations same name. Secondly, we clarify that these note types are required to be represented in their plain-text form when included in various content exchange standards (e.g., C–CDA, FHIR) as may be applicable to the certification criteria in which the USCDI is referenced. v. Provenance We proposed (84 FR 7442) for the USCDI v1 to include a new Data Class, entitled ‘‘provenance.’’ As we indicated, stakeholders 35 have identified ‘‘provenance’’ as valuable for interoperable exchange. Stakeholders also referenced the provenance of data as a fundamental need to improve the trustworthiness and reliability of the data being exchanged. Provenance describes the metadata, or extra information about data, that can help answer questions such as who created the data and when. In the Proposed Rule, we noted that the inclusion of ‘‘provenance’’ as a Data Class in the USCDI v1 would also complement the Cures Act requirement in section 4002(a) to support the exchange of data through the use of APIs. This approach differs from the exchange of data via the C–CDA. While C–CDAs are often critiqued due to their relative ‘‘length,’’ the C–CDA represents the output of a clinical encounter and includes relevant context. The same will not always be true in an API context. APIs facilitate the granular exchange of data and, as noted in the original 2015 Edition final rule, offer the potential to aggregate data from multiple sources using a web or mobile application (80 FR 62675). The inclusion of provenance would help retain the relevant context so the recipient can better understand the origin of the data. We proposed to further delineate the provenance Data Class into three Data Elements: ‘‘the author,’’ which represents the person(s) who is responsible for the information; ‘‘the author’s time stamp,’’ which indicates the time the information was recorded; and ‘‘the author’s organization,’’ which would be the organization the author is associated with at the time they interacted with the data (84 FR 7442). We indicated that we identified these three Data Elements as fundamental for data recipients to have available and noted that they are commonly captured and currently available through standards. We requested comment on the inclusion of these three Data Elements and whether any other 35 https://www.healthit.gov/topic/interoperability/ trusted-exchange-framework-and-commonagreement. VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 provenance Data Elements, such as the identity of the individual or entity the data was obtained from or sent by (sometimes discussed in standards working groups as the provenance of the data’s ‘‘last hop’’), would be essential to include as part of the USCDI v1 standard. We acknowledged that there is currently work to help define provenance in a standard robust manner, and that we anticipated adopting the industry consensus once it became available. Comments. Commenters overwhelmingly supported the addition of provenance as a new Data Class for USCDI v1. Several commenters stated that the proposed elements were insufficient for the purpose of audit logs for use and disclosure of health data, citing the existing standard specification ASTM E2147.36 Other commenters stated that these proposed elements did not apply to all use cases of exchanged data and requested clarification regarding applicability, including whether provenance would have to be created for elements created before the implementation deadline of USCDI v1. Because this is a new Data Class, some commenters also requested additional time to adopt and implement this new requirement. Some commenters stated that there could be ambiguity in designating ‘‘author’’ for certain clinical information such as patient-reported medications, while in certain other cases, there could be multiple authors for the same clinical information, such as clinical notes. Additionally, some commenters suggested that the ‘‘author’’ be limited to only a limited set of Data Elements and not to all the Data Elements. Another commenter specifically addressed several concerns related to the definition of ‘‘author’’ for this purpose. Commenters specifically stated they understood author to be the person entering the data into the EHR, but noted that data may also be historical, captured from a device, started by a patient and completed by clinical staff, entered by a patient, entered by resident/students working under a supervising physician, or reported by a patient. The commenter noted that there are additional documentation scenarios such as dictation to scribes or other medical staff, which conflate ‘‘responsibility’’ for authorship, and that defining author for every Data Element can be complex. Finally, one health IT developer recommended a 36-month implementation period to begin only after test procedures, implementation guides, and test and validation tools are 36 https://www.astm.org/Standards/E2147.htm. PO 00000 Frm 00035 Fmt 4701 Sfmt 4700 25675 available and after ONC has consulted at least five CEHRT developers. Response. We acknowledge that these Data Elements may not be able to fully support the needs of all use cases, but we believe their adoption will improve the trustworthiness and reliability of data being exchanged. For this Data Class, it appears that many commenters over-interpreted our proposal and the effect of having these data in the USCDI. As we noted earlier, the adoption of the USCDI standard and its Data Classes and elements is not specific as to its usage within a setting of care, a health care specialty, or by a specific category of health IT user. Rather it applies to certified health IT’s ability to send and receive those Data Elements without requirements regarding functionality, user interface, or the use of those Data Elements in exchange. Therefore, with respect to our reference to provenance data in the USCDI, we have no preset notion or explicit upfront requirement for how this data should be used. We believe that having provenance data is highly impactful, essential for trustworthy interoperability, and will generate greater value for stakeholders as they identify new ways to put this data to use. Regarding ‘‘author’’ as a Data Element within the provenance Data Class, we agree that significant practical scope challenges may arise. Our analysis of the concerns raised by commenters identified a risk of unintended burden and potential risk of error and misattribution associated with this particular Data Element. In most use cases, the inclusion of author organization and author time stamp is sufficient to convey provenance. As a result, we have not finalized the ‘‘author’’ as a required Data Element within the provenance Data Class in USCDI. However, we understand that for exchanging certain data elements, such as ‘‘clinical notes,’’ it is critical to also send the ‘‘author’’ information if available. Our analysis of the various content exchange standards and specifications (e.g., C–CDA and FHIR) indicates that even though the ‘‘author’’ Data Element is not explicitly required in USCDI, the health IT specifications in which USCDI Data Elements are represented also set specific data element requirements for certain contexts. For example, in the context of clinical notes, these content exchange standards require health IT systems to be capable of exchanging ‘‘author’’ information when it is available. Further, ‘‘author’’ is treated as a ‘‘Must Support’’ data element in the FHIR US Core Implementation Guide STU 3.1.0 and has a ‘‘SHALL’’ constraint (with E:\FR\FM\01MYR3.SGM 01MYR3 25676 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations appropriate null flavor value) in the C– CDA 2.1. As we have noted previously, we believe that the proposed 24-month timeline for updating certified health IT to comply with the new USCDI standard in § 170.213 is an adequate implementation timeline and will maintain this requirement as finalized earlier in this section. Therefore, in consideration of the comments received, we have finalized the provenance Data Class in the USCDI v1 and the following two Data Elements: • ‘‘author time stamp,’’ which indicates the time the information was recorded; and • ‘‘author organization,’’ which would be the organization the author is associated with at the time they interacted with the data. We believe these two provenance Data Elements, ‘‘author organization’’ and ‘‘author time stamp,’’ within the USCDI v1, which are also used in the C–CDA and FHIR-based certification criteria we have adopted that incorporate the USCDI, will serve as a foundation on which industry stakeholders can subsequently work together to build out additional provenance data requirements in the USCDI. As noted above, we have not finalized the proposed Data Element ‘‘the author,’’ which represents the person(s) who was responsible for the information. vi. Medication Data Request for Comment In the Proposed Rule, we proposed (84 FR 7443) that the USCDI v1 ‘‘Medication’’ Data Class include two constituent Data Elements within it: Medications and Medication Allergies. With respect to the latter, Medication Allergies, we requested comment on an alternative approach. This approach would remove the Medication Allergies Data Element from the Medication Data Class and add it to a new Data Class titled ‘‘Substance Reactions,’’ which would include the concept of ‘‘Medication Allergies.’’ The new ‘‘Substance Reactions’’ Data Class would include the following Data Elements: ‘‘Substance’’ and ‘‘Reaction,’’ and include SNOMED CT as an additional applicable standard for nonmedication substances. Comments. The majority of commenters supported the creation of a new Data Class ‘‘Substance Reactions’’ but requested we preserve the Medication Allergy element because of patient safety concerns related to the adoption of an entirely new Data Element. One commenter supported the change but recommended the new Data Class name be aligned with the HL7 FHIR resource ‘‘AllergyIntolerance.’’ VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 This would also be consistent with the C–CDA 2.1 ‘‘Allergy and Intolerance’’ section. Response. We thank the commenters for their input. While we appreciate that there may be some risk associated with the adoption of a new Data Element, we believe this alternative approach better aligns with other standards representing substance reactions, including medication allergies, and this alignment enhances patient safety. Additionally, we agree with the commenter who suggested renaming this new Data Class to align with FHIR and C–CDA approaches. In consideration of comments, we have finalized the creation of a Data Class in USCDI v1 entitled ‘‘Allergies and Intolerances,’’ instead of ‘‘Substance Reactions’’ from the original USCDI v1 proposal. The Allergies and Intolerances Data Class in USCDI v1 consists of the following Data Elements: ‘‘Substance—(Medication),’’ ‘‘Substance—(Drug Class),’’ and ‘‘Reaction.’’ ‘‘Substance—(Medication)’’ must be represented by RxNorm codes and ‘‘Substance—(Drug Class)’’ must be represented by SNOMED CT codes. The addition of the ‘‘Substance—(Drug Class)’’ better represents when an individual may have a reaction to an entire drug class as opposed to a specific medication. Additionally, we believe having the Allergy and Intolerances Data Class separated from the Medication Class will accommodate potential additions of other substance Data Elements such as food, environmental, and biologic agents. The Data Element ‘‘Reaction’’ is meant to include, but is not limited to, medication allergies. As the USCDI is updated over time to include substances other than medications, we can also see the need to have substance reactions updated as part of this Data Class. To reflect this change, we have updated the terminology in the regulatory text in § 170.315 to remove ‘‘medication allergy’’ and replace with ‘‘allergy and intolerance.’’ c. USCDI Standard—Relationship to Content Exchange Standards and Implementation Specifications In recognition of the evolution of standards over time and to facilitate updates to newer versions of standards, we proposed (84 FR 7443) that the USCDI v1 (§ 170.213) would be agnostic as to ‘‘content exchange’’ standard. As we noted, the USCDI v1 establishes ‘‘data policy’’ and does not directly associate with the content exchange standards and implementation specifications which, given a particular context, may require the exchange of the PO 00000 Frm 00036 Fmt 4701 Sfmt 4700 entire USCDI, a USCDI Data Class, or some or all of the Data Elements within a given Data Class or classes. We further indicated that, to our knowledge, all Data Classes in the USCDI v1 can be supported by commonly used ‘‘content exchange’’ standards, including HL7 C– CDA Release 2.1 and FHIR. We received no comments on this specific proposal and we have finalized our proposal to make USCDI v1 agnostic as to ‘‘content exchange standard’’ as described. 2. Clinical Notes C–CDA Implementation Specification In conjunction with our proposal to adopt the USCDI v1, we proposed to adopt the HL7 CDA® R2 IG: C–CDA Templates for Clinical Notes R1 Companion Guide, Release 1 in § 170.205(a)(5) (‘‘C–CDA Companion Guide’’). The C–CDA Companion Guide provides supplemental guidance and additional technical clarification for specifying data in the C–CDA Release 2.1.37 As we noted in the Proposed Rule (84 FR 7443), the proposed USCDI v1 included new Data Classes, such as ‘‘clinical notes,’’ which were further supported through the C–CDA Companion Guide. For example, the C– CDA Companion Guide provides specifications for clinical notes by indicating that clinical notes should be recorded in ‘‘note activity’’ and requires references to other discrete data, such as ‘‘encounters.’’ The C–CDA Companion Guide also enhances implementation of the updated 2015 Edition certification criteria that reference the C–CDA Release 2.1 (§ 170.205(a)(4)). As noted by stakeholders, the C–CDA Release 2.1 includes some optionality and ambiguity with respect to Data Element components, such as the locations and value sets. We attempted to address some of this optionality by clarifying requirements using Certification Companion Guides (CCGs) 38 and by specifying in the CCDS definition where certain data should be placed in the C– CDA Release 2.1 templates (e.g., ‘‘goals’’ in the goals section).39 The C–CDA Companion Guide, which was released in August, 2015, provides similar, but additional C–CDA implementation structure. For example, race and ethnicity are required Data Elements in the USCDI and must be included in C– CDA exchanges if known, or they may be marked with a nullFlavor value ‘‘UNK’’ (unknown) if not known. The 37 https://www.hl7.org/implement/standards/ product_brief.cfm?product_id=447. 38 https://www.healthit.gov/topic/certificationehrs/2015-edition-test-method. 39 https://www.healthit.gov/sites/default/files/ topiclanding/2018-04/2015Ed_CCG_CCDS.pdf. E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations C–CDA Release 2.1 is unclear on the location and value set, but the C–CDA Companion Guide clarifies the location and value set. We noted in the Proposed Rule that the adoption of the C–CDA Companion Guide would align with our goal to increase the use of consistent implementation of standards among health IT developers and improve interoperability. We proposed to adopt this C–CDA Companion Guide to support best practice implementation of USCDI v1 Data Classes and 2015 Edition certification criteria that reference C– CDA Release 2.1 (§ 170.205(a)(4)). The criteria include: • ‘‘transitions of care’’ (§ 170.315(b)(1)); • ‘‘clinical information reconciliation and incorporation’’ (§ 170.315(b)(2)); • ‘‘care plan’’ (§ 170.315(b)(9)); • ‘‘view, download, and transmit to 3rd party’’ (§ 170.315(e)(1)); • ‘‘consolidated CDA creation performance’’ (§ 170.315(g)(6)); and • ‘‘application access—all data request’’ (§ 170.315(g)(9)). We proposed, as a Maintenance of Certification requirement for the real world testing Condition of Certification requirement, that health IT developers with health IT certified to the six aboveidentified certification criteria prior to the effective date of a subsequent final rule would have to update such certified health IT to the proposed revisions (84 FR 7443).40 We further proposed as a Maintenance of Certification requirement for the real world testing Condition of Certification requirement, that health IT developers would be required to provide the updated certified health IT to all their customers with health IT previously certified to the identified criteria no later than 24 months after the effective date of a final rule (84 FR 7443). For the purposes of meeting that compliance timeline, we indicated that we expected health IT developers to update their certified health IT without new mandatory testing and notify their ONC–ACB on the date at which they have reached compliance. Developers would also need to factor these updates into their next real world testing plan as discussed in section VII.B.5 of the Proposed Rule.41 Comments. One commenter supported the use of C–CDA for Clinical Notes. One commenter sought clarity on testing for Clinical Notes conformance to C–CDA 2.1, noting that all C–CDA 40 We proposed to codify this requirement in § 170.405(b)(4) (84 FR 7596). 41 The finalized real world testing plan requirements, codified in § 170.405(b)(2) are discussed in section VII.B.5 of this final rule. VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 documents are the same except for the document header. Two commenters recommended review of the Common Well Concise Consolidated CDA white paper. Response. We thank the commenters for their suggestions and support. During the past few months, industry stakeholders updated the C–CDA Companion Guide to a newer version to best address how clinical notes should be handled in the C–CDA. In consideration of the update to the C– CDA Companion Guide and the comments, we have finalized the adoption of the most up-to-date version, HL7 CDA R2 IG: C–CDA Templates for Clinical Notes STU Companion Guide, Release 2 in § 170.205(a)(5) (‘‘C–CDA Companion Guide’’) and have incorporated by reference in § 170.299. This includes adoption of the USCDI v1 and the associated Data Classes. In order to align ‘‘clinical information reconciliation and incorporation’’ (§ 170.315(b)(2)) with the updated Data Classes in the USCDI v1 as proposed in 84 FR 7441, we have replaced the ‘‘medication allergies’’ data element in § 170.315(b)(2)(iii)(D)(2) criterion to ‘‘Allergies and Intolerances’’ Data Class and require reconciliation of all the data elements in ‘‘Allergies and Intolerances’’ Data Class, which includes Substance (Medication), Substance (Drug Class), and Reaction Data Elements. We have revised the regulation text (§ 170.315(b)(2)) to align with this change. We decline to accept the recommendation to adopt the CommonWell specification as we believe the criterion is best met following the C–CDA specification published by HL7. We have additionally finalized the timeline for the update to the use of the C–CDA companion guide of 24 months after the publication date of this final rule for the following criteria: • ‘‘transitions of care’’ (§ 170.315(b)(1)); • ‘‘clinical information reconciliation and incorporation’’ (§ 170.315(b)(2)); • ‘‘care plan’’ (§ 170.315(b)(9)); • ‘‘view, download, and transmit to 3rd party’’ (§ 170.315(e)(1)); • ‘‘consolidated CDA creation performance’’ (§ 170.315(g)(6)); and • ‘‘application access—all data request’’ (§ 170.315(g)(9)). 3. Unique Device Identifier(s) for a Patient’s Implantable Device(s) C–CDA Implementation Specification We noted in the Proposed Rule (84 FR 7443) our awareness of a recently published implementation guide (IG) by HL7 that provides further guidance on the unique device identifier (UDI) PO 00000 Frm 00037 Fmt 4701 Sfmt 4700 25677 requirements. The Health Level 7 (HL7) CDA R2 Implementation Guide: C–CDA Supplemental Templates for Unique Device Identification (UDI) for Implantable Medical Devices, Release 1–US Realm (UDI IG Release 1), identifies changes needed to the C–CDA to better facilitate the exchange of the individual UDI components in the health care system when devices are implanted in a patient. The UDI components include the Device Identifier (DI) and the following individual production identifiers: The lot or batch number, serial number, manufacturing date, expiration date, and distinct identification code. As this new IG had been recently published, we requested comment on whether we should add this UDI IG as a requirement in § 170.299(f)(35) for health IT to adopt in order to meet the requirements for content exchange using C–CDA. In addition, we indicated that we did not have a reliable basis on which to estimate how much it would cost to meet the requirements outlined in the UDI IG; and, therefore, we requested comment on the cost and burden of complying with this proposed requirement. Comments. Commenters unanimously supported adoption of the UDI IG Release 1 as a new requirement for health IT to meet the requirements for the USCDI UDI Data Class. One commenter requested additional guidance regarding the determination of the ‘‘person responsible for the information’’ contained in the ‘‘Device’’ entry. None of the commenters provided a basis of estimate for the cost to meet the requirements outlined in the UDI IG Release 1. Response. We thank the commenters for their support. As we noted earlier, the adoption of the USCDI standard and its Data Classes and elements is not specific as to its usage within a setting of care, a health care specialty, or by a specific category of health IT user; rather it applies to certified health IT’s ability to send and receive those Data Elements without requirements regarding functionality, user interface, or the use of those Data Elements in exchange. Therefore, we do not specify who must enter such data. We note also that the C–CDA Companion Guide referenced in subsection (d) below of this final rule now includes the content of the UDI IG Release 1 named in the Proposed Rule. In consideration of comments, we have finalized the proposed UDI Data Class within the USCDI v1, and have adopted the UDI Organizer Template defined in the UDI IG Release 1 and subsequently published as Appendix B of the HL7® E:\FR\FM\01MYR3.SGM 01MYR3 25678 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations CDA® R2 IG: C–CDA Templates for Clinical Notes, Release 2.1 Companion Guide, Release 2—US Realm, October 2019, as a new requirement for Health IT Modules to meet the requirements for C–CDA-based exchange. We note that the UDI Organizer Template, though subsequently published in Appendix B of the HL7 CDA R2 IG: C–CDA Templates for Clinical Notes STU Companion Guide, Release 2, September 2019, remains substantially unchanged from its previous publication in the UDI IG Release 1 in November 2018 and has been thoroughly reviewed and subjected to balloting and a public comment process. 4. Electronic Prescribing Criterion We proposed to adopt a new version of the NCPDP SCRIPT standard in 45 CFR 170.205(b)(1), specifically NCPDP SCRIPT standard version 2017071 (84 FR 7444). Because we proposed to adopt a new standard for electronic prescribing (e-Rx), we also proposed to adopt a new certification criterion in § 170.315(b)(11) for the proposed e-Rx standard to replace the old standard in § 170.315(b)(3). The proposed new certification criterion reflected our proposed adoption of NCPDP SCRIPT standard version 2017071 as well as all transactions adopted for the CMS Medicare Part D E-prescribing Program (84 FR 23832). These proposals were made to realign ONC’s Health IT Certification Program (Program) policies with those of CMS’ Part D E-prescribing rules. ONC and CMS have historically aligned standards adopted under their programs such as those for e-Rx and medication history (MH) to ensure that entities regulated under both schemes can comply with the different programs’ requirements. For this reason, we stated that should our proposal to adopt the new e-Rx criterion (§ 170.315(b)(11)) be finalized prior to January 1, 2020, we also proposed to permit continued certification to the current 2015 Edition ‘‘electronic prescribing’’ criterion (§ 170.315(b)(3)) that references NCPDP SCRIPT standard version 10.6 for the period of time in which that version of the NCPDP SCRIPT standard would continue to be used in the CMS Medicare Part D E-prescribing Program or the CMS Promoting Interoperability Programs. Finally, we proposed in 84 FR 7445 that once NCPDP SCRIPT standard version 10.6 is no longer used in those Programs, we would no longer permit certification to that criterion and would remove it from the Code of Federal Regulations, and that we would consider setting an effective date for such actions in a subsequent final rule VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 based on stakeholder feedback and CMS policies at the time. In addition to continuing to reference the current transactions included in § 170.315(b)(3), in keeping with CMS’ Modernizing Part D and Medicare Advantage To Lower Drug Prices and Reduce Out-of-Pocket Expenses final rule (84 FR 23832), we also proposed in 84 FR 7445 and in § 170.315(b)(11) to require the support of all of the NCPDP SCRIPT standard version 2017071 transactions CMS has adopted for the Part D E-prescribing regulations in 42 CFR 423.160(b)(2)(iv). Given the January 1, 2020 effective date in CMS rulemaking (83 FR 16440) and the effective date of this final rule, we have finalized our proposed update to the new version of the standard for the electronic prescribing criterion in § 170.315(b)(3) instead of creating a new criterion as proposed in 84 FR 7427 in § 170.315(b)(11). Unlike other criteria in this final rule that allow testing to either version of a required standard until 24 months after the publication date of this final rule, we will not allow certification testing to version 10.6 of the NCPDP SCRIPT standard, as the implementation date for CMS’ new Part D E-prescribing Program of January 1, 2020 has passed. However, based on stakeholder feedback, we have finalized a transition period in 45 CFR 170.405(b)(4)(ii) of 24 months from the date of publication of this final rule for certification so developers may test and certify to the updated criterion with all associated transactions. Comments. The majority of commenters were supportive of our proposal and recommended moving to the NCPDP SCRIPT standard version 2017071 for the e-Rx certification criterion in alignment with CMS’ adoption of the standard for the Part D E-prescribing Program. However, a number of commenters expressed concern that while EHRs or other electronic prescribing systems may become certified, pharmacy information systems (PIS) lack a similar certification program and associated standards and technical capability requirements, thus creating a mismatch between the eprescribing system requirements for EHR users and PIS users. Several commenters specifically noted that PIS, which send or receive these transactions, are not required to adopt the capability to support these transactions as they are out of scope for the Program. Response. First, we note that the comments suggesting that pharmacies on the sending or receiving end of Part D e-Rx transactions are not required to utilize NCPDP SCRIPT standard version PO 00000 Frm 00038 Fmt 4701 Sfmt 4700 2017071 transactions are inaccurate. To the extent that a pharmacy conducts electronic prescribing with prescribers e-prescribing Part D covered drugs for Part D eligible individuals, those pharmacies are required to use the NCPDP SCRIPT version 2017071 standard. While there may not be 2015 Edition certification criteria to which pharmacy information systems can be certified, the Part D rules require support of the standard under the Part D E-prescribing Program. Thus, we believe the mismatch concerns raised by commenters are unfounded. As a general matter, Part D prescribers need health IT systems capable of conducting compliant transactions (regardless of ONC certification) and so too do Part D receiving pharmacies. ONC health IT certification will provide an added layer of assurance for Part D prescribers that their e-Rx systems have been tested and certified as being capable of accurately conducting the adopted NCPDP SCRIPT standard version 2017071 transactions.42 In addition, we received several comments related to the readiness of PIS for specific transactions beyond those defined for Part D. We include these comments as applicable in the discussion of each transaction below. We reiterate that PIS are outside the scope of the ONC Health IT Certification Program, and we acknowledge the challenge of pharmacy readiness to support all transactions at this time, but if they conduct e-Rx for part D covered drugs prescribed to Part D eligible Medicare beneficiaries, they will be required to use the standard we are adopting for our program by the Medicare Part D e-Rx Program—so if they do e-prescribing at all, we expect that they will be able to conduct transactions using the standard adopted here. Generally, the goal of certification is to ensure that Health IT Modules voluntarily submitted for the Program are capable of conducting the transactions as specified. This ensures that providers have the capability to use the certified product for these transactions where feasible. For this reason, we have finalized the transactions as described below for certified Health IT Modules and encourage pharmacy information system developers to advance their capacity to support a nationwide network of fully interoperable pharmacy information systems. Comments. As noted, the majority of commenters were supportive of the proposal to remove the 2015 Edition 42 https://www.govinfo.gov/content/pkg/FR-201510-16/pdf/2015-25597.pdf. E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations certification criterion (codified in § 170.315(b)(3)) that references NCPDP SCRIPT standard version 10.6 and replace it with an updated e-Rx criterion (proposed to be codified in § 170.315(b)(11)). Commenters requested that ONC work with CMS on a smooth transition and timeline that would allow adequate time for the development, testing, and full adoption of these updates. A number of commenters stated that the NCPDP SCRIPT standard version 2017071 is not backward compatible with NCPDP SCRIPT standard version 10.6, and therefore there should be no transition period where both standards are applicable. Commenters sought clarity on the timing of the change and expressed concerns that developers and providers may face operational issues in their adoption of version 2017071 of the NCPDP SCRIPT standard by January 1, 2020. Commenters recommended that ONC allow certification timelines that support compliance with Part D while allowing adequate time to mitigate the risk associated with the additional requirements for certification to the proposed criterion. Response. We appreciate the support expressed by commenters as well as the concern about maintaining alignment between required standards across HHS. We note that the CMS requirement for Part D e-Rx transactions includes a compliance date of January 1, 2020, and that industry feedback notes a consistent and deliberate move toward readiness for the adoption of the new standard for Part D e-Rx, including by health IT industry leaders supporting pharmacy implementation. We believe that this overall industry readiness supports our adoption of the update to the standard for certification purposes and to be in alignment with the required standard update for Part D e-Rx purposes. In response to the request for a smooth transition and continuity of certification for health care providers, we have finalized a revision to the existing criterion in § 170.315(b)(3) rather than removing and replacing the criterion. In order to support the transition to the new standard for Part D, at the request of stakeholders, ONC issued guidance 43 in the third quarter of CY2019 stating, ‘‘. . . developers of 2015 Edition certified Health IT Modules certified to the e-prescribing criterion adopted at 45 CFR 170.315(b)(3) are permitted to update 43 For Part D covered drugs prescribed for Part D eligible individuals. ONC Electronic Prescribing Certification Companion Guide: https:// www.healthit.gov/test-method/electronicprescribing. VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 their products to use the NCPDP SCRIPT standard version 2017071 to meet CMS’ compliance requirements . . .’’ This guidance also noted that ONC would discontinue certification of new products to the electronic prescribing certification criterion using version 10.6 of the NCPDP SCRIPT standard as of January 1, 2020. In consideration of the comments we received, we have finalized our proposal to update the electronic prescribing (eRx) NCPDP SCRIPT standard used for electronic prescribing in the 2015 Edition to NCPDP SCRIPT standard version 2017071, which results in a new e-Rx standard becoming the baseline for certification. As the effective date of this final rule will occur after January 1, 2020, we have not finalized our proposal to permit new products to continue to be certified to the prior standard until the January 1, 2020 date. Instead, we discontinued certification of new products to the former electronic prescribing criterion using the NCPDP SCRIPT standard version 10.6 to align with CMS requirements. We have finalized this update as a modification to the existing certification criterion rather than as a separate new certification criterion to allow for a smooth transition, and to allow for continuity with the certification(s) issued to Health IT Modules for § 170.315(b)(3) prior to January 1, 2020 that are updated under the ONC guidance. This approach will also continue to allow for compliance with the January 1, 2020 timeline for CMS’ Medicare Part D e-Rx and Medication History standards. As noted by commenters, we understand that there is a lack of backward compatibility between the two standards. In order to allow for a reasonable transition period to certification to the full set of NCPDP SCRIPT transactions and other requirements defined in the updated eRx certification criterion, we have framed our Maintenance of Certification in section 45 CFR 170.405(b)(5)(ii) with flexibility that will allow health IT developers up to 24 months from the date of publication of this final rule to test and certify to the updated criterion reflective of all NCPDP SCRIPT 2017071 transactions to demonstrate full conformance with the updated criterion. After January 1, 2020, use of the NCPDP SCRIPT 10.6 standard will be prohibited under the Part D program, so we do not expect or anticipate health IT systems certified to § 170.315(b)(3) will conduct Part D transactions using that standard. We also recognize, however, for the purposes of maintaining a product certificate with § 170.315(b)(3) in its PO 00000 Frm 00039 Fmt 4701 Sfmt 4700 25679 scope, that these 24 months from the date of publication from this final rule enable continued compliance and oversight associated with other capabilities in § 170.315(b)(3) that are not applicable for Part D, and for which conformance is still required. We have finalized this 24-month period for the update for this criterion under the real world testing provisions in § 170.405(b)(5) as follows: • Electronic Prescribing. A health IT developer with health IT certified to § 170.315(b)(3) prior to June 30, 2020, must: Æ Update their certified health IT to be compliant with the revised versions of this criterion adopted in § 170.315(b)(3)(ii); and Æ Provide its customers of the previously certified health IT with certified health IT that meets paragraph (b)(5)(i) of this section by May 2, 2022. a. Electronic Prescribing Standard and Certification Criterion Comments. Commenters expressed concerns about standardization generally within the context of eprescribing. Several commenters expressed concern about using the NCPDP SCRIPT standard version 2017071, the RxNorm standard, as a requirement for e-prescribing, and other standards such as Fast Healthcare Interoperability Resources (FHIR). One commenter further stated that only inventory (packaging or unit dose strength) codes are standardized in RxNorm, and that drug regimens should be standardized and made computable in RxNorm for safety reasons. Another commenter noted that RxNorm does not index brand names exhaustively with a single unique ID for each branded drug, but that current indexing only allows for generic-level interoperability and only at unit dose level. One commenter expressed concern that the criterion as proposed does not appear to support medication assisted treatment (MAT) for opioid use disorder (OUD) and other long-acting medications. Another commenter stated a hope that standards such as the NCPDP SCRIPT version 2017071 standard can ease data integration into the workflow, lessen burden, and help achieve greater compliance with policy and legal requirements for querying State prescription drug monitoring programs (PDMP). Another commenter supported the adoption of the NCPDP SCRIPT standard version 2017071 because the standard supports the prescribing of compound medications and the sig (i.e., instructions) field is not limited to 140 characters. E:\FR\FM\01MYR3.SGM 01MYR3 25680 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations Some commenters also provided suggestions to improve the NCPDP SCRIPT 2017071 standard and its availability to the public by the standards developing organization. Another commenter stated that today’s NCPDP standards are not in an APIready format, and recommended CMS and ONC collaborate with NCPDP to explore API FHIR standards specific to the HL7 Da Vinci Project for a January 2022 effective date or later. A few commenters stated that because many NCPDP standards are not openly accessible and require a paid membership to obtain the technical specifications, our adoption could limit widespread adoption and a standardized implementation nationwide. Several commenters suggested that ONC adopt FHIR as a standard for the Program, and for the eRx criterion specifically. We also received several comments that are out of scope which are not addressed in this rulemaking. Response. We appreciate the commenters’ consideration of the standards. We note that RxNorm is a standard maintained by the National Library of Medicine (NLM). ONC adopted RxNorm to represent medication information as a vocabulary standard in § 170.207(d) (80 FR 62612). We encourage all developers who have experience with, and feedback relevant to, RxNorm to contact NLM. As a reminder, RxNorm is considered a minimum standard code set under the Program, and developers are permitted to upgrade their products to comply with a newer version of RxNorm without adversely affecting a product’s certification status pursuant to 45 CFR 170.555(b)(2) as long as no other law prohibits such action. In reference to the OUD prevention and treatment-related concerns that commenters expressed, we note that the NCPDP SCRIPT 2017071 standard does support the exchange of medicines used in medication-assisted treatment (MAT) for opioid use disorder treatment purposes. An electronic prescription of controlled substances transaction containing a MAT drug such as buprenorphine can be sent from a prescriber to a pharmacy through the specified transactions, and the updated § 170.315(b)(3) criterion also requires the inclusion of a reason for the prescription using <Diagnosis><Primary> or <Secondary> elements, or optionally, the technology must be able to receive and transmit the reason for the prescription using the <IndicationforUse> element. In addition, the RxHistoryRequest transaction contains a patient consent VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 indicator that the receiving entity must evaluate for accurate reporting. We are also aware that many PDMPs across the country accept reporting of medication history transactions containing buprenorphine, naltrexone, and other medications that could be used in the treatment of OUD. We thank commenters for their input related to improvements that could be made to the NCPDP SCRIPT version 2017071 standard, however NCPDP is a member-driven standards developing organization that requires membership in order to participate in standards developing and to access standards and implementation guides. We appreciate the suggestion to provide a direct link to the appropriate NCPDP SCRIPT standard implementation guide, but we have no authority over the business processes of standards developing organizations like NCPDP. We encourage any and all participants with an interest in improving the standard to engage with NCPDP. Regarding the recommendation for ONC to collaborate with NCPDP to explore FHIR, we appreciate the suggestion and support any advancements in technical standards and frameworks that support interoperability. At this time, NCPDP SCRIPT standard version 2017071 has not been mapped to FHIR, but ONC will continue to monitor the industry for opportunities to align the ONC Health IT Certification Program with industry developments. Comments. Five commenters fully supported all proposed transactions and requirements detailed in the Proposed Rule. The vast majority of commenters noted concerns about the proposed criterion specific to the transactions proposed for adoption in the § 170.315(b)(11) e-Rx certification criterion; details in support or not in support of adoption as proposed are further detailed for each type of transaction below. As a whole, the primary concerns for the transactions and requirements as proposed include the following: (1) EHRs are required to comply with the new transactions and requirements, while receiving pharmacy information systems are not; (2) lack of pharmacy adoption and readiness, as sufficient adoption should occur prior to making the transactions required; and (3) implementation of the proposed transactions and requirements is resource intensive, if not prohibitive, in order to meet the January 1, 2020 deadline set by CMS. Several commenters suggested either an extension or that certain transactions should be made optional. Response. We appreciate all of the public comments and have modified the PO 00000 Frm 00040 Fmt 4701 Sfmt 4700 transactions to specify which transactions are finalized as required for Health IT Modules for purposes of obtaining or retaining certification to § 170.315(b)(3), which are optional for Health IT Modules for purposes of obtaining or retaining certification to § 170.315(b)(3), and any other § 170.315(b)(3) requirements below. Additional public comment received and related responses are grouped below based on the comment’s relation to the specific transactions. We note that ‘‘optional’’ for the purposes of certification does not mean, and should not be interpreted as, ‘‘optional’’ for Part D E-prescribing Program compliance. To the extent that prescribers and pharmacies conduct electronic prescribing with Part D covered drugs prescribed for Part D eligible individuals they will be required to use the NCPDP SCRIPT 2017071 standard to conduct those transactions under the Part D E-prescribing Program. Thus, a transaction designated as ‘‘optional’’ for the purposes of certification means a health IT developer can elect to have that transaction explicitly tested as part of certification for its product or can choose not to do so—either will allow its product to be certified to § 170.315(b)(3). We reiterate that comments regarding CMS’ January 1, 2020 timeline are out of scope as we cannot change CMS’ policy or its timeline. b. Electronic Prescribing Transactions In addition to adopting the NCPDP SCRIPT version 2017071 standard for the transactions that are listed in the current ‘‘electronic prescribing’’ criterion (§ 170.315(b)(3)), we also proposed to adopt and require conformance to all of the NCPDP SCRIPT version 2017071 standard transactions CMS adopted in 42 CFR 423.160(b)(2)(iv). We proposed this updated 2015 electronic prescribing criterion to therefore include the following transactions: i. Create and Respond to New Prescriptions (NewRx, NewRxRequest, NewRxResponseDenied) We proposed in 84 FR 7444 to enable a user to perform the related electronic transactions for NewRx, NewRxRequest and NewRxResponseDenied. A NewRx transaction is a new prescription from a prescriber to a pharmacy so that it can be dispensed to a patient. A NewRxRequest is a request from a pharmacy to a prescriber for a new prescription for a patient. A NewRxResponseDenied is a denied response to a previously sent NewRxRequest (if approved by the E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations prescriber, a NewRx would be sent instead). A NewRxResponseDenied response may occur when the NewRxRequest cannot be processed or if information is unavailable. Comments. While the NewRx transaction received unanimous support as a required transaction for adoption in the updated § 170.315(b)(3) criterion, the vast majority of commenters opposed adopting the NewRxRequest and NewRxResponseDenied transactions as required transactions primarily due to a lack of adoption by the PIS involved in the exchange. Several commenters stated that the NewRxRequest and NewRxResponseDenied is not yet in broad use. A commenter who supported adoption of NewRxRequest and NewRxRequestDenied believed that they may be beneficial for electronic prescribing of controlled substances (EPCS) and noted that pharmacies have expressed interest in implementation. Response. In consideration of public comments, we have adopted NewRx as a required transaction, and NewRxRequest and NewRxResponseDenied as optional transactions in the updated § 170.315(b)(3) electronic prescribing criterion. We have finalized these latter two transactions as optional in response to commenters’ concerns regarding a lack of adoption by the PIS that would be involved in the exchange. Additionally, we note that pursuant to the certification criterion, health IT presented for certification must be capable of including the reason for the prescription as referenced in the updated § 170.315(b)(3)(ii) or § 170.315(b)(3)(ii)(D) in the NewRx transaction. ii. Request and Respond to Change Prescriptions (RxChangeRequest, RxChangeResponse) We proposed in 84 FR 7444 to enable a user to perform the related electronic transactions for RxChangeRequest and RxChangeResponse. An RxChangeRequest transaction originates from a pharmacy and may be sent to a prescriber to: Request a change in the original prescription (new or fillable); validate prescriber credentials; request a review by a prescriber of the drug requested; or obtain prior authorization from the payer for the prescription. An RxChangeResponse transaction originates from a prescriber to respond to: A prescription change request from a pharmacy; a request for a prior authorization from a pharmacy; or a prescriber credential validation request from a pharmacy. VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 25681 iii. Request and Respond to Cancel Prescriptions (CancelRx, CancelRxResponse) adoption in place before it is a certification requirement. Response. We thank commenters for their overall support of the proposed CancelRx and CancelRxResponse transactions. In light of the commenters’ overall support for the proposed CancelRx transactions and in order to support patient safety and the free flow of communication between prescribers and pharmacies, we have included these transactions as required in the revised § 170.315(b)(3) electronic prescribing criterion. We reiterate that although PIS are outside the scope of the ONC Health IT Certification Program, we encourage pharmacy information system developers to advance their capacity to support a nationwide network of fully interoperable PIS. Additionally, we note that pursuant to the certification criterion, health IT presented for certification must be capable of including the reason for the prescription as referenced in the updated § 170.315(b)(3)(ii) or § 170.315(b)(3)(ii)(D) in the CancelRx transaction. We proposed in 84 FR 7444 to enable a user to perform the related electronic transactions for CancelRx and CancelRxResponse. A CancelRx transaction is a request from a prescriber to a pharmacy to not fill a previously sent prescription. A CancelRx must contain pertinent information for the pharmacy to be able to find the prescription in their system (patient, medication (name, strength, dosage, form), prescriber, and prescription number if available). A CancelRxResponse is a response from a pharmacy to a prescriber to acknowledge a CancelRx, and is used to denote if the cancellation is approved or denied. Comments. The majority of public comments reflected support for finalizing CancelRx and CancelRxResponse as required transactions. One commenter stated that the CancelRx transaction will reduce cost and improve patient safety, as patients may have remaining refills available that are subsequently modified based on a physician’s new assessment. Another commenter noted that certified technology currently supports CancelRx transactions in version 10.6 of the NCPDP SCRIPT standard and encouraged developers to upgrade their technology to support CancelRx transactions in NCPDP SCRIPT standard version 2017071, as these transactions provide great value to end users. One commenter expressed concern for pharmacy readiness for CancelRx, and felt there should be sufficient industry iv. Request and Respond to Renew Prescriptions (RxRenewalRequest, RxRenewalResponse) We proposed in 84 FR 7444 to enable a user to perform the related electronic transactions for RxRenewalRequest and RxRenewalResponse. An RxRenewalRequest transaction originates from a pharmacy to request additional refills beyond those originally prescribed. An RxRenewalResponse transaction originates from a prescriber to respond to the request from the pharmacy. Comments. Commenters supported adoption of the RxRenewalRequest and RxRenewalResponse transactions as proposed. One commenter stated that these transactions could be implemented after the CMS deadline of January 1, 2020 without loss of current functionality. Another commenter said that these transactions are widely used in the industry and provide great value to end users. Response. We appreciate the support for the RxRenewalRequest and RxRenewalResponse transactions and have included these transactions as required in the updated § 170.315(b)(3) electronic prescribing criterion. We reiterate that the entire updated § 170.315(b)(3) criterion and requirements must be met before certification can be granted. Additionally, we note that pursuant to the certification criterion, health IT presented for certification must be capable of including the reason for the prescription as referenced in the Comments. Most commenters supported the proposed adoption of the RxChangeRequest and RxChangeResponse transactions. One commenter recommended against adoption until industry adoption is more widely spread across retail pharmacies and demonstrates value. Response. Because the majority of commenters were in support of adoption of the RxChangeRequest and RxChangeResponse transactions as proposed, we have included these transactions as required in the updated § 170.315(b)(3) electronic prescribing criterion. Additionally, we note that pursuant to the certification criterion, health IT presented for certification must be capable of including the reason for the prescription as referenced in the updated § 170.315(b)(3)(ii) or § 170.315(b)(3)(ii)(D) in the RxChangeRequest and RxChangeResponse transactions. PO 00000 Frm 00041 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25682 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations updated § 170.315(b)(3)(ii) or § 170.315(b)(3)(ii)(D) in the RxRenewalRequest and RxRenewalResponse transactions. v. Receive Fill Status Notifications (RxFill, RxFillIndicatorChange) We proposed in 84 FR 7444 to enable a user to perform the related electronic transactions for RxFill and RxFillIndicatorChange. An RxFill transaction is sent from a pharmacy to a prescriber or long term and post-acute care (LTPAC) facility indicating the FillStatus (dispensed, partially dispensed, not dispensed or returned to stock, or transferred to another pharmacy) of the new, refill, or resupply prescriptions for a patient. RxFillIndicator informs the pharmacy of the prescriber’s intent for fill status notifications for a specific patient/ medication. An RxFillIndicatorChange is sent by a prescriber to a pharmacy to indicate that the prescriber is changing the types of RxFill transactions that were previously requested, and in which the prescriber may modify the fill status of transactions previously selected or may cancel future RxFill transactions. Comments. While the RxFill transaction received unanimous support as a required transaction, the vast majority of comments opposed adopting the RxFillIndicatorChange as proposed due to a lack of industry adoption and broad use by PIS. One commenter stated that there has not been a significant use case for the RxFillIndicatorChange transaction to prescribers. A few commenters suggested that ONC wait to require the RxFillIndicatorChange until this transaction is more widely adopted by both prescribers and pharmacies and value is realized in the industry, and suggested either removing RxFillndicatorChange from the proposed criterion or making this transaction optional. Another commenter argued that RxFillIndicatorChange should be optional as development to support this transaction in NCPDP SCRIPT standard version 2017071 would be resource intensive. Commenters in support of the adoption of the RxFillIndicatorChange transaction stated it is the only way to alter the prescriber notification preferences in an ambulatory or acute setting outside of a fillable message. Commenters supporting adoption of the RxFillIndicatorChange transaction further noted that, historically, the lack of prescriber control over notification messages may have had an impact on hindering adoption. One commenter suggested that, in lieu of the RxFillIndicatorChange transaction, VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 EHRs receive all fill notifications and subsequently use logic to bring the clinician’s attention to only important indicators. Response. We appreciate all of the comments that supported the RxFill transaction and the RxFillIndicatorChange transaction. After consideration of comments received on the RxFill and RxFillIndicatorChange transactions, we have adopted the RxFill transaction as required and the RxFillIndicatorChange transaction as optional in the updated § 170.315(b)(3) electronic prescribing criterion. We encourage further development and innovation to address the concerns that we heard from commenters, and we will continue to monitor advancements in standards and technology for future rulemaking. We reiterate that PIS are outside the scope of the ONC Health IT Certification Program and encourage pharmacy information system developers to advance their capacity to support a nationwide network of fully interoperable PIS. Additionally, we note that pursuant to the certification criterion, health IT presented for certification must be capable of including the reason for the prescription as referenced in the updated § 170.315(b)(3)(ii) or § 170.315(b)(3)(ii)(D) in the RxFill transaction. vi. Request and Receive Medication History (RxHistoryRequest, RxHistoryResponse) We proposed in 84 FR 7444 to enable a user to perform the related electronic transactions for RxHistoryRequest and RxHistoryResponse. An RxHistoryRequest transaction is a request from a prescriber to a pharmacy for a list of medications that have been prescribed, dispensed, claimed, or indicated by a patient. An RxHistoryResponse is a response to an RxHistoryRequest containing a patient’s medication history. It includes the medications that were dispensed or obtained within a certain timeframe, and optionally includes the prescriber that prescribed it. Comments. Commenters supported adoption of the RxHistoryRequest and RxHistoryResponse transactions as proposed. One commenter also stated that both transactions could facilitate EHR and other health IT data integration with PDMP systems, yet noted that in many cases, State law or policy prohibits data integration between EHRs and PDMPs. Another commenter stated that these transactions are widely used in the industry and provide great value to end users. PO 00000 Frm 00042 Fmt 4701 Sfmt 4700 Response. We appreciate all comments we have received on the use of the RxHistoryRequest and RxHistoryResponse transactions. We agree with the commenter that the RxHistoryRequest and RxHistoryResponse transactions support data integration between health IT systems such as EHRs and other information technology systems such as PDMPs, and encourage any efforts made by developers to fully integrate prescription and other health data into a provider’s workflow within allowable law. We reiterate that ONC does not have control over State laws that govern PDMPs. We will continue to monitor regulatory and industry advancements in this area and will take them into consideration in future rulemaking. We have adopted these transactions as required in the updated § 170.315(b)(3) electronic prescribing criterion. Additionally, we note that pursuant to the certification criterion, health IT presented for certification must be capable of including the reason for the prescription as referenced in the updated § 170.315(b)(3)(ii) or § 170.315(b)(3)(ii)(D) in the RxHistoryResponse transaction. vii. Ask the Mailbox If There Are Any Transactions (GetMessage) We proposed in 84 FR 7444 to enable a user to perform the electronic transaction GetMessage for Ask the Mailbox. This transaction is used by the prescriber or pharmacy when asking the mailbox if there are any transactions. It is the basis for the mechanism used by a prescriber or pharmacy system to receive transactions from each other, from a payer, or from the Risk Evaluation and Mitigation Strategy (REMS) Administrator via a switch acting as a mailbox. Comments. Approximately half of commenters opposed adoption of the GetMessage transaction and the other half supported adoption in the updated § 170.315(b)(3) electronic prescribing criterion. Commenters not in support of the GetMessage transaction asserted that it is not in use by prescribers and that it is an obsolete method of message retrieval. Commenters in support of adoption argued that it is applicable when not transacting with real-time messaging, and should be adopted as an optional transaction. Response. We thank commenters for their input. After careful consideration of all comments received, and in our ongoing efforts to align with CMS Part D requirements, we have determined to adopt the GetMessage transaction as optional for the updated § 170.315(b)(3) electronic prescribing criterion. E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations viii. Relay Acceptance of a Transaction Back to the Sender (Status) We proposed in 84 FR 7444 to enable a user to perform the related electronic transaction to relay acceptance of a transaction back to the sender. A Status transaction in response to any applicable transaction other than GetMessage indicates acceptance and responsibility for a request. A Status transaction in response to GetMessage indicates that no mail is waiting for pickup. A Status transaction cannot be held in an electronic mailbox and may not contain an error. Comments. Commenters supported adoption of the Status transaction as proposed. Two commenters noted that since the transaction is an acknowledgement, it would not contain the reason for the prescription as referenced in the updated § 170.315(b)(3)(ii) or § 170.315(b)(3)(ii)(D). Response. We appreciate all comments in support of the Status transaction and have included this transaction as required in the updated § 170.315(b)(3) electronic prescribing criterion. As an acknowledgement, we agree that the NCPDP SCRIPT version 2017071 standard does not support the conveying the reason for the prescription in the Status transaction, and have modified the requirement to reflect this. ix. Respond That There Was a Problem With the Transaction (Error) We proposed in 84 FR 7444 to enable a user to perform the related electronic transaction for Error response. This transaction indicates an error has occurred and that the request was terminated. An Error can be generated when there is a communication problem or when the transaction actually had an error. An Error can be held in an electronic mailbox, as it may be signifying to the originator that a transaction was unable to be delivered or encountered problems in the acceptance. The Error must be a different response than a Status, since the communication between the system and the mailbox must clearly denote the actions taking place. An Error is a response being delivered on behalf of a previous transaction, while Status signifies no more mail. Comments. Commenters supported adoption of the Error transaction as proposed. Two commenters noted that since the transaction is an acknowledgement, it would not contain the reason for the prescription as referenced in the updated VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 § 170.315(b)(3)(ii) or § 170.315(b)(3)(ii)(D). Response. We appreciate all comments in support of the Error transaction and have included this transaction as required in the updated § 170.315(b)(3) electronic prescribing criterion. As an acknowledgement, we agree that the NCPDP SCRIPT version 2017071 standard does not support the reason for the prescription in the Error transaction, and we have modified that requirement to reflect this. x. Respond That a Transaction Requesting a Return Receipt Has Been Received (Verify) We proposed in 84 FR 7445 to enable a user to perform the related electronic transaction for Verify. This transaction is a response to a pharmacy or prescriber indicating that a transaction requesting a return receipt has been received. Verifications result when a ‘‘return receipt requested’’ flag is set in the original request. Upon receiving a transaction with ReturnReceipt set, it is the responsibility of the receiver to either generate a Verify in response to the request (recommended), or generate a Status in response to this request, followed subsequently by a freestanding Verify transaction. This transaction notifies the originator that the transaction was received at the software system. It is not a notification of action taking place, since time may elapse before the ultimate response to the transaction may take place. Comments. Commenters supported adoption of the Verify transaction as proposed. Two commenters noted that since the transaction is an acknowledgement, it would not contain the reason for the prescription as referenced in the updated § 170.315(b)(3)(ii) or § 170.315(b)(3)(ii)(D). Response. We appreciate all comments in support of the Verify transaction and have included this transaction as required in the updated § 170.315(b)(3) electronic prescribing criterion. As an acknowledgement, we agree that the NCPDP SCRIPT standard version 2017071 does not support the reason for the prescription in the Verify transaction, and we have modified that requirement to reflect this. xi. Request to Send an Additional Supply of Medication (Resupply) We proposed in 84 FR 7445 to enable a user to perform the related electronic transaction for Resupply. This transaction is a request from a Long Term and Post-Acute Care (LTPAC) organization to a pharmacy to send an additional supply of medication for an PO 00000 Frm 00043 Fmt 4701 Sfmt 4700 25683 existing order. An example use case is when a medication supply for a resident is running low (e.g., 2–3 doses) and a new supply is needed from the pharmacy. In such a circumstance, the LTPAC organization sends the Resupply transaction as a way to notify the pharmacy that an additional supply for the medication is needed. Comments. Commenters expressed concern over adopting this transaction as a required transaction for a few reasons. Some commenters noted that the Resupply transaction is only applicable to LTPAC practice settings for management of on-site pharmacy inventory and for communication between a LTPAC facility and a contracted pharmacy. Other commenters mentioned that PIS on the sending or receiving end of the transaction are not required to support this transaction. Some commenters stated that this transaction is not widely adopted among prescribers, and that it should not be adopted until this occurs. Two commenters requested that we either remove the transaction from the final rule or make the Resupply transaction optional. Other commenters stated that while this transaction may be beneficial in the future, it was their opinion that it is premature to require the Resupply transaction in the electronic prescribing criterion at this time. Response. We appreciate all comments related to the Resupply transaction and have included this transaction as optional in the updated § 170.315(b)(3) electronic prescribing criterion. We are aware of several ONCcertified EHRs and other health IT that were either designed exclusively for, or were expressly designed to support, LTPAC providers in addition to other institutions, and encourage those and other developers to undergo certification testing to the Resupply transaction. Additionally, we note that pursuant to the certification criterion, health IT presented for certification must be capable of including the reason for the prescription as referenced in the updated § 170.315(b)(3)(ii) or § 170.315(b)(3)(ii)(D) in the Resupply transaction. We reiterate that PIS are outside the scope of the ONC Health IT Certification Program and encourage pharmacy information system developers to advance their capacity to support a nationwide network of fully interoperable PIS. xii. Communicate Drug Administration Events (DrugAdministration) We proposed in 84 FR 7445 to enable a user to perform the related electronic transaction for DrugAdministration. E:\FR\FM\01MYR3.SGM 01MYR3 25684 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations This transaction communicates drug administration events from a prescriber or care facility to the pharmacy or other entity. It is a notification from a prescriber or care facility to a pharmacy or other entity that a drug administration event has occurred (e.g., a medication was suspended or administration was resumed). Comments. Commenters expressed concern over adopting this transaction as a required transaction for a few reasons. Some commenters noted that the DrugAdministration transaction is only applicable to LTPAC practice settings and is therefore not relevant to the scope of all certified health IT products, though one commenter noted that there could be possible value of this transaction in ambulatory and acute care settings as well. In addition, one commenter reported LTPAC organizations interested in potentially using e-prescribing transactions rated DrugAdministration as a low priority transaction type, meaning there may not be a wide user base interested in implementing it. Response. We appreciate comments related to the DrugAdministration transaction and have included this transaction as optional in the updated § 170.315(b)(3) electronic prescribing criterion. We are aware of several ONCcertified EHRs and other health IT that were either designed exclusively for, or are used in support of, LTPAC providers, and encourage those and other developers to undergo certification testing to the DrugAdministration transaction. In light of the commenters’ concerns, we have adopted the DrugAdministration transaction as optional because the ONC Health IT Certification Program is agnostic to care settings and programs, yet still supports many different use cases. This allows the ONC Health IT Certification Program to support multiple program and setting needs, including but not limited to the Promoting Interoperability Programs and long term and post-acute care. Because the transaction will be optional in the updated (b)(3) criterion, developers whose clients do not support long term care settings will not be required to demonstrate their capacity to send this transaction. xiii. Request and Respond to Transfer One or More Prescriptions Between Pharmacies (RxTransferRequest, RxTransferResponse, RxTransferConfirm) We proposed in 84 FR 7445 to enable a user to perform the related electronic transactions for RxTransferRequest, RxTransferResponse and VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 RxTransferConfirm. The RxTransferRequest transaction is used when the pharmacy is asking for a transfer of one or more prescriptions for a specific patient to the requesting pharmacy. The RxTransferResponse transaction is the response to the RxTransferRequest which includes the prescription(s) being transferred or a rejection of the transfer request. It is sent from the transferring pharmacy to the requesting pharmacy. The RxTransferConfirm transaction is used by the pharmacy receiving (originally requesting) the transfer to confirm that the transfer prescription has been received and the transfer is complete. Comments. The vast majority of commenters expressed concerns with the proposal to adopt RxTransferRequest, RxTransferResponse, and RxTransferConfirm transactions as proposed because they are only used in pharmacy-to-pharmacy transactions and are not applicable to EHRs. Further, two commenters noted that PIS are not required to support these transactions. Conversely, the two commenters that supported these transactions cited the benefit of allowing pharmacies to transfer unfilled controlled substance prescriptions, including Schedule 2, between pharmacies. Response. We thank commenters for their input. We proposed to require all of the NCPDP SCRIPT 2017071 standard transactions CMS adopted in 42 CFR 423.160(b)(2)(iv) to illustrate our continued dedication to establish and maintain complementary policies to ensure that the current standard for certification to the electronic prescribing criterion permits use of the current Part D e-Rx and MH standards. With consideration of comments, and because it was not the intent of this certification criterion to include pharmacy specific transactions for the purposes of certification, we have adopted RxTransferRequest, RxTransferResponse, and RxTransferConfirm as optional in the updated § 170.315(b)(3) electronic prescribing criterion. We reiterate that PIS are outside the scope of the ONC Health IT Certification Program and encourage pharmacy information system developers to advance their capacity to support a nationwide network of fully interoperable PIS. xiv. Recertify the Continued Administration of a Medication Order (Recertification) We proposed in 84 FR 7445 to enable a user to perform the related electronic transaction for Recertification. This transaction is a notification from a PO 00000 Frm 00044 Fmt 4701 Sfmt 4700 LTPAC facility, on behalf of a prescriber, to a pharmacy recertifying the continued administration of a medication order. An example use is when an existing medication order has been recertified by the prescriber for continued use. Comments. Commenters expressed concern over adopting the Recertification transaction as proposed primarily because it is only applicable to LTPAC practice settings. One commenter stated that LTPAC organizations interested in potentially using e-prescribing transactions rated Recertification as a low priority transaction type, suggesting that there may not be a wide user base interested in using it. Response. We appreciate all comments in support of the Recertification transaction. In light of commenters concerns, we have adopted this transaction as optional in the updated § 170.315(b)(3) electronic prescribing criterion. We are aware of several ONC-certified EHRs and other health IT that were either designed expressly for or in support of LTPAC providers, among other institutions, and encourage those and other developers to undergo certification testing to the Recertification transaction. xv. Complete Risk Evaluation and Mitigation Strategy (REMS) Transactions (REMSInitiationRequest, REMSInitiationResponse, REMSRequest, and REMSResponse) We proposed in 84 FR 7445 to enable a user to perform the related electronic transactions for REMSInitiationRequest, REMSInitiationResponse, REMSRequest, and REMSResponse. With CMS’ adoption of these transactions in their recently issued final rule associated with e-Rx for Medicare Part D (42 CFR 423.160(b)(2)(iv)(W)–(Z)), we believe that it will be beneficial to include these four REMS transactions as part of this certification criterion: REMSInitiationRequest, REMSInitiationResponse, REMSRequest, and REMSResponse. Furthermore, under the Food and Drug Administration Amendments Act (FDAAA) of 2007 (Pub. L. 110–85), the Food and Drug Administration (FDA) requires REMS from a pharmaceutical manufacturer if the FDA determines that a REMS is necessary to ensure the benefits of a drug outweigh the risks associated with the drug. In support of our sister agencies’ work, we therefore proposed to include the REMS transactions as part of this certification criterion. E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations Comments. The vast majority of commenters supported adoption of REMSInitiationRequest, REMSInitiationResponse, REMSRequest, and REMSResponse as optional, not required, transactions. Those in support of the transactions as proposed suggested that ONC should develop strategies to encourage providers to consciously consider and appropriately act on alerts to reduce the risk that these messages can easily be clicked through and missed, particularly if that provider is experiencing alert fatigue. Multiple reasons were provided by commenters who stated that the proposed REMS transactions should be adopted as optional in the proposed certification criterion. These reasons included the state of system readiness and adoption by manufacturers, REMS administrators, and pharmacy information systems. Another commenter stated that these REMS transactions are not yet in widespread use and should be piloted before being required as they require extensive design and development effort. Response. Given comments in support of the REMSInitiationRequest, REMSInitiationResponse, REMSRequest, and REMSResponse transactions, we have included these transactions as optional in the updated § 170.315(b)(3) electronic prescribing criterion. We encourage commenters, developers, and other stakeholder to review and provide feedback on sections related to REMS (https:// www.healthit.gov/isa/allows-aprescriber-communicate-a-remsadministrator) and all other electronic prescribing use cases on the ONC Interoperability Standards (ISA) and post suggested edits and updates on these transactions as the industry advances. We encourage manufacturers, REMS administrators, and pharmacy information system developers to adopt these and other NCPDP SCRIPT standard version 2017071 transactions to improve safe prescribing practices and patient safety, and encourage developers to test their capacity to send and receive REMS messages by utilizing the testing tools that are available. xvi. Electronic Prior Authorization The Part D E-prescribing prior authorization process in 84 FR 28450 through 28458 requires that providers supply additional clinical information to verify that the medication can be covered under the Medicare Part D benefit. The prior authorization process is intended to promote better clinical decision-making and ensure that patients receive medically necessary prescription drugs. We are looking for VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 ways that would streamline the process for exchanging clinical and financial data amongst prescribers and payers for prior authorization and improve patients’ access to needed medications. Electronic prior authorization (ePA) automates this process by allowing providers to request and respond to electronic prior authorization transactions within their workflow. Using electronic prior authorization (ePA) transactions in the NCPDP SCRIPT standard version 2017071 provides a standard structure for exchanging prior authorization (PA) questions and answers between prescribers and payers, while allowing payers to customize the wording of the questions. Electronic prior authorization transactions will additionally support the automation of the collection of data required for PA consideration, allowing a health IT developer to systemically pull data from a patient’s medical record. The efficiency gains offered by the ePA transactions in the NCPDP SCRIPT standard version 2017071 are the primary driver behind the development of this new capability. We believe the adoption of the ePA transactions included in version 2017071 of the NCPDP SCRIPT standard as optional transactions aligns with CMS’ proposals for Part D ePA, and therefore, will not be adopting NCPDP SCRIPT standard version 2013101 as suggested by the commenter. On June 17, 2019, CMS issued the Secure Electronic Prior Authorization for Medicare Part D proposed rule (84 FR 28450), including a proposed new transaction standard for the Medicare Prescription Drug Benefit program’s (Part D) e-prescribing program. Under this proposal, Part D plan sponsors would be required to support version 2017071 of the NCPDP SCRIPT standard for four ePA transactions, and prescribers would be required to use that standard when performing ePA transactions for Part D covered drugs they wish to prescribe to Part D eligible individuals. While not currently adopted as part of the Part D eRx standard, the NCPDP SCRIPT standard version 2017071 includes eight transactions that would enable the prescribers to initiate medication ePA requests with Part D plan sponsors at the time of the patient’s visit. The eight transactions are: PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse, PACancelRequest, and PACancelResponse. Comments. Several commenters recommended the adoption of the ePA transactions available in the NCPDP PO 00000 Frm 00045 Fmt 4701 Sfmt 4700 25685 SCRIPT standard version 2017071 for a variety of reasons, including improving efficiencies in the prior authorization process, improving patient outcomes, reducing point-of-sale rejections, increasing health IT developer adoption, and improving the Medicare Part D member experience. Several commenters indicated that lack of vendor support for the ePA transactions is a major barrier to physician use of the transactions. One commenter also suggested ONC adopt the NCPDP SCRIPT standard version 2013101 prior authorization transactions. Response. We thank commenters for their feedback. In consideration of comments, we have adopted the ePA transactions in the NCPDP SCRIPT standard version 2017071 as optional for the updated § 170.315(b)(3) electronic prescribing criterion. We believe the adoption of the ePA transactions included in version 2017071 of the NCPDP SCRIPT standard as optional transactions aligns with CMS’ proposals for Part D ePA. We note that this final rule allows only for the voluntary certification of Health IT Modules by health IT developers to support these transactions, and does not require the certification, adoption, or use of such Health IT Modules by health care providers for this or any other purpose. We also note that development, testing, and implementation to support these transactions are important first steps toward integrating pharmacies in the prior authorization process for Part D prescriptions, while supporting widespread industry adoption and reducing burden on providers. We refer readers to the ONC Strategy on Reducing Regulatory and Administrative Burden Relating to the Use of Health IT and EHRs,44 drafted in partnership with CMS, for further discussion of potential opportunities to ease related clinician burden through improved health IT enabled processes. xvii. Reason for the Prescription For each transaction specified, the technology must be able to receive and transmit the reason for the prescription. Comments. Commenters supported continued adoption of the reason for the prescription in specific electronic prescribing transactions. Some commenters noted that some of the proposed transactions would not contain the reason for the prescription as referenced in the updated 44 https://www.healthit.gov/topic/usability-andprovider-burden/strategy-reducing-burden-relatinguse-health-it-and-ehrs. E:\FR\FM\01MYR3.SGM 01MYR3 25686 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations § 170.315(b)(3)(ii) or § 170.315(b)(3)(ii)(D). Response. We thank commenters for their feedback. We reiterate our decision to require Health IT Modules seeking certification to the updated electronic prescribing certification criterion to be capable of including the reason for the prescription as referenced in the updated § 170.315(b)(3)(ii) or § 170.315(b)(3)(ii)(D) within relevant electronic prescription transactions to support patient safety and align with HHS goals to expand safe, high quality health care. Health IT certified to the updated § 170.315(b)(3) criterion must have the capacity to enable a user to receive and transmit the reason for the prescription using the diagnosis elements: <Diagnosis><Primary> or <Secondary>, or optionally, the technology must be able to receive and transmit the reason for the prescription using the <IndicationforUse> element, and be consistent with the International Statistical Classification of Diseases and Related Health Problems (ICDs) sent in the diagnosis element(s). The <IndicationforUse> element defines the indication for use of the medication as meant to be conveyed to the patient, and is included in the Sig. This requirement would apply to the following NCPDP SCRIPT standard version 2017071 transactions that we have adopted in this criterion (see discussion above): NewRx, RxChangeRequest, RxChangeResponse, CancelRx, RxRenewalRequest, RxRenewalResponse, RxFill, RxHistoryResponse, Resupply, RxTransferRequest, RxTranferResponse, REMSInitiationRequest, REMSInitiationResponse, REMSRequest, REMSResponse, PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse, PACancelRequest, and PACancelResponse. xviii. Oral Liquid Medications Limit a user’s ability to prescribe all oral liquid medications in only metric standard units of mL (i.e., not cc). Comments. While not within the scope of the Proposed Rule, one commenter did not support the continued requirement to prescribe oral liquids in ‘‘mL’’ units. The commenter supported the use of metric units, but did not agree with the requirement of the ONC Health IT Certification Program to limit this to only milliliters. The commenter recommended that the unit of measure used by a prescriber be at their discretion, as long as it is appropriate for the dosage. VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 Response. We thank the commenter for the input. Because this requirement is out of scope for the Proposed Rule in that we did not propose to change this conformance requirement, we decline to relax or retire the requirement for oral liquid medications to be prescribed in mL units. When we first adopted this requirement for the 2015 Edition Proposed Rule, several commenters were supportive of improving patient safety through use of the metric standard for dosing, but recommended that this requirement only apply to oral liquid medications. Incorrect dosage is a common error with liquid medication, often resulting from confusion between different dose measurements (e.g., mL and teaspoons). If these measurements are confused with each other, too much or too little of the medicine can be given. This requirement is also in alignment with NCPDP SCRIPT implementation recommendations. xix. Signatura (Sig) Element The Signatura (Sig) element is used to support electronic prescribing for the consistent expression of patient directions for use by relaying this information between a prescriber and a pharmacist. It must be legible, unambiguous, and complete to ensure the prescriber’s instructions for use of the medication are understood. For each transaction, the technology must be able to receive and transmit the reason for the prescription using the indication elements in the SIG Segment. Comments. One commenter requested that the Sig element be required rather than optional to aid in future medication reconciliation and clinical reporting. Another commenter noted that the NCPDP SCRIPT standard version 2017071 allows for an increase in Sig length. Response. Given the lack of attention paid to and support for modifying the electronic prescribing criterion for Sig from optional to required, we have decided to retain Sig as optional in the updated § 170.315(b)(3) criterion. As discussed in the Reason for Prescription section, health IT may optionally seek certification to the updated electronic prescribing criterion by demonstrating their capacity to receive and transmit the reason for the prescription using the Sig element. xx. Real Time Pharmacy Benefit While development is still currently underway by NCPDP, the Real-Time Pharmacy Benefit (RTPB) standard is not yet complete. When complete, the RTPB standard is expected to facilitate the ability for pharmacy benefit payers/ processors to communicate formulary PO 00000 Frm 00046 Fmt 4701 Sfmt 4700 and benefit information to providers. In the absence of that or another similar standard, CMS has adopted policies requiring the development and/or implementation of Real Time Benefit Transaction (RTBT) standards in the Part D e-Rx Program in the context of recent rulemaking. On May 16, 2019, CMS issued the Modernizing Part D and Medicare Advantage to Lower Drug Prices and Reduce Out-of-Pocket Expenses final rule, which includes a requirement under the electronic prescribing standards that Part D plan sponsors implement one or more electronic real-time benefit tools that are capable of integrating with at least one prescriber’s electronic prescribing system or electronic health record no later than January 1, 2021 (84 FR 23832). One commenter recommended that CMS and ONC coordinate with NCPDP on requirements for real-time benefit functionality. We are also aware of industry efforts to develop a consumer-facing real-time pharmacy benefit functionality FHIR®-based implementation guide that we anticipate will be balloted in 2020. ONC will continue to monitor these efforts and consider proposing the NCPDP RTPB standard or a similar standard to enable real-time benefit transactions in future rulemaking. xxi. Other Comments Received Outside the Scope of This Rule We note that we received several comments specifically addressing the electronic prescribing of controlled substances and prescription drug monitoring programs. We note that these specific comments are outside the scope of the proposals finalized in this rule. However, we note that we included a discussion of these topics in relation to the discussion of the RFI on OUD prevention and treatment in the Proposed Rule in 84 FR 7461. 5. Clinical Quality Measures—Report Criterion In the 2015 Edition final rule, ONC adopted four clinical quality measure (CQM) certification criteria, § 170.315(c)(1) CQMs—record and export, § 170.315(c)(2) CQMs—import and calculate, § 170.315(c)(3) CQMs— report, and § 170.315(c)(4) CQMs—filter (80 FR 62649 through 62655). These four criteria were adopted with the intent to support providers’ quality improvement activities and in electronically generating CQM reports for reporting with certified health IT to programs such as the EHR Incentive Programs, Quality Payment Program, and Comprehensive Primary Care plus initiative. The ‘‘CQMs—report’’ E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations certification criterion (§ 170.315(c)(3)) included an optional certification provision for demonstrating that the health IT can create Quality Reporting Document Architecture (QRDA) reports in the form and manner required for submission to CMS programs, which is in accordance with CMS’ QRDA Implementation Guide (IGs). The CMS QRDA IGs provide technical guidance and specific requirements for implementing the HL7 QRDA Category I (QRDA I) and Category III (QRDA III) standards for reporting to CMS quality reporting programs.45 The CMS QRDA IGs include the formal template definitions and submission criteria for submitting QRDA documents to the Comprehensive Primary Care Plus (CPC+) and Merit Based Incentive Payments System (MIPS) Programs. Some of the conformance statements in the HL7 QRDA standards have been further constrained to meet the specific requirements from these CMS programs. The CMS QRDA IGs also only list the templates specifying CMS-specific reporting requirements from the base HL7 QRDA standards. QRDA I is an individual-patient-level report. It contains quality data for one patient for one or more electronic clinical quality measures (eCQMs). QRDA III is an aggregate quality report. A QRDA III report contains quality data for a set of patients for one or more eCQMs. Since the 2015 Edition final rule was published, we have gained additional certification experience and received feedback from the industry that health IT certified to the ‘‘CQMs—report’’ criterion (§ 170.315(c)(3)) are only/ primarily being used to submit eCQMs to CMS for participation in CMS’ programs. Therefore, as a means of reducing burden, we proposed to remove the HL7 CDA® Release 2 Implementation Guide: QRDA I; Release 1, Draft Standard for Trial Use (DSTU) Release 3 (US Realm), Volume 1 (§ 170.205(h)(2)), as well as the QRDA Category III, Implementation Guide for CDA® Release 2 (§ 170.205(k)(1)) and the Errata to the HL7 Implementation Guide for CDA® Release 2: QRDA Category III, DSTU Release 1 (US Realm), September 2014 (§ 170.205(k)(2)) standard requirements (HL7 QRDA standards) from the current 2015 Edition CQMs—report criterion in § 170.315(c)(3), and we also proposed to 45 The following resources provide additional information on the differences between the CMS QRDA and the HL7 QRDA standards: https:// ecqi.healthit.gov/system/files/QRDA_HQR_2019_ CMS_IG_final_508.pdf (pg. 38) and https:// ecqi.healthit.gov/sites/default/files/2019-07/2020CMS-QRDA-III-Eligible-Clinicians-and-EP-IG07182019-508.pdf (pg. 18). VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 require that health IT certified to the current 2015 Edition CQMs—report criterion support the CMS QRDA IGs (84 FR 7446). We stated that this change would directly reduce burden on health IT developers and indirectly providers as they would no longer have to develop and support two forms of the QRDA standard. We also solicited comment in the Proposed Rule on the future possibility of FHIR-enabled APIs replacing or complementing QRDA-based quality reporting. We also noted in the Proposed Rule that the Fast Health Interoperability Resources (FHIR®) standard offers the potential for supporting quality improvement and reporting needs, and holds the potential of being a more efficient and interoperable standard to develop, implement, and utilize to conduct quality reporting through APIs. We believe until the potential benefits of FHIR® APIs can be realized for quality reporting, and that solely requiring the CMS QRDA IGs for the updated 2015 Edition ‘‘CQMs—report’’ criterion will balance the burden on developers, while still ensuring module users’ abilities to meet their quality reporting obligations to CMS (84 FR 7446). To support the proposal, we proposed to incorporate by reference in § 170.299 the latest annual CMS QRDA IGs, specifically the 2019 CMS QRDA I IG for Hospital Quality Reporting 46 (§ 170.205(h)(3)) and the 2019 CMS QRDA III IG for Eligible Clinicians and Eligible Professionals (§ 170.205(k)(3)).47 We noted in the Proposed Rule that developers would be able to update certified health IT to newer versions of the CMS QRDA IGs through the real world testing Maintenance of Certification provision for standards and implementation specification updates in § 170.405(b). We also proposed that a Health IT Module would need to be certified to both standards to ensure flexibility for Health IT Module users. We solicited comment on whether to consider an approach that would permit certification to only one of the standards depending on the care setting for which the Health IT Module is designed and implemented. Comments. The majority of commenters were supportive of the proposal to remove the HL7 QRDA standard requirements from the 2015 Edition CQMs—report criterion in 46 https://ecqi.healthit.gov/system/files/QRDA_ HQR_2019_CMS_IG_final_508.pdf. 47 https://ecqi.healthit.gov/system/files/2019_ CMS_QRDA_III_Eligible_Clinicians_and_EP_IG508.pdf. PO 00000 Frm 00047 Fmt 4701 Sfmt 4700 25687 § 170.315(c)(3), and to require that health IT certified to the criterion support the proposed CMS QRDA IGs. Some commenters observed that the main use cases for the certified QRDA export functionality (which is specific to CMS eCQMs) are to support direct data submission to CMS at the conclusion of reporting periods, to enable use of third party data submission Health IT Modules to meet CMS reporting requirements, and to support data extraction for registry reporting for participation in CMS programs such as MIPS. Commenters noted that while in some cases the extraction of data using a QRDA may also support other use cases—for example for a registry—because of the specificity of the criteria to the CMS eCQMs, such a transaction using the certified functionality is primarily for CMS reporting. Commenters noted the use of the CMS QRDA IG does not impede use of the data for other purposes. Finally, commenters noted that ONC should continue to provide health IT developers the flexibility to offer a non-certified QRDA functionality that could support eCQMs beyond those included for CMS programs. One commenter observed that while some health IT systems also provide tools for internal quality performance monitoring, those tools often do not rely on the generation of QRDA exports. Some commenters reported that the technical support of multiple versions of QRDA standards is unnecessary. Other commenters recommended maintaining only the HL7 standard or offering certification to the HL7 standard as an optional alternative to the CMS QRDA IG. One commenter who recommended maintaining both the HL7 standard and the CMS QRDA IGs suggested that ONC cite the CMS version(s) of the QRDA IG as a technical resource in the same manner the C–CDA companion guide is cited for the transition of care criteria and only require certifying to the HL7 version. These commenters agreed that developers should not have to certify to both HL7 QRDA and CMS QRDA IGs, but suggested if a developer passed certification for the CMS QRDA IGs, they should be deemed to have achieved certification to the HL7 QRDA standard as well. Commenters noted that the CMS QRDA apply specifications to the HL7 QRDA to support CMS eCQM reporting requirements. Other commenters specifically stated that the HL7 QRDA should remain as an optional certification criterion, since other organizations (e.g., certain hospital accreditation organizations such as The Joint Commission) use the E:\FR\FM\01MYR3.SGM 01MYR3 25688 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations HL7 QRDA, and there is need to assure the same style for submission across programs. They recommended that the HL7 QRDA IG persist as a continuing option in the Program to enhance alignment with other standards and C– CDA, and to encourage a base standard alignment across implementers such as CMS and The Joint Commission. They stated that citing only to the CMS QRDA IG may lead to misalignment with the base standards and reduce incentives to update the base standard. Some commenters expressed concern over the proposed removal of HL7 QRDA standards from the original 2015 Edition CQMs, stating it may undermine private sector efforts to self-regulate and stated that the removal of the HL7 QRDA may not achieve the envisioned burden reduction through the mere elimination of developers’ need to certify and maintain multiple standards. While some commenters suggested that removing HL7 QRDA from the certification criteria could simplify the reporting process by recognizing the widespread use of CMS’ QRDA IGs, they noted that the HL7 QRDA is currently the standard for most EHR systems and questioned how ONC proposed to implement this change given the prominence of HL7 standards in EHR systems. Several commenters noted that the disconnect between what the certification testing required, and how the standard was really being used in the industry (primarily but not exclusively to meet the CMS QRDA IG) created unnecessary certification testing burden, and asserted that the adoption of the CMS proprietary IG was more appropriate than to maintain HL7 QRDA. Response. We thank commenters for their support for the proposal and comments regarding the versions of standards. We understand the concerns expressed in opposition to this proposal, and we appreciate specifically the identification of potential risk for the elimination of the HL7 standard as applicable for other use cases. As noted previously, since the 2015 Edition final rule was published (October 16, 2015), we have gained received feedback from the industry that health IT certified to the ‘‘CQMs—report’’ criterion (§ 170.315(c)(3)) are only or primarily being used to submit eCQMs to CMS for participation in CMS’ programs. In addition, we note that while the HL7 QRDA may be used for other purposes, the ‘‘CQMs—report’’ criterion (§ 170.315(c)(3)) is specific to the CMS eCQMs specified for participation in CMS reporting programs and no other eCQMs are tested under that criterion. This specificity applies not only to the VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 current 2015 Edition ‘‘CQMs—report’’ criterion, but also to the other 2015 Edition CQM criteria and the prior 2014 Edition CQM criteria. This specificity is intended to provide assurances through testing and certification of the accuracy and standardization of CMS program measures across platforms, while recognizing that it would not be possible to specifically test to the entire universe of potential eCQMs in use by health care providers. Because of this dependency, testing and certification of both the HL7 QRDA for CQMs-report and the CMS QRDA IG is redundant to support eCQM data reporting. This has a dual impact on our considerations to finalize our proposal to require only the CMS QRDA IG. First, for use cases that are not related to CMS eCQM reporting, the certified functionality would not specifically support third party non-CMS eCQM reporting requirements, and so the modification to the functionality does not change the inability to use the certified version of the functionality for such purposes. Second, for those use cases involving registries or other third parties that are implementing or supporting CMS eCQM reporting, use of the CMS QRDA IG could additionally support such purposes. In addition, we are not restricting health IT developers from creating and providing to customers a non-certified functionality that supports the HL7 QRDA for the extraction of data for eCQMs that are not CMS eCQMs. We note that this is not a change from the prior policy allowing such flexibility. The prior certification for the QRDA IG included testing of CMS eCQMs only and it neither supported nor restricted any development of a QRDA functionality for non-CMS eCQMs. We also agree that this approach will support closer alignment between the testing to the CMS QRDA IG specifications for a certified health IT module and the technical requirements for CMS program reporting. As part of the development of the CMS QRDA IGs, CMS strives to use the annual update process to resolve issues with CQMs based on updates to clinical guidelines and to advance the requirements as the standard for reporting eCQM data matures. In this way, aligning the criterion to the CMS program requirements that it specifically supports allows for alignment between these efforts as well as allowing for continued updates through the standards version advancement process. We also believe our finalized proposal will not impede private sector initiatives as the CMS IGs support the continued efforts by public/private PO 00000 Frm 00048 Fmt 4701 Sfmt 4700 collaboration through standards developing organizations (SDOs) to refine standards. Therefore, as a means of reducing burden, we have finalized our proposal to remove the HL7 QRDA standard requirements from the 2015 Edition CQMs—report criterion in § 170.315(c)(3). We maintain our position that this would directly reduce burden on health IT developers and indirectly for health care providers as there would no longer be a requirement to develop and support two forms of the QRDA standard. We note that this does not preclude developers from continuing to support the underlying standard, especially where such standard may support reporting or health information exchange for other quality or public health purposes. Instead, we are simply not requiring testing and certification of any such standards, thereby eliminating testing and certification burden from a criterion that is at this time scoped to the purpose of reporting for CMS quality programs. Comments. A few commenters did not support the proposal but instead recommended that CMS adopt the HL7 QRDA standard and do away with its own. However, several commenters offered suggestions to CMS on the development of the CMS QRDA IG and the alignment to the HL7 QRDA standard. A number of commenters noted the National Technology Transfer and Advancement Act of 1995 principle that Federal agencies are generally required to use technical standards that are developed by voluntary consensus standards bodies rather than a proprietary standard specific to an HHS program. Commenters also stated if CMS wanted to retain certain aspects of its standard, it should work with HL7 to get these vetted, balloted and approved for inclusion within the HL7 standard. Commenters also recommended working with SDOs or other organizations to sufficiently support CMS QRDA IGs. Some commenters suggested that consolidation of QRDA standards would be more likely result in reducing provider burdens than what ONC proposed. Response. We thank the commenters for their recommendations to improve the CMS QRDA IGs, or for CMS to work toward including the aspects of CMS QRDA IGs that they require for their program operations in SDO-balloted and approved consensus standards. Specific suggestions for CMS IG development are outside the scope of this rule. ONC had previously included the HL7 QRDA standards for certification in the 2015 Edition in order to potentially support a broader range of use cases than E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations reporting for CMS programs. However, the specificity of the criterion to the CMS eCQMs limits the utility of the certified functionality beyond use with CMS eCQMs and as stated in the Proposed Rule, since the 2015 Edition final rule, ONC and CMS received significant stakeholder feedback that health IT modules certified to the ‘‘CQMs—report’’ criteria at 170.314(c)(3) in the 2014 Edition and 170.315(c)(3) for the 2015 Edition are used only or primarily for reporting to CMS programs. While we reiterate that these comments are outside the scope of this rule, we will continue to take this and other feedback into consideration and will continue to work with CMS, standards developing organizations, and health IT industry partners to explore the concerns raised in relation to reducing burden and promoting interoperable standards for quality reporting. Comments. Commenters provided mixed feedback on whether the updated 2015 Edition ‘‘CQMs—report’’ criterion should require adherence to both CMS QRDA IGs, specifically the 2019 CMS QRDA I IG for Hospital Quality Reporting 48 and the 2019 CMS QRDA III IG for Eligible Clinicians and Eligible Professionals.49 The majority of commenters recommended that to reduce burden, ONC should consider a certification approach that permits developers to seek certifications based on the care setting(s) their health IT modules are intended serve. For example, commenters suggested that ONC should only require certification to the 2019 QRDA I IG for Hospital Quality Reporting if a Health IT Module is designed exclusively for the reporting of hospital measures, and only require certification to the 2019 QRDA III IG for Eligible Clinicians and Eligible Professionals when a Health IT Module is designed exclusively for the reporting of ambulatory measures. In instances in which both populations are served, the developer would then seek certification to both standards. Commenters suggested this approach would avoid the unnecessary burden of certifying to a standard that the Health IT Module was not intended to serve. Other commenters stated that the certification requirements should ensure that certified Health IT Modules can support quality measure reporting by all potential users, especially given the potential expansion of eligible https://ecqi.healthit.gov/system/files/QRDA_ HQR_2019_CMS_IG_final_508.pdf. 49 https://ecqi.healthit.gov/system/files/2019_ CMS_QRDA_III_Eligible_Clinicians_and_EP_IG508.pdf. 48 VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 participants in certain CMS programs (e.g., should a program expand from hospital-based only to include ambulatory measures). These commenters recommended the adoption of a requirement for certified Health IT Modules to calculate and export both CMS QRDA I patient-level reports for Hospital Quality Reporting and CMS QRDA III aggregate summary reports for Eligible Clinicians and Eligible Professionals. These commenters noted that if a certified Health IT Module can only send an aggregate report without a patient level report, then this would greatly diminish the ability to verify the underlying calculations. However, commenters recommended that ONC clarify that the transition to CMS QRDA I IG-based reports (patient-level, QRDA I IG for Hospital Quality Reporting) does not necessarily mean that a hospital quality measure must be certified by any system (i.e., an ambulatory Health IT Module can certify to only CMS QRDA III IG requirements). Commenters also sought clarity that the transition to QRDA III reports (aggregate-level, IG for Eligible Clinicians and Eligible Professionals) does not necessarily mean that an ambulatory quality measure must be certified by any system (i.e., a hospital system can certify to only hospital measures). Finally, one commenter noted that certifying ambulatory quality measures for the QRDA I to a hospital IG is not effective and will interfere with the use case of using QRDA I to combine data between multiple ambulatory systems such as for group reporting. Response. We thank commenters for their comments regarding whether a Health IT Module should be certified to both CMS QRDA IG standards or whether to consider an approach that permits certification to only one of the standards depending on the care setting for which the Health IT Module is designed and implemented. We agree with commenters that our certification approach should prevent unintended burden by tailoring the requirements to the type of measures being tested. This would mean that for the updated certification criterion ‘‘CQMs—report’’ in § 170.315(c)(3) a Health IT Module testing only ambulatory measures would test only with the CMS QRDA III IG for ambulatory measures and a Health IT Module testing only inpatient measures would test only with the QRDA I CMS IG for inpatient measures. A Health IT Module supporting both ambulatory and inpatient measures would be required to test to both the CMS QRDA I IG and the CMS QRDA III IG. We clarify that testing for the 2015 Edition ‘‘CQM— PO 00000 Frm 00049 Fmt 4701 Sfmt 4700 25689 capture and export’’ criterion in § 170.315(c)(1) criteria includes demonstrating the capability to export a QRDA I report specific to the eCQM being tested—which would support use case noted by the commenter to combine data across multiple ambulatory systems. We have not proposed and have not finalized a change to the 2015 Edition ‘‘CQM— capture and export’’ criterion in § 170.315(c)(1). We further note that health IT developers may leverage QRDA file formats for a wide range of use cases and that our inclusion of the CMS QRDA I and QRDA III IGs does not prohibit the use of the QRDA standard for any other purpose. As noted above, we have finalized the adoption of the CMS QRDA IGs for the ‘‘CQMs—report’’ criterion in § 170.315(c)(3) for which the Health IT Module is presented for certification. Comments. The majority of commenters supported the proposal to adopt the latest CMS QRDA IGs at the time of final rule publication, as CMS updates their QRDA IGs annually to support the latest eCQM specifications and only accepts eCQM reporting to the latest version. However, a few commenters recommended that ONC monitor this part of the certification process for unintended consequences since CMS’ IGs are updated on a yearly basis. Some commenters noted that given the lack of alignment with timing, eCQM measures and standards will continue to lack testing. Other commenters recommended the IGs be updated in alignment with updates to the certification standards. A few commenters requested clarification of the effective dates and asked ONC to evaluate and propose a timeline for the implementation of an alignment between the programs. In addition, commenters asked for clarification on whether ONC will propose penalties for providers who may be unable to meet the timeline if it is insufficient. Response. We thank commenters for their input and have adopted the latest CMS QRDA IG versions available at the time of publication of this final rule. For details on the latest CMS QRDA IGs, we refer readers to the CMS QRDA I Implementation Guide for Hospital Quality Reporting and CMS QRDA III Implementation Guide for Eligible Clinicians and Eligible Professionals available on the eCQI Resource Center website.50 We note that CMS updates 50 The Electronic Clinical Quality Improvement (eCQI) Resource Center. CMS QRDA I Implementation Guide for Hospital Quality Reporting and CMS QRDA III Implementation Guide for Eligible Clinicians and Eligible E:\FR\FM\01MYR3.SGM Continued 01MYR3 25690 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations the CMS eCQMs on an annual basis as well as the CMS QRDA IGs for reporting to CMS programs. As in prior years going back to the 2014 Edition, HHS will continue to update the Cypress testing tool to support health IT developer testing to the most recent annual update. We note that CMS has previously required that EHR technology used for eCQM reporting be certified to all eCQMs but does not need to be recertified each time it is updated to a more recent version of the eCQM electronic specifications, unless the EHR technology is supporting new eCQMs or functionality (such as the ‘‘CQM—filter’’ criterion in § 170.315(c)(4)) (84 FR 42505). This approach allows for continued updates to and testing of eCQMs while minimizing the burden on developers and providers to support those updates in time for each annual performance period. Finally, we note that ONC has no authority to set requirements, incentives, or penalties for health care providers related to the use of health IT, and we direct readers to CMS for information on health IT requirements in CMS programs. Comments. The majority of commenters agreed with ONC’s assessment in the Proposed Rule that quality reporting is not yet ready to transition to FHIR and that more testing and validation of FHIR is needed before requiring a new API-based reporting functionality as a part of the Program. Some commenters supported the adoption of FHIR Release 4-enabled APIs as a replacement for QRDA-based reports, but stated that published documentation aligning HL7 C–CDA, QRDA, and/or FHIR standards to CMS’ ‘‘Quality Data Model,51’’ which is an information model that defines relationships between patients and clinical concepts in a standardized format to enable electronic quality performance measurement and that would allow for more consistent eCQM reporting and improved interoperability in clinical quality feedback between health systems and data registries. Other commenters stated that FHIR standards will likely strengthen standardized data element availability and flexibility to improve the types of eCQMs that may be developed, and suggested that CMS continue to work with the National Quality Forum, measure stewards, and measure developers to advance both existing evidence-based measures (e.g., either administrative or hybrid measures) and evolving outcome Professionals. Available at: https:// ecqi.healthit.gov/qrda. 51 https://ecqi.healthit.gov/qdm. VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 measures that utilize population-based electronic clinical data. Response. We thank commenters for their support. We believe there are potential benefits to be gained by exploring both near-term, program specific implementations of APIs to support current quality reporting submission mechanisms such as for CMS eCQM reporting as well as the long-term potential to reimagine quality measurement by leveraging API technologies. We believe that these technology approaches could help providers and payers, including CMS, move from the current approach, in which providers are required to calculate and submit results on specific quality measures, to one in which payers, including CMS, could obtain clinical data for quality measurement directly through an API. This could potentially include the ability to obtain clinical data for a defined group or sample set of patients to assess quality across patient populations, as well as to compare clinical data for patients over time to assess quality impacts through longitudinal measurement. We believe emerging innovative standards are now available to support such models, specifically the ability to respond with clinical data for a defined group or sample set of patients using the bulk data capabilities in FHIR Release 4. We note that readiness for such an approach, both for recipients of quality data and for health IT developers supporting quality improvement solutions, is not yet mature for adoption of such a criterion in the Program. However, we are committed to continuing to work with HHS partners, health care providers, health IT developers and SDOs to explore the potential for such solutions in the future. Comments. Several commenters recommended additional changes not considered in the Proposed Rule. For example, one commenter recommended ONC require that to be certified in § 170.315(c)(1) ‘‘CQMs—record and export,’’ § 170.315(c)(2), ‘‘CQMs— import and calculate,’’ and § 170.315(c)(3) ‘‘CQMs—report,’’ a Health IT Module be certified in a minimum of 9 eCQMs instead of one eCQM and that the § 170.315(c)(1) criterion should require the ability to export all patients for a given eCQM. Currently, the ability to export a QRDA I file can be limited to one patient at a time. Commenters noted that this limitation defeats the purpose of data interoperability and does not advance the goals of ONC to increase access to data and the interoperability of Health IT Modules. And another commenter PO 00000 Frm 00050 Fmt 4701 Sfmt 4700 recommended that, in addition to the adoption of the CMS IGs under the § 170.315(c)(3) criterion, that the CMS IGs replace the corresponding HL7 QRDA IGs as ONC’s Program standard under the § 170.315(c)(1) criterion (which currently references QRDA I exclusively) and § 170.315(c)(2) criterion (which currently references only QRDA I as standard, but also involves use of QRDA III for purposes of verifying appropriate calculation of measures from imported QRDAs). Response. We thank commenters for input and clarifications. While we appreciate comments suggesting changes to § 170.315(c)(1) ‘‘CQMs— record and export,’’ and § 170.315(c)(2) ‘‘CQMs—import and calculate,’’ the recommended changes are outside the scope of our proposal. Therefore, while we may consider these recommendations for future Program rulemaking, we have not adopted the suggested changes to § 170.315(c)(1) ‘‘CQMs—record and export,’’ or § 170.315(c)(2) ‘‘CQMs—import and calculate in this final rule. As noted previously, we have finalized the update to the ‘‘CQMs— report’’ criterion in § 170.315(c)(3) to require that health IT developers use the CMS QRDA IG appropriate to the measures being submitted for testing and certification to read as follows: ‘‘Clinical quality measures—report. Enable a user to electronically create a data file for transmission of clinical quality measurement data 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 QRDA, category III, for ambulatory measures in § 170.205(k)(3).’’ 6. Electronic Health Information (EHI) Export Criterion We proposed to adopt a new 2015 Edition certification criterion referred to as ‘‘EHI Export’’ in § 170.315(b)(10). The criterion’s conformance requirements were intended to support two contexts in which we believed that all EHI produced and electronically managed by a developer’s technology should be made readily available for export as a capability of certified health IT. First, we proposed in § 170.315(b)(10)(i) at 84 FR 7447 that health IT certified to this criterion would support single patient EHI export upon a valid request by a patient or a user on the patient’s behalf. Second, we proposed in § 170.315(b)(10)(ii) at 84 FR 7447 that the proposed criterion would support the export of all EHI when a health care E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations provider chooses to transition or migrate information to another health IT system. Third, we proposed in § 170.315(b)(10)(iii) that the export format(s) used to support the exports must be made available via a publicly accessible hyperlink, including keeping the hyperlink up-to-date with the current export format. At the time of the Proposed Rule, we indicated our belief that this proposed certification criterion provided a useful first step toward enabling patients to have electronic access to their EHI and equipping health care providers with better tools to transition patient EHI to another health IT system. We noted that this criterion would create a baseline capability for exporting EHI. We requested comments regarding the proposed single patient EHI export and the proposed database export functionalities, as well as the proposed scope of data export and other criterion elements throughout the Proposed Rule section at 84 FR 7447 through 7449. Comments. Commenters generally supported the intent of the proposed ‘‘EHI export’’ criterion to advance the access, exchange, and use of EHI. Commenters in favor of the criterion and its proposed conformance requirements stated that it would foster innovative export capabilities and inform areas where additional standards development could be needed. We also received a variety of comments asking for adjustments to proposed requirements. A majority of commenters requested revisions to the criterion, including calling for a defined set of data elements for export and specific data transport standards. Many commenters offered recommended standards or requested that we provide specific standards to reduce variation. These commenters indicated that no defined standard could lead to broad interpretation and potential inadequacies of the data export. Some commenters expressed a medical record keeping concern that the proposed standards-agnostic approach for the export functionality could be problematic, stating that the export could create a dissonance if the EHI renders health record content in a form or format that is different from what a provider produces or utilizes as output. Other commenters opposed the adoption of this proposed criterion. These commenters expressed concern that later implementation of standards, such as APIs, would make developers invest time and funding into the proposed requirements only for the work to be discarded in the future. Response. We thank commenters for their feedback on the proposed ‘‘EHI VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 export’’ criterion at 84 FR 7446 of the Proposed Rule (§ 170.315(b)(10)). We have considered commenters’ concerns, support, and recommendations and adopted a revised version of this certification criterion. This final certification criterion is designed to align with section 4006(a) of the Cures Act, which requires the Secretary, in consultation with the National Coordinator, to promote policies that ensure that a patient’s EHI is accessible to that patient and the patient’s designees, in a manner that facilitates communication with the patient’s health care providers and other individuals (84 FR 7447). In addition, this criterion complements other provisions that support patients’ access to their EHI and health care providers use of EHI, such as the secure, standardbased API certification criterion (proposed in 84 FR 7427 and finalized in § 170.315(g)(10)), and also supports longitudinal data record development. Therefore, we have finalized the criterion with revisions. Notably, in response to comments on this criterion and the proposed information blocking policies, we have adopted a focused definition of EHI in § 170.102 and § 171.102. For context purposes, the EHI definition is focused on ‘‘electronic protected health information as defined in 45 CFR 160.103 to the extent that it would be included in a designated record set as defined in 45 CFR 164.501’’ with additional caveats not repeated here for briefness. Put simply, the EHI definition represents the same ePHI that a patient would have the right to request a copy of pursuant to the HIPAA Privacy Rule. This is a regulatory concept with which the industry has nearly 20 years of familiarity. Health IT developers’ customer base includes health care providers who are HIPAA covered entities, and in many cases developers serve as HIPAA business associates to their covered-entity customers. Thus, health IT developers should be accustomed to identifying ePHI so that their products support appropriately securing it, the fulfillment of patient access requests, and the identification and reporting on breaches. They should, therefore, be well prepared to identify what EHI their product(s) would need to export in order to support a patient’s HIPAA right of access. The finalized criterion requires a certified Health IT Module to include export capabilities for a single patient (§ 170.315(b)(10)(i)) and patient population (§ 170.315(b)(10)(ii)) related to EHI. More specifically, the export(s) will need to include the EHI that can be PO 00000 Frm 00051 Fmt 4701 Sfmt 4700 25691 stored at the time of certification by the product, of which the Health IT Module is a part. We emphasize that such ‘‘stored’’ data applies to all EHI and is agnostic as to whether the EHI is stored in or by the certified Health IT Module or in or by any of the other ‘‘noncertified’’ capabilities of the health IT product of which the certified Health IT Module is a part. The scope of EHI applies across the product as a whole as a means to further promote the access, exchange, and use of EHI for the use cases required to be supported by this certification criterion. The finalized scope of data included in the criterion export is discussed in greater detail under the ‘‘Scope of Data Export’’ (IV.B.6.c) section below. While the data that must be exported has been more specifically scoped, the certification criterion does not require a specific standard format be used for the purposes of representing the exported EHI. We also modified the certification criterion’s documentation requirements in § 170.315(b)(10)(iii) to be more concise. As finalized, the documentation required for the export format(s) used to support (b)(10)(i) and (ii) functionality must be kept up-todate and made available via a publicly accessible hyperlink. Additional information is included under ‘‘Export Format’’ below. We appreciate the comments received regarding the specific data sets and data transmission standards for this certification criterion. We reiterate that the finalized certification criterion is specific to EHI, as defined, that can be stored at the time of certification by the product, of which the Health IT Module is part, and is not limited to a predefined data set or to specific data transmission standards. Developers are required to ensure the health IT products they present for certification are capable of exporting all of the EHI that can be stored at the time of certification by the product. We acknowledge that the amount of EHI exported and format in which such EHI is represented will differ by developer and products of which certified Health IT Modules are a part. Each product presented for certification, of which the Health IT Module is a part, will likely vary in the amount of EHI it can store. As a result, the amount of EHI that will need to be able to be exported in order to demonstrate conformance with this certification criterion will vary widely because of the diversity of products presented for certification. For example, small software components only capable of storing a certain scope of EHI (and only certified to a few certification criteria) will only need to be able to E:\FR\FM\01MYR3.SGM 01MYR3 25692 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations export that stored EHI in order to meet this certification criterion. In contrast, a more comprehensive product with an EHI storage scope well beyond all of the adopted certification criteria would by its nature need to demonstrate it could export a lot more EHI. But even in this latter case, it is important to note that while that scope of EHI may be comprehensive for that product, it may still not be all of the health information for which a health care provider is the steward and that meets the EHI definition within the health IT products deployed within their organization. In other words, a health IT user may have other health IT systems with no connection to the Certification Program that store EHI and such EHI would still be in scope from an information blocking perspective. We note all of these distinctions to make clear for and to dissuade readers from jumping to an improper conclusion that the EHI export criterion in the Certification Program is a substitute for or equivalent to the EHI definition for the purposes of information blocking. We direct readers to the information blocking section (VIII) for additional information. Unless a health care provider (which is an ‘‘actor’’ regulated by the information blocking provision) only used a single health IT product to store EHI that was also certified to this certification criterion, the EHI definition will always be larger. Regardless of the amount of EHI each product has within its scope to export, the purpose of this certification criterion is to make the EHI already available in such health IT products more easily available for access, exchange, and use by patients and their providers, which is a fundamental principle established by the Cures Act. As technology continues to advance, and as stated in the Proposed Rule at 84 FR 7447, this criterion may not be needed in the future. However, the comments suggesting we not adopt this certification criterion at all because it will be outmoded at some point in the future did not appear to acknowledge that all technology is eventually replaced for a variety of reasons. We too look forward to a day where standardsbased APIs are the predominant method for enabling electronic health information to be accessed, exchanged, and used. We strongly encourage industry partners to engage in their own consortiums, with ONC and other Federal agencies, and other stakeholders in the health IT ecosystem to advance standards development, prototypes, and pilot testing in order to ultimately build a body of evidence that could accelerate VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 the adoption and implementation timeline of technology that could either add more structure to or remove the need for this certification criterion in the future. However, we do not accept the promise of this future state as a reason to simply wait, nor do we believe that the potential of this future justifies delaying the incremental progress the industry can make. In this case, had we followed such commenters direction, we would be withholding from patients and health care providers the certainty that there would be technical capabilities within a defined time that could be used to enable the access, exchange, and use of EHI. We note that suggestions by commenters to structure the certification criterion to only move information within specific data sets or via specific standards-based export functionality would delay the ability of patients and users of health IT to access, exchange, and use the information they need and would run counter to the underlying principles supporting this certification criterion—that the electronic health information should be accessible for access, exchange, and use. For this reason, we have not included specific data set or export requirements in this certification criterion as some commenters suggested. In consideration of comments, the finalized ‘‘EHI export’’ criterion in § 170.315(b)(10) is not included in the 2015 Edition Base EHR definition, which is a modification from what we proposed. We revised the policy in recognition of comments received, including comments regarding the structure and scope of the criterion as proposed and the development burden of the criterion. As finalized here, we believe that including this certification criterion in the Conditions and Maintenance of Certification is the best place to include the requirement associated with the criterion. Thus, we have finalized the § 170.315(b)(10) certification criterion as a general certification requirement for the ONC Health IT Certification Program, and have not included it in the 2015 Edition Base EHR Definition. In general, we also note that those who use Health IT Module(s) certified to the ‘‘EHI export’’ criterion remain responsible for safeguarding the security and privacy of individuals’ EHI consistent with applicable laws and regulations related to health information privacy and security, including the HITECH Act, HIPAA Privacy and Security Rules, 42 CFR part 2, and State laws. The existence of a technical capability to make EHI more accessible and useable by Health IT Module users does not alter or change any of their PO 00000 Frm 00052 Fmt 4701 Sfmt 4700 data protection responsibilities under applicable laws and regulations. Comments. Comments received included concerns with the development and use of the certification criterion. Some commenters expressed support for the criterion’s overall flexibility but cautioned ONC to be realistic regarding the goals and expectations for the certification criterion. These commenters also expressed concern that the proposed certification criterion would result in development for an ambiguous scope of data export and would divert from work needed to achieve other interoperability goals. Other commenters stated concerns that development costs could potentially be passed onto health IT users, such as health care providers. These commenters also anticipated use and implementation challenges for users that work with multiple systems. Response. We thank commenters for sharing their concerns. In regards to the use of the capabilities required by this certification criterion, we interpreted from comments some confusion related to potential ‘‘users’’ of the health IT. As previously defined under the Program, ‘‘user’’ is a health care professional or their office staff; or a software program or service that would interact directly with the certified health IT (80 FR 62611, 77 FR 54168). We also appreciate the comments and concerns regarding the potential development burden that could result to meet the requirements of the proposed criterion. In consideration of those expressed concerns, we have narrowed the scope of data that must be exported. This more focused scope should measurably reduce the stated ambiguity by commenters and development burden for health IT developers in contrast to what was proposed (84 FR 7448). We appreciate the concerns expressed for the potential user(s) of Health IT Modules, but note that the certification criterion is designed to advance the electronic movement of data out of a product while factoring in the current variability in health IT. As always, we encourage developers to seek innovative and expedient capabilities that, at minimum, meet the requirements of the certification criterion, as well as the developing needs of their health IT users. Comments. Commenters provided alternative ideas for the criterion specific to USCDI. Some recommended amending the criterion to require the specific structure and applicable standards for USCDI elements, or starting this criterion with a minimum of USCDI data elements. Several commenters recommended expanding E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations the existing 2015 Edition ‘‘data export’’ criterion to include USCDI in lieu of the proposed ‘‘EHI export’’ criterion. Response. We thank commenters for sharing these ideas. We have finalized the ‘‘EHI export’’ criterion as described above. Our intent under this finalized criterion is to advance export functionality for single patient and patient population EHI exports, while leaving flexibility in regard to format and without assigning specific data sets due to the different scopes of data that health IT may include. Toward those ends, limiting the scope of this certification criterion to solely the data represented by the USCDI would make it no different than other USCDI bounded certification criteria already adopted and would not advance the policy interests we have expressed. In regards to comments on the existing 2015 Edition ‘‘data export’’ criterion (§ 170.315(b)(6)), we refer readers to our discussion of the criterion below. Comments. Some comments expressed confusion and asked for guidance on how this certification criterion would apply to health IT that is no longer certified. Commenters also asked for guidance on how this criterion applies to other systems that interact with Health IT Modules certified to this criterion based on the proposed scope of data for export. Response. We thank commenters for requesting clarification. We first clarify that the export functionality under this certification criterion applies to Health IT Modules presented for certification under the Program. More specifically, if a health IT developer presents for certification a health IT product of which a Health IT Module is a part and the product electronically stores EHI, certification to § 170.315(b)(10) is required. As noted in our response above, this would include the EHI that can be stored at the time of certification by the product, of which the Health IT Module is a part. This includes all EHI stored by the product’s certified and ‘‘non-certified’’ capabilities. For example, if a health IT product includes a component(s) that is presented for certification and that component stores EHI, then that EHI must be made available for export, in accordance with § 170.315(b)(10). Importantly, the scope of data required to be exported in accordance with § 170.315(b)(10) includes only to the EHI that can be stored at the time of certification by the product. We emphasize that such ‘‘stored’’ data applies to all EHI and is agnostic as to whether the EHI is stored in or by the certified Health IT Module or in or by any of the other ‘‘noncertified’’ capabilities of the health IT VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 product of which the certified Health IT Module is a part. The scope of EHI applies across the product as a whole as a means to further promote the access, exchange, and use of EHI for the use cases required to be supported by this certification criterion. a. Single Patient Export To Support Patient Access As part of this criterion, we proposed a functionality for single patient EHI export at 84 FR 7447 which would enable a user of certified health IT to timely create an export file(s), with the proposed scope of data export of all of the EHI the health IT product produces and electronically manages on a single patient. The functionality would also require a user to be able to execute this capability at any time the user chooses and without subsequent developer assistance to operate. In addition, we proposed that health IT certified to this criterion would be required to enable the ability to limit the users who could create such export file(s) in at least one of two ways: To a specific set of identified users, and (2) as a system administrative function. We also proposed that the export file(s) created must be electronic and in a computable format and that the export file(s) format, including its structure and syntax, must be included with the exported file(s). Comments. We received many comments in support of the proposal for single patient export to support patient access under the certification criterion. The majority of these commenters provided recommended revisions, including suggested transmission formats and data export content standards. Some commenters recommended the addition of this certification criterion to the list of criteria subject to real world testing. Response. We thank commenters for their feedback. We have finalized the single patient export functionality in § 170.315(b)(10)(i) with some modifications. We finalized a focused data export scope, which applies to the data expected to be available for export under the single patient export capability. We defined the scope of data that needs to be exported to EHI that can be stored at the time of certification by the product, of which the Health IT Module is a part. Thus, we have modified the title of § 170.315(b)(10)(i) to ‘‘single patient electronic health information export’’ to reflect the scope of this data export. We finalized that the capability for a user to execute a single patient export must be able to be limited at least one of two ways: To a specific set of identified users, and as a system administrative function. While we PO 00000 Frm 00053 Fmt 4701 Sfmt 4700 25693 finalized as proposed in § 170.315(b)(10)(i)(D) that the export files must be electronic and in a computable format, we modified in § 170.315(b)(10)(ii)(E) that the publicly accessible hyperlink of the export’s format must be included with the exported file(s). This modification clarifies that the user is able to access the format, and that the developer will keep their hyperlink up-to-date. We appreciate commenter’s recommendations for specific data transmission formats and data content standards, and considered the range of recommendations when developing the finalized scope of data export required for this criterion. We believe the definition of EHI as focused in § 171.102, as well as the modifications to the scope of data export, addresses the data ambiguity concerns received by commenters. We direct readers to our detailed discussion of the scope of data export below. As finalized, the certification criterion’s export, for both single and patient population EHI Export, remain standards-agnostic. We believe that the finalized certification criterion will serve as an initial step towards increased access, exchange, and use of electronically available data. We will continue working alongside industry stakeholders and will revisit export strategies as standards continue to develop and mature. We appreciate confirmation that commenters support inclusion of the criterion in § 170.315(b)(10) alongside the rest of the care coordination criteria in § 170.315(b), and have finalized that this certification criterion is part of the real world testing Condition of Certification requirement. Comments. Some commenters asked ONC to clarify how health IT developers may limit the users’ ability to access and initiate the export function in § 170.315(b)(10)(i), and to include examples of potential permissible and non-permissible behaviors. Response. We appreciate the comments received. We again clarify that ‘‘user’’ is a health care professional or their office staff; or a software program or service that would interact directly with the certified health IT (80 FR 62611, 77 FR 54168). In regards to questions on permissible behaviors for developers, the ability to limit the health IT users’ access to the single patient EHI export functionality in § 170.315(b)(10)(i) is intended to be used by and at the discretion of the organization implementing the technology. We reiterate that similar to the 2015 edition ‘‘data export’’ criterion in § 170.315(b)(6), this cannot be used by health IT developers as a way to E:\FR\FM\01MYR3.SGM 01MYR3 25694 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations thwart or moot the overarching userdriven aspect of this capability (80 FR 62646). We do not wish to limit this functionality to specific permissible or non-permissible behaviors at this time, but reaffirm in § 170.315(b)(10)(i)(B) that a user must be able to execute the single patient EHI export capability at any time the user chooses and without subsequent developer assistance to operate. To be clear, the user must be able to execute the export without the intervention of the developer. We also finalize, as proposed, in § 170.315(b)(10)(i)(C) that this capability must limit the ability of user who create such export files(s) in at least one of two ways; (1) to a specific set of identified users, and (2) as a system administrative function. Comments. The majority of comments received asked for further clarity on ‘‘timely’’ regarding a health IT user’s request to create an export file(s). Response. We thank commenters for the questions. We specify that ‘‘timely’’ means near real-time, while being reasonable and prudent given the circumstances. Comments. Commenters also sought clarity on data in electronic health records that may be shared between patients and possibly included in the export. These commenters asked if under the proposed criterion, patients have a right to information about others that may be contained in their medical record. Response. We thank commenters for submitting these questions. In regards to shared patient data concerns, we note that the export functionality requirements apply to what a product with a Health IT Module certified to this criterion must be able to do regardless of whether the developer is operating the export for a health care provider or a health care provider is maintaining and operating the technology in their own production environment. Under the HIPAA Privacy Rule, when a covered health care provider, in the course of treating an individual, collects or otherwise obtains an individual’s family medical history, this information may become part of the medical record for that individual and thus be included in the ‘‘designated record set’’ (defined at 45 CFR 164.501)). Thus, if the family medical history becomes part of the designated record set, the individual/ patient may exercise the right of access (45 CFR 164.524) under the HIPAA Privacy Rule to this information in the same fashion as any other information in the medical record. The HIPAA Privacy Rule does not prevent individuals, themselves, from gathering medical information about their family VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 members or from deciding to share this information with family members or others, including their health care providers. Thus, individuals are free to provide their doctors with a complete family medical history or communicate with their doctors about conditions that run in the family. To the degree that, for example, Patient A’s medical record include that their mother had breast cancer, that information would be accessible to Patient A because it was provided by Patient A and included as part of their medical record. Under this criterion, patients would not have a ‘‘right’’ to other patient’s records, consistent with existing laws. In general, with respect to patient access to information, we note that Health IT Module users must ensure that any disclosures of data conform to all applicable laws and regulations, including but not limited to alignment between this rule and the HIPAA Privacy Rule, as discussed in IV.B.6 above. We also refer readers to the information blocking section at VIII in this preamble, as well. Comments. Commenters requested clarity on how ONC will monitor a developer’s compliance with exporting in a timely manner and what penalties ONC will impose if there is a delay in regards to a Health IT Module user’s request. Commenters requested ONC release sub-regulatory guidance that describes how users may file complaints and recommended ONC work with the HHS Office for Civil Rights (OCR) on patient education. Response. Any noncompliance by developers with the finalized ‘‘EHI export’’ certification criterion (§ 170.315(b)(10)) or the associated Conditions and Maintenance of Certification requirements (e.g., § 170.402(a)(4) and (b)(2)) would be subject to review, corrective action, and enforcement procedures under the Program. We refer readers to the enforcement (VII) and information blocking (VIII) sections of this preamble for further information. We do not believe there is a general need to work with OCR further on this particular issue or to issue further sub-regulatory guidance. The functionality of the ‘‘EHI export’’ criterion in § 170.315(b)(10) provides a user (e.g., a health care provider) with the ability to export a file for a single patient and multiple patients. If a user or other stakeholder has concerns about ongoing compliance of health IT certified to this criterion, with the required functionality of the criterion, or the associated Conditions and Maintenance of Certification requirements, they may file a complaint PO 00000 Frm 00054 Fmt 4701 Sfmt 4700 with the health IT developer, an ONC– ACB, or ONC. Comments. Some commenters requested specific stakeholder exemptions from this requirement, such as health plans. Response. We thank commenters for the recommendations. We note that the ‘‘EHI export’’ criterion is applicable only to health IT products presented by developers for certification under the Program that meet the criterion and ‘‘Assurances’’ Condition of Certification requirements in § 170.402. In addition, we note that the information subject to the export requirements is EHI that can be stored at the time of certification by the product, of which the Health IT Module is a part. i. EHI Export for Patient-Initiated Requests In the Proposed Rule, we reiterated that the ‘‘user’’ of the single patient export functionality would typically be a provider or their office staff on behalf of the patient (80 FR 62611, 77 FR 54168). We also recognized that in service to innovative and patient-centric approaches, a health IT developer could develop a method that allows a patient to execute the request for data export without needing a provider to do so on their behalf. Under this scenario, we sought comments on whether the single patient export functionality should be made more prescriptive and require that the developers design the health IT to allow only the patient and their authorized representative to be the requestor of their EHI (84 FR 7447). Comments. In the scenario of patientcentric approaches created by developers, the majority of commenters were in favor of developers designing the export capability to make the patient and their authorized representative able to be the direct requestors of their EHI without needing a provider to execute this capability on their behalf. We also received recommended terms to further define ‘‘authorized representative’’ under this scenario. Several commenters advised against specifying or restricting the potential additional user roles able to initiate a single patient export. Some commenters recommended additional requirements for developers, including requiring developers to create this capability to enable the patient or their ‘‘proxy’’ to request their information through and receive information from the patient’s health portal or an application. Commenters asked for the final rule to include clarification on what the patient and their authorized representative can access. We did receive some comments that requested clarification of this potential approach. E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations We also received comments expressing confusion with the patient and authorized representative requests applying across the certification criterion, as opposed to the proposed and previously defined ‘‘users’’ of health IT that will typically perform the request on behalf of a patient. Response. We thank commenters for their input and requests for clarification. In response to the concerns and potential confusion, we clarify the following. This certification criterion does not require ‘‘direct-to-patient’’ functionality in order to demonstrate conformance. Providing such a capability and demonstrating conformance to this certification criterion with such a capability would be at the sole discretion of the health IT developer. In general, just like with the ‘‘data export’’ criterion in § 170.315(b)(6), the capability to execute this certification criterion can be health care provider/health care organization initiated (presumably upon that organization receiving a request by patient for their EHI). In instances where the functionality certified to this criterion is implemented in a ‘‘direct-topatient’’ way such that the patient can request and accept EHI export without assistance from a user, we recognize that further configuration of the functionality or product in which it is implemented may be needed in order to account for applicable laws related to the patient’s information access rights and other privacy and information blocking policies that apply to the configuration and use of the Health IT Module. While this specific capability within the certification criterion emphasizes health IT developer assistance must not be needed to operate the export, we recognize that user assistance (e.g., a provider) may be necessary to initiate such capability in the user’s product. b. Patient Population EHI Export for Transitions Between Health IT Systems In addition to the single patient export functionality in § 170.315(b)(10)(i), we proposed in § 170.315(b)(10)(ii) that health IT certified to this criterion would also facilitate the migration of EHI to another health IT system. We proposed that a health IT developer or health IT certified to this criterion must, at a user’s request, provide a complete export of all EHI that is produced or electronically managed (84 FR 7447 through 7448) by means of the developer’s certified health IT. Comments. We received many comments in support of the functionality under this criterion for VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 transitions between health IT systems. Many commenters recommended format and content specifications, such as the use of bulk FHIR®-based APIs for export transmission. Some commenters stressed that ONC should determine and require standards, as well as clarify the scope of data export specific to this use case. Some commenters expressed concerns, including gathering patient consent and the developer burden that may exist with gathering data from disparate systems under the proposed scope terminology. One commenter was against the transitions between health IT systems capability, citing that data structured for one system will not necessarily work in another. Response. We thank commenters for their feedback specific to the functionality of transitions between health IT systems under this criterion. We finalized this export functionality with modifications. First, this functionality is now referred to as ‘‘patient population electronica health information export’’ in § 170.315(b)(10)(ii) to better reflect the policy intent of patient data transitions in instances of providers switching health IT systems, and to reflect the finalized scope of data that a product with a certified Health IT Module must be capable of exporting. Similar to the modifications in § 170.315(b)(10)(i), we finalized in § 170.315(b)(10)(ii)(A) that the export files must be electronic and in a computable format and we modified in § 170.315(b)(10)(ii)(B) that the publicly accessible hyperlink of the export’s format must be included with the exported file(s). This modification clarifies that the user is able to access the format, and that the developer will keep their hyperlink up-to-date. In response to comments on defining a separate scope of data export specific to the patient population export functionality, it is our final policy for this certification criterion to align both the single patient and patient population export data to EHI, as defined in this rule, that can be stored at the time of certification by the product, of which the Health IT Module is a part. This narrower scope also addressed concerns received regarding development burden expressed regarding gathering data from disparate systems under the proposed scope terminology. In regards to the comments on enforcing format and standards for data transmission, it is our intent under this certification criterion that health IT developers have flexibility regarding how the export outcome is achieved. We again encourage the industry to work together toward this common goal and PO 00000 Frm 00055 Fmt 4701 Sfmt 4700 25695 to create an industry-wide approach. We do acknowledge the comments received that data structured for one system may not necessarily seamlessly align with another, and refer commenters to the export format requirements of this certification criterion. As finalized in § 170.315(b)(10)(ii)(A), the export created must be electronic and in a computable format. In contrast with the single patient EHI export capability, which must be available to a user without subsequent developer assistance to operate, the patient population EHI export capability of this criterion could require action or support on the part of the health IT developer. We acknowledged in the Proposed Rule (84 FR 7448) that because of anticipated large volume of electronic health information that could be exported under this specific proposed capability, developer action or support could be needed. Our thinking remains the same post-public comments even with the narrowed scope of data export. While exporting one patient’s data on an asneeded basis is a capability that should be executable by a user on their own, orchestrating an entire export of EHI for migration to another health IT system is an entirely different task and dependent on a variety of factors such as the organization’s overall infrastructure and deployment footprint. Additionally, developers of health IT certified to this criterion are required to provide the assurances in § 170.402, which include providing reasonable cooperation and assistance to other persons (including customers, users, and third-party developers) to enable the use of interoperable products and services. Thus, while developers have flexibility regarding how they implement the export functionality for transitions between systems, they are ultimately responsible for ensuring that the capability is deployed in a way that enables a customer and their third-party contractors to successfully migrate data. Such cooperation and assistance could include, for example, assisting a customer’s third-party developer to automate the export of EHI to other systems. We refer readers to the export format section below for additional details. We note that the narrowed scope of data that certified Health IT Modules must be capable of exporting does not reduce contractual obligations of health IT developers to continue to support providers if they do want to change systems, and direct readers to the information blocking section (VIII) for additional information. E:\FR\FM\01MYR3.SGM 01MYR3 25696 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations c. Scope of Data Export We proposed in 84 FR 7448 and in § 170.315(b)(10) that for both use cases supported by this criterion, the scope of data that the certified health IT product must be capable of exporting would encompass all the EHI that the health IT system produces and electronically manages for a patient or group of patients. Our intention was that ‘‘produces and electronically manages’’ would include a health IT product’s entire database. In the Proposed Rule, our use of the term EHI was deliberate. At the time of rulemaking, the proposed definition of the EHI term in § 171.102 was intended to support the consistency and breadth of the types of data envisioned by this proposed criterion. We requested comment on the terminology used (‘‘produces and electronically manages’’) or whether there were alternatives to the proposed language. Comments. Some commenters were supportive of our proposed scope of data export requirements, while a few others offered alternative specific terminology options. Those commenters suggested terminology such as all EHI the health IT system ‘‘collects and retains,’’ or ‘‘produces or can electronically access, exchange, or use.’’ A majority of commenters, however, stated that the proposed terminology, including the proposed EHI definition, left broad interpretations of the scope of data a Health IT Module would have to be capable of exporting under this criterion. These commenters expressed concerns that the ambiguity and potentially vast amounts of data would create undue burden on health IT developers for development and upkeep of export capabilities, as well as compliance issues with other applicable laws. A majority of commenters requested and highlighted a need for further specificity regarding the terminology used to define data exported under this criterion. Some commenters expressed concerns that a developer presenting a Health IT Module for certification may not know all systems a user may later connect to the health IT capabilities. We also received many comments reflecting varied thoughts on what should or should not be included in the criterion’s data export. Some commenters strongly opposed any data limits, citing existing regulations such as the HIPAA Privacy Rule right of access, while others proposed alternatives to constrain data export requirements, citing development infeasibility. Recommendations to constrain the proposed criterion’s scope included VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 alignment with other regulations and data standards, such as the USCDI. We also received a recommended requirement for health IT developers to provide a plain language definition of the EHI typically included in their Health IT Module’s export. Some commenters expressed confusion on how the criterion’s proposed scope of data export may apply to EHI ‘‘produced or electronically managed’’ by both the product’s certified and ‘‘non-certified’’ capabilities as well as data from third parties. Response. We thank commenters for feedback on our proposed terms and for specific recommendations. The finalized criterion draws the upper bound of its data scope from the focused definition of EHI as finalized. The criterion export includes the EHI, as defined, that can be stored at the time of certification by the product, of which the Health IT Module is a part. As defined in this rule, EHI means electronic protected health information as defined in 45 CFR 160.103 to the extent that it would be included in a designated record set as defined in 45 CFR 164.501 (other than psychotherapy notes as defined in 45 CFR 164.501 or information compiled in reasonable anticipation of, or for use in, a civil, criminal, or administrative action or proceeding), regardless of whether the actor is a covered entity as defined in 45 CFR 160.103. In response to comments received, this revised scope of data for export provides a more manageable and less administratively burdensome certification criterion for health IT developers for several reasons. We agree with commenters that our proposed terms of all EHI a health IT system ‘‘produces and electronically manages’’ (84 FR 7448) raised the potential for broad variance in interpretations and concerns about the breadth of data intended for export under this criterion and potential development burden. We also considered the comments noting that a developer presenting a Health IT Module for certification may not, at the time of certification, know all systems a user will later connect to the health IT capabilities. Ultimately, we considered several approaches to better reflect the policy intent and to alleviate confusion related to the proposed criterion. In consideration of the public comments and the policy outcome we sought to address, we revised the final criterion‘s phrasing to describe what information health IT products with Health IT Module(s) certified to the criterion must be capable of exporting. The revised scope of data export applies to both the single patient and patient population PO 00000 Frm 00056 Fmt 4701 Sfmt 4700 export functionalities as well as the Conditions and Maintenance of Certification requirements tied to this criterion. First, we agree with comments received and acknowledge that a health IT developer is best positioned to know (and would be solely responsible for only) the EHI that can be stored by the health IT product at the time the Health IT Module is presented for certification. In response to comments regarding the applicability of the scope of export to the product’s certified and ‘‘noncertified’’ capabilities, as well as data from third parties, we clarify and reiterate the following from our prior responses. We emphasize that such ‘‘stored’’ data applies to all EHI and is agnostic as to whether the EHI is stored in or by the certified Health IT Module or in or by any of the other ‘‘noncertified’’ capabilities of the health IT product of which the certified Health IT Module is a part. To be clear, conformance ‘‘at the time of certification’’ means the combined data that can be stored by the product, of which the Health IT Module is a part, at the time the Health IT Module is presented for certification. As such, for the purposes of this certification criterion, the EHI that must be exported does not include any data generated from unique post-certification in response to a particular customer (though such data could meet the definition of EHI for the purposes of information blocking). Such modifications could include custom interfaces and other data storage systems that may be subsequently and uniquely connected to a certified Health IT Module post-certification. Additionally, to remain consistent with ‘‘at the time of certification,’’ we clarify that any new EHI stored by the product due to ongoing enhancements would need to be included within the scope of certification only when a new version of the product with those new EHI storage capabilities is presented for certification and listing on the CHPL. In consideration of comments, we believe that this approach to define storage at the time the product is presented for certification of a Health IT Module will make the certification requirements more clear for health IT developers and more efficient to administer from a Program oversight perspective. In addition, the use of ‘‘can be stored by’’ refers to the EHI types stored in and by the health IT product, of which the Health IT Module is a part. This is meant to be interpreted as the combination of EHI a heath IT product stores itself and in other data storage locations. Thus, the cumulative data E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations covered by these storage techniques would be in the scope of data export. Per our policy intent, by focusing the definition of EHI and defining the data for export under this criterion, users of certified Health IT, such as health care providers, will have the ability to create ‘‘readily producible’’ exports of the information of a single patient upon request by the user, which increases patient access as reflected in the Cures Act. Lastly, in support of the second functionality we finalized for patient population export, the EHI exported (within the Health IT product’s scope of data export) would likely be of significant importance to health care providers for the purposes of transitioning health IT systems and maintaining continuity of care for patients, and also helps remove potential barriers to users switching systems to meet their needs or their patient’s needs. In finalizing this policy, we emphasize that health IT developers may provide the export of data beyond the scope of EHI and for functionalities beyond those discussed under this criterion. In such cases, for additional export purposes, it is advised that health IT developers and users discuss and agree to appropriate requirements and functionalities. We again emphasize that health IT product users must ensure that any disclosures of data conform to all applicable laws, including the HIPAA Rules and 42 CFR part 2. Stakeholders should review applicable laws and regulations, including those regarding patients’ right of access to their data, in order to determine the appropriate means of disclosing patient data. We also refer readers to the information blocking section at VIII. i. Image, Imaging Information, and Image Element Export In the Proposed Rule, we noted at 84 FR 7448 that clinical data would encompass imaging information, both images and narrative text about the image. However, we addressed that EHRs may not be the standard storage location for images. We solicited additional feedback and comments on the feasibility, practicality, and necessity of exporting images and/or imaging information. We requested comment on what image elements, at a minimum, should be shared such as image quality, type, and narrative text. We did not make any proposals in 84 FR 7448. Comments. Most commenters were supportive of sharing images and/or related data elements, expressing that interoperability should include electronic ordering of imaging studies, VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 which they asserted would assist health care providers in delivering care. Other commenters expressed burden concerns with data image export, particularly challenges around the movement and storage of large amounts of data and accumulating data from disparate health IT systems. A few commenters requested specific exclusion of images or videos created as a byproduct of procedures. As for minimum image data elements to share, recommendations varied and included Digital Imaging and Communications in Medicine (DICOMTM) data elements or file type recommendations. Comments included additional policy recommendations, such as making Picture Archiving and Communication Systems (PACS) developers subject to certification rules and requiring EHI export data to include links for remote authorized access to externally hosted images. Response. We thank commenters for their shared insight and recommendations regarding the export of images, imaging information, and image elements. Health IT Modules certified to the finalized criterion must electronically export all of the EHI, as defined, that can be stored at the time of certification by the product, of which the Health IT Module is a part. Thus, any images, imaging information, and image elements that fall within this finalized scope of EHI that can be stored at the time of certification in or by the product, of which the Health IT Module is a part will need to be exported under this certification criterion. We appreciate the recommendations received for image transfer methods and encourage the stakeholder community to continue exploring innovative image transfer methods, including for image transfer that would fall outside of this certification criterion. We appreciate the policy recommendations, such as including PACS developers. The ‘‘EHI export’’ certification criterion only applies to developers of health IT seeking or maintaining certification under the Program. To the extent such providers are developers of health IT under the Program they would be included. If they are not developers under the Program, they would not be included. We also thank commenters for their suggestions to require data export to include links for remote authorized access to externally hosted images. We note that the export requirements of this certification criterion refers to the EHI that can be stored at the time of certification by the product, of which the Health IT Module is a part. In the context of imaging, if the only EHI stored in or by the product to which this PO 00000 Frm 00057 Fmt 4701 Sfmt 4700 25697 certification criterion applies are links to images/imaging data (and not the images themselves, which may remain in a PACS) then only such links must be part of what is exported. We encourage developers to work with their customers to achieve innovative ways to share all relevant data, including situations outside of the scope of data export under this criterion where images could be made more accessible. ii. Attestation of Information a Health IT Developer Cannot Support for Export In the Proposed Rule (84 FR 7448), we also solicited comment on whether we should require, to support transparency, health IT developers to attest or publish as part of the export format documentation the types of EHI they cannot support for export. We did not have any specific proposals. Comments. The majority of commenters supported public attestation regarding the information a Health IT Module is unable to export. Some commenters requested that we add to the regulatory text to state that developers attest to information they cannot support for export ‘‘and/or ingestion.’’ Some commenters questioned if it is fair for EHI developers to delineate what is in their Health IT Module’s scope of data for export under this criterion. Another felt that this requirement should be extended to health care delivery organizations and that the attestation should be included within patient portals or other communications. Response. We thank commenters for their feedback. We again note the revised scope of data export under this finalized criterion. Under the finalized approach, which focuses on the export of the EHI that can be stored at the time of certification by the product, we have determined that our final requirements provide sufficient clarity and have not included any additional requirements such as those on which we sought comment. Additionally, we believe the recommendation for ingestion would be impracticable as part of this certification criterion due to the flexibility we permit for the output format(s). It would not be possible from a regulatory enforcement perspective to administer a certification criterion that included within its scope a conformance requirement for a Health IT Module’s capability to import any proprietary format that may exist without prior knowledge of such formats. iii. Export Exclusion Request for Comments In the Proposed Rule, we proposed metadata categories at 84 FR 7448 for E:\FR\FM\01MYR3.SGM 01MYR3 25698 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations exclusion from this criterion. We also requested feedback on what metadata elements should remain included for export or added to the list of excluded data. Metadata proposed for exclusion from the criterion included metadata present in internal databases used for physically storing the data, metadata that may not be necessary to interpret the EHI export, and metadata that refers to data that is not present in the EHI export. Examples of these proposed exclusions are provided at 84 FR 7448. Comments. Commenters offered varied recommendations for metadata elements to remain excluded, or to be included under the scope of data export for this criterion. We received several comments strongly supporting the inclusion of audit log metadata. Commenters noted that the inclusion of audit log metadata had potential legal utility and could aid in the patient’s ability to have all of their data and knowing who has accessed their data. Commenters also requested increased clarity on the definition of metadata, audit log, and access log in regards to this rulemaking, and requested the use of standards to further clarify policy intentions. We note, however, that other commenters were against the inclusion of audit log data as part of the EHI export. Those against inclusion stated that this information was not necessary to interpret the EHI export, could be burdensome for development of export capabilities, and potentially contain personally identifiable information of the health care staff. Response. We thank commenters for their input on potential metadata exclusions. As noted above, we have finalized that EHI that can be stored at the time of certification by the product is the scope of data that must be included in exports pursuant to § 170.315(b)(10). Under this revised and specified scope of data export, it is no longer necessary to list specific metadata exclusions or inclusions. We direct readers to the discussion of scope of data export (IV.B.6.c) under this criterion for further details. d. Export Format We did not propose a content standard for the export. However, we did propose to require documentation in § 170.315(b)(10)(iii) that health IT developers include the export file(s) format, including its structure and syntax, such as a data dictionary or export support file, for the exported information to assist the user requesting the information in processing the EHI (84 FR 7448). This was to prevent loss of information or its meaning to the extent reasonably practicable when VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 using the developer’s certified Health IT Module(s). We also proposed in § 170.315(b)(10)(iii) that the developer’s export format must be made available via a publicly accessible hyperlink and kept up-to date. Comments. Comments received were in favor of this proposal in § 170.315(b)(10)(iii). Several commenters were supportive of the flexibility of export format for developers, as long as export documentation is provided as specified in the Proposed Rule, citing specifically how this would support the export capability in § 170.315(b)(10)(ii). Some commenters recommended additional clarification for the publicly accessible hyperlink, specifically to ensure that information is available without login or other associated requirements. Commenters also provided export format suggestions. Response. We thank commenters for their feedback regarding developers’ export format. We have finalized § 170.315(b)(10)(iii) with modifications to clarify the regulatory text. We finalized that the export format(s) used to support § 170.315(b)(10)(i) and § 170.315(b)(10)(ii) of this section must be kept up-to-date. We clarify that the documentation for the export format(s) in § 170.315(b)(10)(iii) consists of information on the structure and syntax for how the EHI will be exported by the product such as, for example, C–CDA document(s) or data dictionary for comma separated values (csv) file(s), and not the actual EHI. The user will use the export format documentation to process the EHI after it is exported by the product. We also require that health IT developers keep the export format(s) used to support § 170.315(b)(10)(i) and § 170.315(b)(10)(ii) must be ‘‘up-todate.’’ For example, if the health IT developer had previously specified the C–CDA standard as the export format for meeting the criterion, but subsequently updated their product to use the FHIR standard and stopped supporting C–CDA export format then the documentation for export format would need to be updated so that users are able to continue to accurately process the EHI exported by the product. We appreciate suggestions received regarding ensuring that such information is available without login or other associated requirements. In response to these comments, our policy intent to foster transparency, and in alignment with other certification criterion requirements set forth in this rule, we note our modifications in § 170.315(b)(10)(i)(E) and § 170.315(b)(10)(ii)(B) that the publicly PO 00000 Frm 00058 Fmt 4701 Sfmt 4700 accessible hyperlink of the export’s format must be included with the exported file(s). We clarify that the hyperlink must allow any person to directly access the information without any preconditions or additional steps. We note that the export format need not be the same format used internally by the certified health IT and the health IT developer does not need to make public their proprietary data model. This certification criterion also does not prescribe how (i.e., media/medium) the exported information is to be made available to the user, as this may depend on the size and type of information to be exported. While file formats and related definitions are not finalized as specific certification requirements, we encourage developers to continue to foster transparency and best practices for data sharing, such as machinereadable format, when they create and update their export format information. e. Initial Step Towards Real-Time Access In the Proposed Rule at 84 FR 7449, we offered a clarifying paragraph to highlight that the criterion in § 170.315(b)(10) was intended to provide a step in the direction of realtime access goals, as well as a means to, within the confines of other applicable laws, encourage mobility of electronic health data while other data transfer methods were maturing. In that section, we clarified that ‘‘persistent’’ or ‘‘continuous’’ access to data is not required to satisfy the proposed ‘‘EHI export’’ criterion’s requirements, and that the minimum requirement of developers presenting Health IT Module(s) for certification to this criterion is for a discrete data export capability. In this clarification section, we did not have specific proposals or requests for comments. Comments. We received recommendations to further specify the use of ‘‘persistent’’ and ‘‘continuous’’ in context of access to EHI. Additional commenters recommended specifying Representational state transfer (REST) or ‘‘RESTful’’ transfer, or specifying data transport methods. Response. We thank commenters for their input. We first clarify that this section was added to the Proposed Rule for additional clarification and to provide prospective context on the proposed certification criterion. However, we recognize from the comments received that our reference to ‘‘persistent’’ or ‘‘continuous’’ access in the Proposed Rule may have created confusion. We again note that ‘‘persistent’’ or ‘‘continuous’’ access is not required by health IT developers E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations presenting Health IT Module(s) to satisfy the requirements of this certification criterion. We have finalized the ‘‘EHI export’’ criterion as described above in response to comments received on proposals we have made. We appreciate the responses to our future looking points in the Proposed Rule but have not made further revisions to the final certification criterion in response. f. Timeframes We requested input and comments on the criterion and timeframes at 84 FR 7449. In particular, beyond the proposal to export all the EHI the health IT system produces and electronically manages, we sought comment on whether this criterion should include capabilities to permit health care providers to set timeframes for the EHI export, such as only the ‘‘past two years’’ or ‘‘past month’’ of EHI (84 FR 7449). Comments. A majority of commenters were against the concept of allowing providers to set timeframes for the export functionality. Commenters were concerned that creating the capability to limit timeframes would involve significant technical complexity for health IT developers. Commenters also expressed concern that allowing providers the capability to limit timeframes would not align with the HIPAA Privacy Rule right of access at 45 CFR 164.524 and could potentially implicate information blocking. Commenters provided alternative approaches and concepts to implement timeframe capabilities for this criterion, including use of APIs, granting flexibility to developers, allowing intervals or dynamic timeframe requirements, and considering permitted fees. Commenters asked for clarification on how far back the data request capabilities could go and requested clarification regarding how this criterion aligns with other APIrelated criteria within this rule. Response. We thank commenters for their feedback. We will not require the Health IT Module support a specific or user-defined timeframe range or time limit capability for the purposes of demonstrating conformance to this certification criterion. We agree with commenters concerns regarding potential development complexity for health IT developers if we included such a requirement upfront. What this means, however, is that for the purposes of testing and certification, a health IT developer will need to prove that the product, of which a Health IT Module is part, can perform the capabilities required by the certification criterion, inclusive of all EHI that could be VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 exported. In turn, when these capabilities are deployed in production they will need to be capable of exporting all of the EHI that can be stored at the time of certification by the product, of which the Health IT Module is a part. We also agree with the points received regarding the HIPAA Privacy Rule right of access at 45 CFR 164.524 and emphasize the importance of HIPAA covered entities aligning with applicable law regarding patient access to health information. g. 2015 Edition ‘‘Data Export’’ Criterion in § 170.315(b)(6) We proposed to remove the ‘‘data export’’ criterion (defined in § 170.315(b)(6)) from the 2015 Edition Base EHR definition in § 170.102 and to replace ‘‘data export’’ with the proposed ‘‘EHI export’’ criterion (defined in § 170.315(b)(10)) by amending the third paragraph of the 2015 Edition Base EHR definition in § 170.102. We did not propose a transition period for the ‘‘data export’’ criterion. Rather, we proposed to remove the criterion from the 2015 Edition Base EHR definition upon the effective date of a final rule. We also proposed to modify the 2015 Edition Base EHR definition to include the new proposed export criterion (defined in § 170.315(b)(10)), with an implementation date 24 months from the effective date of the final rule. We welcomed comments on this approach. Comments. Some commenters were in favor of immediate removal of this criterion (§ 170.315(b)(6)) from the 2015 Edition Base EHR definition, stating it would reduce burden. However, the majority of commenters were against a potential gap in functionality due to the compliance timeline for the new export criterion (§ 170.315(b)(10)) and requested that we keep the ‘‘data export’’ criterion until the new criterion in § 170.315(b)(10) and other standardized data transmission methods were fully implemented. Some commenters supported an indefinite retention of the ‘‘data export’’ criterion, regardless of the proposed addition of § 170.315(b)(10). Several commenters also recommended to expand the current § 170.315(b)(6) criterion through USCDI as an alternative approach to the proposed ‘‘EHI export’’ criterion in § 170.315(b)(10). In addition, some commenters expressed concern that that the ‘‘data export’’ criterion is inconsistent with CMS Quality Payment Program (QPP) requirements such as View, Download, and Transmit (VDT) at 83 FR 59814 of the CY 2019 Physician Fee Schedule final rule. Response. In consideration of public comments in support of the retention of PO 00000 Frm 00059 Fmt 4701 Sfmt 4700 25699 the ‘‘data export’’ certification criterion, we have maintained the ‘‘data export’’ certification criterion in § 170.315(b)(6) as available for certification until 36 months after this final rule’s publication date. To implement this decision, we have finalized in § 170.550(m) that ONC–ACBs are permitted to issue certificates to ‘‘data export’’ in § 170.315(b)(6) until, but not after, 36 months after the publication date of this final rule. However, we note the ‘‘data export’’ certification criterion has been removed from the 2015 Edition Base EHR definition (in § 170.102) as of the general effective date of this final rule (60 days after its publication in the Federal Register). During the 36 months immediately following publication of this final rule, developers will be able to maintain the certification to § 170.315(b)(6) as a standardized means of exporting the discrete data specified in the CCDS, but the criterion will not be updated to the USCDI. Given that certification to the § 170.315(b)(6) criterion will no longer be available after 36 months, we do not believe an update to the USCDI is the best path. Rather, § 170.315(b)(6) will remain an unchanged criterion in the Program for the 36 months immediately following publication of this final rule in the Federal Register. After that timeframe, the EHI export criterion in § 170.315(b)(10), including that certification criterion’s scope of data export, will remain an available data export certification criterion for health IT developers that present for certification a Health IT Module that is part of a heath IT product which electronically stores EHI. This approach will support prior investments in § 170.315(b)(6) by developers and their customers, and also encourage movement toward the interoperability opportunities afforded by new criteria. Regarding commenter concerns that the ‘‘data export’’ criterion is inconsistent with CMS QPP requirements, such as View, Download and Transmit (VDT), we do not believe that this criterion would be inconsistent with QPP program requirements. In the CY 2019 Physician Fee Schedule final rule, CMS removed the VDT measure in § 170.315(e)(1) (83 FR 59814). However, the Promoting Interoperability performance category of QPP currently includes the measure entitled Provide Patients Electronic Access to their Health Information (83 FR 59812 through 59813), and CMS has identified technology certified to the ‘‘View, Download and Transmit to 3rd party’’ criterion at 45 CFR 170.315(e)(1) as required to meet this measure (83 FR E:\FR\FM\01MYR3.SGM 01MYR3 25700 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 59817). The Data Export criterion in § 170.315(b)(6) is not required for the Provide Patients Electronic Access to their Health Information measure included in the Promoting Interoperability performance category, nor have we proposed to change the ‘‘View, Download and Transmit to 3rd party’’ criterion in § 170.315(e)(1) required for this measure, thus we do not believe this final policy will conflict with CMS requirements for QPP. 7. Standardized API for Patient and Population Services Criterion We proposed to adopt a new API criterion in § 170.315(g)(10) at 84 FR 7449. In response to comments, we are adopting a Standardized API for Patient and Population Services criterion for Certification in § 170.315(g)(10) with modifications. The new criterion, will replace the old ‘‘application access— data category request’’ certification criterion (§ 170.315(g)(8)). In doing so, we are also adding the Standardized API for Patient and Population Services criterion to the updated 2015 Edition Base EHR definition and removing the application access—data category request criterion (§ 170.315(g)(8)). This finalized Standardized API for patient and population services certification criterion requires the use of the FHIR Release 4 and several implementation specifications. The new criterion focuses on supporting two types of APIenabled services: (1) Services for which a single patient’s data is the focus and (2) services for which multiple patients’ data are the focus. Please refer to the ‘‘Application Programming Interfaces’’ section (VII.B.4) in this preamble for a more detailed discussion of the ‘‘API’’ certification criterion and related Conditions and Maintenance of Certification requirements. 8. Privacy and Security Transparency Attestations Criteria In 2015, the HIT Standards Committee (HITSC) recommended the adoption of two new ‘‘authentication’’ certification criteria for the Program (81 FR 10635). The National Coordinator endorsed the HITSC recommendations for consideration by the Secretary, and the Secretary determined that it was appropriate to propose adoption of the two new certification criteria through rulemaking. To implement the Secretary’s determination, we proposed two new criteria to which health IT would need to be certified (84 FR 7450). These would require the developer to attest to whether the Health IT Module for which they are seeking certification to the criteria encrypts authentication credentials (§ 170.315(d)(12)) and/or VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 supports multi-factor authentication (§ 170.315(d)(13)). We did not propose to require that health IT have these authentication and encryption-related functions, but instead proposed that a health IT developer must indicate whether or not their certified health IT has those capabilities by attesting ‘‘yes’’ or ‘‘no.’’ We did, however, propose to include the two criteria in the 2015 Edition privacy and security certification framework (§ 170.550(h)). For clarity, attesting ‘‘yes’’ to either of these criteria indicates that the Health IT Module can support either Approach 1 or Approach 2 of the 2015 Edition privacy and security certification framework for these criteria. We note that we received many comments on the proposed ‘‘encrypt authentication credentials’’ and ‘‘multifactor authentication’’ criteria, but the majority of comments conflated the two proposals and provided collective responses. Therefore, we have responded to them in kind to preserve the integrity of the comments. a. Encrypt Authentication Credentials We proposed in 84 FR 7450 to adopt an ‘‘encrypt authentication credentials’’ certification criterion in § 170.315(d)(12) and include it in the P&S certification framework (§ 170.550(h)). We proposed to make the ‘‘encrypt authentication credentials’’ certification criterion applicable to any Health IT Module currently certified to the 2015 Edition and any Health IT Module presented for certification that is required to meet the ‘‘authentication, access control, and authorization’’ certification criterion adopted in § 170.315(d)(1) as part of Program requirements. Encrypting authentication credentials could include password encryption or cryptographic hashing, which is storing encrypted or cryptographically hashed passwords, respectively. If a developer attests that its Health IT Module encrypts authentication credentials, we proposed in 84 FR 7450 that the attestation would mean that the Health IT Module is capable of protecting stored authentication credentials in accordance with standards adopted in § 170.210(a)(2), Annex A: Federal Information Processing Standards (FIPS) Publication 140–2, ‘‘Approved Security Functions for FIPS PUB 140–2, Security Requirements for Cryptographic Modules.’’ We posited that FIPS Publication 140–2 is the seminal, comprehensive, and most appropriate standard. Moreover, in the specified FIPS 140–2 standard, there is an allowance for various approved encryption methods, and health IT developers would have the flexibility to PO 00000 Frm 00060 Fmt 4701 Sfmt 4700 implement any of the approved encryption methods in order to attest ‘‘yes’’ to this criterion. We noted that health IT developers should keep apprised of these standards as they evolve and are updated to address vulnerabilities identified in the current standard. We did not propose that a Health IT Module would be required to be tested to the ‘‘encrypt authentication credentials’’ certification criterion. Rather, by attesting ‘‘yes,’’ the health IT developer is attesting that if authentication credentials are stored, then the authentication credentials are protected consistent with the encryption requirements above. We proposed in 84 FR 7450 that the attestations ‘‘yes’’ or ‘‘no’’ would be made publicly available on the Certified Health IT Product List (CHPL). We proposed in 84 FR 7450 that, for health IT certified prior to the final rule’s effective date, the health IT would need to be certified to the ‘‘encrypt authentication credentials’’ certification criterion within six months after the final rule’s effective date. For health IT certified for the first time after the final rule’s effective date, we proposed that the health IT must meet the proposed criterion at the time of certification. We also noted that some Health IT Modules presented for certification are not designed to store authentication credentials. Therefore, we specifically requested comment on whether we should include an explicit provision in this criterion to accommodate such health IT. We stated that this could be similar to the approach we utilized for the 2015 Edition ‘‘end-user device encryption’’ criterion (§ 170.315(d)(7)(ii)), where we permit the criterion to be met if the health IT developer indicates that their health IT is designed to prevent electronic health information from being locally stored on end-user devices. b. Multi-Factor Authentication We proposed in 84 FR 7450 to adopt a ‘‘multi-factor authentication’’ (MFA) criterion in § 170.315(d)(13) and include it in the P&S certification framework (§ 170.550(h)). We proposed to make the ‘‘multi-factor authentication’’ certification criterion applicable to any Health IT Module currently certified to the 2015 Edition and any Health IT Module presented for certification that is required to meet the ‘‘authentication, access control, and authorization’’ certification criterion adopted in § 170.315(d)(1) as part of Program requirements. To provide clarity as to what a ‘‘yes’’ attestation for ‘‘multifactor authentication’’ attestation would E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations mean, we provided the following explanation. MFA requires users to authenticate using multiple means to confirm they are who they claim to be in order to prove one’s identity, under the assumption that it is unlikely that an unauthorized individual or entity will be able to succeed when more than one token is required. MFA includes using two or more of the following: (i) Something people know, such as a password or a personal identification number (PIN); (ii) something people have, such as a phone, badge, card, RSA token or access key; and (iii) something people are, such as fingerprints, retina scan, heartbeat, and other biometric information. Thus, we proposed in 84 FR 7451 that in order to be issued a certification, a health IT developer must attest to whether or not its Health IT Module presented for certification supports MFA consistent with industryrecognized standards (e.g., NIST Special Publication 800–63B Digital Authentication Guidelines, ISO 27001).52 We proposed in 84 FR 7451 that, for health IT certified prior to the final rule’s effective date, the health IT would need to be certified to the ‘‘multi-factor authentication’’ certification criterion within six months after the final rule’s effective date. For health IT certified for the first time after the final rule’s effective date, we proposed that the health IT must meet this criterion at the time of certification. We solicited comment on the method of attestation and, if the health IT developer does attest to supporting MFA, whether we should require the health IT developer to explain how they support MFA. In particular, we asked whether a health IT developer should be required to identify the MFA technique(s) used/supported by submitting specific information on how it is implemented, including identifying the purpose(s)/use(s) to which MFA is applied within their Health IT Module, and, as applicable, whether the MFA solution complies with industry standards. Comments. The vast majority of commenters supported the adoption of the two proposed privacy and security transparency attestation certification criteria. A few commenters were opposed to the new criteria. Several supporters of the proposed criteria recommended that we make the criteria operative functional requirements (including testing), rather than yes/no attestations. Some of these commenters reasoned that MFA should be a requirement for all certified health IT, 52 NIST Special Publication 800–63B: https:// pages.nist.gov/800-63-3/sp800-63b/cover.html VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 given the risks involved with singlefactor authentication and how easy it is today to implement MFA. We also received a number of comments requesting that we clarify that the MFA proposal does not create a requirement for health care providers to implement MFA or encryption of authentication credentials. Similarly, we received several comments seeking clarification that a ‘‘yes’’ attestation would only require support of MFA, not that MFA would have to be implemented. Along these same lines, several commenters expressed concerns that the requirements could interfere with clinical care and urged that the requirements not contribute to provider burden. Response. We have adopted both proposed privacy and security transparency attestation criteria and included both criteria (§ 170.315(d)(12) and § 170.315(d)(13)) in the P&S certification framework (§ 170.550(h)), with minor modifications. While some commenters recommended that MFA should be a requirement for all certified health IT, we did not propose such a requirement nor could health IT developers have foreseen such an outcome in this final rule based on our proposals, particularly considering the clarity provided with our proposals (84 FR 7450) and the complexities of such a requirement. For example, as noted by commenters below, MFA may not be appropriate or applicable in all situations and there is wide variation in authentication needs and approaches throughout the industry. These criteria will, however, still provide increased transparency, and if a developer attests ‘‘yes’’ to these criteria regarding a certified Health IT Module, that Health IT Module will then be subject to ONC– ACB surveillance for any potential nonconformity with the requirements of these criteria. Given the strong support expressed in public comments for these criteria as proposed, we believe this is the appropriate approach at this time. While we believe that encrypting authentication credentials and MFA represent best practices for privacy and security in health care settings, we emphasize again that these criteria do not require certified health IT to have these capabilities or for health IT developers to implement these capabilities for a specific use case or any use case. Equally important, the criteria place no requirements on health IT users, such as health care providers, to implement these capabilities (if present in their Health IT Modules) in their health care settings. However, we note that information regarding the security capabilities of certified health IT PO 00000 Frm 00061 Fmt 4701 Sfmt 4700 25701 provided by such transparency can aid health IT users in making informed decisions on how best to protect health information and comply with applicable security regulations (e.g., the HIPAA Security Rule). Comments. Some commenters who supported the proposed criteria requested clarification on the scope and intent of the criteria, including what level of authentication and which types of users and user roles the criteria apply to, as well as on how to attest for multiple sign-on paths. A number of commenters noted the wide variation in authentication needs and approaches throughout the industry, and they recommended that we permit health IT developers to describe how they support authentication, rather than simply attest ‘‘yes’’ or ‘‘no.’’ The commenters stated that such information would provide helpful clarity regarding what the certified health IT supports. Additionally, several commenters stated that we should require that health IT developers explain how they support MFA. A number of commenters stressed that MFA may not be appropriate or applicable in all situations, and in particular, several commenters noted that automated transactions, including some that may occur in the public health reporting context, cannot support MFA. Response. In response to requests for modifications and clarifications, we have modified the ‘‘encrypt authentication credentials’’ criterion to permit a health IT developer that attests ‘‘no’’ for its Health IT Module(s) to indicate why the Health IT Module(s) does not support encrypting stored authentication credentials. A health IT developer that attests ‘‘no’’ to the ‘‘encrypt authentication credentials’’ criterion may explain, for example, that its Health IT Module is not designed to store authentication credentials, therefore there is no need for the Health IT Module to encrypt authentication credentials because it does not store, or have the capability to store, authentication credentials. For the ‘‘MFA’’ criterion, consistent with our solicitation of comments and the comments received recommending that health IT developers explain how they support MFA, we have modified the criterion to require health IT developers that attest ‘‘yes’’ to describe the use cases supported. For example, a health IT developer could attest ‘‘yes’’ to supporting MFA and state that the Health IT Module supports MFA for remote access by clinical users, thus providing clarity on the user roles to which MFA applies for that particular Health IT Module. To be clear, health IT E:\FR\FM\01MYR3.SGM 01MYR3 25702 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations developers are not expected to provide specific technical details about how they support MFA that could pose security risks. Again, the purpose is to enable health IT developers to give an indication of the types of uses for which their Health IT Module(s) support MFA. We note that health IT developers may wish to add new MFA use cases for their certified health IT over a period of time. In such instances, to provide the clarity sought in the Proposed Rule as to the MFA technique(s) used/supported and how MFA is implemented, including identifying the purpose(s)/ use(s) to which MFA is applied within their Health IT Modules, any new MFA use cases are required to comply with this criterion’s ‘‘yes’’ attestation provisions and be part of the quarterly CHPL reporting by health IT developers and ONC–ACBs under § 170.523(m). If a health IT developer attests ‘‘no,’’ then it would not be required to explain why its Health IT Module does not support authentication, through multiple elements, of the user’s identity with the use of industry-recognized standards. We did not propose to require an explanation for ‘‘no’’ attestation nor did we request comment on allowing health IT developers to provide an explanation for a ‘‘no’’ attestation like we did for ‘‘yes’’ attestations (84 FR 7450–7451). However, in an effort to provide transparency and consistency for these privacy and security attestation criteria, we will also permit developers to provide a reason for attesting ‘‘no’’ in order to provide more context. Such a reason may be due to MFA being inapplicable or inappropriate. In those cases, a developer could state, for example, that the Health IT Module does not support MFA because it is engaged in system-to-system public health reporting and MFA is not applicable. Comments. We received several comments requesting adjustment to the deadline for compliance to meet these criteria. We also received a number of comments recommending that we only apply both of the proposed criteria to new certifications and new Health IT Modules, and not to Health IT Modules already in widespread use. Response. Regarding the timeframe for compliance, and in response to comments recommending that we only apply the criteria to ‘‘new certifications,’’ we have determined that certification to these criteria as part of the updated 2015 Edition privacy and security certification framework (§ 170.550(h)) will only be necessary for Health IT Modules that are presented for certification. Thus, a new Health IT VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 Module seeking certification for the first time to the criteria specified in the 2015 Edition privacy and security certification framework (§ 170.550(h)), after the effective date of this final rule, will need to meet these privacy and security transparency attestation criteria at the time of certification. Similarly, a previously certified Health IT Module that has undergone revision, such as removal of certain capabilities, and is presenting for revised certification to the criteria specified in the 2015 Edition privacy and security certification framework (§ 170.550(h)) after the effective date of this final rule, will need to meet these privacy and security transparency attestation criteria at the time of certification. We believe that this approach will still provide the intended transparency as health IT will need to be issued new certifications as Health IT Modules are updated or certified to other new or revised criteria adopted in this final rule. At the same time, this approach should reduce burden for health IT developers and allow them more time to plan and prepare to meet these new transparency requirements. 9. Security Tags and Consent Management Criteria In the 2015 Edition final rule, we adopted two ‘‘data segmentation for privacy’’ (DS4P) certification criteria. One criterion, ‘‘DS4P-send’’ (§ 170.315(b)(7)), includes capabilities for applying security tags according to the DS4P standard in § 170.205(o) at the document-level of a summary care record formatted to the C–CDA 2.1 standard in § 170.205(a)(4). The other criterion, ‘‘DS4P-receive’’ (§ 170.315(b)(8)), includes capabilities for receiving a summary care record formatted to the C–CDA 2.1 standard in § 170.205(a)(4) with document-level security tags according to the DS4P standard in § 170.205(o). As noted in the 2015 Edition final rule (80 FR 62646), certification to these criteria is not required to meet the CEHRT definition for PI Programs. Security tagging enables computer systems to recognize the existence of sensitive elements in data and properly protect the privacy and security of the data by ensuring that only the appropriate individuals and entities can access it. Security tagging capabilities do not compromise the availability or comprehensiveness of health information available for treatment or research purposes; rather, they enable appropriate access controls in accordance with existing policies, governance, and applicable laws. The DS4P standard describes a method for PO 00000 Frm 00062 Fmt 4701 Sfmt 4700 applying security tags to HL7 CDA documents to ensure that privacy policies established at a record’s source can be understood and enforced by the recipient of the record. The utility of the DS4P standard is not limited to data subject to the Federal regulations governing the Confidentiality of Substance Use Disorder Patient Records, 42 CFR part 2 (80 FR 62647). DS4P may be implemented to support other data exchange use cases in which compliance with State or Federal legal frameworks require special protections for sensitive health information. Security tagging capabilities are an initial step towards enabling an interoperable health care system to use technical standards to permit appropriate access, use, or disclosure of sensitive health information in accordance with applicable policies and patient preferences. We understand and acknowledge additional challenges related the prevalence of unstructured data, sensitive images, and potential issues around use of sensitive health information by clinical decision support systems. The adoption of document level data tagging for structured documents would not solve these issues, but could help move technology in the direction where these issues could be addressed (80 FR 16841). Adoption of the 2015 Edition final rule DS4P criteria was consistent with earlier HIT Policy Committee (HITPC) recommendations for the use of security tagging to enable the electronic implementation and management of disclosure policies that originate from the patient, the law, or an organization, in an interoperable manner, so that electronic sensitive health information may be appropriately shared.53 The HITPC recommendations consisted of a glide path for the exchange of 42 CFR part 2-protected data starting with the inclusion of Level 1 (document level tagging) send and receive functionality. The HITPC also recommended advancing the exchange of 42 CFR part 2-protected data, by outlining additional capabilities in sharing, viewing and incorporating privacy restricted data at a more granular level, as well as 53 See HIT Policy Committee (HITPC) Recommendation Letter to ONC, July 2 014, https:// www.healthit.gov/facas/sites/faca/files/PSTT_ DS4P_Transmittal%20Letter_2014-07-03.pdf; see also HITPC’s Privacy and Security Tiger Team Public Meeting, Transcript, May 12, 2014, https:// www.healthit.gov/facas/sites/faca/files/PSTT_ Transcript_Final_2014-05-12.pdf.; Public Meeting, Transcript, May 27, 2014, https://www.healthit.gov/ facas/sites/faca/files/PSTT_Transcript_Final_201405-27.pdf. E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations managing computable patient consent for the use of restricted data.54 Since the 2015 Edition final rule, the health care industry has engaged in additional field testing and implementation of the DS4P standard. As of the beginning of the fourth quarter of the 2019 calendar year, 34 Health IT Modules were certified to one or both of the current 2015 Edition DS4P certification criteria (Health IT Modules with multiple certified versions were counted once). Stakeholders have shared with ONC—through public forums, listening sessions, and correspondence—that document-level security tagging does not provide enough flexibility to address more complex privacy and security use cases. Stakeholders noted that certain provider types, such as pediatrics and behavioral health, often rely on burdensome manual workflows to appropriately segment and share sensitive health information according to State and local laws. Additionally, stakeholders expressed interest in ONC adopting health IT standards that work with DS4P to support electronic consent for the exchange of security tagged data over an API. Therefore, in consideration of stakeholder feedback and HITPC recommendations to adopt DS4P certification criteria on a glide path, we proposed (84 FR 7452) to remove the 2015 Edition DS4P-send (§ 170.315(b)(7)) and DS4P-receive (§ 170.315(b)(8)) certification criteria. We proposed that the effective date of removal of these criteria would be the effective date of the final rule. We proposed to replace the removed DS4P criteria with two new 2015 Edition DS4P certification criteria in § 170.315(b)(12) and § 170.315(b)(13) that would support security tagging according to the DS4P standard at the document, section, and entry levels of C–CDA 2.1 formatted documents. Our primary purpose for proposing to remove and replace the criteria, in lieu of proposing to revise them, was to provide clarity to stakeholders about the additional functionality enabled by health IT certified to the new criteria. We also proposed a new 2015 Edition certification criteria for sharing patient consent information over an API using the Substance Abuse and Mental Health Services Administration’s (SAMHSA) Consent2Share (C2S) IG a FHIR-based exchange standard, in § 170.315(g)(11). We noted resources released by ONC 54 For more details on the two glide paths for part 2-protected data, see https://www.healthit.gov/facas/ sites/faca/files/PSTT_DS4P_Transmittal%20Letter_ 2014-07-03.pdf. VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 and OCR, such as the HHS Security Risk Assessment Tool 55 and the Guide to Privacy and Security of Electronic Health Information,56 as well as the Office for Civil Rights’ security risk analysis guidance 57 that entities may employ to make risk-based decisions regarding their implementation of the proposed DS4P criteria. We also noted the availability of the Electronic Consent Management Landscape Assessment, Challenges, and Technology report.58 The report includes suggestions for overcoming barriers associated with implementing electronic consent management, which may be considered for further research and discussion. We note that we received many comments on the proposed DS4P criteria and the proposed consent management for the API criterion but the majority of comments conflated the two proposals and provided a collective response. We tried to separate where possible, but in some instances, we kept them combined in order to preserve the integrity of the comments. a. Implementation With the Consolidated CDA Release 2.1 In place of the removed 2015 Edition DS4P criteria, we proposed (84 FR 7452) to adopt new DS4P-send (§ 170.315(b)(12)) and DS4P-receive (§ 170.315(b)(13)) criteria that would remain based on the CDA 2.1 and the HL7 DS4P standard. These criteria would include capabilities for applying security tags according to the DS4P standard at the document, section, and entry level. We believe this offers more valuable functionality to providers and patients, especially given the complexities of the landscape of privacy laws for multiple care and specialty settings. We stated in the Proposed Rule that we believe health IT certified to these criteria would support multiple practice settings and use cases. Comments. We received many comments both in support and against this proposal. In certain instances, commenters were supportive of our aims but felt there were too many 55 HHS Security Risk Assessment Tool: https:// www.healthit.gov/providers-professionals/securityrisk-assessment. 56 ONC Guide to Privacy and Security of Electronic Health Information: https:// www.healthit.gov/sites/default/files/ pdf/privacy/ privacy-and-security-guide.pdf. 57 HHS Office for Civil Rights: https:// www.hhs.gov/hipaa/for-professionals/security/ guidance/; and https://www.hhs.gov/ hipaa/for-professionals/security/guidance/ guidance-risk-analysis/?language=es. 58 https://www.healthit.gov/sites/default/files/ privacy-security/ecm_finalreport_ forrelease62415.pdf. PO 00000 Frm 00063 Fmt 4701 Sfmt 4700 25703 barriers and challenges near term, including but not limited to the perceived cost involved with successful segmentation in practice and indicated we should delay our finalization of the proposal. Others felt immediate adoption of our proposal in the final rule was critical for patient care and the secure exchange of sensitive health information. Many commenters in favor of our proposal provided examples of use cases which it could support, such as helping to combat the opioid crisis by facilitating the secure exchange of sensitive health information across health care settings and including substance use disorder (SUD) information covered by 42 CFR part 2. We also received support of our proposal for the protection of women’s health—the commenter explained that segmenting at the element level would protect individuals who have experienced intimate partner violence, sexual assault, and other sensitive experiences. Stakeholders shared with us that focusing certification on segmentation to only the document level does not permit providers the flexibility to address more granular segmentation needs. We received many comments on this proposal in the context of the following topics: provider and developer burden; readiness of the standard and C–CDA exchange; information blocking and EHI; future multidisciplinary activities (such as workgroups) and creating a vision for segmentation using health IT; safety; privacy policy conformity; suggested use cases; cost; and requests for specific clarifications. We describe these comments further below. Response. We thank commenters for their input. To address the comments concerned about the cost and timing, at the current time, these criteria are voluntary and not required under the definition of CEHRT or to participate in any HHS program. For more information on the costs for the adoption of these criteria, please see the Regulatory Impact Analysis in section XIII. For the reasons noted above, in this final rule, we have finalized our proposal to support a more granular approach to privacy tagging data consent management for health information exchange supported by the C–CDA exchange standard. We do this not by removing and replacing the 2015 Edition DS4P criteria with new § 170.315(b)(12) and § 170.315(b)(13), but by revising the 2015 Edition DS4P criteria, DS4P criteria DS4P-send (§ 170.315(b)(7)) and DS4P-receive (§ 170.315(b)(8)), to include the full scope of the HL7 DS4P standard for E:\FR\FM\01MYR3.SGM 01MYR3 25704 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations security tagging at the document, section and entry level with modifications as described below. Comments. We received many comments regarding the perceived burden of segmentation on providers and developers including comments focused on workflow challenges. One commenter indicated a lack of system and explained that tagging is burdensome for implementers because it does not describe how to determine what information is sensitive and should be tagged. Another indicated that DS4P creates a permanent added burden of extensive and costly manual data curation to redact each page to meet overlapping Federal and State regulations. Commenters indicated end users would be required to flag each individual data element, a process that is time consuming and error prone. They further explained that granular level privacy tagging has the risk of adding additional data entry burden to provider workflows if users must tag each item individually. Response. We appreciate the thoughtful comments submitted on the proposed criteria. Notably, with respect to the comments we received that expressed concern about the DS4P standard due to the burden, our analysis of the comments indicates that the concerns the commenters express are more closely related to the complexity of the privacy law landscape than to the specific functionality and standard in our proposal. As noted above, at the current time, these criteria are voluntary and not required under the definition of CEHRT or to participate in any HHS program. The DS4P standard is a tool and voluntary certification to these criteria is an initial step towards enabling an interoperable health care system to use technical standards to compute and persist security tags to permit access, use, or disclosure of sensitive health information. The criteria do not specify that a manual workflow is required to implement security tagging, and we understand from examples of DS4P use in practice that solutions may include the use of value sets to automate the tagging process. We reiterate that these criteria are intended to apply standards to the transmission of documents so that such security tags may be interoperable. Though the updated criteria would support a more granular approach to tagging the sensitive information, we recognize that this will not solve the whole problem of how to manage data segmentation for privacy and consent management. The recipient will still receive and can view the information that is tagged—the recipient will need to VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 determine what they are going to do with that information. Policies and procedures for what to do with the information once it is received are outside the scope of these criteria and this final rule. However, we emphasize that health care providers already have processes and workflows to address their existing compliance obligations for State and Federal privacy laws, which could be made more efficient and cost effective through the use of health IT, rather than relying on case-by-case manual redaction and subsequent workarounds to transmit redacted documents. We believe this tool may be one part of innovative solutions to support health IT enabled privacy segmentation in care coordination workflows to significantly reduce the burden of these manual processes currently in practice. Comments. Several commenters indicated that enhanced segmentation may unintentionally impact clinical care when providers are presented with an incomplete picture of patient data. Commenters stated there could be patient care risks involved with not sharing elements as users of downstream systems may not realize that a single element is filtered and act improperly, such as by prescribing a contraindicated medication due to missing information. Response. DS4P is a technical standard for C–CDA that helps health care providers comply with existing, applicable laws. As such, health care providers should already have processes and workflows in place to address their existing compliance obligations. The DS4P standard does not itself create incomplete records. Under existing law, patients already have the right to prevent re-disclosure of certain types of data by withholding consent to its disclosure or to place restrictions on its re-disclosure. DS4P allows providers to electronically tag (mark) data as sensitive and express re-disclosure restrictions and other obligations in an electronic form. DS4P does not determine whether a segmentation obligation exists legally or what that legal obligation means to the recipient. Instead, DS4P allows for tagging and exchange of health information that has already been determined to be sensitive and in need of special protections under existing law. Comments. We received comments in support of our proposal indicating that, without data segmentation, other mandatory criteria, such as the proposed ‘‘EHI export’’ criterion, would be difficult to implement without risking disclosure of sensitive data or information blocking. One commenter PO 00000 Frm 00064 Fmt 4701 Sfmt 4700 indicated that without this technical standard, it would be difficult for stakeholders to know whether appropriate consent has been obtained prior to releasing health information. Further, the commenter indicated concern that without such capabilities, hospitals and health systems could be accused of information blocking because they cannot verify that a patient has given consent for their EHI to be shared. They further commented that if ONC does not finalize this criterion, then we should provide an appropriate exception in the information blocking provisions so that an entity is not accused of information blocking because they do not know if another organization has obtained consent from patients. One commenter stated ONC should propose a new information blocking exception that specifically clarifies that a health IT developer’s choice to not certify to an optional standard cannot be a practice that implicates information blocking. Response. We thank commenters for their support of the DS4P standard. While we understand commenters’ concerns, we first reiterate the DS4P capability enables sensitive health information to be exchanged electronically with security tags in a standardized format. It does not enable the full segmentation of a patient’s record within an EHR, which may be necessary when responding to a request for EHI. Second, we have revised the Infeasibility Exception in the information blocking section of this final rule to provide that an actor is not required to fulfill a request for access, exchange, or use of EHI if the actor cannot unambiguously segment the requested EHI from other EHI: (1) Because of a patient’s preference or because the EHI cannot be made available by law; or (2) because the EHI is withheld in accordance with the Harm Exception in § 171.201 (§ 171.204(a)(2)). For instance, an actor will be covered under this condition if the actor could not fulfill a request to access, exchange, or use EHI because the requested EHI could not be unambiguously segmented from patient records created by federally assisted programs (i.e., Part 2 Programs) for the treatment of substance use disorder (and covered by 42 CFR part 2) or from records that the patient has expressed a preference not to disclose. We refer readers to the Infeasibility Exception discussion in section VIII.D.1.d of this final rule. Comments. Many commenters noted a low level of adoption for these standards and concerns related to readiness expressing that the standard E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations utility is limited by lack of widespread developer implementation. Several commenters encouraged ONC to defer adoption of the DS4P criteria with a few commenters recommending that the optional 2015 Edition criterion should be maintained with document level tagging only until practical implementations at scale have been demonstrated at this level. One commenter suggested that organic adoption by end-user providers will help spark innovation in this emerging standard while expressing concern that C–CDA level data tagging for privacy is largely untested in real world scenarios. Others encouraged ONC to provide additional guidance on the adoption of the DS4P standards and certification criteria and forgo the inclusion of this requirement until additional real world testing is available. They also indicated ONC should first conduct use test cases to demonstrate how this functionality will be effectively used across a variety of environments. Response. We appreciate the comments on the proposed criteria. In reference to the DS4P standard’s maturity, we note that it is considered a ‘‘normative’’ standard from the HL7 perspective—a status which indicates the content has been enhanced and refined through trial use. While we recognize that to date the standard has not been widely adopted, the SAMHSA C2S application uses the standard to segment Part 2 information. Likewise, the U.S. Department of Veterans Affairs (VA) and private companies across the country have used the DS4P standard to support behavioral health and pediatric care models. In addition, as of the fourth quarter of 2019, 34 individual Health IT Modules obtained certification to one of or both of the prior 2015 Edition certification criteria. Our intent for adopting the updates to these criteria is that in the absence of adoption of consensus driven standards there is increased risk that single-use-case, proprietary solutions will be developed, which may increase fragmentation, provider burden, and cost while limiting interoperability. Further, the purpose of adopting these criteria is to encourage the use of interoperable standards, in this case to use technical standards to compute and persist security tags upon exchange of a summary of care document in an interoperable manner. In addition, the certification criteria using the DS4P standard are voluntary and therefore our intent is, as commenters noted, to support organic adoption of technology certified to the criteria by providers seeking to implement health IT VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 solutions to replace burdensome manual privacy workflows. Comments. Several commenters called for the need to increase conformity among Federal and State privacy provisions to achieve successful implementation of granular tagging. They noted the significant policy component involved with the successful implementation of the DS4P standard in practice, and in certain instances specifically noted support for HIPAA Privacy Rule and 42 CFR part 2 harmonization. Several commenters identified specific areas for technical development of IT supporting data segmentation for privacy based on Federal and State privacy provisions. One commenter indicated that ONC could map which clinical codes are associated with certain health conditions that receive special privacy protections in addition to the HIPAA Rules. Other commenters noted that mapping of privacy policy to technical specifications is not a sufficient or adequate approach given policy complexities. One commenter indicated a future approach should focus on development of criteria that support a data provenance driven method of sensitive data management as applicable under privacy laws. Response. As we have stated, the DS4P standard enables sensitive health information to be exchanged electronically with security tags in a standardized format and we encourage health IT developers to include DS4P functionality and pursue certification of their health IT to these criteria in order to help support their users’ compliance with relevant State and Federal privacy laws that protect sensitive health information. We recognize that the current privacy law landscape is complex. In light of the complexities of the privacy law landscape, we believe that supporting a standard that allows for increased granularity in security tagging of sensitive health information would better allow for the interoperable exchange of this information to support a wide range of privacy related use cases. Comments. Many commenters offered an approach for next steps to advance the standard. To advance adoption and implementation of the standard, several commenters suggested that ONC work closely with clinicians, privacy subject matter experts and interoperability experts (notably the HL7 Privacy and Security workgroups) to develop a clear vision for implementing enhanced data segmentation. Many commenters specifically called for ONC to sponsor or lead a multidisciplinary workgroup of stakeholders to develop PO 00000 Frm 00065 Fmt 4701 Sfmt 4700 25705 recommendations for industry adoption and implementation. One commenter in support of our proposal suggested such workgroup focus on including whether additional standards are needed, as well as data visualization of non-disclosed data and its utilization in clinical decision support algorithms. Several commenters cited existing work to help support potential new multidisciplinary efforts indicating that one SDO has already undertaken early work toward evolving DS4P implementation guidance via the HL7 V2 to FHIR mapping project sponsored by the HL7 Orders Work Group. One commenter, called for an ONC led public-private collaborative effort to reduce data entry burden. One commenter recommended that ONC stand up a multi-stakeholder workgroup to identify and define policy needs and functional requirements to address patient privacy and provider needs. Response. We thank commenters for their recommendations. ONC believes that data segmentation is an integral capability for exchanging sensitive health data. ONC first studied policy considerations regarding data segmentation in electronic health information exchange in 2010 and informed ONC’s launch of the DS4P Standards and Interoperability Framework (S&I Framework) Initiative in 2011.59 The initiative focused on the development of a DS4P technical specification that would allow highly sensitive health information to flow more freely to authorized users while improving the ability of users of health IT to meet their obligations under State and Federal privacy rules. Recommendations from the initiative called for the use of metadata security tags to demonstrate privacy and security obligations associated with patient health information. It also advised that patients and providers be able to share portions, or segments, of records in order to maintain patient privacy. Pilot projects conducted under the DS4P S&I Framework Initiative demonstrated ways to enable the sharing of information that is protected by Federal and State laws, including the substance use disorder treatment confidentiality regulations, 42 CFR part 2. ONC’s prior Federal Advisory Committee, the HITPC, also focused on the health IT certification needed to enable exchange of behavioral health data.60 Additionally, ONC led a project on 59 https://archive.healthit.gov/providersprofessionals/ds4p-initiative. 60 https://www.healthit.gov/topic/Federaladvisory-committees/health-it-policy-committeerecommendations-national-coordinator. E:\FR\FM\01MYR3.SGM 01MYR3 25706 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations patient choice where the exchange of sensitive data was addressed.61 ONC also led a project on the Behavioral Health Data Exchange (BHDE) Consortium. The purpose of the project was to facilitate and address barriers to the intra and interstate exchange of behavioral health data.62 Currently, ONC’s Leading Edge Acceleration Projects (LEAP) in Health Information Technology (IT) program seeks to address well-documented and fast emerging challenges inhibiting the development, use, and/or advancement of well-designed, interoperable health IT. In 2019, one of the two LEAP awards issued by ONC focused on the standardization and implementation of the Fast Healthcare Interoperability Resources (FHIR®) Consent resource. Under this project, a FHIR® Consent Implementation Guide (IG) and package of open-source prototypes and content to assist partners in using the FHIR® Consent Resource will become available.63 Also, ONC actively participates in HL7 International (HL7®) Workgroups and standards-development activities related to data segmentation and consent management. It is critical for sensitive health information to be included in health information exchange and we are exploring opportunities for additional collaboration in the future. Comments. One commenter recommended a companion guide be developed to assist implementers with the standard. Another indicated ONC should provide guidance to facilitate adoption of the DS4P standards and certification criteria including dissemination of best practices to help ensure that providers can most effectively implement the standards and associated workflows. Another referred to a Query-Based Document Exchange IG which has further guidance on the ability to assert access policies and DS4P implementation considerations. Response. The 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 standard 64 § 170.205(o)(1) (HL7 DS4P standard) describes the technical means to apply security tags to 61 https://www.healthit.gov/topic/patient-consentelectronic-health-information-exchange. 62 https://www.healthit.gov/topic/health-it-healthcare-settings/behavioral-health-data-exchangeprimary-care-and-behavioral. 63 https://www.healthit.gov/topic/leading-edgeacceleration-projects-leap-health-informationtechnology-health-it. 64 https://www.hl7.org/implement/standards/ product_brief.cfm?product_id=354. VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 a health record and data may be tagged at the document-level, the section-level, or individual data element-level. The HL7 DS4P standard also provides a means to express obligations and disclosure restrictions that may exist for the data. We appreciate commenters input on additional guidance beyond these certification requirements that may prove useful for developers. However, we reiterate that in this rule we address only that guidance that is required for those developers to voluntarily submit a Health IT Module for certification to our criteria. Additional guidance on best practices would be outside the scope of this rulemaking. However, as noted above, we are committed to continuing to work with stakeholders, including health IT developers and those involved in implementing privacy policy in the health care industry, to work toward interoperable solutions for privacy and consent management. Comments. We received several comments seeking clarification on our proposal to remove the current 2015 Edition ‘‘DS4P-send’’ (§ 170.315(b)(7)) and ‘‘DS4P-receive’’ (§ 170.315(b)(8)) certification criteria and to replace these two criteria with three new 2015 Edition DS4P certification criteria (two for C– CDA and one for a FHIR-based API). As examples, one commenter sought clarification on whether our proposal was for DS4P send and receive to become mandatory for the revised 2015 Edition certification, or if they will remain voluntary criteria. One commenter sought clarification on whether the data protections apply to FHIR transmissions. Another indicated that they believe the DS4P implementation guide only focuses on data segmentation for C–CDA documents and not for HL7 FHIR and sought ONC clarification regarding whether or not we intend to apply data segmentation labeling to the HL7 FHIR resources in support of the USCDI as well. Another commenter recommended that we require FHIR Release 4 version but commented that a consistent approach of USCDI across HL7 CDA, C– CDA and HL7 FHIR is not attainable at this time. One commenter stated a similar need for clarification indicating that the standard for DS4P should be HL7 standards for CDA Version 2 and FHIR security tagging and not be the SAMHSA C2S stating that ONC should clarify this misunderstanding. Another commenter sought clarification by ONC to indicate that the IG is for CCDS and not FHIR, and also indicated confusion regarding STU4. One commenter noted that the DS4P criteria are only effective PO 00000 Frm 00066 Fmt 4701 Sfmt 4700 for C–CDA-based data exchange and recommended ONC add FHIR-based standard for tagging of sensitive data. Several commenters expressed concern over what they described as misalignment of this proposal with other ONC policies explaining that neither USCDI nor ARCH, nor HL7 FHIR US Core includes the FHIR Composition resource, which would be at the equivalent level of granularity as a C– CDA document. Response. We thank commenters for their input and we appreciate the need for clarity requested by commenters. In the Proposed Rule (84 FR 7452), we proposed both to adopt an update to the HL7 DS4P standard for the existing 2015 Edition certification criteria to support security tagging of a C–CDA upon send and receive by removing DS4P-send (§ 170.315(b)(7)) and DS4P-receive (§ 170.315(b)(8)) and replacing them with DS4P-send (§ 170.315(b)(12)) and DS4P-receive (§ 170.315(b)(13)) and to also adopt a new criterion to support API exchange via consent management solutions using the FHIR standard. In other words, these were two separate proposals, the first to support security tags in summary of care documents and another to support consent management for specific use cases that leverage a FHIR-based API. As of this final rule, these criteria remain voluntary and not required under the definition of CEHRT or to participate in any HHS program. We proposed these several criteria in a single section of the Proposed Rule because of the relationship between them as two potential health IT tools that could be part of overarching solutions to manage privacy and consent in health information exchange. However, as stated earlier, we note that neither of these tools addresses the entirety of the scope of data segmentation for privacy. To address the comment on the DS4P implementation guide, we confirm that the HL7 DS4P standard in § 170.205(o)(1) describes the technical means to apply security tags to a health record and data may be tagged at the document-level, the section-level, or individual data element-level in the C–CDA and not for FHIR. Currently, we do not intend to apply data segmentation labeling to the HL7 FHIR resources in support of the USCDI because all FHIR resources already include the capability to apply security tags to the resource as metadata. We appreciate the recommendation to require FHIR Release 4 for consent management but as discussed below, we have decided not to finalize the proposal for consent management for APIs in this final rule. For further E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations discussion of our FHIR-based consent management proposal, we direct readers to subsection b below. For the updates to the existing DS4P criteria, to support greater clarity requested by public comment, rather than removing the existing 2015 Edition criteria and replacing them with new criteria as proposed, we instead finalized a simple update to the existing criteria to note the use of the full HL7 DS4P standard for tagging or applying security tags at the document, section, and entry level. We further note that these updated criteria remain voluntary, and that we have finalized modifications in § 170.315(b)(7)(ii) and § 170.315(b)(8)(i)(B) to our proposed effective date for this change to allow for a longer glide path for health IT developers to update Health IT Modules to the full standard to better support clinical and administrative workflows. While certification to the updated standards will be available after the effective date of this final rule upon successful testing, we have finalized that document-level tagging remains applicable for up to 24 months after the publication date of this final rule. For certification and compliance of Health IT Modules certified after 24 months after the publication date of this final rule, only the full scope of the HL7 DS4P standard is applicable. We have finalized this 24 month period for the update for these criteria under the real world testing provisions in § 170.405(b)(6) as follows: • Security tags. A health IT developer with health IT certified to § 170.315 (b)(7) and/or § 170.315 (b)(8) prior to June 30, 2020, must: Æ Update their certified health IT to be compliant with the revised versions of the criteria adopted in § 170.315(b)(7) and/or the revised versions of the criteria adopted in § 170.315(b)(8); and Æ Provide its customers of the previously certified health IT with certified health IT that meets paragraph (b)(6)(i) of this section by May 2, 2022, In addition, we have finalized these updated criteria with modifications to the criteria names to better describe the function the criteria support in interoperable health IT systems. The modifications to the criteria are as follows: • Prior criterion: ‘‘DS4P-send’’ (§ 170.315(b)(7)) includes capabilities for creating a summary care record formatted to the C–CDA standard and document-level tagging as restricted (and subject to restrictions on redisclosure) according to the DS4P standard. VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 • Revised criterion: ‘‘Security tags— Summary of Care (send)’’ (§ 170.315(b)(7)) includes capabilities for creating a summary of care record formatted to the C–CDA standard and that is tagged as restricted and subject to restrictions on re-disclosure according to the DS4P standard at the document, section, and entry (data element) level, or at the document-level for the period until May 2, 2022. • Prior criterion: ‘‘DS4P-receive’’ (§ 170.315(b)(8)) includes capabilities for receiving a summary care record formatted to the C–CDA standard and document-level tagged as restricted (and subject to restrictions on re-disclosure) according to the DS4P standard. • Revised criterion: ‘‘Security tags— Summary of Care (receive)’’ (§ 170.315(b)(8)) includes capabilities for receiving a summary of care record formatted to the C–CDA standard and that is tagged as restricted and subject to restrictions on re-disclosure according to the DS4P standard at the document, section, and entry (data element) level, or at the document-level for the period until May 2, 2022. We have finalized our proposal to include in the voluntary ‘‘Security tags— Summary of Care (receive)’’ (§ 170.315(b)(8)) criterion as a requirement that the Health IT Module has the capability to preserve privacy markings to ensure fidelity to the tagging based on consent and with respect to sharing and re-disclosure restrictions as proposed. b. Implementation With the Fast Healthcare Interoperability Resources (FHIR®) Standard In collaboration with ONC, SAMHSA developed the C2Sapplication to address the specific privacy protections for patients with substance use disorders whose treatment records are covered by the Federal confidentiality regulation, 42 CFR part 2. C2S is an open source application for data segmentation and consent management. It is designed to integrate with existing FHIR systems. SAMHSA created a FHIR implementation guide (the Consent2Share Consent Profile Design, hereafter referred to as ‘‘Consent Implementation Guide’’) that describes how the Consent2Share application and associated access control solution (C2S platform) uses the FHIR Consent resource to represent and persist patient consent for treatment, research, or disclosure.65 The implementation guide 65 The draft FHIR IG titled ‘‘Consent2Share FHIR Profile Design.docx’’ can be accessed through the Community- Based Care and Privacy (CBCP) HL7 workgroup, within the Package Name titled PO 00000 Frm 00067 Fmt 4701 Sfmt 4700 25707 provides instructions for using the FHIR Consent resource to capture a record of a health care consumer’s privacy preferences. In section VII.B.4 of this final rule, we discuss policies related to the implementation of a standardized API to support the exchange of health information between providers and patients and among members of a care team. In the Proposed Rule, we anticipated that the proposed 2015 Edition ‘‘standardized API for patient and population services’’ certification criterion (§ 170.315(g)(10)) would result in a proliferation of APIs that will enable a more flexible and less burdensome approach to exchanging EHI. We stated our belief that the health care industry could leverage this API infrastructure to share segmented data in a secure and scalable manner. Therefore, we proposed to adopt a 2015 Edition certification criterion ‘‘consent management for APIs’’ in § 170.315(g)(11) to support data segmentation and consent management through an API in accordance with the Consent Implementation Guide. Comments. Overall, the majority of commenters were supportive of the concept of consent management for APIs but many had concerns with the proposed criteria, specifically the adoption of the Consent Implementation Guide or the C2S platform as part of a certification criterion. Many commenters raised concerns that the Consent Implementation Guide has not been balloted as an HL7 standard and noted that C2S does not support a consenter’s signature or specification to protect information content data requirements. A couple of commenters stated that the Consent Implementation Guide is a new emerging standard in pilot with feedback requested. Commenters also raised concern that the IG has not gone through an SDO process. Another commenter raised concern that SAMHSA no longer supports the C2S platform and the Consent Implementation Guide and it now lacks a steward. A couple of commenters suggested ONC defer the consent management criteria at least until an API FHIR standard version is finalized and the Consent Implementation Guide is revised to conform that to that version. One commenter supported the adoption of FHIR v3-based Consent resource, but urged ONC to also consider pediatric and geriatric use cases in its adoption. Other commenters stated that their understanding was that tagging will be ‘‘BHITS_FHIR_Consent_IG,’’ at https:// gforge.hl7.org/gf/project/cbcc/frs/. E:\FR\FM\01MYR3.SGM 01MYR3 25708 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations a feature of FHIR Release 4, but were unclear how the proposal to move to FHIR Release 2 would work. One commenter questioned how if there are no standards-based approaches for identifying what in the record is sensitive, how one could feasibly implement privacy-tagging and consent management via FHIR at the Resource level and that tagging at a more granular level is too cumbersome and unrealistic. A number of commenters stated that the standards were premature and if adopted could have unintended negative effects. Commenters were not supportive of having two versions of FHIR but instead recommended the use of FHIR Release 4. Commenters recommended ONC focus on driving real-world implementation experience before adopting the standards. On the other hand, a few commenters supported our proposal, and stated that the C2S platform and the Consent Implementation Guide is mature and already supports granular level security tagging and data segmentation and supports several API standards listed in the Proposed Rule. One commenter expressed support broadly for the C2S platform indicating that, though it was originally designed to satisfy 42 CFR part 2 consent for the substance use disorder data, it supports the other sensitive categories such as HIV and mental health. Several commenters stated that the criteria should be required in the Base EHR definition. Many providers called for patient education and for ONC to work with SAMHSA, OCR, and CMS. It was also suggested that ONC coordinate with SAMHSA to establish a public-private project to advance the C2S platform and the Consent Implementation Guide using an analogous process to that of the Da Vinci Project with transparency and with no membership fees. Finally, several commenters raised issues that are out of scope for this rule including concerns specifically with the HIPAA Rules or 42 CFR part 2 which are under the authority of OCR and SAMHSA respectively. Response. We appreciate the comments received and the insights into real world implementing challenges of consent management. We agree that there is continued work to be done to ballot and field test the C2S platform and the Consent Implementation Guide and also agree with commenters that identified this resource as having significant potential to support consent management for specific use cases such as 42 CFR part 2, behavioral health, and pediatric care. We also note that we had included a series of questions in our Proposed Rule related to the alignment VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 of FHIR releases and we appreciate comments received related to these questions. We direct readers to section VII.B.4.c for further discussion of our adoption in this rule the FHIR Release 4 standard. We note that the Consent Implementation Guide is designed in FHIR Release 3 and that there is significant work to be done in standards development before the IG would be feasible with FHIR Release 4. At this time, FHIR Release 4 version of FHIR consent resource is not normative and can change from version to version and therefore further development, review, balloting, and testing would be required for a FHIR Release 4 based IG to be a viable consensus standard for adoption in the Program. In consideration of comments, and the scope of the additional work required for readiness of an IG that could be adopted in our regulations, we have not finalized the proposed ‘‘consent management for APIs’’ certification criterion in § 170.315(g)(11). We maintain, as stated above, that the C2S platform and the Consent Implementation Guide may still serve as a template for implementation of consent management workflows leveraging APIs and that it may be a part of health IT solutions to facilitate health information exchange of sensitive information. We will continue to monitor the development of the Consent Implementation Guide and other FHIR resources to support consent management and may consider including in a future rulemaking. 10. Auditable Events and TamperResistance, Audit Reports, and Auditing Actions on Health Information Since adopting the Auditable events and tamper-resistance (§ 170.315(d)(2)), Audit Reports (§ 170.315(d)(3)), and Auditing Actions on health information (§ 170.315(d)(10)) criteria in the 2015 Edition, there has been an update to ASTM E2147—1 standard and has been replaced by a newer version. Given the older version has been deprecated and based on comments received, we have updated these criteria with the most up to date standard, ASTM E1247—18 in § 170.210(h). We have also updated the requirements to align with the new numbering sequence of the updated standard. In order to meet the minimum requirements for capturing and auditing electronic health information, we have specified, in § 170.210(e)(1)(i), that the data elements in sections 7.1.1 through 7.1.3 and 7.1.6, through 7.1.9 in ASTM E1247—18 are required. We believe that the updated standard reinforces what we have previously required and maintained with previous certification PO 00000 Frm 00068 Fmt 4701 Sfmt 4700 requirements and note that there is no substantial change to the standard. We further note that health IT developers must update Health IT Modules to these updated standards referenced in these criteria within 24 months after the publication date of this final rule. We have added as a Maintenance of Certification requirement for the real world testing Condition of Certification requirement, that health IT developers are required to provide the updated certified health IT to all their customers with health IT previously certified to the identified criteria no later than 24 months after the publication date of the final rule. Developers would also need to factor these updates into their next real world testing plan as discussed in section VII.B.5 of this final rule and in § 170.405(b)(7). C. Unchanged 2015 Edition Criteria— Promoting Interoperability Programs Reference Alignment In the FY 2019 IPPS/LTCH PPS proposed rule (83 FR 20516), CMS proposed scoring and measurement policies to move beyond the three stages of meaningful use to a new phase of EHR measurement with an increased focus on interoperability and improving patient access to health information. To reflect this focus, CMS changed the name of the Medicare and Medicaid EHR Incentive Programs, to the Medicare and Medicaid Promoting Interoperability (PI) Programs. To align with the renaming of the EHR Incentive Programs, we proposed to remove references to the EHR Incentive Programs and replace them with ‘‘Promoting Interoperability Programs’’ in the updated 2015 Edition ‘‘automated numerator recording’’ criterion in § 170.315(g)(1) and the ‘‘automated measure calculation’’ criterion in § 170.315(g)(2). Comments. We did not receive any comments on this proposal to remove references to the EHR Incentive Programs and replace them with ‘‘Promoting Interoperability Programs’’ in the updated 2015 Edition ‘‘automated numerator recording’’ criterion in § 170.315(g)(1) and the ‘‘automated measure calculation’’ criterion in § 170.315(g)(2). Response. We have removed references to the EHR Incentive Programs and replaced them with ‘‘Promoting Interoperability Programs’’ in the 2015 Edition ‘‘automated numerator recording’’ criterion in § 170.315(g)(1) and the ‘‘automated measure calculation’’ criterion in § 170.315(g)(2). E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations V. Modifications to the ONC Health IT Certification Program A. Corrections 1. Auditable Events and Tamper Resistance We proposed to revise § 170.550(h)(3) to require the End-User Device Encryption criterion in § 170.315(d)(7) as appropriate, and exempt Health IT Modules from having to meet § 170.315(d)(7) when the certificate scope does not require § 170.315(d)(7) certification (see § 170.315(d)(2)(i)(C)) (84 FR 7454). As noted in the Proposed Rule (84 FR 7454), paragraph 170.315(d)(2)(i)(C) was not applicable to the privacy and security testing and certification of a Health IT Module required by § 170.550(h)(3)(iii), (v), (vii), and (viii), but we intended for it to also be exempted from the aforementioned paragraphs. We, therefore, proposed to revise § 170.550(h)(3)(iii), (v), (vii), and (viii) by removing references to paragraph 170.315(d)(2)(i)(C). Comments. One commenter expressed support of the proposals under section V (‘‘Modifications of the ONC Health IT Certification Program’’) of the Proposed Rule as a whole. However, we received no comments specific to this proposal. Response. We have finalized the revision as proposed. Certification can proceed for the audit log process without the Health IT Module demonstrating that it can record an encryption status in accordance with § 170.315(d)(2)(i)(C). Paragraph § 170.315(d)(2)(i)(C) is not applicable for the privacy and security testing and certification of a Health IT Module required by § 170.550(h)(3)(iii), (v), (vii), and (viii). We had previously identified this error in guidance,66 and have now codified the correction to § 170.550(h)(3)(iii), (v), (vii), and (viii) in regulation. 2. Amendments We proposed to revise § 170.550(h) to remove the ‘‘amendments’’ criterion’s application to certain non-applicable clinical criteria including: ‘‘Drug-drug, drug-allergy interaction checks for computerized provider order entry (CPOE)’’ in § 170.315(a)(4); ‘‘clinical decision support (CDS)’’ in § 170.315(a)(9); ‘‘drug-formulary and preferred drug list checks’’ in § 170.315(a)(10); and ‘‘patient-specific education resources’’ in § 170.315(a)(13) (84 FR 7454). The ‘‘amendments’’ certification criterion § 170.315(d)(4) is not necessarily indicated for health IT capabilities that may not have any 66 https://www.healthit.gov/test-method/ auditable-events-and-tamper-resistance. VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 patient data for which a request for an amendment would be relevant. Comments. One commenter expressed support of the proposals under section V (‘‘Modifications of the ONC Health IT Certification Program’’) of the Proposed Rule as a whole. However, we received no comments specific to this proposal. Response. We have finalized the proposal with modifications. Health IT Modules presented for certification to these criteria do not have to demonstrate the capabilities required by the revised 2015 Edition ‘‘amendments’’ certification criterion (§ 170.315(d)(4)), unless the Health IT Module is presented for certification to another criterion that requires certification to the 2015 Edition ‘‘amendments’’ criterion under the privacy and security (P&S) certification framework. We note that, because we have not finalized our proposal to remove the ‘‘drug-formulary and preferred drug list checks’’ criterion in § 170.315(a)(10) and the ‘‘patientspecific education’’ criterion in § 170.315(a)(13), but to only permit ONC–ACBs to issue certificates for these criteria until January 1, 2022, we have not removed references to these criteria from the exemption in § 170.550(h) at this time. This clarification has already been incorporated into sub-regulatory guidance,67 and is now codified in regulation. 3. View, Download, and Transmit to 3rd Party We proposed to remove § 170.315(e)(1)(ii)(B), which includes a cross-reference to § 170.315(d)(2) indicating that a Health IT Module may demonstrate compliance with active history log requirements if it is also certified to § 170.315(d)(2) (84 FR 7454). Comments. One commenter expressed support of the proposals under section V (‘‘Modifications of the ONC Health IT Certification Program’’) of the Proposed Rule as a whole. However, we received no comments specific to this proposal. Response. We thank commenters for their support and have finalized the proposal to remove § 170.315(e)(1)(ii)(B), which includes a cross-reference to § 170.315(d)(2). As noted in the Proposed Rule (84 FR 7454), this cross-reference indicates that a Health IT Module may demonstrate compliance with activity history log requirements if it is also certified to the 2015 Edition ‘‘auditable events and 67 https://www.healthit.gov/test-method/drugdrug-drug-allergy-interaction-checks-cpoe; https:// www.healthit.gov/test-method/clinical-decisionsupport-cds; https://www.healthit.gov/test-method/ drug-formulary-and-preferred-drug-list-checks; and https://www.healthit.gov/test-method/patientspecific-education-resources. PO 00000 Frm 00069 Fmt 4701 Sfmt 4700 25709 tamper-resistance’’ certification criterion (§ 170.315(d)(2)). However, we no longer require testing of activity history log when certifying for § 170.315(d)(2). Therefore, this crossreference is no longer applicable to meet certification requirements for the updated 2015 Edition ‘‘view, download, and transmit to 3rd party’’ certification criterion (§ 170.315(e)(1)) activity history log requirements. Consequently, we have finalized our proposal to remove § 170.315(e)(1)(ii)(B). 4. Integrating Revised and New Certification Criteria Into the 2015 Edition Privacy and Security Certification Framework We proposed to require the new certification criteria (§ 170.315(d)(12) and (d)(13)) to apply to all § 170.315 certification criteria (84 FR 7454). Therefore, given these and the other modifications discussed above, we proposed to revise the P&S Certification Framework as shown in Table 1 of the Proposed Rule (84 FR 7455), noting that the P&S Certification Framework when finalized could differ depending on finalization of proposals in section III.B.4 of the Proposed Rule (84 FR 7436 and 7437) to remove certain 2015 Edition certification criteria. Comments. One commenter expressed support of the proposals under section V (‘‘Modifications of the ONC Health IT Certification Program’’) of the Proposed Rule as a whole. However, we received no comments specific to this proposal. Response. We thank the commenter for their input regarding our proposals under section V (‘‘Modifications of the ONC Health IT Certification Program’’) of the Proposed Rule. We have adopted the revisions as proposed with modifications. As noted in section IV.B.8.a, we have also adopted both proposed privacy and security transparency attestation criteria (§ 170.315(d)(12) and (d)(13)) with minor modifications. We have applied § 170.315(d)(12) and (d)(13) to all certification criteria across the P&S Certification Framework. Table 2 shows the final updated P&S Certification Framework, which includes all changes including the removal of certain 2015 Edition certification criteria as finalized in section III.B.4 of this final rule. We updated the P&S Certification Framework to reflect other changes made throughout this final rule. The privacy and security certification criteria applicable to a Health IT Module presented for certification is based on the other capabilities included in the Health IT Module and for which certification is sought (80 FR 62705). In this final rule, we have determined that E:\FR\FM\01MYR3.SGM 01MYR3 25710 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations § 170.315(b)(10) and, consistent with the rationale provided in the 2015 Edition final rule, (g)(1) through (6) are exempt from the P&S Certification Framework due to the capabilities included in these criteria, which do not implicate privacy and security concerns (80 FR 62707). We have revised § 170.550(h) of this final rule to reflect these clarifications. We also corrected Table 2 to accurately reflect the regulatory text at § 170.315(a)(3), (a)(14), and (a)(15). Sections 170.315(a)(3), (a)(14), and (a)(15), though included in the regulatory text, were erroneously deleted in the Proposed 2015 Edition Privacy and Security Certification Framework table and we corrected it in Table 2. TABLE 2—2015 EDITION PRIVACY AND SECURITY CERTIFICATION FRAMEWORK It will need to be certified to approach 1 or approach 2 for each of the P&S certification criteria listed in the ‘‘approach 1’’ column If the Health IT Module includes capabilities for certification listed under: Approach 1 Approach 2 § 170.315(a)(1) through (3), (5), (12), (14), and (15). § 170.315(d)(1) (authentication, access control, and authorization), (d)(2) (auditable events and tamper resistance), (d)(3) (audit reports), (d)(4) (amendments), (d)(5) (automatic log-off), (d)(6) (emergency access), (d)(7) (end-user device encryption) (d)(12) (encrypt authentication credentials) (d)(13) (multi-factor authentication). For each applicable P&S certification criterion not certified using Approach 1, the health IT developer submits system documentation that is sufficiently detailed to enable integration such that the Health IT Module has implemented service interfaces for each applicable P&S certification criterion that enable the Health IT Module to access external services necessary to meet the requirements of the P&S certification criterion. § 170.315(a)(4), (9), (10), and (13) ... § 170.315(d)(1) through (d)(3), (d)(5) through (d)(7), (d)(12), and (d)(13). § 170.315(d)(1) through (d)(3), (d)(5) through (d)(8) (integrity), (d)(12), and (d)(13). § 170.315(d)(1) through (d)(3) and (d)(5), (d)(12), and (d)(13) *. § 170.315(d)(1) through (d)(3), (d)(5), (d)(7), (d)(9) (trusted connection), (d)(12), and (d)(13). § 170.315(d)(1) through (d)(3), (d)(5), (d)(9), (d)(12), and (d)(13) *. § 170.315(d)(1) through (d)(3), (d)(7), (d)(12), and (d)(13). § 170.315(d)(1) and (d)(9); (d)(2) or (d)(10) (auditing actions on health information), (d)(12), and (d)(13). § 170.315(d)(1) through (d)(3), (d)(12), and (d)(13) *. § 170.315(b)(1) through (3) and (6) through (9). § 170.315(c) ....................................... § 170.315(e)(1) .................................. § 170.315(e)(2) and (3) ..................... § 170.315(f) ........................................ § 170.315(g)(7) through (g)(10) ......... § 170.315(h) ....................................... An ONC–ACB must ensure that a Health IT Module presented for certification to any of the certification criteria that fall into each regulatory text ‘‘first level paragraph’’ category of § 170.315 (e.g., § 170.315(a)) identified in Table 2 is certified to either Approach 1 (technically demonstrate) or Approach 2 (system documentation). In order to be issued a certification, a Health IT Module would only need to be tested once to each applicable privacy and security criterion identified as part of Approach 1 or Approach 2 so long as the health IT developer attests that such privacy and security capabilities apply to the full scope of capabilities included in the requested certification, except for the certification of a Health IT Module to § 170.315(e)(1) ‘‘view, download, and transmit to 3rd party.’’ For this criterion, a Health IT Module must be separately tested to § 170.315(d)(9) because of the specific capabilities for secure electronic transmission included in the criterion. * § 170.315(d)(2)(i)(C) is not required if the scope of the Health IT Module does not include end-user device encryption features. B. Principles of Proper Conduct for ONC–ACBs 1. Records Retention We proposed to revise the records retention requirement in § 170.523(g) to include the ‘‘life of the edition’’ as well as three years after the retirement of an edition related to the certification of Complete EHRs and Health IT Modules (84 FR 7456). We also proposed to clarify that HHS has the ability to access certification records for the ‘‘life of the edition,’’ which begins with the codification of an edition of certification criteria in the Code of Federal Regulations through a minimum of three years from the effective date of the final rule that removes the applicable edition from the Code of Federal Regulations (CFR), not solely during the three-year VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 period after removal from the CFR (84 FR 7456). Comments. Several commenters expressed support for ONC’s proposal to revise the records retention requirement. Another commenter requested that ONC provide a separate posting or notice that lists the dates specific to when the ‘‘life of the edition’’ starts and dates specific to when the ‘‘life of the edition’’ and the minimum period of three years from the effective date that removes the applicable edition end. Response. We thank commenters for their input and have finalized this revision as proposed. Because the ‘‘life of the edition’’ begins with the codification of an edition of certification criteria in the CFR and ends on the effective date of the final rule that removes the applicable edition from the PO 00000 Frm 00070 Fmt 4701 Sfmt 4700 CFR, the start and end dates for the ‘‘life of the edition’’ are published in the Federal Register in the rulemaking actions that finalize them. The period of three years beyond the ‘‘life of the edition’’ begins on the effective date of the final rule that removes the applicable edition from the CFR, thus the three-year period after removal from the CFR continues through three full calendar years following that date. For example, if the effective date of a hypothetical final rule removing an edition from the CFR were July 1, 2025, then the three year period following the end of the life of this hypothetical edition would be June 30, 2028. We anticipate continuing to work with ONC–ACBs to provide guidance and information resources as necessary or appropriate to promote successful adherence to all Principles of Proper E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations Conduct (PoPC) applicable to their participation in the Program. 2. Conformance Methods for Certification Criteria The PoPC in § 170.523(h) specified that ONC–ACBs may only certify health IT that has been tested by ONC–ATLs using tools and test procedures approved by the National Coordinator. We proposed to revise the PoPC in § 170.523(h) in three ways (84 FR 7456). First, we proposed to revise this PoPC to additionally permit ONC–ACBs to certify Health IT Modules that the ONC– ACB has evaluated for conformance with certification criteria without first passing through an ONC–ATL. However, we proposed that such methods to determine conformity must first be approved by the National Coordinator. Second, we proposed to revise the PoPC to clarify that certifications can only be issued to Health IT Modules and not Complete EHRs. We proposed to remove the 2014 Edition from the CFR (see section III.B.2 of this preamble) and Complete EHR certifications are no longer available for certification to the 2015 Edition (80 FR 62608; 79 FR 54443). We also proposed to remove the provision that permits the use of test results from National Voluntary Laboratory Accreditation Program (NVLAP)-accredited testing laboratories under the Program because the regulatory transition period from NVLAP-accredited testing laboratories to ONC–ATLs has expired (81 FR 72447). Third, we proposed to remove the provision that permits the certification of health IT previously certified to an edition if the certification criterion or criteria to which the Health IT Module(s) was previously certified have not been revised and no new certification criteria are applicable because the circumstances that this provision seeks to address are no longer feasible with certification to the 2015 Edition. Comments. One commenter sought clarification on whether the proposal to remove references to § 170.545, which includes the ability to maintain Complete EHR certification, would impact § 170.550(k), which requires ONC–ACBs to accept requests for a newer version of a previously certified Health IT Module(s) to inherit the certified status of the previously certified Health IT Module(s) without requiring the newer version to be recertified. The commenter strongly urged ONC to allow ONC–ACBs to grant inherited certification status to updated versions of certified technology. VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 Another commenter expressed support for ONC’s proposal to revise the PoPC to clarify that certifications can only be issued to Health IT Modules and not Complete EHRs. The commenter also expressed support for ONC’s proposal to remove the provision that permits the certification of health IT previously certified to an edition if the certification criterion or criteria to which the Health IT Module(s) was previously certified have not been revised and no new certification criteria are applicable because the circumstances that this provision seeks to address are no longer feasible with certification to the 2015 Edition. Response. We have finalized the proposal to revise the PoPC in § 170.523(h). As noted in the Proposed Rule, the ability to maintain Complete EHR certification is only permitted with health IT certified to the 2014 Edition certification criteria (84 FR 7435). Because this concept was not continued in the 2015 Edition (84 FR 7456), we proposed revisions to clarify that Complete EHR certifications are no longer available. We note that ONC– ACBs have discretion, and processes in place, to evaluate updates made to certified health IT and assess the need for additional testing. These ONC–ACB processes allow for efficient certification of upgraded version releases of previously certified health IT while ensuring its continued conformity with certification criteria and standards to which the prior version release of the same Module(s) had been certified. We have finalized this proposal. Comments. Multiple commenters expressed support for the use of conformance methods approved by the National Coordinator. One commenter noted that the opportunity would enable alternative testing methods and less costly testing. Another commenter noted that this proposal would reduce burden for EHR developers and for ONC–ATLs by leveraging certification programs and alternative test methods and specifically requested that ONC consider a specific proprietary certification related to e-prescribing functionalities for potential approval. While expressing appreciation for the flexibility offered by the proposed revision, one commenter expressed concern about certifications based on other ONC-approved conformance methods that are not specifically designed to test against the ONC criteria and stressed the importance of assessing conformance to technical standards before being deployed to end users. Another commenter questioned whether the ONC–ACB would be permitted to do all evaluation directly, thus eliminating PO 00000 Frm 00071 Fmt 4701 Sfmt 4700 25711 the need for ONC–ATLs entirely. Two commenters sought clarity from ONC as to what metrics the National Coordinator will use to approve a conformance method. These commenters also sought clarification on ONC’s plan to reduce the risk of developers seeking certification through fraudulent means. The commenters cited the example of two developers who are currently operating under corporate integrity agreements with the HHS Office of the Inspector General due to court cases brought against them in relation to conduct including, but not limited to, the process of seeking certification. Response. We thank commenters for their feedback. We have finalized the proposal to revise the PoPC in § 170.523(h) to permit a certification decision to be based on an evaluation conducted by the ONC–ACB for Health IT Modules’ compliance with certification criteria by use of conformity methods approved by the National Coordinator. We note that all certification criteria will continue to have some method of holding developers responsible for demonstrating conformity whether through ONC–ATL testing, developer self-declaration, or some other method assessed and approved by the National Coordinator. As noted in the Proposed Rule (84 FR 7456), ONC acknowledges that there is a broad spectrum of types of evidence of conformance, from laboratory testing with an ONC–ATL to developer self-declaration. Some of these types of evidence may be more appropriate than others in specific circumstances. Historically, it has been proven that, in some circumstances, the requirement for ONC–ATL testing has presented more administrative burden on health IT developers than benefits for assessing conformity. For example, under § 170.315(a)(5) demographics certification criteria require only documentation or a visual inspection, and do not require testing by an ONC– ATL. We note that industry advancements have presented opportunities for improved efficiency for demonstrating conformity and this flexibility will allow the Program to advance as the state of the art for demonstrating conformance evolves. This flexibility addresses the current Program construct limitation of ONC– ACB certification only being permissible for health IT that has been tested by an ONC–ATL with ONC-approved test procedures. In some instances, such as developer self-declaration, there is no testing required and thus bypassing the ONC–ATL testing step reduces burden and enables a more streamlined and E:\FR\FM\01MYR3.SGM 01MYR3 25712 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations efficient process. By adopting this flexibility, we may approve conformance methods that rely solely on ONC–ACB evaluation, and not ONC– ATL testing, when appropriate. We will follow the same process used for alternative test methods (76 FR 1280) for the submission of non-governmental developed conformance methods to the National Coordinator for approval. A person or entity may submit a conformance method to the National Coordinator to be considered for approval for use under the Program. The submission should identify the developer of the conformance method; specify the certification criterion or criteria that is/are addressed by the conformance method; and explain how the conformance method would evaluate a Health IT Module’s or, if applicable, other type of health IT’s, compliance with the applicable certification criterion or criteria. The submission should also provide information describing the process used to develop the conformance method, including any opportunity for the public to comment on the conformance method and the degree to which public comments were considered. In determining whether to approve a conformance method for purposes of the Program, the National Coordinator will consider whether it is clearly traceable to a certification criterion or criteria adopted by the Secretary; whether it is sufficiently comprehensive (i.e., assesses all required capabilities) for the assessment of Health IT Modules’, or other type of health IT’s, conformance to the certification criterion or criteria adopted by the Secretary; whether an appropriate public comment process was used during the development of the conformance method; and any other relevant factors. When the National Coordinator has approved a conformance method for purposes of the Program, we will publish a notice of availability in the Federal Register and identify the approved conformance method on the ONC website. 3. ONC–ACBs To Accept Test Results From Any ONC–ATL in Good Standing We proposed to add the PoPC for ONC–ACBs in § 170.523(r) in order to address business relationships between ONC–ACBs and ONC–ATLs (84 FR 7456). To encourage market competition, we proposed to require ONC–ACBs to accept test results from any ONC–ATL that is in good standing under the Program and is compliant with its ISO/IEC 17025 accreditation requirements. However, if an ONC–ACB has concerns about accepting test results from a certain ONC–ATL, the ONC–ACB VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 would have an opportunity to explain the potential issues to ONC and NVLAP, and on a case-by-case basis, ONC could consider the facts and make the final determination. Comments. Multiple commenters expressed support for the proposed requirement that ONC–ACBs must accept test results from any ONC–ATL in good standing. One commenter expressed an opinion that this proposal has value in ensuring the credibility of the Program. Another commenter agreed that this proposal would encourage market competition and provide more options to developers. One commenter recommended that ONC–ATLs should also be required to provide their results to any ONC–ACB to which the developer has chosen to present its health IT for certification, stating that this consistency across ONC–ACBs and ONC–ATLs would ensure market competition. Response. We thank commenters for their input. We have finalized the PoPC for ONC–ACBs in § 170.523(r) as proposed. While an ONC–ATL attempting to inappropriately restrict developers’ choice of ONC–ACBs to those favored by the ONC–ATL would not support appropriate competition, we do not believe it would be practical to mandate direct transmission of ONC– ATL results to any ONC–ACB designated by the developer, in part because developers often do not initiate engagement with an ONC–ACB until after they have received and had a chance to review their ONC–ATL results. To date, we are not aware of substantial evidence that the standard practice of NVLAP-accredited testing laboratories providing test results to the client who engaged them to test their Health IT Modules is not serving as a sufficient safeguard against anticompetitive behavior on the part of ONC–ATLs in relation to their client developers’ selection of ONC–ACBs. 4. Mandatory Disclosures and Certifications We proposed to revise the PoPC in § 170.523(k) to remove § 170.523(k)(1)(ii)(B) because certifications can only be issued to Health IT Modules and not Complete EHRs (84 FR 7456). We also proposed to revise § 170.523(k)(1)(iii)(A) to broaden the section beyond the Promoting Interoperability (PI) Programs. We proposed to revise the section to include 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 PO 00000 Frm 00072 Fmt 4701 Sfmt 4700 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. We also proposed to remove the provision in § 170.523(k)(3) that requires a certification issued to a precoordinated, integrated bundle of Health IT Modules to be treated the same as a certification issued to a Complete EHR for the purposes of § 170.523(k)(1), except that the certification must also indicate each Health IT Module that is included in the bundle (84 FR 7457). We proposed to revise § 170.523(k)(4) to clarify that 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 (84 FR 7457). We also proposed changes related to transparency attestations and disclosures of limitations in section III.B.5 of the Proposed Rule preamble (84 FR 7437 and 7438). Additionally, we proposed other new PoPC for ONC– ACBs as discussed in sections VII.B.5 (84 FR 7501) and VII.D (84 FR 7506 and 7507) of the Proposed Rule preamble. Comments. Multiple commenters expressed support for ONC’s proposal to include 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. One commenter endorsed the transparency that this proposal would provide, noting that it would help providers budget for their health IT, but also expressed concern that requiring developers to disclose how much they charge for a particular functionality may be impractical due to variations across contracts and over time, or potentially have unintended consequences on market pricing. Multiple commenters expressed support for our proposal to remove subsection § 170.523(k)(1)(ii)(B). One commenter expressed support for ONC’s proposed revisions to § 170.523(k)(4). Another commenter was supportive of the proposal to remove the provision in § 170.523(k)(3). Response. We thank commenters for their support. We have finalized the proposals, in their entirety, as proposed. To clarify, the finalized revision in § 170.523(k) requires disclosure of a detailed description of all known material information concerning E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations additional types of costs or fees a user may be required to incur or pay to implement or use the Health IT Module’s capabilities to achieve any use within the scope of the health IT’s certification. We emphasize that (unless required elsewhere in CFR part 170) the requirement is for a description of the types of costs or fees, not predicted amounts of these costs or fees across the full array of probable implementation circumstances or over time. Among other considerations, we note that costs required to achieve some particular uses within the scope of some certifications may be for third-party services outside the control of the developer required to disclose the detailed description. C. Principles of Proper Conduct for ONC–ATLs—Records Retention We proposed to revise the records retention requirement in § 170.524(f) to include the ‘‘life of the edition’’ as well as 3 years after the retirement of an edition related to the testing of Health IT Module(s) to an edition of certification criteria (84 FR 7457). The circumstances are the same as in section V.B.1 of the Proposed Rule preamble, as summarized above. Therefore, we proposed the same revisions for ONC– ATLs as we did for ONC–ACBs. We did not receive any comments specific to this proposed revision to the PoPC for ONC–ATLs. In light of the absence of comments, we have finalized the revisions as proposed. VI. Health IT for the Care Continuum Health IT should help promote and support patient care when and where it is needed. This means health IT should help support patient populations, specialized care, transitions of care, and practice settings across the care continuum. In the Proposed Rule, we provided a history of the many actions we have taken since the inception of the ONC Health IT Certification Program through the Proposed Rule (84 FR 7457). As stated in the Proposed Rule, section 4001(b)(i) of the Cures Act instructs the National Coordinator to encourage, keep, or recognize, through existing authorities, the voluntary certification of health IT under the Program for use in medical specialties and sites of service for which no such technology is available or where more technological advancement or integration is needed. This provision of the Cures Act closely aligns with our ongoing collaborative efforts with both Federal partners and stakeholders within the health care and health IT community to encourage and support the advancement of health IT for a wide range of clinical settings. These initiatives have included projects VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 related to clinical priorities beyond those specifically included in the EHR Incentive Programs (now called the Promoting Interoperability Programs) including efforts in public health, behavioral health, and long-term and post-acute care. We noted in the Proposed Rule that these initiatives often include the development of nonregulatory informational resources to support the specific implementation goal and align with the technical specifications already available in the Program for certification. To advance these efforts, we also explained in the Proposed Rule that we generally consider a range of factors including: Stakeholder input and identification of clinical needs and clinical priorities, the evolution and adoption of health IT across the care continuum, the costs and benefits associated with any policy or implementation strategy related to care settings and sites of service, and potential regulatory burden and compliance timelines. Our goal was then and is now to support the advancement of interoperable health IT and to promote health IT functionality in care and practice settings across the care continuum (see 80 FR 62604). As stated in the Proposed Rule (84 FR 7458), generally, our approach can be summarized in three parts: • First, we analyze existing certification criteria to identify how such criteria may be applicable for medical specialties and sites of service. • Second, we focus on the real-time evaluation of existing and emerging standards to determine applicability to medical specialties and sites of service as well as to the broader care continuum, including the evaluation of such standards for inclusion in the ONC Interoperability Standards Advisory (ISA).68 • Third, we may work in collaboration with stakeholders to support the development of informational resources for medical specialties and sites of service for which we identify a need to advance the effective implementation of certified health IT. We continue to believe this approach is economical, flexible, and responsive for both health care providers and the health IT industry. It is also in alignment with the provisions of section 4001(a) in the Cures Act related to burden reduction and promoting interoperability. We are committed to continuing to work with stakeholders to promote the adoption of health IT to support medical specialties and sites of service and to help ensure that 68 https://www.healthit.gov/isa/. PO 00000 Frm 00073 Fmt 4701 Sfmt 4700 25713 providers have the tools they need (such as access to essential health information across care settings) to support patients at the point of care. A. Health IT for Pediatric Setting Section 4001(b)(iii) of the Cures Act— ‘‘Health information technology for pediatrics’’ requires: • First, that the Secretary, in consultation with relevant stakeholders, shall make recommendations for the voluntary certification of health IT for use by pediatric health providers to support the health care of children, and • Second, that the Secretary shall adopt certification criteria to support the voluntary certification of health IT for use by pediatric health providers to support the health care of children. In the Proposed Rule (84 FR 7458), we described our approach to stakeholder engagement, the analysis used to develop the recommendations, the specific 2015 Edition certification criteria that support each recommendation, and the voluntary certification of health IT for use by pediatric health providers to support the health care of children. Comments. We received several comments requesting further clarification on whether the pediatric health IT recommendations will be adopted as an independent certification program and/or certification criteria designated specifically for pediatric care. One commenter recommended that pediatric provisions should be formalized over time within what they refer to as the current pediatric program and not as a separate program, and that this future aligns with the 2015 Children’s EHR Format. One commenter also sought clarification as whether ONC intends for other government agencies/programs such as CHIP, to develop conditions of participation or financial incentives around the adoption of certification criteria identified in this rulemaking. We also received several comments stating that since current EHRs have pediatric capabilities, there is no need to specify requirements in regulation, and that there is no value in having EHRs certified as ‘‘pediatric-friendly,’’ only increased costs. We also received several comments stating that our approach reflects an attempt to retrofit the needs of pediatric patients by using adult requirements. Response. We thank commenters for their feedback. The comments we received suggests a need for greater clarity on our approach. We therefore reiterate that we did not propose to adopt care- or practice-specific certification tracks, or additional E:\FR\FM\01MYR3.SGM 01MYR3 25714 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations voluntary program(s), in parallel to the existing voluntary ONC Health IT Certification Program. In the Proposed Rule, we reiterated our statements from the 2015 Edition final rule, which explained that we did not intend to develop and issue separate regulatory certification ‘‘paths’’ or ‘‘tracks’’ for particular care or practice settings (e.g., a ‘‘long-term and post-acute care (LTPAC) certification’’) because it would be difficult to independently construct such ‘‘paths’’ or ‘‘tracks’’ in a manner that would align with other relevant programs and specific stakeholder needs. We further stated that stakeholders had indicated that separate certification pathways could have unintended consequences related to increasing burden on health care providers and health IT developers. We also stated that we would welcome the opportunity to work with HHS agencies, other agencies, and provider associations in identifying the appropriate functionality and certification criteria in the Program to support their stakeholders (80 FR 62704). In response to the comments regarding our approach to implement section 4001(b) of the Cures Act, we clarify that the 2015 Edition certification criteria identified for the voluntary certification of health IT for use by pediatric health providers are agnostic to the age of the patient (with the exception of the pediatric vital signs in the USCDI). Therefore, we believe our approach to fulfilling the Cures Act requirement for pediatric health care providers and settings, which involves identifying existing, new, or revised 2015 Edition criteria—as applicable to an identified clinical or interoperability priority—is appropriate across patient populations. We also note that our authority is limited to implementing the described requirements of the Cures Act related to pediatric settings. We cannot speak for the actions of other Federal agencies, but would note once again that we have taken a limited regulatory approach to implementing the pediatric provisions of the Cures Act. Comments. We received multiple comments requesting clarification on the intended use and functionality of the Certified Health IT Products List (CHPL) for pediatric certification, such as guidance on navigating the CHPL to identify relevant products based on pediatric care settings. Response. We thank stakeholders for their comments on the CHPL. We do not intend to have a separate tag functionality on the CHPL that identifies a product specifically for pediatric care. We did not propose, and do not intend, for there to be a separate VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 certification pathway or a new ONC certification designation called pediatric certification. However, we recognize that beyond certification and testing there are certain implementation needs that are important for pediatric care and services. We agree with the overwhelming prior feedback from stakeholders stating that they should not have to purchase separate products that contain universally applicable functionality, such as the ‘‘API functionality’’ certification criteria. We are exploring options for non-regulatory informational resources on effective implementation of health IT for use by pediatric health providers to expand the availability of health IT products supporting the care of children. Comments. We received comments regarding how the approach for voluntary certification of health IT for use by pediatric health providers might be applicable to other medical specialties and use cases. One commenter noted that the pediatric experience is scalable and should be extended to other disciplines. Another commenter sought clarification if this model could be used for broad applicability to multiple medical specialties such as pathologists. Response. We thank these commenters for identifying the applicability of our approach to pediatrics to other medical specialties. We confirm that our approach for advancing health IT can be used for other use cases and medical specialties, and welcome the opportunity to engage with stakeholders representing a wide range of medical specialties or sites of service to provide insight into this process and to inform stakeholder-led efforts to improve clinically-relevant health IT implementation across specialties and settings of care. 1. Background and Stakeholder Convening Over the past ten years, a number of initiatives have focused on the availability and use of effective health IT tools and resources for pediatric care. These have included a number of public-private partnerships including efforts between HHS, State agencies, and health systems for innovative projects that range from care coordination enterprise solutions to immunization information systems and to point of care solutions for specialty needs. In order to learn from and build upon these efforts, ONC has engaged with stakeholders in both the public and private sector including other Federal, State and local government partners, health care providers engaged in the care of children, standards developing PO 00000 Frm 00074 Fmt 4701 Sfmt 4700 organizations, charitable foundations engaged in children’s health care research, and health IT developers supporting pediatric care settings. For example, significant work has been done by the Agency for Healthcare Research and Quality (AHRQ), CMS, the Health Resources and Services Administration (HRSA), and organizations around the Children’s EHR Format (Children’s Format), which is critical to any discussion of the pediatric health IT landscape.69 The Children’s Format was authorized by the 2009 Children’s Health Insurance Program Reauthorization Act (CHIPRA) 70 and developed by AHRQ in close collaboration with CMS. It was developed to bridge the gap between the functionality present in most EHRs currently available and the functionality that could optimally support the care of children. Specifically, the Children’s Format provides information to EHR system developers and others about critical functionality and other requirements that are helpful to include in an EHR system to address health care needs specific to the care of children. The final version of the Children’s Format, released in 2015, consists of 47 high priority functional requirements in 19 topic areas that focus on improvements that would better support the safety and quality of care delivered to children. The Children’s Format was intended as a starting point for developers, users, and purchasers for informing an approach for pediatric voluntary certification. We refer to the Voluntary Edition proposed rule for a description of our prior discussion around the Children’s Format (79 FR 10930). In the summer of 2017, the American Academy of Pediatrics (AAP) reviewed the 2015 Children’s Format using a robust analytical process and engagement with their members. The result was a prioritized list of eight clinical priorities to support pediatric health care (‘‘Priority List’’). In October 2017, we held a technical discussion with stakeholders titled ‘‘Health IT for Pediatrics’’ with the specific purpose of obtaining input from an array of stakeholders in an effort to draw correlations between the pediatric providers’ clinical priorities identified in the Priority List with the detailed 69 Agency for Health Care Information and Technology. Health Information Technology. https:// healthit.ahrq.gov/health-it-tools-and-resources/ childrens-electronic-health-record-ehr-format. Accessed September, 2017. 70 Pub. L. 111–3, section 401 https:// healthit.ahrq.gov/sites/default/files/docs/citation/ children-ehr-format-enhancement-finalrecommendation-report-abridged.pdf. E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations technical requirements outlined in the Children’s Format and the capabilities and standards that could be included in certified health IT. Through this collaborative approach, the meeting participants identified a set of priority needs for health IT to support pediatric care based upon those identified by the Priority List and the primary correlation to the Children’s Format. 2. Recommendations for the Voluntary Certification of Health IT for Use in Pediatric Care To support the first part of section 4001(b) of the Cures Act, we considered the historical efforts on the Children’s Format, the input from stakeholders, and our own technical analysis and review of health IT capabilities and standards to develop a set of recommendations for voluntary certification of health information technology for use by pediatric health providers to support the health care of children. These include eight recommendations related to the Priority List: • Recommendation 1: Use biometricspecific norms for growth curves and support growth charts for children • Recommendation 2: Compute weight-based drug dosage • Recommendation 3: Ability to document all guardians and caregivers • Recommendation 4: Segmented access to information • Recommendation 5: Synchronize immunization histories with registries • Recommendation 6: Age- and weight- specific single-dose range checking • Recommendation 7: Transferrable access authority • Recommendation 8: Associate maternal health information and demographics with newborn We also developed two additional recommendations beyond the Priority List, which relate to other items within the Children’s Format that are considered important to pediatric stakeholders. These additional recommendations, which may be supported by certified health IT, are as follows: • Recommendation 9: Track incomplete preventative care opportunities • Recommendation 10: Flag special health care needs In order to implement the second part of section 4001(b) of the Cures Act for the adoption of certification criteria to support the voluntary certification of health IT for use by pediatric health care providers, we identified both the 2015 Edition certification criteria and the new or revised certification criteria VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 proposed in the Proposed Rule that support the 10 recommendations for the voluntary certification of health IT for use by pediatric health providers to support the health care of children. In the Proposed Rule (84 FR 7459), we directed readers to the appendix of the Proposed Rule for a set of technical worksheets, which include a crosswalk of the various criteria specifically associated with each recommendation. These worksheets outlined the following information: • The alignment of each recommendation to the primary Children’s Format 71 item identified by stakeholders • The alignment of each recommendation to the 2015 Edition certification criteria and the new or revised criteria described in the Proposed Rule • Supplemental items from the Children’s Format for each recommendation and the related 2015 Edition certification criteria We also sought comment on the following: 1. Relevant gaps, barriers, safety concerns, and resources (including available best practices, activities, and tools) that may impact or support feasibility of the recommendation in practice. 2. Effective use of health IT itself in support of each recommendation as it relates to provider training, establishing workflows, and other related safety and usability considerations. 3. If any of the 10 recommendations should not be included in ONC’s final recommendations for voluntary certification of health IT for use by pediatric health providers to support the health care of children. 4. Any certification criteria from the Program that is identified for the 10 recommendations that should not be included to support the specific recommendation. Comments. We received many comments asking for detailed guidance and/or implementation specifications post final rulemaking, with one commenter noting that the majority of recommendations require additional capabilities beyond the scope of any aligned existing or proposed certification criteria. We also received many comments providing implementation recommendations specific to the 10 ONC recommendations for the voluntary certification of health IT for use by pediatric health providers such as 71 https://healthit.ahrq.gov/health-it-tools-andresources/childrens-electronic-health-record-ehrformat. PO 00000 Frm 00075 Fmt 4701 Sfmt 4700 25715 adding in developmental activity milestones, including what versions of growth charts should be supported, and including listings to clearly identify medical home providers. Several commenters also referenced concerns regarding the feasibility of implementing the content included as part of the pediatric health IT technical worksheet crosswalk analysis included in the Proposed Rule appendix for Recommendation 5 ‘‘Synchronize immunization histories with registries.’’ In this regard, several commenters noted that FHIR is not currently consistent with CDC/AIRA standards or practices for immunization data submission or query/response, and that public health is not currently funded to provide this capability from IIS. Response. We thank commenters for their useful input regarding the technical worksheets in the appendix we included for the Proposed Rule. As we stated in the Proposed Rule, these comments, and the detailed insights received through stakeholder outreach, will inform the future development of a non-binding informational guide or informational resource to provide useful information for health IT developers and pediatric care providers seeking to successfully implement these health IT solutions in a clinical setting. To facilitate adoption of the ten recommendations, we are developing a Pediatric Health IT Developer Informational Resource and a Pediatric Health IT Provider Informational Resource to be available for respective use in 2020. As such, we appreciate the comments we received specific to implementation recommendations and will take them into account in the support of the creation of non-regulatory informational resources for health IT developers and other stakeholders. We plan to continue working with stakeholders as we further develop and consider technical and implementation recommendations we have received through solicited public comments, the Health Information Technology Advisory Committee (HITAC), and other engagements. We also direct readers to our ‘‘pediatrics health IT’’ web page (www.healthIT.gov/pediatrics) for information on future work pertaining to health IT for pediatric care. Comments. We received several comments suggesting the use of pediatric-focused clinicians and settings to test EHR systems as part of these provisions, specifically recommending that we should require EHR developers to use pediatric-focused scenarios and mock pediatric patients when testing functionality, as well as requiring the E:\FR\FM\01MYR3.SGM 01MYR3 25716 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations inclusion of pediatric clinicians as part of end-user testing. Response. We thank commenters for their input. We agree that it would be beneficial for health IT developers to include pediatric-focused testing of their health IT especially with regards to ensuring patient safety. We note that we have established requirements for real world testing that requires health IT developers to real world test their health IT for the types of setting(s) in which it is intended for use (we refer readers to section VII.B.5 for more information on real world testing Condition and Maintenance of Certification requirements). a. 2015 Edition Certification Criteria In order to implement the second part of section 4001(b) of the Cures Act to adopt certification criteria to support the voluntary certification of health IT for use by pediatric health providers to support the health care of children, we identified the following already adopted 2015 Edition certification criteria in the Proposed Rule that support the recommendations. The already adopted 2015 Edition criteria are as follows: • ‘‘API functionality’’ criteria (§ 170.315(g)(7)–(g)(9)) which address many of the challenges currently faced by patients and by caregivers such as parents or guardians accessing child’s health information, including the ‘‘multiple portal’’ problem, by potentially allowing individuals to aggregate health information from multiple sources in a web or mobile application of their choice. • ‘‘Care plan’’ criterion (§ 170.315(b)(9)) which supports pediatric care by facilitating the documentation of electronic health information in a structured format to improve care coordination (80 FR 62648 and 62649). • ‘‘Clinical decision support’’ (CDS) criterion (§ 170.315(a)(9)) which supports pediatric care by enabling interventions based on the capture of biometric data. • ‘‘Common Clinical Data Set’’ (§ 170.315(b)(4) and § 170.315(b)(5)) which includes optional pediatric vital sign data elements including as optional the reference range/growth curve for three pediatric vital signs—BMI percent per LOINC identifiers for age per sex, weight per length/sex, and head occipital-frontal circumference for children less than three years of age. • ‘‘Data segmentation for privacy’’ send criterion and receive criterion (§ 170.315(b)(7) and § 170.315(b)(8)) which provides the ability to: Create a summary record that is tagged at the document level as restricted and subject VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 to re-disclosure; receive a summary record that is document-level tagged as restricted; separate the document-level tagged document from other documents received; and view the restricted document without having to incorporate any of the data from the document. • ‘‘Demographics’’ criterion (§ 170.315(a)(5)) which supports pediatric care through the capture of values and value sets relevant for the pediatric health care setting as well as allowing for improved patient matching which is a key challenge for pediatric care. • ‘‘Electronic Prescribing’’ criterion (§ 170.315(b)(3)) which includes an optional Structured and Codified Sig Format, which has the capability to exchange weight-based dosing calculations within the NCPDP SCRIPT 10.6 standard and limits the ability to prescribe all oral, liquid medications in only metric standard units of mL (i.e., not cc) important for enabling safe prescribing practices for children. • ‘‘Family health history’’ criterion (§ 170.315(a)(12)) which supports pediatric care because it leverages concepts or expressions for familial conditions, which are especially clinically relevant when caring for children. • ‘‘Patient health information capture’’ criterion (§ 170.315(e)(3)) which supports providers’ ability to accept health information from a patient or authorized representative. This criterion could support pediatric care through documentation of decisionmaking authority of a patient representative. • ‘‘Social, psychological, and behavioral data’’ criterion (§ 170.315(a)(15)) which supports integration of behavioral health data into a child’s record across the care continuum by enabling a user to record, change, and access a patient’s social, psychological, and behavioral data based using SNOMED CT® and LOINC® codes. • ‘‘Transitions of care’’ criterion (§ 170.315(b)(1)) which supports structured transition of care summaries and referral summaries that help ensure the coordination and continuity of health care as children transfer between different clinicians at different health care organizations or different levels of care within the same health care organization. • ‘‘Transmission to immunization registries’’ criterion (§ 170.315(f)(1)) which supports the safe and effective provision of child health care through immunizations and registry linkages. This criterion also provides the ability to request, access, and display the PO 00000 Frm 00076 Fmt 4701 Sfmt 4700 evaluated immunization history and forecast from an immunization registry for a patient. Immunization forecasting recommendations allow for providers to access the most complete and up-to-date information on a patient’s immunization history to inform discussions about what vaccines a patient may need based on nationally recommended immunization recommendations (80 FR 62662 through 62664). • ‘‘View, download, and transmit to 3rd party’’ (VDT) criterion (§ 170.315(e)(1)) which supports transferrable access authority for the pediatric health care setting and provides the ability for patients (and their authorized representatives) 72 to view, download, and transmit their health information to a 3rd party. We noted in the Proposed Rule (84 FR 7460) that some of these criteria may be updated based on proposals contained in the Proposed Rule (see further discussion below on new or revised certification criteria); and stated that we continue to believe that prior to any such updates, technology that is currently available and certified to these 2015 Edition criteria can make a significant impact in supporting providers engaged in the health care of children. We invited readers to use the technical worksheets in the appendix of the Proposed Rule to inform their public comment on the recommendations, the inclusion of specific items from the Children’s Format, and the identified 2015 Edition certification criteria as they relate specifically to use cases for pediatric care and sites of service. b. New or Revised Certification Criteria In order to implement the second part of section 4001(b)(iii) of the Cures Act to adopt certification criteria to support the voluntary certification of health information technology for use by pediatric health providers to support the health care of children, we also identified new or revised 2015 Edition certification criteria (and standards) in the Proposed Rule (84 FR 7460) that support the recommendations. These proposed criteria and standards include: • New API criterion (§ 170.315(g)(10)) which would serve to implement the Cures Act requirement to permit health information to be accessed, exchanged, 72 The VDT criterion includes a ‘‘patientauthorized representative’’ concept that aligns with the use of the term under the EHR Incentive Program. A ‘‘patient-authorized representative’’ is defined as any individual to whom the patient has granted access to their health information (see also 77 FR 13720). However, consent is not needed for minors, for whom existing local, state, or Federal law grants their parents or guardians access (see also 77 FR 13720). E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations and used from APIs without special effort. • New ‘‘DS4P’’ criteria (two for C– CDA ((§ 170.315(b)(12)) and (§ 170.315(b)(13)) and one for FHIR (§ 170.315(g)(11))) that would support a more granular approach to privacy tagging data for health information exchange supported by either the C– CDA or FHIR-based exchange standards. • New electronic prescribing certification criterion (§ 170.315(b)(11)), which would support improved patient safety and prescription accuracy, workflow efficiencies, and increased configurability of systems including functionality that could support pediatric medication management. • USCDI (§ 170.213) and USCDIbased criteria which enables the inclusion of pediatric vital sign data elements, including the reference range/ scale or growth curve for BMI percentile per age and sex, weight for age per length and sex, and head occipitalfrontal circumference. Each of the new or revised certification criteria and standards are further described in other sections of this final rule, including all final actions related to the criteria (some of which are described below in the response to comments). Comments. A majority of comments received supported our recommendations for the voluntary certification of health IT for use by pediatric health providers to support the health care of children along with the alignment with the Children’s Format and 2015 Edition certification criteria. Several commenters suggested that the 10 recommendations should only be the first step and encouraged future development of additional recommendations using the Children’s Format. Commenters were also pleased with the 10 recommendations selected by ONC from the Children’s Format stating that they represent a strong, positive step forward for improving EHRs used in the care of children. Many commenters stated that they support the continued alignment with the 2015 Edition recommendations. Response. We thank commenters for their support and feedback. As such, we have maintained the 10 recommendations for the voluntary certification of health IT for use by pediatric health providers to support the health care of children. We have finalized in this final rule the majority of the aligned proposed new 2015 Edition certification criteria that support the voluntary certification of health IT for use by pediatric health providers, with the exception of the proposed criterion for ‘‘consent management’’ in § 170.315(g)(11) since we did not VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 finalize our proposal for the criterion in this final rule. The functionality of the proposed new ‘‘DS4P’’ criteria have been incorporated into the already adopted 2015 Edition DS4P criteria DS4P-send (§ 170.315(b)(7)) and DS4Preceive (§ 170.315(b)(8)) now referred to as ‘‘Security tags—Summary of Caresend’’ and ‘‘Security tags—Summary of Care—receive,’’ respectively. The functionality of the proposed new e-Rx criterion was also incorporated in the already adopted e-Rx criterion (§ 170.315(b)(3)). Last, we have removed the ‘‘Common Clinical Data Set’’ (§ 170.315(b)(4) and § 170.315(b)(5)) from the 2015 Edition in this final rule. We note that we are aware that the NCPDP SCRIPT Standard Version 2017071 Implementation Guide contains a number of requirements intended to improve accurate dosing and pediatric patient safety. One such requirement is the inclusion of the most recent patient height and weight in the Observation Segment on all new and renewal prescriptions sent from the prescriber to the pharmacy, along with the date associated with these measures, for all patients 18 years old and younger. We are also aware of the challenges that such a requirement may pose on specific providers and under certain circumstances where height and/ or weight is not required or applicable for dosing of the product. We believe additional work must be done on refining this requirement, and will continue to monitor standards and industry advancements before proposing such a requirement. At this time, we recommend vital signs to be included in all electronic prescriptions for all patient populations when available and where applicable. The 10 recommendations and the aligned 2015 Edition certification criteria support the health IT needs of pediatric care providers. We believe further support can be provided through non-regulatory informational resources. These resources can help inform technical and implementation specifications for health IT developers and products for use by pediatric health providers to support the health care of children. We also agree with commenters that the 10 recommendations are a first step and welcome input and collaboration from the health IT industry and health care providers to continue efforts to develop and build a health IT infrastructure supporting pediatric care and other specialty care and sites of service across the continuum. PO 00000 Frm 00077 Fmt 4701 Sfmt 4700 25717 B. Health IT and Opioid Use Disorder Prevention and Treatment—Request for Information We identified a need to explore ways to advance health IT across the care continuum to support efforts to fight the opioid epidemic. For that purpose, in the Proposed Rule, we included a request for information (RFI) related to health IT and opioid use disorder prevention and treatment (84 FR 7461 through 7465). We received over 100 comments in responses to this RFI, which included recommendations from the HITAC. We appreciate the feedback and recommendations provided by commenters and the HITAC taskforce, respectively. We plan to share this feedback with appropriate Department partners. VII. Conditions and Maintenance of Certification Requirements for Health IT Developers Section 4002 of the Cures Act modifies section 3001(c)(5) of the Public Health Service Act (PHSA) to require the Secretary of HHS, through notice and comment rulemaking, to establish Conditions and Maintenance of Certification requirements for the Program. Specifically, health IT developers or entities must adhere to certain Conditions and Maintenance of Certification requirements concerning information blocking; appropriate exchange, access, and use of electronic health information; communications regarding health IT; application programming interfaces (APIs); real world testing; attestations regarding certain Conditions and Maintenance of Certification requirements; and submission of reporting criteria under the EHR Reporting Program under section 3009A(b) of the PHSA. A. Implementation To implement section 4002 of the Cures Act, we proposed an approach whereby the Conditions and Maintenance of Certification requirements express initial certification requirements for health IT developers and their certified Health IT Module(s) as well as ongoing maintenance requirements that must be met by both health IT developers and their certified Health IT Module(s) under the ONC Health IT Certification Program (Program). If these requirements are not met, the health IT developer may no longer be able to participate in the Program and/or its certified health IT may have its certification terminated. We proposed to implement each Condition of Certification requirement with further specificity as it applies to E:\FR\FM\01MYR3.SGM 01MYR3 25718 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations the Program. We also proposed to establish Maintenance of Certification requirements for certain Conditions of Certification requirements as standalone requirements. As we stated in the Proposed Rule, this approach would establish clear baseline technical and behavior Conditions of Certification requirements with evidence that the Conditions of Certification requirements are continually being met through the Maintenance of Certification requirements. Comments. We received comments expressing general support for the concept of requiring Conditions and Maintenance of Certification requirements. Commenters stated that these requirements are a step forward toward promoting transparency, improving usability, and achieving interoperability of health IT. We also received comments asserting that the Conditions and Maintenance of Certification requirements should only apply to developers of certified health IT. Response. We thank commenters for their support. We provide further details on each of the Conditions and Maintenance of Certification requirements within their respective subsections in this section of the final rule. However, to clarify our approach to the Conditions and Maintenance of Certification requirements in response to comments, the Conditions and Maintenance of Certification requirements, except for the ‘‘information blocking’’ and ‘‘assurances’’ Conditions and Maintenance of Certification requirements, apply only to actions and behaviors of health IT developers related to their certified health IT as well as to the certified health IT itself. For the ‘‘information blocking’’ and ‘‘assurances’’ Conditions and Maintenance of Certification requirements, consistent with the Cures Act provisions and our implementation of section 3022(a) (information blocking) of the PHSA, a health IT developer is also responsible to ensure that all of its health IT and related actions and behaviors do not constitute information blocking or inhibit the appropriate access, exchange, and use of electronic health information (EHI). We refer readers to section VIII of this preamble for further discussion of the information blocking regulations. B. Provisions 1. Information Blocking The Cures Act requires that a health IT developer, as a Condition and Maintenance of Certification VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 requirement under the Program, not take any action that constitutes ‘‘information blocking’’ as defined in section 3022(a) of the PHSA (see 3001(c)(5)(D)(i) of the PHSA). We proposed to establish this Information Blocking Condition of Certification in § 170.401. We proposed that the Condition of Certification would prohibit any health IT developer who has at least one health IT product certified under the Program from taking any action that constitutes information blocking as defined by section 3022(a) of the PHSA and proposed in § 171.103. We clarified in the Proposed Rule that this proposed ‘‘information blocking’’ Condition of Certification and its requirements would be substantive requirements of the Program and would rely on the definition of ‘‘information blocking’’ established by section 3022(a) of the PHSA and proposed in § 171.103 (84 FR 7465). We received no comments specifically about the Information Blocking Condition of Certification and have adopted the Condition of Certification as proposed. We received many comments regarding the information blocking provision, and have responded to those comments in the information blocking discussion in section VIII of this preamble. We also refer readers to section VII.D of this final rule for additional discussion of ONC’s enforcement of this and other Conditions and Maintenance of Certification requirements. 2. Assurances The Cures Act requires that a health IT developer, as a Condition and Maintenance of Certification requirement under the Program, provide assurances to the Secretary, unless for legitimate purposes specified by the Secretary, that it will not take any action that constitutes information blocking as defined in section 3022(a) of the PHSA, or any other action that may inhibit the appropriate exchange, access, and use of electronic health information (EHI). We proposed to implement this Condition of Certification and accompanying Maintenance of Certification requirements in § 170.402. As a Condition of Certification requirement, a health IT developer must comply with the Condition of Certification as recited here and in the Cures Act. We discussed in section VIII of the Proposed Rule the proposed reasonable and necessary activities specified by the Secretary, which constitute the exceptions to the information blocking definition. We also proposed to establish more specific Conditions and Maintenance of Certification requirements for a health IT developer to provide assurances that PO 00000 Frm 00078 Fmt 4701 Sfmt 4700 it does not take any action that may inhibit the appropriate exchange, access, and use of EHI. These proposed requirements serve to provide further clarity under the Program as to how health IT developers can provide such broad assurances with more specific actions. Comments. Most commenters agreed with the central premise of our proposal to adopt the ‘‘assurances’’ Condition and Maintenance of Certification requirement, requiring that a health IT developer provide certain assurances to the Secretary, including that, unless done for one of the ‘‘legitimate purposes’’ specified by the Secretary, it will not take any actions that constitutes information blocking as defined in section 3022(a) of the PHSA, or any other action that may inhibit the appropriate exchange, access, and use of electronic health information (EHI). Commenters stated that they support ONC’s efforts to eliminate barriers that result in information blocking. One commenter stated that it is not clear what constitutes ‘‘satisfactory to the Secretary’’ as interpretations may change from Secretary to Secretary, and suggested removing the term ‘‘Secretary.’’ Response. We thank commenters for their support. We have finalized our proposal to adopt the ‘‘assurances’’ Condition and Maintenance of Certification requirement subject to the clarifications and revisions discussed below. In response to the comment recommending we remove the term ‘‘Secretary’’ as Secretaries may change over time, it will not be removed as it is in the authorizing Cures Act statutory language. For clarification, future Secretaries may establish changes to the implementation of the Cures Act ‘‘assurances’’ Condition and Maintenance of Certification requirements through notice and comment rulemaking, as has been done with this rulemaking. a. Full Compliance and Unrestricted Implementation of Certification Criteria Capabilities We proposed, as a Condition of Certification requirement, that a health IT developer must ensure that its health IT certified under the Program conforms to the full scope of the certification criteria to which its health IT is certified. This has always been an expectation of ONC and users of certified health IT and, importantly, a requirement of the Program. As stated in the Proposed Rule, we believe that by incorporating this expectation as an explicit Condition of Certification requirement under the Program, there E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations would be assurances, and documentation via the ‘‘Attestations’’ Condition and Maintenance of Certification requirements proposed in § 170.406, that all health IT developers fully understand their responsibilities under the Program, including not to take any action with their certified health IT that may inhibit the appropriate exchange, access, and use of EHI. To this point, certification criteria are designed and issued so that certified health IT can support interoperability and the appropriate exchange, access, and use of EHI. We also proposed that, as a complementary Condition of Certification requirement, health IT developers of certified health IT must provide an assurance that they have made certified capabilities available in ways that enable them to be implemented and used in production environments for their intended purposes. More specifically, developers would be prohibited from taking any action that could interfere with a user’s ability to access or use certified capabilities for any purpose within the scope of the technology’s certification. Such actions may inhibit the appropriate access, exchange, or use of EHI and are therefore contrary to this proposed Condition of Certification requirement. While such actions are already prohibited under the Program (80 FR 62711), making these existing requirements that prohibit developers from taking any action that could interfere with a user’s ability to access or use certified capabilities for any purpose within the scope of the technology’s certification explicit in this Condition of Certification requirement will ensure that health IT developers are required to attest to them pursuant to the Attestations Condition of Certification requirement in § 170.406, which will in turn provide additional assurances to the Secretary that developers of certified health IT support and do not inhibit appropriate access, exchange, or use of EHI. As discussed at 84 FR 7466 in our Proposed Rule, actions that would violate this Condition of Certification requirement include failing to fully deploy or enable certified capabilities; imposing limitations (including restrictions) on the use of certified capabilities once deployed; or requiring subsequent developer assistance to enable the use of certified capabilities, contrary to the intended uses and outcomes of those capabilities). The Condition of Certification requirement would also be violated were a developer to refuse to provide documentation, support, or other assistance reasonably VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 necessary to enable the use of certified capabilities for their intended purposes. More generally, any action that would be likely to substantially impair the ability of one or more users (or prospective users) to implement or use certified capabilities for any purpose within the scope of applicable certification criteria would be prohibited by this Condition of Certification requirement. Such actions may include imposing limitations or additional types of costs, especially if these were not disclosed when a customer purchased or licensed the certified health IT. Comments. We received a comment recommending additional language to allow health IT developers to be able to provide an explanation of how their software conforms to the certification criteria requirements and how they enable the appropriate exchange, access, and use of EHI. Response. We thank the commenter for their input, but do not accept the recommendation. Health IT must comply with certification criteria as specified in regulation. We also refer readers to the ‘‘Attestations’’ Condition of Certification requirement in this section of the preamble for more information regarding how we proposed to provide flexibilities, including a method for health IT developers to indicate their compliance, noncompliance, or the inapplicability of each Condition and Maintenance of Certification requirement as it applies to all of their health IT certified under the Program, as well as the flexibility to specify noncompliance per certified Health IT Module, if necessary. As such, we have finalized the Full Compliance and Unrestricted Implementation of Certification Criteria Capabilities Condition of Certification requirement as proposed that a health IT developer must ensure that its health IT certified under the Program conforms to the full scope of the certification criteria to which its health IT is certified, and that health IT developers would be prohibited from taking any action that could interfere with a user’s ability to access or use certified capabilities for any purpose within the scope of the technology’s certification. We note that because compliance with the information blocking section of this final rule (Part 171) is not required until six months after the publication date of the final rule, § 170.402(a)(1) also has a six-month delayed compliance date. Comments. A couple of commenters requested clarification on whether requiring subsequent developer assistance to enable the use of certain certified capabilities would be PO 00000 Frm 00079 Fmt 4701 Sfmt 4700 25719 considered noncompliance with the Condition of Certification requirement, such as managed services, hosting, connecting with exchange networks, or outsourced arrangements under agreement. Response. We clarify that the purpose of this Condition of Certification requirement is to make certified capabilities available in ways that enable them to be implemented and used in production environments for their intended purposes. As stated above, the Condition of Certification requirement would be violated were a developer to refuse to provide documentation, support, or other assistance reasonably necessary to enable the use of certified capabilities for their intended purposes (see 84 FR 7466). We do not believe that actions by health IT developers to provide their customers with education, implementation, and connection assistance to integrate certified capabilities for their customers would typically constitute actions that interfere with a customer’s ability to use certified capabilities for their intended purposes, but in the absence of specific facts, we cannot say that whether there are scenarios that would result in the assistance interfering with a user’s ability to access or use certified capabilities for any purpose within the scope of the health IT’s certification. As such, education and other assistance may be offered, but care should be taken to do so in a manner that minds the Condition of Certification requirement standards. Comments. We received a comment asking that health IT developers be required to provide honest communication and expert advice as required by a user. Response. We appreciate the commenter’s suggestion regarding honest communication and expert advice. However, such a requirement would not be consistent with this Condition of Certification requirement, which focuses on assurances that Health IT developers did not take actions that may inhibit the appropriate exchange, access, and use of electronic health information (EHI). We also believe it would be difficult to enforce such a requirement in terms of determining what constitutes an ‘‘honest’’ communication and ‘‘expert advice.’’ b. Certification to the ‘‘Electronic Health Information Export’’ Criterion We proposed that a health IT developer that produces and electronically manages EHI must certify their health IT to the 2015 Edition ‘‘EHI export’’ criterion in § 170.315(b)(10). As E:\FR\FM\01MYR3.SGM 01MYR3 25720 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations a Maintenance of Certification requirement, we proposed that a health IT developer that produces and electronically manages EHI must provide all of its customers of certified health IT Modules with health IT certified to the functionality included in § 170.315(b)(10) within 24 months of a subsequent final rule’s effective date or within 12 months of certification for a health IT developer that never previously certified health IT to the 2015 Edition, whichever is longer. Consistent with these proposals, we also proposed to amend § 170.550 to require that ONC–ACBs certify health IT to the proposed 2015 Edition ‘‘EHI export’’ certification criterion when the health IT developer of the health IT Module presented for certification produces and electronically manages EHI. As discussed in section IV.C.1 of the Proposed Rule, the availability of the capabilities in the ‘‘EHI export’’ certification criterion promote access, exchange, and use of health information to facilitate electronic access to single patient and patient population health information in cases such as a patient requesting their information, or a health care provider switching health IT systems. As such, health IT developers with health IT products that have health IT Modules certified to the finalized ‘‘EHI export’’ certification requirement must make this functionality available to customers and provide assurances that the developer is not taking actions that constitute information blocking or any other action that may inhibit the appropriate exchange, access, and use of health information. We discussed the EHI export functionality in section IV.B.4 of the Proposed Rule. Comments. A couple of commenters expressed their support for the Condition of Certification requirement, noting that certifying health IT to § 170.315(b)(10) would provide greater EHI access to end users. Several commenters requested extending the implementation timeframe to 36 months stating that more time is needed for analysis, product development, and testing, with an additional 12 months for client adoption, testing, and training. A couple of commenters supported the 24-month timeframe, but stated that they did not support ONC dictating the adoption schedule for providers, and that the proposal does not consider the efforts required from providers to plan and execute effective implementation and adoption. One commenter stated that 24 months is not aggressive enough and that the rule should prioritize certain aspects of patient-directed exchange and make these available in 12 VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 months or less. Another commenter suggested that we narrow the type of health IT developer that must certify health IT to § 170.315(b)(10), noting that some Health IT Modules may manage data produced by other Health IT Modules, or received and incorporated from other sources. We did not receive any comments specific to our proposal to amend § 170.550 to require that ONC–ACBs certify health IT to the proposed 2015 Edition ‘‘EHI export’’ criterion when the health IT developer of the health IT Module presented for certification produces and electronically manages EHI. Response. We thank the commenters for their support. In response to comments regarding scope of data export under this criterion, we have modified the proposed ‘‘EHI export’’ certification criterion and scope of data export. In doing so, we have also revised our Condition of Certification requirement, which we have finalized in § 170.402(a)(4), that 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). Additionally, we clarify that in attesting to § 170.406, a health IT developer must attest accurately in accordance with § 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 EHI. The finalized criterion focuses on the Health IT Module’s ability to export EHI for the health IT product’s single and patient population, which encompasses the EHI that can be stored at the time of certification by the product, of which the Health IT Module is a part. To note, we do not require developers to disclose proprietary information about their products. Also, as clarified above and in § 170.315(b)(10)(iii), we do not require any specific standards for the export format(s) used to support the export functionality. In regards to when health IT developers must provide all of their users of certified health IT with health IT certified to the functionality included in § 170.315(b)(10), we have removed the proposed language ‘‘within 12 months of certification for a health IT developer that never previously certified health IT to the 2015 Edition, whichever is longer.’’ Our intention was to provide equity between existing and new health IT developers. However, we have concluded that new health IT developers will not be at a disadvantage to meet the same timeline considering all health IT developers will be aware of requirements necessary for certification PO 00000 Frm 00080 Fmt 4701 Sfmt 4700 when this final rule is published. We also acknowledge the concerns expressed regarding the 24-month timeframe and have extended the compliance timeline to within 36 months of the final rule’s publication date, as finalized in § 170.402(b)(2)(i). With the narrowed scope of data export for the criterion, we believe health IT developers should be able to provide all of their customers of Health IT Modules certified to § 170.315(b)(10) with the export functionality included in § 170.315(b)(10) within 36 months. We have also finalized in § 170.402(b)(2)(ii) that on and after 36 months from the publication of this final rule, health IT developers that must comply with the requirements of § 170.402(a)(4) must provide all of their customers of certified health IT with health IT certified to § 170.315(b)(10). From this milestone forward, a health IT developer’s participation in the Certification Program obligates them to provide the technical capabilities expressed in § 170.315(b)(10) when they provide such certified health IT to their customers. We will monitor ongoing compliance with this Condition and Maintenance of Certification through a variety of means including, but not limited to, developer attestations pursuant to § 170.406, health IT developers real world testing plans, response to user complaints, and ONC– ACB surveillance activities. Consistent with the above revisions and in alignment with our proposal to amend § 170.550, we have also amended § 170.550(g)(5) regarding Health IT Module dependent criteria for consistency with the requirements of § 170.402(a)(4) and (b)(2) when a Health IT Module presented for certification is part of a health IT product which can store electronic health information. In addition, we have amended § 170.550(m)(2) to only allow ONC– ACBs to issue certifications to § 170.315(b)(6) until 36 months after the publication date of this final rule. Thus, ONC–ACBs may issue certificates for either § 170.315(b)(6) or (b)(10) up until 36 months after the publication date of this final rule, but on and after 36 months they may only issue certificates for Health IT Modules in accordance with § 170.315(b)(10). We note that ONC–ACBs are required by their ISO/ IEC 17065 accreditation to have processes in place to meet the expectations and minimum requirements of the Program. Thus, ONC–ACBs are expected to have processes in place in order to effectively monitor these timeline requirements on and after 36 months after the E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations publication of this rule, and to additionally ensure that the health IT developer attests accurately to § 170.402(a)(4) and (b)(2). Should a developer fail to comply, the ONC–ACB will follow its processes to institute corrective action and report to ONC in accordance with Program reporting requirements in 45 CFR 170.523(f)(1)(xxii). In the event the developer does not follow through with the corrective action plan established and approved with the ONC–ACB, the ONC–ACB must alert ONC of the health IT developer’s failure to comply with the Conditions and Maintenance of Certification requirements. Comments. A commenter requested ONC add functionality to the CHPL (or in another format) that provides a list of the start and end dates of each previously certified Health IT Module. Response. We appreciate this suggestion and note that the CHPL already lists certification dates for certified Health IT Modules, including the dates the Health IT Module was last modified, decertified, or made inactive. c. Records and Information Retention We proposed that, as a Maintenance of Certification requirement in § 170.402(b)(1), a health IT developer must, for a period of 10 years beginning from the date of certification, retain all records and information necessary to demonstrate initial and ongoing compliance with the requirements of the Program. In other words, records and information should be retained starting from the date a developer first certifies health IT under the Program and applies separately to each unique Health IT Module (or Complete EHR, as applicable) certified under the Program. This retention of records is necessary to verify health IT developer compliance with Program requirements, including certification criteria and Conditions and Maintenance of Certification requirements. As stated in the Proposed Rule, 10 years is an appropriate period of time given that many users of certified health IT participate in various CMS programs, as well as other programs, that require similar periods of records retention. In an effort to reduce administrative burden, we also proposed, that in situations where applicable certification criteria are removed from the Code of Federal Regulations before the 10 years have expired, records must only be kept for 3 years from the date of removal for those certification criteria and related Program provisions unless that timeframe would exceed the overall 10year retention period. This ‘‘3-year from the date of removal’’ records retention VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 period also aligns with the records retention requirements for ONC–ACBs and ONC–ATLs under the Program. We encouraged comment on these proposals and whether the proposed requirements can provide adequate assurances that certified health IT developers are demonstrating initial and ongoing compliance with the requirements of the Program; and thereby ensuring that certified health IT can support interoperability, and appropriate exchange, access, and use of EHI. Comments. Some commenters requested clarification on what records and information are expected to be maintained and how this is different from the records ONC–ACBs and ONC– ATLs retain. A couple commenters requested clarification on when the records and information retention requirement would take effect. One commenter requested clarification regarding the role of health IT developers that no longer maintain a certified Health IT Module or have their certification suspended. One commenter recommended setting a retention period for record keeping in the event that a health IT developer removes a Health IT Module from market to ensure that potentially short lived Health IT Modules would inadvertently not have their documentation maintained. Response. We have adopted our proposal in § 170.402(b)(1) without revisions. We continue to believe that 10 years is an appropriate period of time given that many users of certified health IT participate in various CMS programs, as well as other programs, that require similar periods of records retention. We also finalized that in situations where applicable certification criteria are removed from the Code of Federal Regulations, records must only be kept for 3 years from the date of removal for those certification criteria and related Program provisions unless that timeframe would exceed the overall 10year retention period. We clarify that health IT developers are best situated to determine what records and information in their possession would demonstrate their compliance with all of the relevant Program requirements. We note that it is our understanding that health IT developers are already retaining the majority of their records and information for the purposes of ONC– ACB surveillance and ONC direct review under the Program. We also refer readers to section VII.D of this final rule preamble for additional discussion of records necessary for the enforcement of the Conditions and Maintenance of Certification requirements. In regard to the requested clarification for the role of PO 00000 Frm 00081 Fmt 4701 Sfmt 4700 25721 health IT developers that no longer maintain a certified Health IT Module or have their certification suspended, a health IT developer who does not have any certified Health IT Modules within the Program would no longer have any obligation to retain records and information for the purposes of the Program. However, we note that it may be in the health IT developer’s best interest to retain their records and information. For example, records may be useful for health IT developers in any potential investigation or enforcement action taken outside of the ONC Health IT Certification Program such as by the HHS Office of the Inspector General (e.g., information blocking) or the U.S. Department of Justice (e.g., False Claims Act). d. Trusted Exchange Framework and the Common Agreement—Request for Information In the Proposed Rule, we included a Request for Information (RFI) as to whether certain health IT developers should be required to participate in the Trusted Exchange Framework and Common Agreement (TEFCA) as a means of providing assurances to their customers and ONC that they are not taking actions that constitute information blocking or any other action that may inhibit the appropriate exchange, access, and use of EHI. We received 40 comments on this RFI. We appreciate the input provided by commenters and may consider them to inform a future rulemaking. 3. Communications The Cures Act requires that a health IT developer, as a Condition and Maintenance of Certification requirement under the Program, does not prohibit or restrict communication regarding the following subjects: • The usability of the health information technology; • The interoperability of the health information technology; • The security of the health information technology; • Relevant information regarding users’ experiences when using the health information technology; • The business practices of developers of health information technology related to exchanging electronic health information; and • The manner in which a user of the health information technology has used such technology. The Cures Act established the broad communications protections delineated above (referred to hereafter as ‘‘protected communications’’) and we proposed in 84 FR 7467 to implement E:\FR\FM\01MYR3.SGM 01MYR3 25722 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations this general prohibition against developers imposing prohibitions and restrictions on protected communications in § 170.403. We also recognized that there are circumstances where it is both legitimate and reasonable for developers to limit the sharing of information about their health IT. As such, we proposed to allow developers to impose prohibitions or restrictions on protected communications in certain narrowly defined circumstances. In order for a prohibition or restriction on a protected communication to be permitted, we proposed in 84 FR 7467 that it must pass a two-part test. First, the communication that is being prohibited or restricted must not fall within a class of communications (hereafter referred to as ‘‘communications with unqualified protection’’) that is considered to always be legitimate or reasonable—such as communications required by law, made to a government agency, or made to a defined category of safety organizations. Second, to be permitted, a developer’s prohibition or restriction on communications must also fall within a category of communications (hereafter referred to as ‘‘permitted prohibitions and restrictions’’) for which it is both legitimate and reasonable for a developer to limit the sharing of information about its health IT. This would be because of the nature of the relationship between the developer and the communicator or because of the nature of the information that is, or could be, the subject of the communication. We proposed that a developer’s restriction or prohibition that does not satisfy this two-part test would contravene the Communications Condition of Certification requirement. We note that this two-part test strikes a reasonable balance between the need to promote open communication about health IT and related business practices, and the need to protect the legitimate interests of health IT developers and other entities. Comments. The majority of public comments we received supported the proposed Communications Condition of Certification requirements, with many commenters expressing strong support. Commenters stated that the proposed requirements would enable better communication that would improve health IT and patient care. Some commenters who supported the proposed requirements sought clarification or had specific concerns, including regarding the proposed deadlines for contract modification. These matters are discussed in more detail below. Additionally, a handful of public comments strongly opposed the VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 proposed requirements, primarily based on concerns regarding intellectual property (IP). Response. We appreciate the overall strong support for the Communications Condition of Certification requirements as proposed and have finalized with modifications in § 170.403. We also recognize the need to provide clarification regarding some aspects of the requirements, including regarding the protections available for IP that are included in the Communications Condition and Maintenance of Certification requirements. We emphasize that, under section 3001(c)(5) of the PHSA, participation in the ONC Health IT Certification Program (Program) is voluntary. In other words, ONC cannot compel health IT developers to participate in the Program nor can ONC impose consequences (e.g., enforcement actions or penalties) on health IT developers who choose not to participate in the Program. The requirements of the Program are much like requirements for any other voluntary contract or agreement an entity would enter into with the Federal Government. Through the Conditions and Maintenance of Certification requirements, we have essentially offered developers terms for participation in the Program that we believe are appropriate based on: Our statutory instruction and interpretation of the Cures Act; the utility and necessity of using intellectual property, including screenshots, to communicate issues with usability, user experience, interoperability, security, or the way the technology is used (and relatedly, the real and substantial threat to public health and safety resulting from prohibitions and/or restrictions on the communication of screenshots); and the measured approach we have taken throughout the Communications Condition and Maintenance of Certification requirements (which is discussed in detail in this section). Because the Program is voluntary, developers have the option to agree to the terms we have offered or to choose not to participate in the Program. As such, we believe our policies concerning intellectual property, including the use of screenshots, are consistent with other laws and regulations that govern terms for voluntary contracts and agreements with the Federal Government. Further, we believe that the final provisions of this Condition of Certification include appropriate consideration of health IT developers’ intellectual property rights. We further discuss the various aspects of the Communications Condition of Certification requirements, as well as PO 00000 Frm 00082 Fmt 4701 Sfmt 4700 the changes we have made to our proposals, in more detail below. a. Background and Purpose The Communications Condition of Certification requirements address industry practices of certified health IT developers that can severely limit the ability and willingness of health IT customers, users, researchers, and other stakeholders to openly discuss and share their experiences and other relevant information about health IT performance, including about the ability of health IT to exchange health information electronically. These practices result in a lack of transparency that can contribute to and exacerbate patient safety risks, system security vulnerabilities, and health IT performance issues. We explained in the Proposed Rule that the challenges presented by health IT developer actions that prohibit or restrict communications have been examined for some time. The problem was identified in a 2012 report by the Institute of Medicine of the National Academies (IOM) entitled ‘‘Health IT and Patient Safety: Building Safer Systems for Better Care’’ 73 (IOM Report). The IOM Report stated that health care providers, researchers, consumer groups, and other health IT users lack information regarding the functionality of health IT.74 The IOM Report observed, relatedly, that many developers restrict the information that users can communicate about developers’ health IT through nondisclosure clauses, confidentiality clauses, IP protections, hold-harmless clauses, and other boilerplate contract language.75 The report stressed the need for health IT developers to enable the free exchange of information regarding the experience of using their health IT, including the sharing of screenshots relating to patient safety.76 Concerns have also been raised by researchers studying health IT,77 who emphasize that confidentiality and IP provisions in contracts often place broad and unclear limits on authorized uses of information related to health IT, 73 IOM (Institute of Medicine), Health IT and Patient Safety: Building Safer Systems for Better Care (2012). Available at https:// www.nationalacademies.org/hmd/Reports/2011/ Health-IT-and-Patient-Safety-Building-SaferSystems-for-Better-Care.aspx. 74 Id. at 37. 75 Id. at 36, 128. 76 Id. 77 See Hardeep Singh, David C. Classen, and Dean F. Sittig, Creating an Oversight Infrastructure for Electronic Health Record-Related Patient Safety Hazards, 7(4) Journal of Patient Safety 169 (2011). Available at https://www.ncbi.nlm.nih.gov/pmc/ articles/PMC3677059/. E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations which in turn seriously impact the ability of researchers to conduct and publish their research.78 The issue of health IT developers prohibiting or restricting communications about health IT has been the subject of a series of hearings by the Senate Committee on Health, Education, Labor and Pensions (HELP Committee), starting in the spring of 2015. Senators on the HELP Committee expressed serious concern regarding the reported efforts of health IT developers to restrict, by contract and other means, communications regarding user experience, including information relevant to safety and interoperability.79 Developer actions that prohibit or restrict communications about health IT have also been the subject of investigative reporting.80 A September 2015 report examined eleven contracts between health systems and major health IT developers and found that, with one exception, all of the contracts protected large amounts of information from being disclosed, including information related to safety and performance issues.81 b. Condition of Certification Requirements i. Protected Communications and Communicators We proposed in 84 FR 7468 that the protection afforded to communicators under the requirements of the Communications Condition of Certification in § 170.403(a) would apply irrespective of the form or medium in which the communication is made. We proposed in 84 FR 7468 that developers must not prohibit or restrict communications whether written, oral, electronic, or by any other method if they are protected, unless such prohibition or restriction is otherwise permitted by the requirements of this Condition of Certification. Similarly, we proposed that these Condition of Certification requirements do not impose any limit on the identity of the communicators that are able to benefit from the protection afforded, except that employees and contractors of a health IT developer may be treated differently 78 Kathy Kenyon, Overcoming Contractual Barriers to EHR Research, Health Affairs Blog (October 14, 2015). Available at https://healthaffairs. org/blog/2015/10/14/overcoming-contractualbarriers-to-ehr-research/. 79 Senate HELP Committee Hearing at 13 and 27 (July 23, 2015), available at https:// www.help.senate.gov/hearings/achieving-thepromise-of-health-information-technologyinformation-blocking-and-potential-solutions. 80 D. Tahir, POLITICO Investigation: EHR gag clauses exist—and, critics say, threaten safety, Politico, August 27, 2015. 81 Id. VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 when making communications that are not afforded unqualified protection under § 170.403(a)(2)(i). For example, we proposed that this Condition of Certification’s requirements are not limited to communications by health IT customers (e.g., providers) who have contracts with health IT developers. Comments. Many commenters addressed the scope of protected communications in their comments. Several commenters suggested that the proposed scope of protected communications was too broad. Other commenters stated that the scope should be clarified. One commenter suggested that the scope of private communications that can be shared should be limited and that ONC should require mutual consent for such communications to be made public. Response. We appreciate these comments. The Cures Act identifies a list of subject areas about which health IT developers cannot prohibit or restrict communications to meet the conditions for certification. The terms we proposed for the protected subject areas are taken from the language in section 4002 of the Cures Act and include: • The usability of the health information technology; • The interoperability of the health information technology; • The security of the health information technology; • Relevant information regarding users’ experiences when using the health information technology; • The business practices of developers of health information technology related to exchanging electronic health information; and • The manner in which a user of the health information technology has used such technology. We continue to interpret the above statutory terms broadly, but within the limiting framework we proposed, which includes a distinction between communications entitled to unqualified protections and those communications not entitled to such protection. We have, however, finalized some provisions with further limiting and clarifying language as well as provided examples to improve understanding of the provisions. We decline to create a consent requirement as part of the requirements of this Condition of Certification because such a requirement could unnecessarily encumber vital communications protected by the Cures Act. As highlighted above, the Communications Condition of Certification requirements are intended to enable unencumbered communication about usability, PO 00000 Frm 00083 Fmt 4701 Sfmt 4700 25723 interoperability, and other critical issues with health IT, and a consent requirement would chill the ability of users of health IT to engage in that communication as well as be contrary to section 4002 of the Cures Act. Comments. One commenter stated that the Communications Condition of Certification requirements should apply only to certified health IT, recommending that ONC clarify that the use of ‘‘the health IT’’ refers only to the developer’s health IT that is certified under the ONC Health IT Certification Program. The commenter stated that the use of ‘‘the health IT’’ in the Cures Act can only be reasonably interpreted as referring to the health IT for which a developer is seeking certification, not all of the developer’s health IT. Another commenter stated that other health IT, such as billing systems, should be out of scope of this requirement and noted that to do otherwise would create a regulatory imbalance between developers of such health IT who also offer certified health IT and those who do not. Response. We appreciate these comments regarding restricting the applicability of the Communications Condition of Certification requirements to certified health IT. We clarify that, as with all of the Conditions of Certification requirements, the Communications Condition of Certification requirements apply to developers of health IT certified under the Program and to the conduct of such developers with respect to health IT certified under the Program. By way of example, if a developer had health IT certified under the Program and also had health IT that was not certified under the Program, then only those communications about the certified health IT would be covered by the Communications Condition of Certification requirements. Comments. We received one comment requesting more specificity on the definition of communicators covered by the Communications Condition of Certification requirements. The commenter expressed concern that the broad scope could impact the ability to maintain confidentiality in traditional business-to-business relationships. Response. We appreciate this comment and understand the concern noted by the commenter. As stated in the Proposed Rule and finalized in § 170.403, the Communications Condition and Maintenance of Certification requirements generally do not impose any limit on the identity of communicators that are able to benefit from the protection afforded. We also note that there are limited exceptions E:\FR\FM\01MYR3.SGM 01MYR3 25724 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations where communications by certain communicators can be restricted. Specifically, as finalized in § 170.403(a)(2)(ii)(A), health IT developers can place limited restrictions on communications by employees and contractors. We believe this will enable traditional business-to-business relationships to continue without undue disruption, including allowing implementation of non-disclosure agreements or other contracts as necessary to maintain confidentiality. ii. Protected Subject Areas Comments. We received several comments requesting that we clarify how the Communications Condition of Certification requirements would apply to communications regarding public health reporting, including communications made by public health authorities. Response. We emphasize that the Cures Act identified a list of subject areas about which we were required to forbid developers from prohibiting or restricting communications. Though public health reporting was not specifically covered by the Cures Act or our proposed regulations, it may be that certain public health communications will fall within the categories established by the statute. We also note that one of the ‘‘communications with unqualified protection’’ discussed later in this section is for communicating information about adverse events, hazards, and other unsafe conditions to government agencies, health care accreditation organizations, and patient safety organizations. Depending on the specific communication in question, a communication about public health reporting or a communication made to public health authorities could be a communication that could not be restricted in any way. We also emphasize that, subject to limited circumstances already discussed above, we do not impose any limit on the identity of the communicators that are able to benefit from protections afforded under the Communications Condition of Certification requirements. Communicators are broadly defined and could include public health agencies and authorities. Comments. Several commenters had concerns regarding how a developer may address communications that contain false claims or libelous statements. Commenters discussed the need to enable health IT developers to— for example—refute false claims, deal with anonymous claims, and restrict certain communications (such as false statements or communications protected by attorney-client privilege). Some of VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 these comments emphasized that false communications such as libel should not be protected, nor should communications sent by someone who obtained them illegally, such as a hacker. Some of the commenters recommended adding a category of communications that would never be protected under the proposed framework, and such communications would not receive unqualified protection or necessitate permitted restrictions. This would allow a developer to—for example—prohibit or restrict communications that are false or deceptive, would violate a law or court order, or would result in a breach of contract. Response. We appreciate the concerns expressed by commenters regarding statements that may be false or misleading. However, developers already have legal means and remedies available to them to address such statements, and this rule does not change that. For example, each State has libel laws that address libelous or defamatory statements and provide remedies in situations where the specific facts in a damaging statement can be proven to be untrue. We believe that such statements are best addressed through those laws and that it is neither prudent nor practical for ONC to use the Program and the Communications Condition of Certification requirements to attempt to assess such statements and make determinations as to their veracity. Further, we note that the Communications Condition of Certification requirements only provide that such protected communications cannot be restricted or prohibited. It is up to the health IT developer whether and how they choose to respond to the protected communication once made. Therefore, we clarify that it is not a violation of the Communications Condition of Certification requirements for developers to respond to false or unlawful comments under applicable law, as they do now, and to pursue litigation or any other available legal remedy in response to any protected communications that are covered by the Communications Condition of Certification. For example, it would not be a violation of the Communications Condition of Certification for a health IT developer who restricts the communication of screenshots as permitted under § 170.403(a)(2)(ii)(D) to pursue litigation for Copyright infringement or violation of contract if a ‘‘protected communication’’ disclosed more screenshots than the developer’s restriction allowed. PO 00000 Frm 00084 Fmt 4701 Sfmt 4700 Comments. Several commenters requested that ‘‘safety’’ be added as a protected category or that ONC should include in the final rule a specific ban that prohibits any restrictions on communications about health IT-related patient safety. Additionally, several commenters noted that ONC should include specific reporting methods or standards in the final rule to improve safety reporting or add examples to help encourage reporting of safety and security issues. Several commenters also requested that ONC develop protocols for reporting safety issues, and one commenter recommended ONC develop a patient safety reporting system. Response. In implementing the Cures Act requirement that a health IT developer, as a Condition of Certification requirement under the Program, not restrict communications about health IT, we adhered to the list of protected subject areas identified by Congress in the Cures Act. Those subject areas include communications about ‘‘usability,’’ ‘‘relevant information regarding users’ experiences when using the health information technology,’’ and the ‘‘manner in which a user of the health information technology has used such technology.’’ We clarify that patient safety issues related to an interaction with the health IT could be covered in one or more of those categories. Additionally, we agree with commenters that safety-related communications should receive specific protections, and we emphasize that the communication of safety concerns is also addressed as a protected communication receiving ‘‘unqualified protection.’’ In the section of this final rule on ‘‘Communications with Unqualified Protection,’’ and in § 170.403(a)(2)(i)(B), we state that communicating information about adverse events, hazards, and other unsafe conditions to government agencies, health care accreditation organizations, and patient safety organizations is a communication about which a developer would be prohibited from imposing any prohibition or restriction. (A) Usability of Health Information Technology The term ‘‘usability’’ is not defined in the Cures Act, nor in any other relevant statutory provisions. We proposed in 84 FR 7469 that the ‘‘usability’’ of health IT be construed broadly to include both an overall judgment on the ‘‘usability’’ of a particular certified health IT product by the user, as well as any factor that contributes or may contribute to usability. We proposed that the factors of usability that could be the subject of E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations protected communications include, but are not limited to, the following: The user interface (e.g., what a user sees on the screen, such as layout, controls, graphics and navigational elements); ease of use (e.g., how many clicks); how the technology supports users’ workflows; the organization of information; cognitive burden; cognitive support; error tolerance; clinical decision support; alerts; error handling; customizability; use of templates; mandatory data elements; the use of text fields; and customer support. Comments. One commenter stated that ‘‘usability’’ is too broadly defined and should relate more specifically to judgments on the ease of use of the health IT, rather than factors related to usability. Response. We do not believe that ‘‘usability’’ is inaccurately defined nor too broadly defined. To define usability in the Proposed Rule, we referenced the NIST standard 82 as well as principles recognized by the Healthcare Information and Management Systems Society (HIMSS). We also emphasized that there are a multitude of factors that contribute to any judgment about ‘‘usability,’’ including factors contributing to the effectiveness, efficiency, and performance of the health IT. We have finalized the scope of the protected subject area ‘‘usability of its health IT’’ in § 170.403(a)(1)(i) as proposed, providing that the ‘‘usability’’ of health IT be construed broadly to include both an overall judgment on the ‘‘usability’’ of a particular certified health IT product, as well as any of the many factors that could contribute to usability as described in the Proposed Rule. We also note that communications about the usability of health IT may include communications about features that are part of the certified health IT as well as communications about what is not in the certified health IT (e.g., the absence of alerts or features that a user believes would aid in usability or are related to the other subject areas identified by the Cures Act). (B) Interoperability of Health Information Technology The Cures Act, as codified in section 3000(9) of the PHSA, provides a definition of ‘‘interoperability’’ that describes a type of health IT that demonstrates the necessary capabilities to be interoperable. For the purposes of the Communications Condition of Certification requirements, we proposed that protected communications regarding the ‘‘interoperability of health IT’’ would include communications about whether certified health IT and associated developer business practices meet the interoperability definition described in section 3000(9) of the PHSA, including communications about aspects of the technology or developer that fall short of the expectations found in that definition. We stated that this would include communications about the interoperability capabilities of health IT and the practices of a health IT developer that may inhibit the access, exchange, or use of EHI, including information blocking. As previously noted, Congress did not define the terms used in the Communications Conditions of Certification requirements in section 4002(a) of the Cures Act and codified in section 3001(c)(5)(D)(iii) of the PHSA. We believe that ‘‘interoperability’’ was appropriately defined in the Proposed Rule by using the interoperability definition that is located elsewhere in section 4003(a)(2) of the Cures Act and codified in section 3000(9) of the PHSA. We did not receive comments about this aspect of the Proposed Rule, and we have finalized the scope of the protected subject area ‘‘interoperability of its health IT’’ in § 170.403(a)(1)(ii) as proposed above. (C) Security of Health IT The security of health IT is addressed by the HIPAA Security Rule,83 which establishes national standards to protect individuals’ electronic protected health information (ePHI) that is created, received, maintained, or transmitted by a covered entity or business associate (as defined at 45 CFR 160.103). Covered entities and business associates must ensure the confidentiality, integrity, and availability of all ePHI; protect against any reasonably anticipated threats or hazards to the security or integrity of such information; and protect against any reasonably anticipated uses or disclosures of such information that are not permitted or required under the HIPAA Privacy Rule.84 The HIPAA Security Rule requires health IT developers, to the extent that they are business associates of covered entities, to implement appropriate administrative, physical, and technical safeguards to ensure the confidentiality, integrity, and availability of ePHI.85 We proposed in 84 FR 7469 that the matters that fall within the topic of health IT security should be broadly construed to include any safeguards, whether or not 83 45 84 45 82 See https://www.nist.gov/programs-projects/ health-it-usability. VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 CFR part 160 and subparts A and C of part 164. CFR part 160 and subparts A and C of part 164. 85 Id. PO 00000 Frm 00085 Fmt 4701 Sfmt 4700 25725 required by the HIPAA Security Rule, that may be implemented (or not implemented) by a developer to ensure the confidentiality, integrity, and availability of EHI (information that includes ePHI), together with the certified health IT’s performance regarding security. Comments. One commenter noted that it is important that developers are able to remove posts on a website or forum that could compromise the security of health IT and recommended that ONC explicitly allow developers to do so in the final rule. Response. We recognize the importance of protecting the security of EHI and health IT. We also recognize that our engagement with stakeholders, as well as the language in section 4002 of the Cures Act, emphasize the strong public interest in allowing unencumbered communications regarding the protected subject areas and communications with unqualified protection, which are discussed in more detail below and in § 170.403(a)(2)(i). We emphasize that developers may respond to communications as allowed under applicable law and may pursue any appropriate legal remedy. Taking these factors into consideration, we decline at this time to explicitly allow developers to restrict communications regarding security as suggested by the commenter. Comments. One commenter requested that ONC consider narrowing the permitted communication of security elements in § 170.403(a)(1)(iii) that might be used to compromise a particular certified health IT’s security, for example restricting the sharing of authentication credentials issued to a customer or user to access a system containing sensitive information such as PHI. Response. We do not believe it is necessary in this final rule to narrow or restrict the information that can be communicated where security elements are included in the communication. As stated above, we believe there is a strong public interest in allowing unencumbered communications regarding the protected subject areas and communications with unqualified protection. Further, assurances that access credentials and PHI communicated under these circumstances will not be shared inappropriately are addressed in the HIPAA Security Rule and relevant State laws, and this rule does not change those protections. Comments. One comment recommended that the Communications Condition of Certification requirements should protect communication E:\FR\FM\01MYR3.SGM 01MYR3 25726 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations regarding the overall security posture that the health IT developer takes or makes the user take, including communications regarding a system with known and longstanding issues or bugs. Response. We appreciate this comment and clarify that communications related to the overall security posture taken by a health IT developer would be within the subject area of ‘‘security of its health IT,’’ and thus would be protected communications covered by the Communications Condition of Certification requirements. We have finalized the scope of the protected subject area ‘‘security of its health IT’’ in § 170.403(a)(1)(iii) as proposed. (D) User Experiences The phrases ‘‘relevant information regarding users’ experiences when using the health IT’’ and ‘‘user experience’’ are not defined in the Cures Act nor any other relevant statutory provisions. We proposed in 84 FR 7470 to afford the term ‘‘user experience’’ its ordinary meaning. To qualify as a ‘‘user experience,’’ we proposed that the experience would have to have been one that is had by a user of health IT. However, beyond this, we did not propose to qualify the types of experiences that would receive protection under the Communications Condition of Certification requirements based on the ‘‘user experience’’ subject area. To illustrate the breadth of potential user experiences that would be protected by the proposed Communications Condition of Certification requirements, we proposed that communications about ‘‘relevant information regarding users’ experiences when using the health IT’’ would encompass, for example, communications and information about a person or organization’s experience acquiring, implementing, using, or otherwise interacting with the health IT. We also proposed that this would include experiences associated with the use of the health IT in the delivery of health care, together with administrative functions performed using the health IT. We proposed that user experiences would also include the experiences associated with configuring and using the technology throughout implementation, training, and in practice. Further, we proposed that user experiences would include patients’ and consumers’ user experiences with consumer apps, patient portals, and other consumer-facing technologies of the health IT developer. We clarified that a ‘‘relevant user experience’’ would include any aspect of the health IT user VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 experience that could positively or negatively impact the effectiveness or performance of the health IT. Comments. One commenter stated that the most relevant aspect of a user’s experience of a health IT system is whether that experience resulted in patient safety events and requested that ONC specify patient safety events that arise from the use, misuse, or failure of health IT systems as ‘‘user experiences’’ that cannot be covered by gag orders. Response. As previously noted in our response to patient safety comments above, we reiterate that a user experience resulting in a patient safety event would be covered under the Communications Condition of Certification requirements and that a communication about such an experience would be protected, subject to other applicable laws. Further, communications about ‘‘adverse events, hazards, and other unsafe conditions to government agencies, health care accreditation organizations, and patient safety organizations’’ receive unqualified protection as described in § 170.403(a)(2)(i). We noted in the Proposed Rule that the Patient Safety and Quality Improvement Act of 2005 (PSQIA) provides for privilege and confidentiality protections for information that meets the definition of patient safety work product (PSWP). This means that PSWP may only be disclosed as permitted by the PSQIA and its implementing regulations. We clarified that to the extent activities are conducted in accordance with the PSQIA, its implementing regulation, and section 4005(c) of the Cures Act, no such activities shall be construed as constituting restrictions or prohibitions that contravene this Condition of Certification. We believe that ‘‘user experience’’ was appropriately defined in the Proposed Rule and have finalized the scope of the protected subject area ‘‘relevant information regarding users’ experiences when using its health IT’’ in § 170.403(a)(1)(iv) as proposed, with the clarification provided above regarding patient safety events and to clarify that any communications regarding consumer-facing technologies would need to be about certified consumerfacing technologies per our earlier clarification about the scope of this Condition of Certification being limited to certified health IT. (E) Manner in Which a User Has Used Health IT We proposed in 84 FR 7470 that protected communications regarding the ‘‘manner in which a user has used health IT’’ would encompass any PO 00000 Frm 00086 Fmt 4701 Sfmt 4700 information related to how the health IT has been used. We also proposed that the terms used to describe the protected subject areas should be construed broadly. We noted in the Proposed Rule that this subject area largely overlaps with the matters covered under the ‘‘user experience’’ subject area but may include additional perspectives or details beyond those experienced by a user of health IT. We proposed that the types of information that would fall within this subject area include but are not limited to: • Information about a work-around implemented to overcome an issue in the health IT; • customizations built on top of core health IT functionality; • the specific conditions under which a user used the health IT, such as information about constraints imposed on health IT functionality due to implementation decisions; and • information about the ways in which health IT could not be used or did not function as was represented by the developer. We did not receive comments on this specific aspect of the Proposed Rule, and we believe the Proposed Rule appropriately outlined what would fall within the subject matter of the manner in which a user has used health IT. We have finalized the scope of the protected subject area ‘‘manner in which a user of the health IT has used such technology’’ in § 170.403(a)(1)(vi) as proposed, with the clarification that ‘‘used’’ refers to any uses of the certified health IT by the user and is not limited to uses that involve direct patient care. (F) Business Practices Related to Exchange We proposed in 84 FR 7470 that the subject matter of ‘‘business practices of developers of health IT related to exchanging electronic health information’’ should be broadly construed to include developer policies and practices that facilitate the exchange of EHI and developer policies and practices that impact the ability of health IT to exchange health information. We further proposed that the exchange of EHI would encompass the appropriate and timely sharing of EHI. We proposed that protected communications would include, but would not be limited to: • The costs charged by a developer for products or services that support the exchange of EHI (e.g., interface costs, API licensing fees and royalties, maintenance and subscription fees, transaction or usage-based costs for exchanging information); E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations • the timeframes and terms on which developers would or would not enable connections and facilitate exchange with other technologies, individuals, or entities, including other health IT developers, exchanges, and networks; • the developer’s approach to participation in health information exchanges and/or networks; • the developer’s licensing practices and terms as it relates to making available APIs and other aspects of its technology that enable the development and deployment of interoperable products and services; and • the developer’s approach to creating interfaces with third-party products or services, including whether connections are treated as ‘‘one off’’ customizations, or whether similar types of connections can be implemented at a reduced cost. Importantly, we further proposed in 84 FR 7470 that information regarding ‘‘business practices of developers of health IT related to exchanging electronic health information’’ would include information about switching costs imposed by a developer, as we are aware that the cost of switching health IT is a significant factor impacting health care providers adopting the most exchange-friendly health IT available. Comments. One commenter stated that our proposed ‘‘business practices’’ is too broadly defined and should relate exclusively to interoperability elements of certified health IT, rather than to products and services that support exchange. Response. As discussed in the Proposed Rule, we believe the term ‘‘business practices of developers of health IT related to exchanging electronic health information’’ should be broadly construed consistent with our interpretation of the Cures Act language regarding the Communications Condition of Certification requirements, but limited to those business practices that relate to the certified health IT as clarified previously in this Condition and Maintenance of Certification section. A wide variety of business practices could impact the exchange of EHI, including developer business strategies, pricing, and even fraudulent behavior. As such, we have finalized in § 170.403(a)(1)(v) our proposal that such business practices include developer policies and practices that impact or facilitate the exchange of EHI. They could also include costs charged by a developer not only specifically for interoperability elements of the certified health IT, but also for any products or services that support the exchange of EHI through the certified health IT. We reiterate that business practices related to exchange could include timeframes VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 and terms on which developers facilitate exchange; the developer’s approach to participating in health information exchanges and/or networks; the developer’s licensing practices and terms as related to APIs and other interoperable services; and the developer’s approach to creating interfaces with third-party services. As proposed in 84 FR 7473, this Communications Condition of Certification requirement will also apply to any communication concerning a Program requirement (e.g., a Condition or Maintenance of Certification requirement) related to the exchange of EHI or the information blocking provision. Comments. Several commenters had concerns regarding communications about prices and costs, with some commenters asserting that such communications should be protected and some others asserting that developers should be able to restrict communications about prices and costs, including switching costs. Additionally, one commenter had concerns about protecting communications regarding timeframes and terms as well as workarounds and customizations. One commenter also recommended that ONC seek guidance from the Antitrust Division of the FTC regarding economic impacts of regulating health IT developer terms, prices, and timeframes. Response. We continue to interpret costs, information regarding timeframes and terms, and information about health IT workarounds and customizations as protected communications under the ‘‘Business Practices Related to Exchange’’ provision of this condition. We believe that this type of information is frequently relied upon and necessary in order to optimize health IT for the exchange of EHI. We emphasize that the costs charged by a developer for certified health IT or related services that support the exchange of EHI are significant factors that can impact the adoption of interoperable certified health IT and should be protected communications. For example, pricing could include prohibitive costs that prevent or discourage customers from using certified health IT to interact with competing technologies. Likewise, information regarding timeframes and terms is the type of information considered and relied upon in the adoption of interoperable certified health IT and is a protected communication. We have also finalized in § 170.403(a)(1)(vi) that information about certified health IT workarounds and customizations relates to important aspects of how a user has used certified health IT, including how the certified PO 00000 Frm 00087 Fmt 4701 Sfmt 4700 25727 health IT can be used to achieve greater interoperability, and is a protected communication. In response to the comments recommending that we seek guidance from the FTC, we note that we are not regulating health IT developer terms, prices, and timeframes under this Communications Condition of Certification requirements, and therefore do not need to seek further guidance. Rather, the Communications Condition of Certification requirements would protect communications about health IT developer costs, terms, and timeframes as described above and ensure that such information could be shared. We have finalized the scope of the protected subject area ‘‘business practices of developers of health IT related to exchanging electronic health information’’ in § 170.403(a)(1)(v) as proposed. iii. Meaning of ‘‘Prohibit or Restrict’’ The terms ‘‘prohibit’’ and ‘‘restrict’’ are not defined in the Cures Act, nor in any other relevant statutory provisions. We discussed in the Proposed Rule that communications can be prohibited or restricted through contractual terms or agreements (e.g., non-disclosure agreements or non-disparagement clauses) as well as through conduct, including punitive or retaliatory business practices that are designed to create powerful disincentives to engaging in communications about developers or their health IT. Therefore, we proposed in 84 FR 7470 that the Communications Condition of Certification requirements would not be limited to only formal prohibitions or restrictions (such as by means of contracts or agreements) and would encompass any conduct by a developer that would be likely to restrict a communication or class of communications protected by the Communications Condition of Certification requirements. We explained that the conduct in question must have some nexus to the making of a protected communication or an attempted or contemplated protected communication. (A) Prohibitions or Restrictions Arising by Way of Contract We explained in the Proposed Rule that the principal way that health IT developers can control the disclosure of information about their health IT is through contractual prohibitions or restrictions. We noted that there are different ways that contractual prohibitions or restrictions arise. In some instances, a contractual prohibition or restriction will be E:\FR\FM\01MYR3.SGM 01MYR3 25728 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations expressed, and the precise nature and scope of the prohibition or restriction will be explicit in the contract or agreement. However, we also noted that a contract may also impose prohibitions or restrictions in less precise terms. We stated that a contract does not need to expressly prohibit or restrict a protected communication in order to have the effect of prohibiting or restricting that protected communication. The use of broad or vague language that obfuscates the types of communications that can and cannot be made may be treated as a prohibition or restriction if it has the effect of restricting legitimate communications about health IT. We stated that restrictions and prohibitions found in contracts used by developers to sell or license their health IT can apply to customers directly and can require that the customer ‘‘flowdown’’ obligations to the customer’s employees, contractors, and other individuals or entities that use or work with the developer’s health IT. We proposed that such contract provisions would not comply with the Communications Condition of Certification requirements and would be treated as prohibiting or restricting protected communications. We noted that prohibitions or restrictions on communications can also be found in separate nondisclosure agreements (NDAs) that developers require their customers—and in some instances the users of the health IT or third-party contractors—to enter into in order to receive or access the health IT. We proposed that such agreements are covered by the Communications Condition of Certification requirements. We did not receive comments on this specific aspect of the Proposed Rule and have finalized our interpretation proposed in FR 7471 regarding prohibitions or restrictions arising by way of contract as stated above. (B) Prohibitions or Restrictions That Arise by Way of Conduct We proposed in 84 FR 7471 that conduct that has the effect of prohibiting or restricting a protected communication would be subject to the Communications Condition of Certification requirements. We emphasized that the conduct in question must have some nexus to the making of a protected communication or an attempted or contemplated protected communication. As such, developer conduct that was alleged to be intimidating, or health IT performance that was perceived to be substandard, would not, in and of itself, implicate the Communications Condition of Certification requirements unless there VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 was some nexus between the conduct or performance issue and the making of (or attempting or threatening to make) a protected communication. We did not receive comments on this specific aspect of the Proposed Rule and have finalized our interpretation proposed in 84 FR 7471 regarding prohibitions or restrictions arising by way of conduct as stated above. iv. Communications With Unqualified Protection We proposed in 84 FR 7472 a narrow class of communications—consisting of five specific types of communications— that would receive unqualified protection from developer prohibitions or restrictions. With respect to communications with unqualified protection, a developer would be prohibited from imposing any prohibition or restriction. We proposed that this narrow class of communications warrants unqualified protection because of the strength of the public policy interest being advanced by the class of the communication and/or the sensitivity with which the identified recipient treats, and implements safeguards to protect the confidentiality and security of, the information received. We stated that a developer that imposes a prohibition or restriction on a communication with unqualified protection would fail the first part of the two-part test for allowable prohibitions or restrictions, and as such would contravene the Communications Condition of Certification requirements. Comments. One commenter recommended adding language specifying the types of entities that can receive communications with unqualified protection, noting that such specificity would help ensure that these communications go to the appropriate entities so that they can be addressed quickly. The commenter recommended that provisions around reporting to government entities should be limited to United States government entities. Response. We do not believe it is necessary to further specify the types of entities that can receive communications with unqualified protection. We intend for this protection to cover a wide variety of organizations, and further specifying the types of entities that can receive such communications, such as limiting communication to only United States government entities, would unnecessarily limit the scope of this protection and could be counter to the public policy interest to advance the ability of these communications to occur unencumbered. We have finalized in § 170.403(a)(2)(i) our proposal to PO 00000 Frm 00088 Fmt 4701 Sfmt 4700 prohibit developers from imposing any prohibition or restriction on communications that fall into a narrow class of communications—consisting of the five specific types of communications described below—that would receive unqualified protection. (A) Disclosures Required by Law We proposed in 84 FR 7472 that where a communication relates to subject areas enumerated in proposed § 170.403(a)(1) and there are Federal, State, or local laws that would require the disclosure of information related to health IT, developers must not prohibit or restrict in any way protected communications made in compliance with those laws. We noted that we expect most health IT contracts would allow for, or not prohibit or restrict, any communication or disclosure that is required by law, such as responding to a court or Congressional subpoena, or a valid warrant presented by law enforcement. We further proposed that if required by law, a potential communicator should not have to delay any protected communication under the Communications Condition of Certification requirements. We did not receive comments on this aspect of the Proposed Rule and have finalized in § 170.403(a)(2)(i)(A) our approach regarding disclosures required by law as proposed. (B) Communicating Information About Adverse Events, Hazards, and Other Unsafe Conditions to Government Agencies, Health Care Accreditation Organizations, and Patient Safety Organizations We proposed in 84 FR 7472 that there is an overwhelming interest in ensuring that all communications about health IT that are necessary to identify patient safety risks, and to make health IT safer, not be encumbered by prohibitions or restrictions imposed by health IT developers that may affect the extent or timeliness of communications. In addition to the public policy interest in promoting uninhibited communications about health IT safety, we proposed that the recognized communication channels for adverse events, hazards, and unsafe conditions provide protections that help ensure that any disclosures made are appropriately handled and kept confidential and secure. We proposed that the class of recipients to which the information can be communicated under this specific category of communications given unqualified protection should provide health IT developers with comfort that there is little risk of such communications prejudicing the developer’s IP rights. E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations We sought comment on whether the unqualified protection afforded to communications made to a patient safety organization about adverse events, hazards, and other unsafe conditions should be limited. Specifically, we sought comment on whether the unqualified protection should be limited by the nature of the patient safety organization to which a communication can be made, or the nature of the communication that can made. Comments. Several commenters stated that ONC should not place any limits on the unqualified protection afforded to communications made to patient safety organizations about adverse events, hazards, and other unsafe conditions. Response. We have finalized in § 170.403(a)(2)(i)(B) as proposed regarding the unqualified protection afforded to communications about adverse events, hazards, and other unsafe conditions that are made to government agencies, health care accreditation organizations, and patient safety organizations. Additionally, we placed no limits or qualifiers on such communications, including those communications made to patient safety organizations. (C) Communicating Information About Cybersecurity Threats and Incidents to Government Agencies We proposed in 84 FR 7472 that if health IT developers were to impose prohibitions or restrictions on the ability of any person or entity to communicate information about cybersecurity threats and incidents to government agencies, such conduct would not comply with the Communications Condition of Certification requirements. We sought comment on whether it would be reasonable to permit health IT developers to impose limited restrictions on communications about security issues to safeguard the confidentiality, integrity, and security of EHI. In the Proposed Rule, we asked if, for example, health IT developers should be permitted to require that health IT users notify the developer about the existence of a security vulnerability prior to, or simultaneously with, any communication about the issue to a government agency. Comments. Some commenters stated that users should never be required to notify the developer when reporting cybersecurity issues, as this would impose a burden on the user and a potential barrier to reporting. Other commenters recommended that developers should be allowed to require VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 users to notify them simultaneously or prior to reporting such incidents, with one comment noting that this would enable developers to better address and respond to security threats prior to the knowledge of a threat becoming widespread. Some commenters recommended that ONC make it a violation for developers to not share cybersecurity vulnerabilities with providers, and that ONC work with DHS to mitigate issues around sharing such vulnerabilities. One commenter recommended changing the wording regarding communicating cybersecurity and security risks to include known vulnerabilities and health IT defects. Response. We strongly encourage users of health IT to notify developers as soon as possible when reporting security incidents and issues. However, it would not be appropriate to require this practice, which would impose an obligation on users of health IT that is outside the scope of this rule. It would also be outside the scope of this condition to implement additional requirements for developers regarding the sharing of cybersecurity vulnerabilities with health care providers. To be clear, we expect developers with Health IT Modules certified under the Program to share information about cybersecurity vulnerabilities with health care providers and other affected users as soon as feasible, so that these affected users can take appropriate steps to mitigate the impact of these vulnerabilities on the security of EHI and other PII in the users’ systems. Thus, we have finalized the Communications Condition of Certification requirements in § 170.403(a)(2)(i)(C) as proposed. Developers must not place restrictions on communications receiving unqualified protections. We also clarify that known vulnerabilities and health IT defects would likely be considered types of ‘‘adverse events, hazards, and other unsafe conditions’’ that would receive ‘‘unqualified protection,’’ and thus a developer would not be able to restrict a health IT user from communicating about such issues in communications receiving unqualified protections under the Communications Condition of Certification requirements (see § 170.403(a)(2)(i) as finalized). However, we note that in communications not receiving unqualified protection under the Communications Condition of Certification requirements, a security vulnerability that is not already public knowledge would be considered a nonuser-facing aspect of health IT, about PO 00000 Frm 00089 Fmt 4701 Sfmt 4700 25729 which developers are permitted to restrict communications (see § 170.403(a)(2)(ii)(B) as finalized). Last, we note that we will continue to work with our Federal partners to mitigate and address cybersecurity threats and incidents. (D) Communicating Information About Information Blocking and Other Unlawful Practices to a Government Agency We proposed in 84 FR 7473 that the public benefit associated with the communication of information to government agencies on information blocking, or any other unlawful practice, outweighs any concerns developers might have about the disclosure of information about their health IT. We noted that reporting information blocking, as well as other unlawful practices, to a government agency would not cause an undue threat to a health IT developer’s IP. Comments. We received several comments regarding the lack of whistleblower protections in the Proposed Rule for individuals who report information blocking or other issues regarding certified health IT. These comments discussed the need to provide for whistleblower type protections for individuals who highlight information blocking practices, as well as to identify them to the appropriate authorities so that the individual is not subject to retaliatory action by the actor identified by the whistleblower. Response. We appreciate these comments and agree that it is extremely important for individuals to be able to report information blocking and violations of other Conditions of Certification without fear of retaliation. We note that the Communications Condition of Certification requirements provide protections against retaliation and intimidation by developers with respect to protected communications. We discussed in the Proposed Rule that the Communications Condition of Certification requirements cover communications that are prohibited or restricted through contractual terms or agreements (e.g., non-disclosure agreements, non-disparagement clauses) between the health IT developer, or offeror of health IT, and the communicator, as well as through conduct, including punitive or retaliatory business practices that are designed to create powerful disincentives to engaging in communications about developers or their health IT. We clarify, however, that merely filing a lawsuit against the communicator regarding the making of E:\FR\FM\01MYR3.SGM 01MYR3 25730 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations a communication would not be considered intimidating conduct in violation of this Condition. Any such determination would necessarily be fact-specific, and the health IT developer’s lawsuit would have to be designed to intimidate a communicator in order to prevent or discourage that communicator from making a protected communication, rather than be designed to pursue a legitimate legal interest. We believe that the proposed broad interpretation of ‘‘prohibit’’ and ‘‘restrict’’ is appropriate given the intention of the Cures Act, which placed no limitations on the protection of communications about the protected subject areas. We finalized this interpretation of ‘‘prohibit’’ and ‘‘restrict’’ proposed in 84 FR 7470 and believe that the interpretation would provide significant protections for whistleblowers from retaliatory actions. Thus, retaliatory actions by a developer against a whistleblower would be in violation of this provision. We also emphasize that conduct by a developer that may be perceived as intimidating or punitive would not implicate the Communications Condition of Certification requirements unless that conduct was specifically designed to influence the making of a protected communication. In other words, punitive actions must have a nexus to the making of a protected communication, such as retaliation for reporting of information blocking, in order to violate the Communications Condition of Certification requirements in § 170.403(a)(1). Last, we refer readers to the discussion of ‘‘complaints’’ under the information blocking section of this final rule, which details the confidentiality provided to information blocking complaints and complainants. We have finalized the Communications Condition of Certification requirements in § 170.403(a)(2)(i)(D) as proposed. (E) Communicating Information About a Health IT Developer’s Failure To Comply With a Condition of Certification or Other Program Requirement We proposed in 84 FR 7473 that the benefits to the public and to users of health IT of communicating information about a health IT developer’s failure to comply with a Condition of Certification requirement or other Program requirement (45 CFR part 170) justify prohibiting developers of health IT from placing any restrictions on such protected communications. We explained that information regarding the failure of certified health IT to meet any Condition of Certification requirement VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 or other Program requirement is vital to the effective performance and integrity of the Program. Moreover, the failure of a certified health IT to meet such requirements could impact the performance of the certified health IT with respect to usability, safety, and interoperability. We stated that it is important to enable unencumbered reporting of such information and that such reporting is essential to the transparency that section 4002 of the Cures Act seeks to ensure. While the current procedures for reporting issues with certified health IT encourage providers to contact developers in the first instance to address certification issues, we noted that users of health IT should not hesitate to contact ONCAuthorized Certification Bodies (ONC– ACBs), or ONC itself, if the developer does not provide an appropriate response, or the matter is of a nature that should be immediately reported to an ONC–ACB or to ONC. We did not receive any comments on this aspect of the Proposed Rule. In consideration of the above, we have finalized this provision in § 170.403(a)(2)(i)(E) as proposed. v. Permitted Prohibitions and Restrictions We proposed in 84 FR 7473 that, except for communications with unqualified protection (§ 170.403(a)(2)(i)), health IT developers would be permitted to impose certain narrow prohibitions and restrictions on communications. Specifically, we proposed that, with the exception of communications with unqualified protection, developers would be permitted to prohibit or restrict the following communications, subject to certain conditions: • Communications of their own employees; • Disclosure of non-user-facing aspects of the software; • Certain communications that would infringe the developer’s or another person’s IP rights; • Publication of screenshots in narrow circumstances; and • Communications of information that a person or entity knows only because of their participation in developer-led health IT development and testing. The proposed Communications Condition of Certification requirements delineated the circumstances under which these types of prohibitions and restrictions would be permitted, including certain associated conditions that developers would be required to meet. We emphasized that any prohibition or restriction not expressly PO 00000 Frm 00090 Fmt 4701 Sfmt 4700 permitted would violate the Communications Condition of Certification requirements. Additionally, we proposed that it would be the developer’s burden to demonstrate to the satisfaction of ONC that the developer met all associated requirements. Further, as an additional safeguard, we proposed that where a developer sought to avail itself of one of the permitted types of prohibitions or restrictions, the developer must ensure that potential communicators are clearly and explicitly notified about the information and material that can be communicated, and that which cannot. We proposed this would mean that the language of health IT contracts must be precise and specific. We stressed that contractual provisions or public statements that support a permitted prohibition or restriction on communication should be specific about the rights and obligations of the potential communicator. We explained that contract terms that are vague and cannot be readily understood by a reasonable health IT customer would not benefit from the qualifications to this Condition of Certification requirement as outlined in the Proposed Rule and below. (A) Developer Employees and Contractors We recognized in the Proposed Rule in 84 FR 7473 that health IT developer employees, together with the entities and individuals who are contracted by health IT developers to deliver products and/or services (such as consultants), may be exposed to highly sensitive, proprietary, and valuable information in the course of performing their duties. We also stated that we recognize that an employer should have the ability to determine how and when the organization communicates information to the public, and that employees owe confidentiality obligations to their employers. We noted that this would similarly apply to contractors of a developer. We proposed in 84 FR 7473 that on this basis, developers would be permitted to impose prohibitions or restrictions on the communications of employees and contractors to the extent that those communications fall outside of the class of communications with unqualified protection as discussed above. Comments. One commenter stated that this provision should be clarified and expanded to cover other third parties with whom the health IT developer shares its confidential information, including subcontractors, agents, auditors, suppliers, partners, cosellers, and re-sellers, as well as E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations potential relationships for which a contract has not yet been signed in case information is shared during a precontract evaluation stage. Response. We reiterate that ‘‘developer employees and contractors’’ include health IT developer employees, together with the entities and individuals who are contracted by health IT developers to deliver health IT and/or services who may be exposed to highly sensitive, proprietary, and valuable information in the course of performing their duties. This functional description of employees and contractors could include subcontractors, agents, auditors, suppliers, partners, co-sellers, and resellers, depending on the specific relationship and circumstances. We have finalized the proposed approach to describing employees and contractors in § 170.403(a)(2)(ii)(A). We note that we did not expand this description to include ‘‘potential relationships’’ because such an addition would make the description overly broad, and it is unlikely that individuals who are not yet under contract would be exposed to highly sensitive, proprietary, and valuable information. Comments. We received one comment that self-developers should not be permitted to place restrictions on the communications of their employees who are using their certified health IT. Response. We agree that selfdevelopers should not be allowed to restrict the communications of users of their certified health IT who are also employees or contractors. We have revised § 170.403(a)(2)(ii)(A) to clarify that the limited prohibitions developers may place on their employees or contractors under the Communications Condition of Certification requirements cannot be placed on users of a selfdeveloper’s certified health IT who are also employees or contractors of the self-developer. For example, a large health system with a self-developed EHR cannot restrict a health care provider, who is employed by that health system and using that EHR to provide services, from communicating about the EHR as a user based on the fact that the health care provider is also an employee of the health system. We note that the concept of ‘‘selfdeveloped’’ refers to a Complete EHR or Health IT Module designed, created, or modified by an entity that assumed the total costs for testing and certification and that will be the primary user of the health IT (76 FR 1300). VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 (B) Non-User-Facing Aspects of Health IT We proposed in 84 FR 7474 that the Communications Condition of Certification requirements would permit health IT developers to impose prohibitions and restrictions on communications to the extent necessary to ensure that communications do not disclose ‘‘non-user-facing aspects of health IT.’’ We noted that, like all permitted prohibitions, such prohibitions and restrictions could only be put in place by developers if there is not an unqualified protection that applies. We proposed in 84 FR 7474 that a ‘‘non-user-facing aspect of health IT,’’ for the purpose of this Condition of Certification, was an aspect of health IT that is not a ‘‘user-facing aspect of health IT.’’ We stated that ‘‘user-facing aspects of health IT’’ would include the design concepts and functionality that is readily ascertainable from the health IT’s user interface and screen display. We stated that they did not include those parts of the health IT that are not exposed to persons running, using, or observing the operation of the health IT and that are not readily ascertainable from the health IT’s user interface and screen display, all of which would be considered ‘‘non-user-facing’’ concepts. We proposed in 84 FR 7474 that ‘‘nonuser-facing aspects of health IT’’ would include source and object code, software documentation, design specifications, flowcharts, and file and data formats. We welcomed comments on whether these and other aspects of health IT should or should not be treated as userfacing. In the Proposed Rule, we noted that the terminology of ‘‘non-user-facing aspects of health IT’’ is not intended to afford only health IT users with specific protections against developer prohibitions or restrictions on communications and is agnostic as to the identity of the communicator. Comments. Some commenters expressed concern regarding the broad scope of ‘‘user-facing’’ and, by extension, the scope of ‘‘non-userfacing.’’ One commenter asked for clarification regarding the definition of ‘‘software documentation’’ with regards to non-user-facing aspects of health IT and suggested that it applies to documentation that is for back-end components, not documents for normalend use. Additionally, a couple of comments stated that administrative functions should not be considered user-facing, including one comment that the relevant users for the purpose of the Communications Condition of Certification requirements are ‘‘end’’ PO 00000 Frm 00091 Fmt 4701 Sfmt 4700 25731 users, thus the non-user-facing provision should apply only to ‘‘nonend-user-facing’’ aspects of health IT. Some commenters emphasized that administrative portions of health IT contain more insight into health IT systems and that administrative functions affect a limited number of users and are not the types of communications or subject matters contemplated by the Cures Act. One commenter stated that algorithms should be considered non-user-facing. Another commenter stated that ONC should clarify the status of diagrams and flowcharts. Response. We do not see a necessary or appreciable distinction between ‘‘users’’ and ‘‘end users,’’ as we have focused on the aspects of the health IT that are and are not subject to protected communications under this Condition of Certification. We also believe that there could be unintended consequences with the term ‘‘end user,’’ such as limiting certain users not specified under the ‘‘permitted prohibitions and restrictions’’ (e.g., developer employees and contractors) from making protected communications. Therefore, we believe ‘‘non-user-facing’’ best reflects the scope of the communications about health IT we seek to capture with these terms. We reiterate that ‘‘non-user-facing aspects of health IT’’ comprise those aspects of the health IT that are not readily apparent to someone interacting with the health IT as a user of the health IT, including source and object code, certain software documentation, design specifications, flowcharts, and file and data formats. We clarify that ‘‘non-userfacing aspects of health IT’’ would also include underlying software that is utilized by the health IT in the background and not directly by a user of the health IT. For example, the programming instructions for proprietary APIs would be considered non-user-facing because they are not readily apparent to the individual users of the health IT. In addition, underlying database software that connects to health IT and is used to store data would be considered a non-user-facing aspect of health IT because it serves data to the health IT, not directly to a user. We further clarify that algorithms would be considered ‘‘non-user-facing aspects of health IT’’ as they are not readily apparent to persons using health IT for the purpose for which it was purchased or obtained. Thus, communications regarding algorithms (e.g., mathematical methods and logic) could be restricted or prohibited, while communications regarding the output of the algorithm and how it is displayed in E:\FR\FM\01MYR3.SGM 01MYR3 25732 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations a health IT system could not be restricted as ‘‘non-user-facing aspects of health IT.’’ Similarly, we also clarify that certain ‘‘software documentation’’ that would be considered to be a nonuser-facing aspect of health IT would include documentation for back-end components, again because it is not readily apparent to persons using health IT. Whether or not a communication would be considered a ‘‘non-user-facing aspects of health IT’’ would be based on whether the communication involved aspects of health IT that would be evident to anyone running, using, or observing the operation of the health IT for the purpose for which it was purchased or obtained. With respect to administrative functions, where the communication at issue relates to aspects of the health IT that are not observable by users of the health IT, it would be considered ‘‘non-user-facing’’ for the purpose of this Condition of Certification requirement. For example, a communication regarding an input process delay experienced by an administrator of health IT that was caused by the underlying database software could be restricted if the communication discussed the underlying database software, which would be considered a non-user-facing aspect of the health IT. However, if the communication discussed the user screens and the delay experienced by the administrator, which would be considered user-facing aspects of health IT, it could not be restricted. Similarly, as long as diagrams or flowcharts do not include aspects of the health IT that are observable by users of the health IT, as described above, they would be considered communications about nonuser-facing aspects of health IT. We have finalized in § 170.403(a)(2)(ii)(B) our proposed approach to the scope of ‘‘non-userfacing aspects of health IT’’ with the clarification provided above regarding scope. (C) Intellectual Property We proposed in 84 FR 7474 that the Communications Condition of Certification requirements are not intended to operate as a de facto license for health IT users and others to act in a way that might infringe the legitimate IP rights of health IT developers or other persons. Indeed, we proposed in 84 FR 7474 that health IT developers are permitted to prohibit or restrict certain communications that would infringe their IP rights so long as the communication in question is not a communication with unqualified protection. We proposed in 84 FR 7474 VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 that any prohibition or restriction imposed by a developer must be no broader than legally permissible and reasonably necessary to protect the developer’s legitimate IP interests. We also proposed in 84 FR 7474 that health IT developers are not permitted to prohibit or restrict, or purport to prohibit or restrict, communications that would be a ‘‘fair use’’ of any copyright work comprised in the developer’s health IT.86 ‘‘Fair use’’ is a legal doctrine that allows for the unlicensed use of copyright material in certain circumstances, which could include circumstances involving criticism, commentary, news reporting, and research.87 Comments. One commenter stated that fair use should not override other IP protections and stressed that relying on fair use could lead to uncertainty because it is determined on a case-bycase basis. Another commenter stated that because the fair use doctrine can be difficult to implement and can lead to uncertain results, ONC should expand the list of communications that would be explicitly protected as fair use to include news reporting, criticism, parody, and communications for educational purposes. Response. We disagree with commenters and believe that relying on the ‘‘fair use’’ doctrine for determining when a screenshot or other communication cannot be restricted should be allowed under the Communications Condition of Certification requirements. This doctrine presents a framework of analysis that is well-developed in case law and thus can be interpreted and applied consistently, even when materials are not formally copyrighted. Accordingly, we are retaining the concept of ‘‘fair use’’ in the final provision in § 170.403(a)(2)(ii)(C). Developers and ONC will apply a fair use test to copyrighted materials and, by analogy, to materials that could be copyrighted, to determine whether developers may prohibit a communication that would infringe on IP rights. The Communication Condition of Certification requirements relate only to protected communications, thus developers can place restrictions on communications about subject matters outside of the protected communications categories without implicating the Communications 86 See 17 U.S.C. 107 (setting forth the four factors required to evaluate a question of fair use under the statutory framework). 87 See https://www.copyright.gov/fair-use/moreinfo.html for more information on fair use. PO 00000 Frm 00092 Fmt 4701 Sfmt 4700 Condition of Certification requirements. Also, as discussed earlier regarding developer employees and contractors in § 170.403(a)(2)(ii)(A), developers may restrict communications by their employees, contractors, and consultants without implicating the Communications Condition of Certification requirements, provided they do not restrict communications with unqualified protections. Further, as described earlier regarding non-userfacing aspects of certified health IT in § 170.403(a)(2)(ii)(B), developers may restrict communications that disclose non-user-facing aspects of the developer’s certified health IT, provided they do not restrict communications with unqualified protections. We clarified in that section that screenshots or videos depicting source code would be considered communications of nonuser-facing aspects of health IT and could be restricted under the Communications Condition of Certification requirements as long as they did not receive unqualified protection. We also clarify that this Condition does not prohibit health IT developers from enforcing their IP rights and that a lawsuit filed by a health IT developer in response to a protected communication regarding infringement of IP rights would not automatically be considered intimidation or retaliation in violation of this Condition. As discussed later in the pre-market testing and development section in § 170.403(a)(2)(ii)(E), developers can place restrictions on communications related to pre-market health IT development and testing activities, which could include IP protections, provided they do not restrict communications with unqualified protections. Combined, these avenues allow for protecting IP in ways that would not implicate the Communications Condition of Certification requirements, thereby allowing developers to take a number of actions to protect and safeguard IP in their certified health IT. Comments. Several commenters requested clarity regarding how the proposed protections for IP would work. One commenter stated that the rule must allow developers to protect legitimate IP interests and asked for clarity on how ONC would determine whether a developer’s restriction on the communication of a screenshot was an allowable protection of trade secrets or an impermissible restriction of protected communications. Several other commenters, who generally supported the Communications Condition of Certification requirements, requested clarification regarding how a E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations prohibition on communications that is designed to protect IP can be applied. Some commenters requested examples of the types of communications that can be restricted on the basis of IP and clarification of the standard ONC will use to determine what prohibitions are permissible. Response. We have finalized an approach in § 170.403(a)(2)(ii)(C) that allows developers to prohibit or restrict communications that involve the use or disclosure of intellectual property existing in the developer’s health IT (including third-party intellectual property), provided that any prohibition or restriction imposed by a developer must be no broader than necessary to protect the developer’s legitimate intellectual property interests and consistent with all other requirements under the ‘‘permitted prohibitions and restrictions’’ (§ 170.403(a)(2)(ii)) of this section. As discussed above, a restriction or prohibition would be deemed broader than necessary and inconsistent with the ‘‘permitted prohibitions and restrictions’’ (§ 170.403(a)(2)(ii)) if it would restrict or preclude a public display of a portion of a work subject to copyright protection (without regard to whether the copyright is registered) that would reasonably constitute a ‘‘fair use’’ of that work. Examples of the types of communications that could be restricted under the Communications Condition of Certification requirements might include a blog post describing a customization of a developer’s health IT that includes the source code of the developer’s health IT or a written review of an analytical feature of the developer’s health IT that reveals the algorithms used. However, as mentioned above, the restriction must be no broader than necessary to protect the developer’s legitimate IP interests, thus only the infringing portions of the communications could be restricted. Comments. One commenter recommended that a health IT developer must demonstrate that a communication was specifically designed to copy or steal a developer’s IP in order for the developer to be allowed to prohibit the communication as an infringement on their IP rights. Response. We appreciate this comment, but decline to require that a developer demonstrate that a communication was designed to copy or steal IP in order for the developer to restrict the communication as one that would infringe on IP rights. We believe that the revised approach discussed above provides appropriate balance between protecting IP rights and VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 enabling protected communications and do not believe that an ‘‘intent’’ element would be necessary. We have finalized the proposals regarding IP in § 170.403(a)(2)(ii)(C), as amended above. (D) Faithful Reproductions of Health IT Screenshots We proposed in 84 FR 7475 that health IT developers generally would not be permitted to prohibit or restrict communications that disclose screenshots of the developer’s health IT. We proposed that the reproduction of screenshots in connection with the making of a communication protected by this Condition of Certification would ordinarily represent a ‘‘fair use’’ of any copyright subsisting in the screen display, and developers should not impose prohibitions or restrictions that would limit that fair use. Notwithstanding this, we proposed that health IT developers would be allowed to place certain restrictions of the disclosure of screenshots as specified in proposed § 170.403(a)(2)(ii)(D). With respect to the limited allowable restrictions on screenshots, we proposed in 84 FR 7475 that developers would be permitted to prevent communicators from altering screenshots, other than to annotate the screenshot or to resize it for the purpose of publication. We also proposed that health IT developers could impose restrictions on the disclosure of a screenshot on the basis that it would infringe third-party IP rights (on their behalf or as required by license). However, to take advantage of this exception, we proposed in 84 FR 7475 that the developer would need to first put all potential communicators on sufficient written notice of those parts of the screen display that contain IP and cannot be communicated, and would still need to allow communicators to communicate redacted versions of screenshots that do not reproduce those parts. Finally, we proposed in 84 FR 7475 that it would be reasonable for developers to impose restrictions on the communication of screenshots that contain PHI, provided that developers permit the communication of screenshots that have been redacted to conceal PHI, or where the relevant individual’s consent or authorization had been obtained. We welcomed comments on whether an appropriate balance had been struck between protecting legitimate IP rights of developers and ensuring that health IT customers, users, researchers, and other stakeholders who use and work with health IT can openly discuss and share their experiences and other relevant information about the performance of health IT. PO 00000 Frm 00093 Fmt 4701 Sfmt 4700 25733 Comments. A large number of commenters, particularly health care providers, supported our proposals regarding the communication of screenshots, with several stressing how helpful screenshots are when communicating usability and safety issues with health IT. One commenter noted that communication of screenshots can help different health care systems understand whether a proposed implementation of an EHR has introduced safety-related challenges at other locations, or help identify solutions to common problems, such as usability challenges. One other commenter stated that there is nothing novel displayed in health IT screenshots that would need to be protected. Response. We appreciate the many positive comments on our proposals regarding screenshots. Comments. Commenters stated that the scope of protected communications as proposed should exclude disclosure of the health IT itself, such as through screenshots. The commenter stressed that the Cures Act required that health IT developers not restrict communications about the certified health IT with respect to specific topic areas, while the Proposed Rule expands that restriction to include communication of the health IT itself. One commenter noted that the Cures Act does not mention screenshots and they should not be included in the Communications Condition of Certification requirements. Response. The Cures Act amended title XXX of the PHSA to establish this condition of certification, which applies to ‘‘health information technology.’’ Title XXX of the PHSA was previously added by the HITECH Act, which included the definition of ‘‘health information technology.’’ Section 3000(5) of the PHSA defines health information technology to mean hardware, software, integrated technologies or related licenses, IP, upgrades, or packaged solutions sold as services that are designed for or support the use by health care entities or patients for the electronic creation, maintenance, access, or exchange of health information. We emphasize both that this definition includes IP associated with the health information technology and that it applies to this condition of certification as this condition references communications regarding health information technology. We have also adopted this definition in § 170.102. We disagree with the commenters’ interpretation of the statutory provision. The statutory provision focuses on ‘‘communications’’ regarding E:\FR\FM\01MYR3.SGM 01MYR3 25734 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations enumerated aspects of the health IT. Communications are not defined nor limited in the Cures Act, and we proposed to broadly define them. Verbal, written, and visual, as well other types of communications, are all covered under the Cures Act. A screenshot is a copy/picture of the user interface of the health IT, or a ‘‘visual communication’’ that is protected under this condition of certification. We have specifically defined ‘‘communication’’ for this section in § 170.403(c) to mean any communication, irrespective of the form or medium. The term includes visual communications, such as screenshots and video. As we emphasized in the Proposed Rule in 84 FR 7475, the sharing of screenshots (with accompanying annotation and/or explanatory prose) is often a critical form of communication of issues with health IT related to—for example—usability, user experience, interoperability, security, or the way the technology is used. We believe screenshots are uniquely helpful as a form of visual communication that can non-verbally illustrate the ‘‘user’s experiences when using the health information technology’’ and the ‘‘manner in which a user of the health information technology has used such technology’’ as they relate intrinsically to both subject areas and capture those user experiences immediately and directly. Further, enabling screenshot sharing can allow for clearer, more immediate, and more precise communication on these pertinent issues, potentially helping a health system avoid costly, or even deadly, complications when implementing health IT. It is also our understanding that screenshots are often the only recourse a user in a network enterprise system has for capturing, documenting, and explaining their concerns. We clarify, however, that the sharing of a screenshot alone would not be considered a protected communication as it would need to be accompanied by an explanation of the issues or aspects of the health IT that the screenshot is meant to communicate or illustrate. Considering the value of communicating significant issues regarding health IT through screenshots, we have finalized our proposal to include screenshots as a protected communications under the Cures Act. However, as discussed in responses to other comments below, we have revised our final policy in multiple ways. Comments. One commenter recommended that screenshots should be defined broadly to include video and other media that can be helpful in demonstrating challenges with EHRs. VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 Response. We agree with the recommendation that protections afforded to screenshots should extend to video. We clarify that, like screenshots, video is considered a form of visual communication. A video of a computer screen while a software program is in operation would capture the user experience of interacting with that program and essentially would show a number of screenshots from that program in rapid succession. We emphasize that video, similarly to individual screenshots, is a critical form of communication of issues with the health IT, including issues related to usability, user experience, interoperability, security, or the way the technology is used. As with screenshots, video is particularly useful in communicating a user’s experience with health IT and the manner in which the user has used health IT. This is especially the case when issues of a temporal nature are involved. For example, video would be essential for illustrating a latency issue experienced during drug ordering that could not be communicated through screenshots or other forms of communication. Video also could be critical to demonstrating an issue with a clinical decision support alert that is designed to appropriately and timely notify the provider of a patient matter but fails to do so. Comments. Several commenters expressed concern regarding how a developer’s IP may be impacted by the proposed Communications Condition of Certification requirements. Several commenters stated that the Proposed Rule goes beyond protecting communications for the purposes of patient safety and system improvement and would enable or require inappropriate sharing and disclosure of IP, potentially creating security risks, increased IP theft, and harming innovation and the marketplace for health IT. Several commenters stated that trade secrets, patent protections, and protections for confidential and proprietary information were not addressed or considered appropriately in the Proposed Rule, and that as a result it would be possible for bad actors to create pirated health IT based on the disclosure of screenshots and similar communications. Commenters stated that developers of health IT have successfully used licensing and nondisclosure agreements that apply to user-facing aspects of the technology to maintain the trade secret status of their health IT and that the Proposed Rule would impact their ability to do so and remain competitive in the market. PO 00000 Frm 00094 Fmt 4701 Sfmt 4700 Response. We appreciate the comments regarding how a developer’s IP may be impacted by the Communications Condition of Certification requirements. As discussed earlier in this section, participation in the Program is voluntary; and developers have the option to agree to the terms we have offered or to choose not to participate in the Program. However, we recognize the need to properly balance the protection of a developer’s IP with the need to advance visual communications (e.g., screenshot and video communications) under the Communications Condition and Maintenance of Certification requirements, which we believe is critical to addressing—among other things—the usability, interoperability, and security of health IT. As discussed throughout this section and in section (C) above, we believe that we have properly considered and addressed health IT developers’ IP rights in this final rule in § 170.403(a)(2)(ii)(C) by amending the proposed regulation as described above. We emphasize that the communication of screenshots is essential to protect public health and safety and that our final policies take a measured approach to responding to and addressing a real and substantial threat to public health and safety. The communication of screenshots enables providers, researchers, and others to identify safety concerns, share their experiences with the health IT, learn from the problems, and then repair dangers that could otherwise cause serious harm to patients. Our position is informed both by years of experience regulating health IT and overwhelming research and academia, which is discussed below. For instance, a study published in 2018 was performed to better characterize accessibility to EHRs among informatics professionals in various roles, settings, and organizations across the United States and internationally.88 To quantify the limitations on EHR access and publication rights, the researchers conducted a survey of informatics professionals from a broad spectrum of roles including practicing clinicians, researchers, administrators, and members of industry. The results were analyzed and levels of EHR access were stratified by role, organizational affiliation, geographic region, EHR type, and restrictions with regard to 88 Khairat, S, et al. 2018 Assessing the Status Quo of EHR Accessibility, Usability, and Knowledge Dissemination. eGEMs (Generating Evidence & Methods to improve patient outcomes), pp. 1–11, https://doi.org/10.5334/egems.228. E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations publishing results of usability testing, including screenshots. Among faculty members and researchers, 72 percent could access the EHR for usability and/ or research purposes, but, of those, fewer than 1 in 3 could freely publish screenshots with results of usability testing and half could not publish such data at all. Across users from all roles, only 21 percent reported the ability to publish screenshots freely without restrictions.89 The study explained that the patient safety implications of EHR publication censorship and restricted EHR access are multiple. First, limiting institutions from sharing usability research findings can prevent the correction of known problems. Second, without public dissemination, poor design practices will propagate to future iterations of existing vendor systems. Finally, research efforts are directed away from real-world usability problems at a time when EHR systems have become widely deployed and when an urgency exists to accelerate usability testing. The study referenced the 2011 Institute of Medicine report (as discussed in the Proposed Rule and in additional detail below), which identified contractual restrictions as a barrier to knowledge regarding patient safety risks related to health IT.90 The study emphasized that the result of this level of censorship is that a vast majority of scientists researching EHR usability are either prevented from publishing screenshots altogether or must first obtain vendor permission, thus impeding the free dialogue necessary in communities of investigation.91 The study argued that: (1) Lack of EHR access makes many critical EHR usability research activities impossible to conduct, and (2) publication censorship, especially regarding screenshots, means that even those usability studies which can be conducted may not have the impact they otherwise would. As a consequence, innovation can be stifled. As such, one of the recommendations made by the researchers was that there should be a mandate that screenshots and images from EHR systems be freely publishable without restrictions from copyright or trade secret constraints.92 In the report by the Institute of Medicine that was noted above, entitled Health IT and Patient Safety: Building Safer Systems for Better Care,93 the 89 Id. at 1. at 2. 91 Id. at 7. 92 Id. at 8. 93 Institute of Medicine 2012. Health IT and Patient Safety: Building Safer Systems for Better 90 Id. VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 Committee on Patient Safety and Health Information Technology (Committee) explained that a significant impediment to gathering safety data is contractual barriers (e.g., nondisclosure, confidentiality clauses) that can prevent users from sharing information about health IT–related adverse events. They further explained that such barriers limit users’ abilities to share knowledge of risk-prone user interfaces, for instance through screenshots and descriptions of potentially unsafe processes. In addition, some vendors include language in their sales contracts and escape responsibility for errors or defects in their software (i.e., ‘‘holdharmless clauses’’). The Committee concluded that these types of contractual restrictions limit transparency, which significantly contributes to the gaps in knowledge of health IT–related patient safety risks. Further, these barriers to generating evidence pose unacceptable risks to safety.94 Based on these findings, the committee recommended that the Secretary of HHS should ensure insofar as possible that health IT vendors support the free exchange of information about health IT experiences and issues and not prohibit sharing of such information, including details (e.g., screenshots) relating to patient safety.95 Recently, the U.S. Food and Drug Administration (FDA) funded Brigham and Women’s Hospital Center for Patient Safety Research and Practice to conduct an exploration of computerized prescriber order entry (CPOE)-related potential for errors in prescribing, particularly as these relate to drug name displays, and ordering and workflow design issues. The project investigated ways to better identify, understand, and prevent electronic ordering errors in the future.96 However, the researchers noted that one large vendor would not grant permissions to share requested screenshots necessary for the study. This refusal ran counter to both the FDA’s task order initial precondition as well as multiple high-level panels’ health IT safety recommendations. The FDA emphasized that it is hard to justify from a safety viewpoint why such permission was withheld, despite the vendors’ proprietary concerns. FDA explained that identifying, preventing, and learning from errors and improving Care. Washington, DC: The National Academies Press, https://doi.org/10.17226/13269. 94 Id. at 3. 95 Id. at 7. 96 U.S. Food & Drug Admin., UCM477419, Computerized Prescriber Order Entry Medication Safety: Uncovering and Learning from Issues and Errors, https://www.fda.gov/downloads/Drugs/ DrugSafety/MedicationErrors/UCM477419.pdf. PO 00000 Frm 00095 Fmt 4701 Sfmt 4700 25735 prescribing safety should be a priority and should take precedence over commercial considerations (and to the extent correctable problems can be identified, likely would result in an improved commercial CPOE product). In cases where the FDA sought to illustrate problems in the system, they drew generic screenshots to illustrate the issue in question.97 Among their recommendations, the FDA recommended that vendors be required to share screenshots and error reports. The FDA emphasized that vendors should be required to permit the sharing of screenshots and information with the FDA and other institutions regarding other CPOE system issues of concern or that pose risk for errors. They stressed that the practice of prohibiting such sharing via copyright must be eliminated. Further, the FDA recommended that vendors should be required to disclose errors reported to them or errors identified in their products, analogous to the requirement that drug manufacturers report significant adverse drug effects.98 One of the co-authors of the FDA study recently wrote a law review article that discussed the significance of screenshots.99 The author noted that the results of the FDA study were remarkable and remarkably distressing, as they identified and took screenshots of over fifty different dangers in the health IT. He expressed frustration that it took up to two years of additional discussions with the vendors to get permission to share the screenshots publicly, and that even after these extended discussions, one vendor— ‘‘with more than a lion’s share of the market’’—prevented the study from displaying the screenshots, some of which were clearly dangerous or deadly. He explained that they had worked around that limitation by substituting the one vendor’s screens with parallel screens taken from Harvard’s homegrown, but by then superannuated, EHR. The author emphasized that those images and screenshots illustrated over fifty EHR risks caused by dangerous and confusing EHR interfaces. The author also emphasized that the study could have been even more helpful in identifying these risks if the FDA had been able to present the findings when first available, rather than haggle for a year or two, and if the study was able 97 Id. at 44. at 52. 99 Ross Koppel, Uses of the Legal System That Attenuate Patient Safety, 68 DePaul L. Rev. (2019) Available at: https://via.library.depaul.edu/lawreview/vol68/iss2/6. 98 Id. E:\FR\FM\01MYR3.SGM 01MYR3 25736 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations to include all of the full images from each system they studied.100 Comments. A commenter recommended that ONC draw a distinction around purpose of use in relation to the fair use of screenshots and require that the discloser of a screenshot be responsible for ensuring the appropriateness of that purpose. Response. As discussed under section (C) above we have retained the concept of ‘‘fair use’’ as it applies to all health IT developer intellectual property covered under ‘‘permitted prohibitions and restrictions’’ (§ 170.403(a)(2)(ii)). As discussed throughout this section, we have placed certain restrictions on the sharing of screenshots responsive to the commenter. Comments. One commenter urged ONC to revise the proposed approach to screenshots by adopting a process that would allow developers to review and approve screenshots for publication for specific purposes, such as communications about safety and usability. Response. A pre-approval process could create potential or perceived barriers to communications and thus could discourage or delay the making of protected communications that are vital to patient safety or other important issues regarding certified health IT. For example, a user might be less willing to go through the process, the time the process takes could undermine the conveyance of the communications, and the objections raised during the process may not be valid or amenable to all parties. Comments. Several commenters had concerns regarding the volume of screenshots that could be shared under our proposal and potential harms that could occur. One commenter emphasized that sharing of screenshots could disclose information about how health IT works, including algorithms and workflows, and enable creation of duplicate software and theft of valuable IP. One commenter suggested that if a user of health IT published hundreds of screenshots of the health IT, a bad actor could theoretically deduce trade secrets based on the screenshots. Several additional commenters were also concerned that the Proposed Rule could allow communication of an unlimited number of screenshots of certified health IT, and one commenter suggested revising the proposed approach to include limiting sharing of screenshots to a reasonable number, such as seven. Response. We appreciate those comments expressing concerns regarding the volume of screenshots that 100 Id. at 280–81. VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 could be shared and the potential negative consequences of allowing screenshots to be shared. In the Proposed Rule in 84 FR 7475, we proposed to allow developers to place limited restrictions on the sharing of screenshots. We stressed in the Proposed Rule that our goal with our proposals concerning screenshots was to enable communications that will address matters such as patient safety, system security vulnerabilities, health IT performance, and usability. Our intent was not to prevent developers from restricting the communication of screenshots for purposes outside the scope of the protected communications detailed in the Cures Act. Additionally, we believe that modern software design best practices uncouple screen design from underlying algorithms, and that limited use of screenshots for safety would not allow reverse engineering of large parts of the underlying code. However, we further emphasize that it was never our intention that screenshots (or other visual communications such as video) depicting source or object codes would be protected communications (see the non-user-facing aspects provision of this Condition of Certification), so long as such communications are not communications with unqualified protection. We reviewed comments that suggested establishing a set numerical limit for the sharing of screenshots. However, we have not finalized a requirement in § 170.403(a)(2)(ii)(D) with a fixed numerical limit because there is no non-arbitrary way to determine what the ‘‘right’’ or ‘‘appropriate’’ number is in a one-sizefits-all way. That is because the number of screenshots or amount of video that would be needed to communicate about the health IT could vary, from one situation to the next, based on the specific issue and circumstances. For instance, an issue with health IT functionality regarding a particular process that involves the user viewing and making selections on several different screens may necessitate images of all of the screens involved in order to communicate the issue. However, an issue regarding how one value is being displayed in a particular context (e.g., a medication name being truncated) may only necessitate one screenshot in order to communicate the issue. Thus, we believe the best approach is to adopt a qualitative standard that is designed to be sufficiently flexible for the wide range of health IT issues that may arise and the varying visual communications PO 00000 Frm 00096 Fmt 4701 Sfmt 4700 that need to be communicated to demonstrate or display the issue. We have finalized provisions in § 170.403(a)(2)(ii)(D)(2) and (3) that allow health IT developers to require persons who communicate screenshots to limit the sharing of screenshots to only the relevant number of screenshots and amount of video that are needed to communicate about the health IT regarding one or more of the six subject areas identified in the Cures Act and detailed in § 170.403(a)(1). Allowing developers to limit the sharing of screenshots to only the relevant number needed to communicate about the health IT—regarding one or more of those six subject areas—places a limitation on the number of screenshots allowed to be shared under the Communications Condition of Certification requirements and requires that the screenshots are related to, and thus necessary in illustrating, the protected communication being made. In practice, this would mean that if a particular safety issue in the health IT could be communicated using three screenshots, the communicator should not share additional screenshots that are irrelevant or only potentially relevant to communicate the safety issue with the health IT. If the communication included additional screenshots that were not necessary to visually communicate about the particular safety issue with the health IT that falls within the usability category, the health IT developer would have grounds to seek redress. As with screenshots, we wish to be sensitive to concerns regarding protecting IP in health IT and allow developers to appropriately limit video communication in order to protect against harms that could occur due to unlimited sharing. Similar to screenshots, the amount of video that may be necessary to make a protected communication about health IT could vary, depending on the nature of the issue or aspect of the health IT being addressed. For example, a video meant to communicate a delay in order entry would need to be long enough to communicate the significance of the delay, but would not need to include video of the log-in process or other unrelated functionality of the health IT. We have finalized a provision in § 170.403(a)(2)(ii)(D)(3) that allows health IT developers to place certain limitations on the communication of video. Under this provision, a health IT developer may require persons who communicate video to limit the sharing of video to: (1) The relevant amount of video needed to communicate about the health IT regarding one or more of the E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations subject areas identified in the Cures Act and detailed in § 170.403(a)(1); and (2) only videos that address temporal matters that the user reasonably believes cannot be communicated through screenshots or other forms of communications. In sum, any disclosure must be limited to the relevant number of screenshots or amount of video that is necessary to convey the matter that falls within one of the six subject areas, with video only being used to convey temporal matters that cannot be communicated through screenshots or other forms of communication. We believe these additional limitations on the communication of screenshots and video will further bolster protections for developer IP, while still allowing necessary and effective communication about health IT issues within the six subject areas. Comments. Several commenters stated that there should be a way to protect against doctored screenshots. Response. As proposed, communicators of screenshots must not alter the screenshots (or video), except to annotate the screenshots or resize the screenshots (§ 170.403(a)(2)(ii)(D)(1)). These restrictions similarly apply to video as well (§ 170.403(a)(2)(ii)(D)(1)). We further note that, despite a lack of comments, on further reflection, we have elected to not finalize proposed limitations to allow developers to impose restrictions on the communication of screenshots that contain PHI. We have made this determination because we believe that most of the individuals or entities communicating the screenshots would be bound by other laws, including the HIPAA Rules and State privacy laws, which would be applicable to the PHI at issue. Therefore, we do not believe it is necessary to provide for developers policing the release of such data in the form of screenshots in this Condition of Certification. Comments. A number of commenters discussed the infeasibility of the proposed requirements regarding restricting communication of screenshots, and in particular, the requirement that health IT developers put all potential communicators on sufficient written notice of each aspect of its screen display that contains thirdparty content that cannot be communicated because it would infringe IP rights. Some commenters stated that the proposed language should be amended to require a list of third-party content that might appear in a screen or that the developer sublicenses, or to require a notice on the developer’s website. Other commenters VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 stated that the proposal should be removed. One commenter recommended ONC consider not making developers accountable for actions by health IT users regarding the disclosure of screenshots with thirdparty information. One commenter requested additional guidance from ONC for dealing with third-party, nonhealth IT content in health IT. Response. Where a health IT developer is prohibited by this rule from restricting the communication of a screenshot and allows a screenshot containing third-party content to be communicated, the health IT developer is acting as required by this final rule and enabling important communication regarding critical health IT issues to occur. Thus, we believe developers acting in accordance with this final rule should not be responsible for third-party content in screenshots that are communicated as required by the Communications Condition of Certification requirements. As such, in § 170.403(a)(2)(ii)(D) we have removed from the requirements related to thirdparty IP rights proposed in 84 FR 7475. (E) Testing and Development We discussed in the Proposed Rule in 84 FR 7475 that some health IT developers expose aspects of their health IT to health care providers and others for the purpose of testing and development prior to a product’s ‘‘general availability’’ release. We stated that such disclosures may relate to beta releases that are shared with certain customers for testing prior to the software being made generally available to the market, or may be made as part of a joint-venture or cooperative development process. In these circumstances, we proposed in 84 FR 7475 that a health IT developer would be justified in keeping information about its health IT confidential. We explained that this permitted prohibition or restriction would allow developers to seek appropriate IP protection and discuss novel, ‘‘unreleased’’ product features with their customer base, which has significant public policy benefits for research and innovation in the health IT industry. We proposed in 84 FR 7475 that this permitted restriction would be limited and would not apply to communications that are subject to unqualified protection as specified in proposed § 170.403(a)(2)(i). We proposed that this permitted restriction would also not apply to communications about the released version of the health IT once the health IT has been released. PO 00000 Frm 00097 Fmt 4701 Sfmt 4700 25737 We requested comment on whether we should limit the time this protection would apply for testing purposes. We also requested comment on whether we should set specific parameters for covered testing. Comments. A couple of commenters stated that there should be no limit on how long testing and development could last for the purpose of the restrictions that developers would be allowed to place on communications regarding products in development. These commenters stressed that any limit would be arbitrary and that until certified health IT is in live commercial use, health IT developers should be permitted to restrict communications about it. Response. We agree with the commenters and did not propose to add a time limit on testing and development phases for the purpose of this Condition of Certification requirement. Comments. A couple of commenters requested clarification that providers testing products in real-world environments would not be considered ‘‘contractors’’ of developers for the purpose of the Communications Condition of Certification requirements because such treatment could result in developers being allowed to place additional communication restrictions on employees and contractors under the Communication Condition of Certification requirements. One comment also stated that restrictions on communications by employees and contractors should not extend to their communications regarding product features and functionality that the employees and contractors were not involved in developing or testing. Response. The applicability of this allowable restriction to providers testing products would be determined by the particular facts at issue and whether or not the provider was an actual contractor, employee, or consultant for the developer. We also clarify that this final rule does not limit the restrictions a developer may place on an employee, contractor, or consultant with regard to protected communications, except to the extent that the communication is one with unqualified protection, in which case no such restrictions would be allowed. Comments. One commenter recommended that a health IT user must have used health IT in a real-world context before a communication by the user about the health IT can be protected. Response. We have finalized our proposal in § 170.403(a)(2)(ii)(E) that a health IT developer would be justified in keeping information about its health E:\FR\FM\01MYR3.SGM 01MYR3 25738 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations IT confidential prior to a product’s ‘‘general availability’’ release. We note that a health IT developer would also be justified in keeping information about a product update confidential because the update is not yet generally available. We do not place any limits on who the communicator has to be in order to be covered by the Communications Condition of Certification requirements, particularly since the protections in the Communications Condition of Certification requirements extend beyond users of certified health IT to cover researchers and other stakeholders who may experience certified health IT in a variety of settings and scenarios. As such, we have decided not to limit the communication protection to only those communications that are made by users of certified health IT in the real-world context. c. Maintenance of Certification Requirements We proposed in 84 FR 7476 that to maintain compliance with the Communications Condition of Certification requirements, a health IT developer must not establish or enforce any contract or agreement provision that contravenes the Communications Condition of Certification requirements. We also proposed in 84 FR 7476 that a health IT developer must notify all entities or individuals with which it has a contract/agreement related to certified health IT that any communication or contract/agreement provision that contravenes the Communications Condition of Certification requirements will not be enforced by the health IT developer. We proposed in 84 FR 7476 that such notification must occur within six months of the effective date of the final rule. Further, we proposed in 84 FR 7476 that this notice would need to be provided annually up to and until the health IT developer amends the contract or agreement to remove or make void any contractual provision that contravenes the Communications Condition of Certification requirements. We further proposed as a Maintenance of Certification requirement in proposed § 170.403(b)(2) that health IT developers must amend their contracts/agreements to remove or make void any provisions that contravene the Communications Condition of Certification requirements within a reasonable period of time, but not later than two years from the effective date of a final rule. In the event that a health IT developer cannot, despite all reasonable efforts, locate an entity or individual that previously entered into an agreement with the developer that prohibits or restricts communications protected by VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 the Communications Condition of Certification requirements, we proposed in 84 FR 7476 that the developer would not be in contravention of the Communications Condition of Certification requirements so long as it takes no step to enforce the prohibition or restriction. We did not propose that health IT developers be required to furnish to ONC or their ONC–ACB copies of notices made to customers, or copies of contracts or agreements revised, in satisfaction of this Maintenance of Certification requirement, although we noted that those communications could be requested by ONC or an ONC–ACB in the usual course of business or to demonstrate compliance. Comments. A number of commenters expressed concerns regarding the proposed deadlines for complying with the requirements. Several commenters stated that the requirement to notify customers and others with whom the developer has contracts or agreements within six months was too long and recommended that the deadline be shortened. Regarding the deadline for amending contracts/agreements that contravene the Communications Condition of Certification requirements, most commenters stated that the deadline was too short, with several requesting that it be extended to five years. Some other commenters recommended that modification of any contracts/agreements to comply with the Communications Condition of Certification requirements should occur whenever such contracts/agreements are renewed, or at the earliest available time, without the need for a specific deadline. A couple of commenters recommended that a health IT developer not be held responsible for amending contracts within two years of the effective date of the final rule if it has made reasonable efforts to do so. Several comments recommended that ONC should allow alternative means of completing this requirement, such as posting relevant language on the developer’s website. One commenter stated that it would be helpful to have a ‘‘standard exception clause’’ that developers could use in their contracts and agreements. Response. We appreciate the comments we received on this provision. We clarify in § 170.403(b)(2)(i) that a developer may not include provisions that contravene the Communications Condition of Certification requirements in any new contract as of the effective date of the final rule. In consideration of comments, we have decided to modify the timeframe requirement proposed in PO 00000 Frm 00098 Fmt 4701 Sfmt 4700 84 FR 7476 for amending contracts/ agreements to be in compliance with this condition. While we considered extending the deadline to five years to allow developers to have additional time for compliance, we determined that a more flexible solution is appropriate. As such, we have modified the requirement in § 170.405(b)(2)(ii) to state that any contracts/agreements in place as of the effective date of the final rule and containing language in contravention of the Communications Condition of Certification requirements must be revised to remove or void the contractual provision that contravenes the Communications Condition of Certification requirements whenever the contract is next modified for any reason. We clarify that where a contract automatically renews, the developer would still be prohibited under the Program from enforcing any agreement or contract provisions that contravene the Communications Condition of Certification requirements in § 170.403(a) and the developer would also be responsible for sending an annual notice as described above until such provisions have been modified. To note, we decline to absolve a developer of the requirement to modify the contract solely because the developer has made a reasonable effort to do so. We finalized the notification requirements proposed in 84 FR 7476. A health IT developer must notify all entities and individuals with which it has a contract/agreement related to certified health IT that any communication or contract/agreement provision that contravenes the Communications Condition of Certification requirements will not be enforced by the health IT developer. However, we no longer require that such notification must occur within six months of the effective date of the final rule and annually thereafter until contravening provisions are amended. Instead, notification must only occur annually, beginning in calendar year 2020, and continue until all contravening provisions are amended. Given the timing of the publication of the final rule, health IT developers could have potentially been required to provide both initial notification and an annual notification in the same calendar year. We believe the removal of the six months notification deadline and retention of an annual requirement only, beginning with notification in calendar year 2020, will simplify compliance for health IT developers while still providing adequate notice and ensuring that initial notification is provided in a reasonable amount of time. Therefore E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations we have finalized the deadline for the notice requirement in § 170.403(b)(1) to be annually, beginning in calendar year 2020. Comments. Several commenters requested clarification that once the final rule goes into effect, contravening provisions in developer contracts prohibiting communications cannot be enforced. One of these commenters stated that developers would often include language in their contracts prohibiting communication on the part of end users and entities, thus preventing communication about issues with EHRs. Several commenters requested that ONC explicitly state that any permitted communication made following the effective date of the final rule be inadmissible as a violation of a contract/agreement regardless of whether the customer has been notified. One commenter requested that ONC clarify that, with respect to protecting communications regarding developer business practices, where the disclosure of certain information is prohibited by contract, the developer would not be liable for its inability to communicate such information. Response. We emphasize that as of the effective date of the final rule, contravening provisions in contracts or agreements cannot be enforced without the risk of losing certification for the developer’s health IT or a certification ban for the developer under the Program, regardless of whether the customer was notified as required by the Communications Condition of Certification requirements. We clarify that provisions of contracts requiring that the health IT customer ‘‘flowdown’’ obligations onto the customer’s employees, contractors, and other users of the health IT that would restrict protected communications would be in contravention of this Condition of Certification. Such provisions could not be enforced after the effective date of the final rule without risking loss of certification as noted above for the developer under the Program. We appreciate commenters’ concern regarding disclosing information that may be otherwise prohibited by contract. However, we clarify that the purpose of the Communications Condition of Certification requirements is to prevent developers from improperly restricting protected communications, including communications about a developer’s practices and policies related to facilitating the exchange of health information. As discussed earlier in this section, costs, timeframes, licensing practices and terms, as well as the developer’s approach to working with VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 third-party services, could all be considered protected communications to the extent they relate to facilitating the exchange of health information. Thus, we reiterate that where a contract entered into by the developer would restrict a communication protected by the Communications Condition of Certification requirements, the developer may not enforce such a contract and may not restrict a protected communication in violation of the Communications Condition of Certification requirements after the effective date of the final rule without risking loss of certification. It is also important to note that not all contractual provisions related to communications would create a risk of de-certification. As noted above, the Communications Condition of Certification requirements in § 170.403(a)(2)(ii) do allow for developers to place restrictions on certain communications as discussed above. Therefore, contractual provisions that appropriately address those allowances would not create a risk of de-certification under the Program. Comments. One commenter suggested that ‘‘renew’’ should be added to the maintenance requirement to not establish or enforce any contract or agreement that contravenes the Communications Condition of Certification requirements in § 170.403(a). Response. We appreciate this comment and amended the proposed regulatory text in § 170.403(b)(2)(i) to include ‘‘renew.’’ We clarify that where a contract auto-renews, the developer would still be prohibited under the Program from enforcing any agreement or contract provisions that contravene the Communications Condition of Certification requirements without risking loss of certification and would also be responsible for sending an annual notice as described above until such provisions have been modified. Comments. A couple of commenters expressed concern about developer efforts to re-negotiate other terms of a contract that are unrelated to protected communications as part of the contract modification process. Response. We stress that the contract modifications required as part of the Communications Condition of Certification requirements are strictly limited to removing any provisions of the relevant contract/agreement that would restrict protected communications in contravention of the Communications Condition of Certification requirements and are not required to be done until the contract/ PO 00000 Frm 00099 Fmt 4701 Sfmt 4700 25739 agreement is modified for other purposes. 4. Application Programming Interfaces The API Condition of Certification requirement in Section 4002 of the Cures Act requires health IT developers to publish APIs that allow ‘‘health information from such technology to be accessed, exchanged, and used without special effort through the use of APIs or successor technology or standards, as provided for under applicable law.’’ The requirement also states that a developer must, through an API, ‘‘provide access to all data elements of a patient’s electronic health record to the extent permissible under applicable privacy laws.’’ Additionally, the API Condition of Certification requirement of the Cures Act includes several key phrases and requirements for health IT developers that go beyond the technical functionality of the Health IT Modules they present for certification. In this section of the preamble, we outline the proposals we have adopted to implement the API Condition of Certification requirement of the Cures Act to provide compliance clarity for health IT developers. We have adopted new standards, new implementation specifications, a new certification criterion, Condition and Maintenance of Certification requirements, and modified the Base EHR definition. Health IT developers should consider these final requirements in the context of information blocking provisions described in section VIII of this preamble. a. Statutory Interpretation and API Policy Principles Section 4002 of the Cures Act requires health IT developers certified to the Program to publish APIs that allow ‘‘health information from such technology to be accessed, exchanged, and used without special effort through the use of APIs or successor technology or standards, as provided for under applicable law.’’ To implement the Cures Act API requirements, we proposed a new 2015 Edition Cures Update ‘‘API’’ certification criterion at 84 FR 7476 that included requirements for an API to have ‘‘read’’ capabilities that support two types of services: (1) Services for which a single patient’s data is the focus; and (2) services for which multiple patients’ data are the focus. We conveyed in the Proposed Rule our belief that ‘‘without special effort’’ requires APIs and the health care ecosystem in which they are deployed to be standardized, transparent, and pro- E:\FR\FM\01MYR3.SGM 01MYR3 25740 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations § 170.215(a)(1) and finalized its use in § 170.315(g)(10). competitive. Therefore, we noted that any Health IT Module certified to the new 2015 Edition Cures Update API criterion and a health IT developer’s business practices would have to have these attributes. b. API Standards and Implementation Specifications i. Base Standard We proposed in § 170.215(a)(1) at 84 FR 7477 to adopt HL7® FHIR® Draft Standard for Trial Use (DSTU) 2 for reference in the criterion proposed in § 170.315(g)(10). Additionally, we requested comment in 84 FR 7478 and 7479 on four options to determine the best version of HL7 FHIR to reference for use in § 170.315(g)(10): Option 1: FHIR DSTU 2, Option 2: FHIR DSTU 2 and FHIR Release 3, Option 3: FHIR DSTU 2 and FHIR Release 4, and Option 4: FHIR Release 4 only. We requested commenters review the proposed certification criterion in § 170.315(g)(10) and the accompanying Condition of Certification requirements attributed to the API certification criteria. Notably, we stated in the Proposed Rule at 84 FR 7479 that if we adopted another FHIR Release in a final rule as an alternative to FHIR Release 2 for the proposed API criterion in § 170.315(g)(10), then we would also adopt the applicable implementation specifications associated with the FHIR Release. Comments. We received overwhelming support for Option 4: Adopt solely FHIR Release 4 in the final rule for reference in § 170.315(g)(10). We received support for the adoption of FHIR Release 4 across a broad array of stakeholders, including health IT developers, medical trade associations, software application developers, and payers. Commenters noted that FHIR Release 4 is the first FHIR release with normative FHIR resources and support for enhanced capabilities. Most commenters emphasized that Option 4 will allow the industry to unify and focus on a single baseline standard, rather than accommodating multiple releases proposed in Options 2 and 3. A minority of commenters suggested alternative or multiple versions, noting this would allow for flexibility, but the vast majority of commenters supported the adoption of FHIR Release 4 only. Response. We appreciate the feedback and agree with commenters that adoption of a single standard is the best option to align industry and enable widespread interoperability. We have adopted the latest version of the standard at the time of this final rule publication (FHIR Release 4.0.1) in VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 ii. United States Core Data for Interoperability We proposed in § 170.215(a)(2) at 84 FR 7479 to adopt the API Resource Collection in Health (ARCH) Version 1 implementation specification, which listed a set of base HL7® FHIR® resources that Health IT Modules certified to the proposed criterion in § 170.315(g)(10) would need to support. Comments. Most commenters were opposed to the adoption of the ARCH in the final rule. Commenters argued for the use of American National Standards Institute accredited standards, and suggested ONC work with standards developing organizations for standards development and maintenance. Several commenters noted that the ARCH has not gone through a formal balloting process, did not support ONC’s proposal to rely upon the National Technology Transfer and Advancement Act’s exception to adopt the ARCH in the final rule, and encouraged the use of technical standards developed or adopted by voluntary consensus standards bodies. Several commenters noted that requiring the ARCH in addition to the other adopted standards could create confusion. Commenters further emphasized the importance of maintaining ongoing consistency between the ARCH and the other adopted standards, and noted this would be challenging to achieve. Additional comments against the ARCH expressed concern with the proposed updates through the Standards Version Advancement Process, and with ONC over-regulating API functionality. Commenters also noted that ONC could encourage API access to specific data elements without creating a new implementation specification. Some commenters in favor of the ARCH implementation specification asked for data element revisions. Commenters also asked for clarity that EHRs will not need to provide the full set of data to modular applications, and asked for specificity on how much of this data would need to be mapped by the API Technology Supplier. Additionally, commenters asked for guidance on lab results, including application creation implementation guides that would ensure accuracy and compliance when incorporating lab data. Response. In response to commenters, we did not adopt the ARCH as an implementation specification in the final rule. Upon consideration of public comments and in an effort to PO 00000 Frm 00100 Fmt 4701 Sfmt 4700 consistently approach how we reference the United States Core Data for Interoperability (USCDI) with various content standards (e.g., C–CDA), we determined that having an implementation specification to map USCDI to HL7 FHIR could create more restrictions than we intended. We appreciate the concerns raised by stakeholders, and as we evaluated the ARCH in context of our other proposals, we determined that we could achieve our desired policy outcome to link the USCDI Data Elements to FHIR Resources without the ARCH. We refer commenters to the sections that follow for further clarity regarding the implementation of Data Elements included in the USCDI implementation specification (IV.B.1). iii. US Core IG and Bulk IG We proposed in 84 FR 7480 in § 170.215(a)(3) to adopt the Argonaut Data Query Implementation Guide version 1 (Argonaut IG) implementation specification, which specifies constraints for 13 of the HL7® FHIR® resources proposed in § 170.215(a)(2). Additionally, we proposed in § 170.215(a)(4) to adopt the Argonaut Data Query Implementation Guide Server implementation specification. Comments. Several commenters advocated for the adoption of the FHIR US Core Implementation Guide STU 3 Release 3.0.0 implementation specification instead of the Argonaut Implementation Guides. Commenters noted that the US Core Implementation Guide was built from the Argonaut Implementation Guides and has been balloted by the standards community. Response. We thank commenters for their feedback. We note that in the Proposed Rule at 84 FR 7479 we stated that if we were to adopt another FHIR Release in the final rule as an alternative to FHIR Release 2, then we would also adopt the applicable implementation specifications and FHIR profiles associated with the FHIR Release. Considering this and commenters’ recommendations, we have adopted the HL7 FHIR US Core Implementation Guide STU 3.1.0 (US Core IG) implementation specification in § 170.215(a)(2). We note that we adopted the latest version of the US Core IG at the time of the final rule publication. The US Core IG defines the minimum conformance requirements for accessing patient data using FHIR Release 4 (adopted in § 170.215(a)(1)), including profiled resources, operations, and search parameters for the Data Elements required in the USCDI implementation specification (adopted in § 170.213). E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations We note that in the Proposed Rule at 84 FR 7479 we proposed to require that the ‘‘Patient.address’’ and ‘‘Patient.telecom’’ elements of the ‘‘Patient’’ resource must be supported. We note these requirements have since been subsumed by the US Core IG, given that ‘‘Patient.address’’ and ‘‘Patient.telecom’’ elements are both flagged ‘‘must support’’ for the ‘‘Patient’’ profile in the US Core IG. We also proposed to require that the ‘‘Device.udi’’ element follow the human readable representation of the unique device identifier found in the recommendation, guidance, and conformance requirements section of the ‘‘HL7 Version 3 Cross Paradigm Implementation Guide: Medical Devices and Unique Device Identification Pattern, Release 1.’’ These requirements have also been subsumed by the US Core IG. Additional information can be found in the ‘‘Device’’ profile of the US Core IG adopted in § 170.215(a)(2). We note that in the Proposed Rule we proposed in 84 FR 7480 that the clinical note text included in the ‘‘DocumentReference’’ resource would need to be represented in its ‘‘raw’’ text form, and further proposed in 84 FR 7480 that it would be unacceptable for the note text to be converted to another file or format (e.g., .docx, PDF) when it is provided as part of an API response. We clarify that the clinical note text included in any of the notes described in the ‘‘Clinical Notes Guidance’’ section of the US Core IG adopted in § 170.215(a)(2) must be represented in a ‘‘plain text’’ form, and would be unacceptable for the note text to be converted to another file or format (e.g., .docx, PDF) when it is provided as part of an API response. We note that in the Proposed Rule we proposed in 84 FR 7480 to require that the ‘‘Provenance.recorded’’ and ‘‘Provenance.agent.actor’’ elements of the ‘‘Provenance’’ resource must be supported. We note these requirements have been subsumed by the US Core IG, given that ‘‘Provenance.recorded’’ and ‘‘Provenance.agent.who’’ elements are both flagged ‘‘must support’’ for the ‘‘Provenance’’ profile in the US Core IG. As addressed under the header ‘‘Standardized API for Patient and Population Services’’ in the section V.B.4.c, we have finalized the adoption of the HL7 FHIR Bulk Data Access (Flat FHIR) (v1.0.0: STU 1) implementation specification (Bulk IG), including mandatory support for the ‘‘groupexport’’ ‘‘OperationDefinition’’ in § 170.215(a)(4). VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 iv. HL7 SMART IG and Backend Services Authorization We proposed in 84 FR 7481 in § 170.215(a)(5) to adopt the HL7® SMART Application Launch Framework Implementation Guide Release 1.0.0 implementation specification, a profile of the OAuth 2.0 specification. Comments. Most commenters expressed support for the HL7 SMART Application Launch Framework Implementation Guide Release 1.0.0 (SMART IG) implementation specification. Multiple commenters suggested that in addition to requiring support for ‘‘refresh tokens,’’ ‘‘Standalone Launch,’’ and ‘‘EHR Launch’’ capabilities from the SMART IG, ONC also require support for ‘‘ssoopenid-connect,’’ ‘‘launch-standalone,’’ ‘‘launch-ehr,’’ ‘‘client-public,’’ ‘‘clientconfidentialsymmetric,’’ ‘‘context-ehrpatient,’’ ‘‘context-standalone-patient,’’ ‘‘permission-patient,’’ ‘‘permissionuser,’’ and ‘‘permission-offline’’ capabilities. Response. We thank stakeholders for their comments. The ten optional capabilities commenters suggested are included in the ‘‘SMART on FHIR Core Capabilities’’ section of the SMART IG. The ‘‘SMART on FHIR Core Capabilities’’ suggested by commenters include ‘‘sso-openid-connect,’’ which allows for support of the OpenID Connect profile in the SMART IG; ‘‘client-public’’ and ‘‘client-confidentialsymmetric,’’ which allow for client authentication; ‘‘context-ehr-patient’’ and ‘‘context-standalone-patient,’’ which provide context to apps at launch time; and ‘‘permission-patient,’’ ‘‘permission-user,’’ and ‘‘permissionoffline,’’ which allow support for patient-level scopes, user-level scopes, and refresh tokens, respectively. Other ‘‘SMART on FHIR Core Capabilities’’ that were not suggested by commenters include ‘‘context-banner’’ and ‘‘contextstyle,’’ which provide basic context to apps at launch time, and ’’context-ehrencounter’’ and ‘‘context-standaloneencounter,’’ which provide encounterlevel granularity to apps at launch time. Given the importance of these ‘‘SMART on FHIR Core Capabilities,’’ and in consideration of public comments and our own research, we have adopted the SMART IG, including mandatory support for the ‘‘SMART on FHIR Core Capabilities’’ in § 170.215(a)(3). We explicitly require mandatory support of the ‘‘SMART on FHIR Core Capabilities’’ in § 170.215(a)(3) because these capabilities are indicated as optional in the implementation specification. We further clarify these ‘‘SMART on FHIR Core Capabilities’’ are PO 00000 Frm 00101 Fmt 4701 Sfmt 4700 25741 in scope for Program testing and certification. Additionally, we clarify that by requiring the ‘‘permissionpatient’’ ‘‘SMART on FHIR Core Capability’’ in § 170.215(a)(3), Health IT Modules presented for testing and certification must include the ability for patients to authorize an application to receive their EHI based on FHIR resource-level scopes. Specifically, this means patients would need to have the ability to authorize access to their EHI at the individual FHIR resource level, from one specific FHIR resource (e.g., ‘‘Immunization’’) up to all FHIR resources necessary to implement the standard adopted in § 170.213 and implementation specification adopted in § 170.215(a)(2). This capability will give patients increased control over how much EHI they authorize applications of their choice to receive. For example, if a patient downloaded a medication management application, they would be able to use these authorization scopes to limit the EHI accessible by the application to only information contained in FHIR ‘‘MedicationRequest’’ and ‘‘Medication’’ profile. Comments. Some commenters noted concerns for privacy and security of APIs. Specifically, one commenter explained the threat of cross-site request forgery (CSRF), and suggested we take action to mitigate that risk, including by requiring the use of both OAuth 2.0 and OpenID Connect Core 1.0. Response. We appreciate the concerns expressed by commenters regarding the privacy and security of APIs. The OAuth 2.0 standard defined at Request For Comment (RFC) 6749 101 describes that ‘‘[The OAuth 2.0 authorization] framework was designed with the clear expectation that future work will define prescriptive profiles and extensions necessary to achieve full web-scale interoperability.’’ The SMART IG serves as a ‘‘prescriptive profile’’ as described in RFC 6749. Thus, consistent with commenters’ recommendations, we have adopted a profile of the OAuth 2.0 standard (SMART IG) in § 170.215(a)(3). Additionally, we have adopted OpenID Connect Core 1.0 incorporating errata set 1 in § 170.215(b), and require conformance with the relevant parts of this standard as part of testing and certification. CSRF is a welldocumented security threat in OAuth 2.0, which can be prevented with adequate security practices. We encourage implementers to adhere to industry best practices to mitigate CSRF and other known security threats. Relatedly, we note that the HL7 community has developed an 101 https://tools.ietf.org/html/rfc6749. E:\FR\FM\01MYR3.SGM 01MYR3 25742 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations ‘‘Implementer’s Safety Check List,’’ 102 a guide of security best practices for implementing FHIR-based APIs. We encourage stakeholders to consult this guide during development and implementation of § 170.315(g)(10)certified Health IT Modules to minimize security risks. For backend services authorization, as addressed under the header ‘‘Standardized API for Patient and Population Services’’ in the section V.B.4.c, we have finalized the adoption of the HL7 FHIR Bulk Data Access (Flat FHIR) (v1.0.0: STU 1) implementation specification (Bulk IG), which includes the ‘‘Backend Services Authorization Guide’’ in § 170.215(a)(4). v. OpenID Connect We proposed in 84 FR 7480 through 7481 in § 170.215(b) to adopt OpenID Connect Core 1.0 including errata set 1. Comments. We received few comments regarding the adoption of OpenID Connect Core 1.0 including errata set 1, however, commenters generally supported the adoption of this standard. Response. We thank commenters for their feedback. Given their support, we have finalized the adoption of OpenID Connect Core 1.0 including errata set 1 as proposed in § 170.215(b). We clarify that only the relevant parts of the OpenID Connect Core 1.0 including errata set 1 adopted in § 170.215(b) that are also included in the implementation specification adopted in § 170.215(a)(3) will be in-scope for testing and certification. c. Standardized API for Patient and Population Services We proposed in 84 FR 7481 to adopt a new certification criterion, § 170.315(g)(10), to replace § 170.315(g)(8), and we proposed in 84 FR 7495 to update the 2015 Edition Base EHR definition, as referenced in § 170.102. The proposed certification criterion would require Health IT Modules to support API-enabled ‘‘read’’ services for single and multiple patients. ‘‘Read’’ services include those that allow authenticated and authorized third-party applications to view EHI through a secure API. These services specifically exclude ‘‘write’’ capabilities, where authenticated and authorized third-party applications would be able to create or modify EHI through a secure API. Comments. Commenters supported the proposed adoption of a new certification criterion, § 170.315(g)(10), to replace § 170.315(g)(8). 102 https://www.hl7.org/FHIR/safety.html. VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 Response. We appreciate the support from commenters. As a result, we have adopted a new certification criterion in § 170.315(g)(10), to replace § 170.315(g)(8) and made several revisions to address public comment as discussed further below. Although the certification criteria finalized at § 170.315(g)(10) will replace § 170.315(g)(8), we note that § 170.315(g)(8) is not removed from regulation. We maintain § 170.315(g)(8) and have finalized in § 170.550(m) that ONC–ACBs can issue certificates for § 170.315(g)(8) during the transition period to § 170.315(g)(10) for 24 months after the publication date of the final rule. Comments. Commenters suggested dividing the § 170.315(g)(10) criterion into two separate criteria for single and multiple patients. Response. We appreciate the feedback. We decline to split the certification criterion into two criteria. In consideration of comments and for clarity, we have improved the organization of the final certification requirements for API-enabled ‘‘read’’ services for single and multiple patients by separating the criterion into distinct sections in the regulation text. Comments. Several commenters supported referencing a standard for API-enabled ‘‘read’’ services for multiple patients, including the HL7® FHIR® Bulk Data Access Implementation Guide Release 1.0.0. Commenters felt that omitting a standard in the criterion would undermine interoperability for APIenabled ‘‘read’’ services for multiple patients. Response. We thank commenters for their feedback. To enable consistent health IT implementation of APIenabled ‘‘read’’ services for multiple patients, we have finalized the adoption of the Bulk IG, including mandatory support for the ‘‘group-export’’ ‘‘OperationDefinition’’ in § 170.215(a)(4). As part of the Program, we require Health IT Modules presented for testing and certification to conform to the Bulk IG implementation specification finalized in § 170.215(a)(4). The adoption of an implementation specification for APIenabled ‘‘read’’ services for multiple patients in § 170.215(a)(4) is responsive to stakeholder concerns and further supports our intent to prevent ‘‘special effort’’ for the use of APIs as mandated in section 4002 of the Cures Act. Furthermore, based on our analysis, we believe the ‘‘group-export’’ ‘‘OperationDefinition,’’ as defined in the Bulk IG implementation specification is essential to fulfill the use cases PO 00000 Frm 00102 Fmt 4701 Sfmt 4700 envisioned for API-enabled ‘‘read’’ services for multiple patients. The ‘‘group-export’’ ‘‘OperationDefinition’’ will allow application developers interacting with § 170.315(g)(10)certified Health IT Modules to export the complete set of FHIR resources as constrained by the US Core IG adopted in § 170.215(a)(2) and USCDI adopted in § 170.213 for a pre-defined cohort of patients. We appreciate commenters’ recommendations, and agree that coalescing around a common implementation specification will advance interoperability of API-enabled ‘‘read’’ services for multiple patients. We provide further discussion of the supported search operations, data response, and authentication and authorization requirements for APIenabled ‘‘read’’ services for multiple patients in the sections below. Comments. Commenters requested clarification that API-enabled ‘‘read’’ services for multiple patients are not intended for patient end users and that health IT developers and health care providers are therefore not expected to supply a patient-facing mechanism for these requests. Response. We appreciate the feedback from commenters. API-enabled ‘‘read’’ services for multiple patients are not intended for patient end users because API-enabled ‘‘read’’ services for multiple patients allow for the disclosure of multiple patients’ records, and individual patients only have the right to access their own records or records of patients to whom they are the personal representative (45 CFR 164.502(f)(1)). Health IT Modules are not required to support patient-facing API-enabled ‘‘read’’ services for multiple patients for the purposes of this certification criterion. Comments. One commenter suggested we modify the language that defines the purpose of this section to provide more clarity, specifically the term ‘‘services.’’ The commenter also requested we include the scope of cohorts we intended to address in ‘‘population services.’’ Response. We appreciate the feedback from commenters. The term ‘‘services’’ includes all § 170.315(g)(10)-related technical capabilities included in a Health IT Module presented for testing and certification. The API-enabled ‘‘read’’ services for single patients is intended to support EHI requests and responses for individual patient records and the API-enabled ‘‘read’’ services for multiple patients is intended to support EHI requests and responses for multiple patients’ records. The scope of patient cohorts for ‘‘population services’’ can include various groups defined at the E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations discretion of the user of the API-enabled ‘‘read’’ services for multiple patients, including, for example, a group of patients that meet certain disease criteria or fall under a certain insurance plan. We have adopted the Bulk IG in § 170.215(a)(4) to support this function as discussed further below. The technical capabilities expected of APIrelated Health IT Modules presented for testing and certification are included in § 170.315(g)(10). Comments. Commenters requested clarification for information blocking policies and health care provider obligations for API-enabled ‘‘read’’ services for multiple patients. Response. We appreciate the request for clarification from commenters. We clarify that the criteria finalized in § 170.315(g)(10) includes the technical capabilities that must be met by APIrelated Health IT Modules presented for testing and certification. The information blocking policies in this rule do not compel health care providers to implement Health IT Modules certified to requirements in 170.315(g)(10). We note that other programs, like CMS value-based programs, may require the use of this technology. We refer commenters to the information blocking section (VIII) for additional clarification. Comments. Commenters asked us to clarify the relationship between the APIenabled ‘‘read’’ services for single and multiple patients in § 170.315(g)(10) and the ‘‘EHI export’’ criterion in § 170.315(b)(10). Response. We thank commenters for this request. The API criterion in § 170.315(g)(10) is separate from the ‘‘EHI export’’ criterion in § 170.315(b)(10). While both criteria aim to advance health IT in alignment with the Cures Act’s goal of ‘‘complete access, exchange, and use of all electronically accessible health information’’ for both single and multiple patients, the criteria specifications and Condition and Maintenance of Certification requirements are distinct. The ‘‘EHI export’’ criterion focuses on a Health IT Module’s ability to electronically export EHI, as defined in § 171.102, that can be stored at the time of certification by the product, of which the Health IT Module is a part. In contrast, the finalized API criterion in § 170.315(g)(10) focuses on ‘‘read’’ services for single and multiple patients for the USCDI (adopted in § 170.213) Data Elements and US Core IG (adopted in § 170.215(a)(2)) FHIR profiles. Additionally, the ‘‘EHI export’’ criterion finalized in § 170.315(b)(10) does not mandate conformance to standards or VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 implementation specifications, whereas the criterion finalized in § 170.315(g)(10) requires conformance to several standards and implementation specifications, as described further below. We refer to the finalized ‘‘EHI export’’ criterion in § 170.315(b)(10) for additional information. Comments. Several commenters supported requiring Health IT Modules to support API-enabled ‘‘write’’ services for single patients, either in this rule or in a future rulemaking. One commenter suggested including a subset of data classes for ‘‘write’’ services for single patients, including ‘‘patient goals,’’ ‘‘patient-generated health data’’ (including patient-reported outcomes, patient generated device data, and questionnaires), and ‘‘care plans.’’ Another commenter suggested adding a list of required operations (‘‘read’’ and ‘‘write’’) to USCDI elements, limited to ‘‘read’’ for this rulemaking. Response. We appreciate the feedback from commenters. While we support the interest in API-enabled ‘‘write’’ services, we have not adopted such requirements. We do not believe API-enabled ‘‘write’’ services have reached a level of a maturity to warrant the addition of regulatory conformance requirements within the Program. We encourage industry to consider all the implications and implementation requirements for API-enabled ‘‘write’’ services, and perform additional API-enabled ‘‘write’’ pilot implementations to demonstrate the readiness for API-enabled ‘‘write’’ services in the testing and certification of Health IT Modules. Additionally, we encourage industry to expand existing profiles like the US Core IG to support ‘‘write’’ services. Comments. Commenters recommended including a requirement for event logging for ‘‘read’’ services for single and multiple patients. Response. We appreciate the recommendation from commenters. The 2015 Edition Privacy and Security Certification Framework requires that if a Health IT Module includes capabilities for certification under § 170.315(g)(10) it needs to be certified to several privacy and security certification criteria including auditable events in § 170.315(d)(2) or auditing actions on health information in § 170.315(d)(10). Comments. Commenters noted that references to APIs focus exclusively on RESTful query and ignore ‘‘push’’ elements of the FHIR API, such as ‘‘POST,’’ ‘‘PUT,’’ and FHIR messaging. Response. We appreciate the feedback from commenters. While we support the interest in the ‘‘push’’ operations of the FHIR standard, including ‘‘POST,’’ PO 00000 Frm 00103 Fmt 4701 Sfmt 4700 25743 ‘‘PUT,’’ and FHIR messaging, we have not adopted such requirements for the Program. We encourage industry stakeholders to further consider all the requirements and implications for the ‘‘push’’ operations of the FHIR standard, develop use cases, perform additional API-enabled ‘‘push’’ pilot implementations, create or expand implementation profiles to support ‘‘push’’ services, and demonstrate the utility of the ‘‘push’’ operations of the FHIR standard for future potential inclusion in the Program. i. Data Response We proposed in 84 FR 7482 in § 170.315(g)(10)(i) that Health IT Modules presented for testing and certification must be capable of responding to requests for data on single and multiple patients in accordance with proposed standards and implementation specifications adopted in § 170.215(a)(1) (HL7® FHIR® DSTU 2 (v1.0.2–7202)), specified in the proposed § 170.215(a)(2) (API Resource Collection in Health (ARCH) Version 1), and consistent with the proposed specifications in § 170.215(a)(3) (Argonaut Data Query Implementation Guide Version 1.0.0). We clarified that all data elements indicated as ‘‘mandatory’’ and ‘‘must support’’ by the proposed standards and implementation specifications must be supported and would be in scope for testing. Comments. Commenters expressed concern with fully enforcing ‘‘mandatory’’ and ‘‘must’’ support requirements of the referenced specifications and implementation guides, explaining that developers may be required to support requirements that are not applicable to the stated intended use of the Health IT Module(s). Response. We appreciate the concerns expressed by commenters. We clarify that the standards and implementation specifications adopted and required for this certification criterion were created by standards developing organizations to support a wide range of health care use cases. We have finalized in § 170.315(g)(10)(i)(A) that Health IT Modules presented for testing and certification must be capable of responding to requests for a single patient’s data according to the standard adopted in § 170.215(a)(1) and implementation specification adopted in § 170.215(a)(2), including the mandatory capabilities described in ‘‘US Core Server CapabilityStatement,’’ for each of the Data Elements included in the standard adopted in § 170.213. This requirement will enable Health IT Modules to support US Core IG E:\FR\FM\01MYR3.SGM 01MYR3 25744 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations operations for each of the Data Elements included in the USCDI. Additionally, we have finalized in § 170.315(g)(10)(i)(B) that Health IT Modules presented for testing and certification must be capable of responding to requests for data on multiple patients as a group according to the standard adopted in § 170.215(a)(1) and implementation specifications adopted in § 170.215(a)(2) and § 170.215(a)(4), for each of the Data Elements included in the standard adopted in § 170.213. Finally, we clarify that the use of the ‘‘SMART Backend Services: Authorization Guide’’ section of the implementation specification adopted in § 170.215(a)(4) is required for API ‘‘read’’ services for multiple patients as finalized in § 170.315(g)(10)(i)(B) and described above. For requests for data on multiple patients, we note that the implementation specification adopted in § 170.215(a)(4) has optional parameters which can be used to filter results to a period of time, or one or several specified FHIR resources. While these parameters are not required for testing and certification, we encourage health IT developers to adopt these parameters and other ‘‘OperationDefinitions’’ to enhance the utility of requests for data on multiple patients. ii. Search Support We proposed in 84 FR 7482 in § 170.315(g)(10)(ii) that Health IT Modules presented for testing and certification must be capable of responding to all of the ‘‘supported searches’’ specified in the proposed implementation specification in § 170.215(a)(4) (Argonaut Data Query Implementation Guide Server). We reiterated that Health IT Modules presented for testing and certification and as implemented must support all search capabilities for single and multiple patients in accordance with the proposed implementation specification in § 170.215(a)(4). We also requested comments on the minimum ‘‘search’’ parameters that would need to be supported for the ’’DocumentReference’’ and ‘‘Provenance’’ HL7® FHIR® resources. Comments. Most commenters supported this proposal. One commenter recommended only requiring the ‘‘target’’ query parameter for the ‘‘Provenance’’ FHIR resource, and ‘‘patient’’ and ‘‘date’’ query parameters for the ‘‘DocumentReference’’ FHIR resource. One commenter suggested deferring this VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 certification requirement until a standard is published by HL7. Response. We appreciate the feedback from commenters. Since we have not finalized the adoption of the ARCH as proposed in § 170.215(a)(2), and instead rely on the search parameters specified in the US Core IG finalized in § 170.215(a)(2) and Bulk IG finalized in § 170.215(a)(4), the comments related to the specific ‘‘Provenance’’ and ‘‘DocumentReference’’ FHIR resources are no longer applicable. We have finalized in § 170.315(g)(10)(ii)(A) that Health IT Modules presented for testing and certification must support all search capabilities for single patients according to the implementation specification adopted in § 170.215(a)(2), including support for all mandatory capabilities included in the ‘‘US Core Server CapabilityStatement.’’ Additionally, we have finalized in § 170.315(g)(10)(ii)(B) that Health IT Modules presented for testing and certification must respond to search requests for multiple patients’ data consistent with the search criteria included in the implementation specification adopted in § 170.215(a)(4). We clarify that the scope of data available in the data responses defined in § 170.315(g)(10)(i) must be supported for single and multiple patient searches via the supported search operations finalized in § 170.315(g)(10)(ii). Additionally, we clarify for the requirements finalized in § 170.315(g)(10)(i) and (ii) that all data elements indicated as ‘‘mandatory,’’ ‘‘must support,’’ by the standards and implementation specifications must be supported and are in scope for testing. iii. Application Registration We proposed in 84 FR 7483 in § 170.315(g)(10)(iii) that Health IT Modules presented for testing and certification must be capable of enabling apps to register with an ‘‘authorization server.’’ As proposed, this would have required an API Technology Supplier to demonstrate its registration process, but would not have required conformance to a standard. We requested comment at 84 FR 7483 on whether to require the OAuth 2.0 Dynamic Client Registration Protocol (RFC 7591) 103 standard as the sole method to support registration for the proposed certification criterion in § 170.315(g)(10), and requested comment on whether we should require its support as part of the final rule’s certification criterion. Additionally, we requested comment at 84 FR 7483 on whether to include application registration in the testing and certification of apps executed within an 103 https://tools.ietf.org/html/rfc7591. PO 00000 Frm 00104 Fmt 4701 Sfmt 4700 API Data Provider’s clinical environment. Comments. Commenters generally supported that Health IT Modules presented for testing and certification must enable apps to register with an authorization server. Some commenters supported excluding application registration from the testing and certification of apps executed within an API Data Provider’s clinical environment. Response. We appreciate the feedback from commenters. Given the overwhelming support, we have finalized in § 170.315(g)(10)(iii) that Health IT Modules presented for testing and certification must enable apps to register with an authorization server. We clarify that Health IT Modules presented for testing and certification must support application registration regardless of the scope of patient search utilized by the application (e.g., single or multiple). This certification criterion requires a health IT developer, as finalized in the Condition of Certification requirements section below, to demonstrate its registration process, but does not require conformance to a standard. Additionally, we expect that apps executed within an implementer’s clinical environment will be registered with an authorization server, but we do not require a health IT developer to demonstrate its registration process for these ‘‘provider-facing’’ apps. We reiterate that we believe implementers of § 170.315(g)(10)-certified Health IT Modules should have the discretion to innovate and execute various methods for application registration within a clinical environment. Comments. Commenters provided a mix of support and opposition for requiring the OAuth 2.0 Dynamic Client Registration Protocol (RFC 7591) standard as the sole method of application registration. Some commenters felt that the Program should require dynamic client registration in the context of patientaccess scenarios only, and others felt the standard is not ready for mandated adoption in the Program. Commenters opposed to requiring the OAuth 2.0 Dynamic Client Registration Protocol (RFC 7591) felt that not specifying a standard would allow flexibility for different innovative registration approaches to be used and developed. Other commenters suggested there should be an option for data holders to support dynamic client application registration if the data holder prefers that approach, including support for dynamic application registration via trusted networks. E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations Response. We appreciate the feedback from commenters. We have not adopted a requirement for Health IT Modules presented for testing and certification to support the OAuth 2.0 Dynamic Client Registration Protocol (RFC 7591) standard. We agree with commenters and believe that requiring registration without a mandated standard will allow registration models to develop further. We encourage health IT developers to coalesce around the development and implementation of a common standard for application registration with an API’s authorization server. Comments. Commenters suggested permitting implementers of § 170.315(g)(10)-certified Health IT Modules to undertake a review of thirdparty applications prior to permitting them to connect to the implementers’ deployed APIs. Response. We appreciate the suggestion from commenters. The requirement that health IT developers must enable an application to register with the § 170.315(g)(10)-certified Health IT Module’s authorization server only applies for the purposes of demonstrating technical conformance to the finalized certification criterion and Condition and Maintenance of Certification requirements. The practices by all parties (including implementers of Health IT Modules) other than developers of certified Health IT Modules are not in scope for this certification criterion nor the associated Condition and Maintenance of Certification requirements. All other practices associated with third-party application review or ‘‘vetting’’ by implementers must not violate the information blocking provision described in section VIII of this preamble and applicable laws and regulations. In general, an implementer of § 170.315(g)(10)-certified Health IT Modules (e.g., health care providers) would be allowed to review third-party applications the implementer intends to use for its own business use (e.g., a third-party decision-support application used by the health care provider in the course of furnishing care) prior to permitting the third-party applications to connect to the implementer’s deployed APIs within its enterprise and clinical users’ workflow. However, implementers of § 170.315(g)(10)certified Health IT Modules (e.g., health care providers) are not permitted to review or ‘‘vet’’ third-party applications intended for patient access and use (see section VII.C.6 of this preamble). We clarify that the third-party application registration process that a health IT developer must meet under this VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 criterion is not a form of review or ‘‘vetting’’ for purposes of this criterion. Comments. Commenters requested clarity on whether the ‘‘EHR Launch’’ scenario was out of scope for testing during registration with an authorization server. Response. Commenters referred to the ‘‘EHR Launch’’ scenario, which is the ‘‘launch-ehr’’ ‘‘SMART on FHIR Core Capability’’ included in the implementation specification adopted in § 170.215(a)(3). Health IT Modules presented for testing and certification must enable all apps that utilize the SMART IG ‘‘launch-standalone’’ ‘‘SMART on FHIR Core Capability’’ to register with an authorization server. We reiterate that the application registration requirement finalized in § 170.315(g)(10)(iii) does not require conformance to a standard or implementation specification. We envision that apps using only the SMART IG ‘‘launch-ehr’’ ‘‘SMART on FHIR Core Capability’’ will be tightly integrated with § 170.315(g)(10)certified Health IT Modules deployed by implementers, and will be able to accommodate registration processes that best suit the needs of those implementers. Additionally, while we do not require conformance to a standard or implementation specification for application registration, we clarify that Health IT Modules presented for testing and certification are required to support application registration functions to enable authentication and authorization as finalized in § 170.315(g)(10)(v). iv. Secure Connection We proposed in 84 FR 7483 in § 170.315(g)(10)(iv) that Health IT Modules presented for testing and certification must be capable of establishing a secure and trusted connection with an application requesting patient data in accordance with the proposed § 170.215(a)(5) (HL7 SMART Application Launch Framework Implementation Guide Release 1.0.0), including mandatory support for ‘‘Standalone Launch’’ and ‘‘EHR Launch’’ modes. Comments. Commenters asked for clarification around where ‘‘Standalone Launch’’ and ‘‘EHR Launch’’ capabilities are required, suggesting that ‘‘Standalone Launch’’ support be used exclusively for patient access and ‘‘EHR Launch’’ support be used exclusively for provider/clinician access. They also noted that testing and certification of ‘‘Standalone Launch’’ would not be a valid use case and should be excluded from the certification criterion. PO 00000 Frm 00105 Fmt 4701 Sfmt 4700 25745 Response. We appreciate the feedback from commenters. The SMART IG ‘‘Standalone Launch’’ and ‘‘EHR Launch’’ modes can be used by both provider- and patient-facing applications. We refer to the adopted implementation specification in § 170.215(a)(3) for clarification of certification requirements for the SMART IG. We have finalized in § 170.315(g)(10)(iv)(A) that Health IT Modules presented for testing and certification must demonstrate the ability to establish a secure and trusted connection with an application requesting data for a single patient in accordance with the implementation specifications adopted in § 170.215(a)(2) and (a)(3). We amended this text from the Proposed Rule by adding the US Core IG implementation specification adopted in § 170.215(a)(2) because the US Core IG specifically requires Transport Layer Security 1.2 (RFC 5246) 104 or higher for all transmissions not taking place over a secure network connection. Pursuant to this adopted implementation specification, we will test Health IT Modules for support for all ‘‘SMART on FHIR Core Capabilities’’ including both ‘‘launch-ehr’’ and ‘‘launch-standalone.’’ Additionally, we have finalized in § 170.315(g)(10)(iv)(B) that Health IT Modules presented for testing and certification must demonstrate the ability to establish a secure and trusted connection with an application requesting data for multiple patients in accordance with the implementation specification adopted in § 170.215(a)(4). The implementation specification adopted in § 170.215(a)(4) has several sections, but for testing and certification to this criterion, we specifically require conformance to, but not limited to, the ‘‘SMART Backend Services: Authorization Guide.’’ v. Authentication and Authorization We proposed in 84 FR 7483 in § 170.315(g)(10)(v) that Health IT Modules presented for testing and certification must demonstrate the ability to perform user authentication, user authorization, and issue a refresh token valid for a period of at least 3 months during its initial connection with an application to access data for a single patient in accordance with the proposed standard in § 170.215(b) (OpenID Connect Core 1.0 incorporating errata set 1) and the proposed implementation specification in § 170.215(a)(5) (HL7® SMART Application Launch Framework Implementation Guide Release 1.0.0). 104 https://tools.ietf.org/html/rfc5246. E:\FR\FM\01MYR3.SGM 01MYR3 25746 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations Additionally, we proposed in § 170.315(g)(10)(vi) that Health IT Modules presented for testing and certification must demonstrate the ability of an application to access data for a single patient and multiple patients during subsequent connections of applications capable of storing a client secret, in accordance with the proposed implementation specification in § 170.215(a)(5) (HL7 SMART Application Launch Framework Implementation Guide Release 1.0.0), without requiring the user to reauthorize and re-authenticate when a valid refresh token is supplied. Additionally, we proposed in 84 FR 7483 that Health IT Modules presented for testing and certification must demonstrate it can issue a new refresh token to an application, valid for a period of at least 3 months. Comments. A majority of commenters supported that Health IT Modules presented for testing and certification must demonstrate the ability to perform user authentication, user authorization, and issue a refresh token valid for a period of at least 3 months. Some commenters noted that the OAuth 2.0 implementation guide does not recommend servers provide refresh tokens to public/non-confidential applications. Response. We thank commenters for their feedback. Given the general support and in response to these comments, we have consolidated the proposed requirements in § 170.315(g)(10)(v) and § 170.315(g)(10)(vi) as a revised set of requirements finalized in § 170.315(g)(10)(v). Specifically, we have finalized requirements for authentication and authorization for patient and user scopes in § 170.315(g)(10)(v)(A) and requirements for authentication and authorization for system scopes in § 170.315(g)(10)(v)(B). We have focused the revised requirements around authentication and authorization scopes to remove any confusion associated with requirements for single and multiple patients. We have finalized authentication and authorization requirements for first time connections for patient and user scopes in § 170.315(g)(10)(v)(A)(1). This include the requirement finalized in § 170.315(g)(10)(v)(A)(1)(i) that Health IT Modules presented for testing and certification must demonstrate that authentication and authorization occurs during the process of granting access to patient data in accordance with the implementation specification adopted in § 170.215(a)(3) and standard adopted in § 170.215(b). It also includes the requirement finalized in VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 § 170.315(g)(10)(v)(A)(1)(ii) that an application capable of storing a client secret must be issued a refresh token valid for a period of no less than three months. Additionally, we have finalized authentication and authorization requirements for subsequent connections for patient and user scopes in § 170.315(g)(10)(v)(A)(2). This includes the requirements finalized in § 170.315(g)(10)(v)(A)(2)(i) that Health IT Modules presented for testing and certification must demonstrate that access is granted to patient data in accordance with the implementation specification adopted in § 170.215(a)(3) without requiring re-authorization and re-authentication when a valid refresh token is supplied by the application. It also includes the requirements finalized in § 170.315(g)(10)(v)(A)(2)(ii) that an application capable of storing a client secret must be issued a new refresh token valid for a new period of no less than three months. Additionally, we have finalized requirements for authentication and authorization for system scopes in § 170.315(g)(10)(v)(B), which require that Health IT Modules presented for testing and certification must demonstrate that authentication and authorization occurs 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(a)(4) and the application must be issued a valid access token. We note that for system scopes, applications will likely be authorized via a prior authorization negotiation and agreement between applications and Health IT Modules. For clarity, we use the term ‘‘an application capable of storing a client secret’’ to refer to ‘‘confidential clients.’’ In the definition at RFC 6749, ‘‘confidential’’ clients are ‘‘clients capable of maintaining the confidentiality of their credentials (e.g., client implemented on a secure server with restricted access to the client credentials), or capable of secure client authentication using other means.’’ RFC 6749 also defines ‘‘public’’ clients as ‘‘clients incapable of maintaining the confidentiality of their credentials (e.g., clients executing on the device used by the resource owner, such as an installed native application or a web browserbased application), and incapable of secure client authentication via any other means.’’ We clarify that the term ‘‘an application capable of storing a client secret’’ specifically excludes ‘‘public’’ clients. PO 00000 Frm 00106 Fmt 4701 Sfmt 4700 Additionally, we clarify that Health IT Modules will be explicitly tested for US Core IG operations using authentication and authorization tokens acquired via the process described in the implementation specification adopted in § 170.215(a)(3), and Health IT Modules will be explicitly tested for Bulk IG operations using authentication and authorization tokens acquired via the process described in the implementation specification adopted in § 170.215(a)(4). Comments. One commenter recommended that ONC introduce a Condition of Certification requirement to ensure that implementers of § 170.315(g)(10)-certified Health IT Modules can obtain automated systemlevel access to all API calls from the API servers offered by the Certified Health IT Developers (e.g., via the SMART Backend Services authorization guide), with ‘‘system/*.*’’ scopes. Response. We decline to accept the recommendation to require ‘‘system/ *.*’’ scopes as a certification requirement in § 170.315(g)(10). Insofar as the commenter requested that Health IT Modules make available automated system-level scopes for the purposes of an ‘‘all information export,’’ we have finalized a similar requirement in § 170.315(b)(10), and refer the commenter to that section for additional detail. Additionally, we have finalized in § 170.315(g)(10)(v)(B) that Health IT Modules must perform authentication and authorization during the process of granting an application access to patient data using system scopes in accordance with the ‘‘SMART Backend Services: Authorization Guide’’ section of the implementation specification adopted in § 170.215(a)(4). We recognize that the capabilities supported by ‘‘SMART Backend Services: Authorization Guide’’ could be used for many other use cases that are currently not required by the criterion. We clarify that implementers of Health IT Modules are not prohibited from configuring Health IT Modules to support the backend ‘‘system’’ scope described in the ‘‘SMART Backend Services: Authorization Guide’’ section of the Bulk IG adopted in § 170.215(a)(4) for API-enabled ‘‘read’’ services defined in the US Core IG. Indeed, we strongly encourage health IT developers to support these use cases as they develop in order to make full use of the certified functions of Health IT Modules and advance the state of the industry. Comments. Commenters suggested specifying that refresh tokens apply exclusively to patient access scenarios, noting that there are too many security risks to allow persistent tokens for provider-facing applications. E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations Additionally, commenters suggested permitting Health IT Modules to support the revocation of refresh tokens in appropriate scenarios to address legitimate security concerns. Response. We appreciate the feedback from commenters. We do not agree that there are too many security risks to allow refresh tokens to be used for provider-facing applications. Refresh tokens are commonly used in health care and other industries to provide seamless integration of systems with other applications while reducing the need for the burdensome process of reauthentication and re-authorization. We expect implementers of § 170.315(g)(10)certified Health IT Modules to have the capability of revoking refresh tokens where appropriate. Additionally, we clarify that implementers of § 170.315(g)(10)-certified Health IT Modules are not prohibited from changing the length of refresh tokens for users of the API including patients and providers to align with their institutional policies. However, implementers of § 170.315(g)(10)certified Health IT Modules should be mindful of information blocking provisions applicable to them and that requiring patients to re-authenticate and re-authorize at a high frequency could inhibit patient access and implicate information blocking. Comments. Commenters suggested amending the time from three months to 12 months. One commenter agreed that the patient token should be valid for three months, but suggested the provider token be limited to 24 hours. One commenter suggested requiring reauthentication every time information is sought via APIs. Response. We appreciate the feedback from commenters. We believe a refresh token valid for a period of three months is sufficient to balance persistent access and security concerns. Moreover, for subsequent connections of applications capable of storing a client secret, Health IT Modules are required to issue a new refresh token valid for a new period of no shorter than three months per the API certification criterion requirement finalized in § 170.315(g)(10)(v)(A)(2)(ii). Given this requirement, we anticipate that the user’s application will renew its refresh token (valid for a new period of three months) every time the user actively engages with the application. We believe this justifies a refresh token length for a moderate period of no shorter than three months rather than a long period of 12 months suggested by commenters. Additionally, as stated above, implementers of § 170.315(g)(10)certified Health IT Modules are not prohibited from changing the length of VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 refresh tokens for users of the API, including patients and providers, to align with their institutional policies. Further, implementers of § 170.315(g)(10)-certified Health IT Modules are not prohibited from implementing their § 170.315(g)(10)certified Health IT Modules in accordance with their organizational security policies and posture, including by instituting policies for reauthentication and re-authorization (e.g., providers and/or patients could always be required to re-authenticate and re-authorize after a set number of refresh tokens have been issued). We also note that we have finalized a requirement in § 170.315(g)(10)(vi) that a Health IT Module’s authorization server must be able to revoke an authorized application’s access at a patient’s direction. This required capability will enable patients to definitively revoke an application’s authorization to receive their EHI until reauthorized, if ever, by the patient. Comments. Commenters suggested creating a more robust assessment process for identity management, including adding additional criteria for identity proofing, authentication, and authorization, and ensuring software developers do not act in a way that could inhibit patient control of their data. Response. We appreciate the feedback and suggestions. Although we agree that identity proofing is an important practice, we did not include requirements for identity proofing in the Proposed Rule, and have not finalized requirements for identity proofing in response to this comment. We note that the certification criterion finalized in § 170.315(g)(10) only applies to health IT developers. Given the scope of the Program, we believe that mandating identity proofing, which are generally business practices performed by organizations and other entities, is not something appropriate to require of health IT developers. We note that per the requirements of the 2015 Edition Privacy and Security Certification Framework, health IT developers with Health IT Modules certified to § 170.315(g)(7) through (g)(10) are required to certify to § 170.315(d)(1), which includes requirements for authentication, access control, and authorization. Additionally, authentication and authorization for use of § 170.315(g)(10)-certified Health IT Modules are included in the requirements finalized in § 170.315(g)(10)(v). We appreciate the sentiment expressed by commenters, and have created thorough and rigorous requirements to ensure adequate privacy PO 00000 Frm 00107 Fmt 4701 Sfmt 4700 25747 and security capabilities are present in § 170.315(g)(10)-certified Health IT Modules. Regarding the request for certification requirements to ensure that software developers do not act in a way that could inhibit patient control of their data, we refer to the requirement finalized in § 170.315(g)(10)(A), which requires that patients have the ability to grant applications authorization to access their EHI using granular FHIR Resources of their choice to comply with the adopted implementation specification in § 170.215(a)(3), and requirement in § 170.315(g)(10)(vi), which requires that a Health IT Module’s authorization server must be able to revoke an authorized application’s access at a patient’s direction. Comments. Several commenters suggested that patients be able to specify refresh token length, if desired, and revoke a third-party application’s access at any time. Commenters suggested that clear information be provided to patients whether authorized access is one-time or ongoing. Response. We appreciate the feedback from commenters. Refresh tokens are an OAuth 2.0 concept, and are largely opaque to the end user. However, we clarify that patients are not prohibited from changing the length of refresh tokens to the degree this option is available to them. Additionally, pursuant to these comments, and to ensure patients have the ability to revoke an application’s access to their EHI at any time, we have finalized an additional certification requirement in § 170.315(g)(10)(vi) which requires that a Health IT Module’s authorization server must be able to revoke an authorized application’s access at a patient’s direction. We have finalized this as a functional requirement to allow health IT developers the ability to implement it in a way that best suits their existing infrastructure and allows for innovative models for authorization revocation to develop. Additionally, per the requirement finalized in § 170.315(g)(10)(v)(A), Health IT Modules must perform authorization conformant with the implementation specification adopted in § 170.215(a)(3), including all ‘‘SMART on FHIR Core Capabilities.’’ The ‘‘permission-offline’’ ‘‘SMART on FHIR Core Capability’’ includes support for the ‘‘offline_ access’’ scope. Importantly, the implementation specification adopted in § 170.215(a)(3) requires that patients have the ability to explicitly enable the ‘‘offline_access’’ scope during authorization. If the ‘‘offline_access’’ scope is not enabled by patients, patients will be required to re- E:\FR\FM\01MYR3.SGM 01MYR3 25748 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations authenticate and re-authorize an application’s access to their EHI after the application’s access token expires. Comments. Commenters suggested providing the ability for implementers of § 170.315(g)(10)-certified Health IT Modules to perform token introspection using services enabled by health IT developers to ensure that additional resource servers can work with the same access tokens and authorization policies as the resource servers provided by API Technology Suppliers. Response. We appreciate the feedback from commenters. Based on feedback, we have finalized in § 170.315(g)(10)(vii) that Health IT Modules presented for testing and certification must demonstrate the ability to receive and validate a token issued by its authorization server, but we did not specify a standard for this requirement. Token introspection will allow implementers of § 170.315(g)(10)certified Health IT Modules to use API authorization servers and authorization tokens with various resource servers. This functionality has the potential to reduce complexity for implementers of § 170.315(g)(10)-certified Health IT Modules authorizing access to several resource servers and reduces the overall effort and subsequent use of § 170.315(g)(10)-certified Health IT Modules consistent with the goals of section 4002 of the Cures Act to enable the use of APIs without ‘‘special effort.’’ Although we do not specify a standard for token introspection, we encourage industry to coalesce around using a common standard, like OAuth 2.0 Token Introspection (RFC 7662).105 Comments. One commenter expressed concerns with the privacy and security of APIs, and nefarious actors posing as legitimate health facilities. Response. Regarding the privacy and security of APIs, the Standardized API for Patient and Population Services certification criterion finalized in § 170.315(g)(10) requires Health IT Modules presented for testing and certification to implement the implementation specification adopted in § 170.215(a)(3), which is based on the OAuth 2.0 security standard that is widely used in industry. The implementation of OpenID Connect paired with OAuth 2.0 allows health care providers to securely deploy and manage APIs consistent with their organizational practices. Health care providers retain control over how their workforce and patients authenticate when interacting with the API. For example, a patient may be required to use the same credentials (e.g., username 105 https://tools.ietf.org/html/rfc7662. VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 and password) they created and use to access their EHI through a patient portal as they do when authorizing an application to access their data. Since patients complete the authentication process directly with their health care provider, no application will have access to their credentials. There is little protection software can provide to protect against nefarious actors posing as legitimate health facilities, however, we believe that implementing the security controls and safeguards described above, along with the privacy and security requirements required under the 2015 Edition Privacy and Security Certification Framework, will help to protect Health IT Modules against nefarious actors. Additionally, the protections required for ePHI in Health IT Modules offered by health IT developers acting as business associates of health care providers remain unchanged. vi. Technical Documentation We proposed in 84 FR 7484 in § 170.315(g)(10)(vii) that an API Technology Supplier needed to provide complete documentation via a publicly accessible hyperlink, without additional access requirements, for all aspects of its § 170.315(g)(10)-certified API, especially for any unique technical requirements and configurations, including API syntax, function names, required and optional parameters supported and their data types, return variables and their types/structures, exceptions and exception handling methods and their returns, the software components and configurations necessary for an application to successfully interact with the API and process its response(s), and all applicable technical requirements and attributes necessary for an application to be registered with an authorization server. Additionally, we proposed in 84 FR 7484 to remove the ‘‘terms of use’’ documentation provisions in the API certification criteria adopted in § 170.315(g)(7) through (g)(9) in order to reflect the Condition of Certification requirements and not be duplicative of the terms and conditions transparency Condition of Certification requirements proposed in 84 FR 7485. Comments. Commenters generally supported the requirements for this criterion as proposed. Some commenters suggested technical documentation should be limited to descriptions of how the API differs from the utilized standards and implementation specifications, like HL7® FHIR® and the SMART IG. Response. We appreciate the feedback from commenters. We did not make PO 00000 Frm 00108 Fmt 4701 Sfmt 4700 substantive changes to the requirements proposed in § 170.315(g)(10)(vii). We have finalized these requirements § 170.315(g)(10)(viii). We recognize that our formal adoption of the HL7 FHIR standard and the associated implementation specifications referenced in § 170.315(g)(10) would be consistent across all Health IT Modules presented for certification. As a result, there may be minimal additional documentation needed for these capabilities beyond what is already documented in adopted standards and implementation specifications. We expect health IT developers to disclose any additional data their § 170.315(g)(10)-certified Health IT Module supports in the context of the adopted standards and implementation specifications. The content of technical documentation required to meet this certification criteria are described in requirements finalized in § 170.315(g)(10)(viii)(A). We expect these and any additional documentation relevant to the use of a health IT developer’s § 170.315(g)(10)-certified Health IT Module to be made available via a publicly accessible hyperlink without preconditions or additional steps to meet the requirement as finalized in § 170.315(g)(10)(viii)(B). d. API Condition of Certification Requirements i. Key Terms We proposed in 84 FR 7477 to adopt new definitions for ‘‘API Technology Supplier,’’ ‘‘API Data Provider,’’ and ‘‘API User’’ in § 170.102 to describe the stakeholders relevant to our proposals. Comments. The majority of commenters recommended updating definitions and providing examples for the key terms, including API User. Most commenters recommended dividing ‘‘API User’’ into two categories: ‘‘FirstOrder Users,’’ to include patients, health care providers, and payers that use apps/services that connect to API technology, and ‘‘Third-Party Users,’’ to include third-party software developers, and developers of software applications used by API Data Providers. Response. We thank commenters for their feedback. We note that in this section we use the terms proposed in § 170.102 that we finalized in § 170.404(c) with added quotation marks for emphasis and clarity. We considered separating the term ‘‘API User’’ into distinct terms for developers of software applications and other users, such as patients and health care providers. However, we determined that this distinction was unnecessary from a regulatory perspective. Narrowing our E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations definitions to distinct subgroups could exclude unforeseen stakeholders that emerge in a future API ecosystem. The term ‘‘API User’’ was intended to describe stakeholders that interact with the certified API technology either directly (e.g., to develop third-party apps/services) or indirectly (e.g., as a user of a third-party app/service). Based on suggestions to revise the proposed key terms, we have renamed the term ‘‘API Data Provider’’ to ‘‘API Information Source’’ finalized in § 170.404(c) to make clear which party is the source and responsible for the EHI (as in ‘‘the source of the information is the health care provider’’), and ‘‘API Technology Supplier’’ to ‘‘Certified API Developer’’ finalized in § 170.404(c) to more clearly refer to health IT developers with Health IT Modules certified to any of the API criteria under the Program. Rather than keeping ‘‘API technology’’ an undefined term, we renamed it to ‘‘certified API technology’’ and finalized a definition in § 170.404(c). Additionally, we amended the definition of ‘‘API User’’ for clarity in § 170.404(c) to ‘‘API User means a person or entity that creates or uses software applications that interact with the ‘certified API technology’ developed by a ‘Certified API Developer’ and deployed by an ‘API Information Source.’’’ Additionally, we did not include the non-exhaustive list of examples of ‘‘API User’’ in the definition finalized in § 170.404(c). Instead, we rely on preamble to provide guidance for examples of ‘‘API Users’’ rather than appearing to limit the regulatory definition to these examples. We interpret that ‘‘API Users’’ can include, but are not limited to, software developers, patients, health care providers, and payers. We simplified the definition of ‘‘API Information Source’’ in § 170.404(c) to ‘‘API Information Source means an organization that deploys ‘certified API technology’ created by a ‘Certified API Developer.’’’ We revised the definition of ‘‘Certified API Developer’’ in § 170.404(c) to ‘‘Certified API Developer means a health IT developer that creates the ‘certified API technology’ that is certified to any of the certification criteria adopted in § 170.315(g)(7) through (10).’’ We added the definition of ‘‘certified API technology’’ in § 170.404(c) as ‘‘certified API technology means the capabilities of Health IT Modules that are certified to any of the API-focused certification criteria adopted in § 170.315(g)(7) through (10).’’ For ease of reference and to clarify that these terms only apply to the Condition and Maintenance of VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 Certification requirements, we have finalized these revised definitions in § 170.404(c). In this and other sections of the rule, we use the original proposed terms in the proposal and comment summaries, and the finalized terms in our responses. Comments. Some commenters suggested ONC allow flexibility for instances where stakeholders may meet the definition of more than one key term, and others recommended restricting stakeholders from meeting the definition of more than one key term. Commenters expressed concern with the complexity of key terms in the Proposed Rule, and confusion with the interaction of these terms with other criteria within the rule. Response. We thank commenters for expressing their concern about stakeholders being able to serve more than one role under the definitions proposed in § 170.102 that we have finalized in § 170.404(c). We do not believe it is practical to restrict persons or entities to just one definition. We anticipate situations where a person or entity can serve more than one role. For example, a large health care system could purchase and deploy ‘‘certified API technology’’ as an ‘‘API Information Source’’ and have ‘‘API Users’’ on staff that create or use software applications that interact with the ‘‘certified API technology.’’ Additionally, a health IT developer could serve as a ‘‘Certified API Developer’’ that creates ‘‘certified API technology’’ for testing and certification and as an ‘‘API User’’ when it creates software applications that connect to ‘‘certified API technology.’’ We clarify that a stakeholder will meet a role defined in § 170.404(c) based on the context in which they are acting. For example, only health IT developers (when acting in the context of a ‘‘Certified API Developer’’) are required to comply with these API Condition and Maintenance of Certification requirements. Comments. Commenters expressed concern that ONC exceeded its regulatory authority by implicating physicians in the definition of ‘‘API Data Providers.’’ Response. We remind commenters that these definitions were created to describe relationships between key API stakeholders and to help describe the Condition and Maintenance of Certification requirements. We clarify that health care providers are not covered by the Condition and Maintenance of Certification requirements to which the definitions apply in § 170.404(c) unless they are serving the role of a ‘‘Certified API Developer. PO 00000 Frm 00109 Fmt 4701 Sfmt 4700 25749 ii. Scope and Compliance We proposed in 84 FR 7485 that the Condition and Maintenance of Certification requirements proposed in § 170.404 apply to API Technology Suppliers with Health IT Modules certified to any API-focused certification criteria adopted in the proposed § 170.315(g)(7) through (11). Comments. Commenters agreed that the proposed applicability for the Condition of Certification requirements proposed in § 170.404 should be limited to health IT developers certified to any API-focused criteria adopted in the proposed § 170.315(g)(7) through (11). One commenter requested clarification whether non-certified internally developed laboratory systems would be subject to this requirement. Response. We thank stakeholders for their comments. We have generally finalized the scope and compliance for the Condition and Maintenance of Certification requirements as proposed in § 170.404 with one modification. Given that we have not adopted the certification criterion proposed for adoption in § 170.315(g)(11), the scope of the Condition and Maintenance of Certification requirements apply only to health IT developers with Health IT Modules certified to any of the APIfocused criteria finalized in § 170.315(g)(7) through (10). The Condition and Maintenance of Certification requirements finalized in § 170.404 do not apply to health IT developers not seeking certification, nor do they apply to health IT developers certified to solely non-API-focused criteria. Additionally, we clarify that the Condition and Maintenance of Certification requirements only apply to practices of Certified API Developers with respect to the capabilities included in § 170.315(g)(7) through (10). In other words, the Condition and Maintenance of Certification requirements would not apply to practices of Certified API Developers with respect to non-certified capabilities or practices associated with, for example, the immunization reporting certification criterion in § 170.315(f)(1), because that criterion is not one of the API-focused criteria finalized in § 170.315(g)(7) through (10). However, health IT developers should understand that other requirements in this final rule, especially those related to information blocking, could still apply to its business practices associated with non-API-focused certification criteria. iii. General We proposed in 84 FR 7485 in § 170.404(a)(1) to adopt the Cures Act’s E:\FR\FM\01MYR3.SGM 01MYR3 25750 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations API Condition of Certification requirement stating that an API Technology Supplier must, through an API, ‘‘provide access to all data elements of a patient’s electronic health record to the extent permissible under applicable privacy laws.’’ We then subsequently proposed in 84 FR 7485 to interpret ‘‘all data of a patient’s electronic health record’’ for the purposes of the scope of this API Condition of Certification requirement to include the proposed ARCH standard, its associated implementation specifications, and the policy expressed around the data elements that must be supported by § 170.315(g)(10)-certified APIs. Comments. Commenters supported our adoption of the Cures Act’s API Condition of Certification requirement. For the purposes of the scope of data covered under this API Condition of Certification requirement, most commenters recommended defining ‘‘all data elements’’ as the Data Elements referenced by the USCDI and the FHIR resources in the FHIR US Core Implementation Guide STU 3 (US Core IG) for FHIR Release 4. We received comments recommending additional data elements to be included that we discuss in our comment summary for the ARCH in the ‘‘API Standards, Implementation Specifications, and Certification Criterion’’ section of this final rule. Response. We appreciate stakeholder feedback. The § 170.315(g)(10) certification criterion requirement and associated standards and implementation specifications will enable secure, standards-based API access to a specific set of information. We have finalized that a Certified API Developer must publish APIs, and must allow EHI from such technology to be accessed, exchanged, and used without special effort through the use of APIs or successor technology or standards, as provided for under applicable law, including providing access to all data elements of a patient’s electronic health record to the extent permissible under applicable privacy laws, in § 170.404(a)(1). Additionally, for the purposes of meeting this portion of the Cures Act’s API Condition of Certification requirement, we clarify the data required and that must be supported to demonstrate conformance to the final § 170.315(g)(10) certification criterion (including all of its associated standards and implementation specifications) constitutes ‘‘all data elements of a patient’s electronic health record to the extent permissible under applicable privacy laws.’’ Regarding the recommendation by commenters that VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 the scope of ‘‘all data elements’’ include the Data Elements of the standard adopted in § 170.213 and FHIR resources referenced by the implementation specification adopted in § 170.215(a)(2), we note that both the standard and implementation specification are included in the interpretation of ‘‘all data elements of a patient’s electronic health record to the extent permissible under applicable privacy laws’’ above. We note that this specific interpretation does not extend beyond the API Condition and Maintenance of Certification requirements finalized in § 170.404 and cannot be inferred to reduce the scope or applicability of other Cures Act Conditions of Certification or the information blocking policies, which include a larger scope of data. iv. Transparency Conditions We proposed in 85 FR 7485 and 7486 in § 170.404(a)(2)(i) to require API Technology Suppliers make available complete business and technical documentation via a publicly accessible hyperlink, including all terms and conditions for use of its API technology. Additionally, we proposed that API Technology Suppliers must make clear to the public the timing information applicable to their disclosures in order to prevent discrepancies between an API Technology Supplier’s public documentation and its direct communication to customers. Additionally, we requested comment at 84 FR 7486 on whether the expectation for API Technology Suppliers to make necessary changes to transparency documentation should be finalized in regulation text, or whether this would be standard practice as part of making this documentation available. Comments. We received overall support from commenters for the need to make complete business and technical documentation available via a publicly accessible hyperlink. We did not receive public comment on whether we should formally include public disclosure requirements for regular updates to business and technical documentation in regulatory text. Response. We thank commenters for their support to make complete business and technical documentation available via a publicly accessible hyperlink. We have finalized in § 170.404(a)(2)(i) that a Certified API Developer must publish complete business and technical documentation, including the documentation described in § 170.404(a)(2)(ii), via a publicly accessible hyperlink that allows any person to directly access the information without any preconditions PO 00000 Frm 00110 Fmt 4701 Sfmt 4700 or additional steps. We made small adjustments to § 170.404(a)(2)(i) to reflect the changes in API definitions finalized in § 170.404(c). Given that we did not receive public comment on whether we should formally include public disclosure requirements for regular updates to business and technical documentation in regulatory text, so we have finalized in 170.404(a)(4)(iii)(B) that a Certified API Developer must provide notice and a reasonable opportunity for API Information Sources and API Users to update their applications to preserve compatibility with certified API technology and to comply with applicable terms and conditions. We note that notice could include a public notice made available on a website, but also encourage Certified API Developers to contact API Information Source customers and registered API Users (application developers) directly prior to updating business and technical documentation. (A) Terms and Conditions We proposed in 84 FR 7485 in § 170.404(a)(2)(ii)(A) that API Technology Suppliers must publish all terms and conditions for its API technology, including any restrictions, limitations, obligations, registration process requirements, or other similar requirements that would be needed to: Develop software applications to interact with the API technology; distribute, deploy, and enable the use of software applications in production environments that use the API technology; use software applications, including to access, exchange, and use EHI by means of the API technology; use any EHI obtained by means of the API technology; and register software applications. Additionally, we proposed in § 170.404(a)(2)(ii)(B) that any and all fees charged by an API Technology Supplier for the use of its API technology must be described in detailed, plain language, including the persons or classes of persons to whom the fee applies; the circumstances in which the fee applies; and the amount of the fee, which for variable fees must include the specific variable(s) and methodology(ies) that will be used to calculate the fee. Comments. We received support from stakeholders regarding the transparency of ‘‘all terms and conditions’’ associated with the use of API technology. Response. We thank commenters for their support. We believe this terms and conditions transparency requirement would ensure that API Information Sources and API Users do not experience ‘‘special effort’’ in the form E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations of unnecessary costs or delays in obtaining the terms and conditions for certified API technology. Furthermore, we believe full transparency is necessary to ensure that API Users have a thorough understanding in advance of any terms or conditions that might apply to them once they have committed to developing software that interacts with certified API technology. We have finalized in § 170.404(a)(2)(ii)(A) that Certified API Developers must publish all terms and conditions for its certified API technology, including any fees, restrictions, limitations, obligations, registration process requirements or other similar requirements as enumerated in § 170.404(a)(2)(ii)(A)(1) through (6). We made small adjustments to § 170.404(a)(2)(ii)(A) to reflect the changes in API definitions finalized in § 170.404(c). Additionally, we moved ‘‘App developer verification’’ from its proposed location in § 170.404(a)(2)(ii)(C) and finalized it in § 170.404(b)(1) to improve organization. We added the phrase ‘‘Used to verify the authenticity of API Users’’ to the regulation text finalized in § 170.404(a)(2)(ii)(A)(5) for consistency with our proposed policy. We also moved the phrase ‘‘Register software applications’’ from its proposed location in § 170.404(a)(2)(ii)(A)(5) to the finalized location in § 170.404(a)(2)(ii)(A)(6) and revised the phrase for consistency. Additionally, we made small changes to the regulation text finalized in § 170.404(a)(2)(ii)(A)(1) through § 170.404(a)(2)(ii)(A)(6) for clarity. Comments. We received both support and disagreement for the requirement to publish transparency documentation on API fees. Some commenters felt transparency documentation of API fees should be limited to value-added services, because those are the only permitted fees applicable to API Users, and the other permitted fees applicable to API Data Providers (usage-based fees and fees to recover costs for development, deployment, and upgrades) would be included in contractual documentation with their customers. Response. We recognize that some commenters had concern with making documentation on permitted fees publicly available. We believe that transparent documentation of all permitted fees is necessary to maintain a competitive marketplace and ensure that fees are reasonably related to the development, deployment, upgrade, and use of certified API technology. Fee transparency will also enable API Information Sources and API Users to VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 shop for certified API technology and related services that meet their needs. We have finalized in § 170.404(a)(2)(ii)(B) that any and all fees charged by a Certified API Developer for the use of its certified API technology must be described in detailed, plain language, including all material information described in § 170.404(a)(2)(ii)(B)(1) through (3). Additionally, we made small adjustments to § 170.404(a)(2)(ii)(B) to reflect the changes in API definitions finalized in § 170.404(c). Comments. Multiple stakeholders expressed the need to include consumer protections in the terms and conditions documentation with an explanation about how EHI will be used. Response. This provision of the Condition of Certification requirements does not prohibit additional content or limit the type of content a Certified API Developer may include in its terms and conditions. A Certified API Developer would be permitted to include consumer protections in their terms and conditions documentation. Additionally, we clarify these API Conditions of Certification requirements only apply to Certified API Developers. As such, API Information Sources and API Users are not required by the API Condition of Certification requirements to publish any terms and conditions, including those that apply to consumer protections. v. Fees Conditions (A) General Fees Prohibition We proposed in § 170.404(a)(3)(i)(A) that API Technology Suppliers would be prohibited from imposing fees associated with API technology as a Condition of Certification requirement. In establishing this general prohibition, ONC was mindful of the need for API Technology Suppliers to recover their costs and to earn a reasonable return on their investments in providing API technology that has been certified under the Program. Accordingly, we identified categories of ‘‘permitted fees’’ in 84 FR 7487 that API Technology Suppliers would be permitted to charge and still be compliant with the Condition of Certification and Program requirements. These include the proposed § 170.404(a)(3)(ii) (permitted fee for developing, deploying, and upgrading API technology), proposed § 170.404(a)(3)(iii) (permitted fee to recover costs of supporting API usage for purposes other than patient access), and proposed § 170.404(a)(3)(iv) (permitted fee for value-added services). We also proposed in 84 FR 7487 that API Technology Suppliers would not be PO 00000 Frm 00111 Fmt 4701 Sfmt 4700 25751 permitted to impose fees on any person in connection with an API Technology Supplier’s work to support the use of API technology to facilitate a patient’s ability to access, exchange, or use their EHI. We also clarified that while the proposed permitted fees set the boundaries for the fees API Technology Suppliers would be permitted to charge and to whom those permitted fees could be charged, the proposed regulations did not specify who could pay the API Technology Supplier’s permitted fee. Rather, we proposed general conditions that an API Technology Supplier’s permitted fees must satisfy in § 170.404(a)(3)(i)(B)(1) through (4), and requested comment in 84 FR 7488 on these conditions and whether they sufficiently restrict fees from being used to prevent access, exchange, and use of EHI through APIs without special effort. We include detailed discussions of permitted fees and related conditions below. Comments. Some commenters supported the clear prohibition on API fees outside those fees permitted in § 170.404(a)(3)(ii) through (iv), expressing that the language in the rule would prevent confusion regarding allowable and restricted fees. Some commenters noted that prohibiting fees would enable patients to exercise their HIPAA right of access without experiencing cost barriers, and remove cost barriers to hospitals and health care facilities using APIs for interoperability. Commenters noted that the proposals addressed many of the access and pricing practices that API Technology Suppliers engaged in to limit data exchange and gain a competitive advantage. Commenters noted that API Technology Supplier pricing practices often create barriers to entry and competition for apps that health care providers seek to use. Some commenters supported the proposal that prohibits API Technology Suppliers from charging fees to API Users. Response. We thank stakeholders for their support of and feedback on our proposal. We have finalized in § 170.404(a)(3)(i)(A) that all fees related to certified API technology not otherwise permitted by § 170.404(a)(3) are prohibited from being imposed by a Certified API Developer. Additionally, we have modified and reorganized these Condition of Certification requirements for clarity. We have renamed the title for the section from the Proposed Rule to ‘‘Fees conditions’’ because the requirements include both permitted and prohibited fees. We have updated the terminology used in this section to reflect changes made to the terminology used throughout the API Condition of E:\FR\FM\01MYR3.SGM 01MYR3 25752 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations Certification requirements and finalized in § 170.404(c). We finalized a requirement in § 170.404(a)(3)(i)(A) that permitted fees in paragraphs § 170.404(a)(3)(ii) and § 170.404(a)(3)(iv) may include fees that result in a reasonable profit margin in accordance with the information blocking Costs Exception provision finalized in § 170.302. We clarify that any fee that is not covered by those exceptions would be suspect under the information blocking provision, and would equally not be permitted by this API Condition of Certification requirement. This general prohibition on fees as finalized in § 170.404(a)(3)(i)(A) is meant to ensure that Certified API Developers do not engage in pricing practices that create barriers to entry and competition for apps and API-based services that health care providers seek to use. Such activities are inconsistent with the goal of enabling API-based access, exchange, and use of EHI by patients and other stakeholders without special effort. As finalized, this general prohibition allows for three categories of permitted fees (§ 170.404(a)(3)(ii) through (iv)) to allow Certified API Developers to recover their costs and to earn a reasonable return on their investments in providing certified API technology while being compliant with the Condition of Certification and Program requirements. Comments. Some commenters were critical of our proposals, expressing concerns that the proposed policies may stifle relationships between API Technology Suppliers and application developers. Others expressed concern that the proposed fee structure would place undue burden on API Data Providers, and that ONC should instead consider regulations that allow fee sharing across stakeholders. Some commenters stated that ONC should remove all prohibitions, and allow for market pricing and revenue sharing. Several commenters, many of whom were providers and provider organizations, requested additional clarity and guidance regarding the API fees that can be charged under the Condition of Certification requirements. Some commenters requested clarification regarding whether an API Data Provider can transfer costs to API Users. Other commenters requested clarification regarding when it is (and is not) appropriate for an API User to be charged a fee in connection with use of API technology. A few commenters requested that ONC provide a chart that lists all actors, all types of costs, and who can charge whom. Response. We appreciate this feedback from commenters. These VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 ‘‘general conditions,’’ as finalized in § 170.404(a)(3)(i) and discussed above, will facilitate API-based access, exchange, and use of EHI by patients and other stakeholders without special effort. We disagree with commenters that the permitted fee policies will stifle relationships between Certified API Developers and API Users. Cumulatively, these final policies create guardrails to protect against anticompetitive practices and reinforce the independence that we believe API Information Sources should have to establish relationships with API Users. Furthermore, we believe these fee policies are necessary in light of the potential for Certified API Developers to use their market position and control over certified API technology to engage in discriminatory practices that create special effort and barriers to the use of certified API technology. We continue to receive evidence that some Certified API Developers are engaging in practices that create special effort for the use of certified API technology. These practices include fees that create barriers to entry or competition as well as rent-seeking and other opportunistic behaviors. For example, we have received feedback that some Certified API Developers are conditioning access to technical documentation on revenue sharing or royalty agreements that bear no plausible relation to the costs incurred by the Certified API Developer to provide or enable the use of certified API technology. We are also aware of discriminatory pricing policies that have the purpose or effect of excluding competitors from the use of APIs and other interoperability elements despite the fact that the API Information Source would like to partner with and use these competitive, best-of-breed services. These practices from Certified API Developers close off the market to innovative applications and services that could empower patients and enable providers to deliver greater value and choice to health care consumers and other service providers. We note that Certified API Developers and API Users have the ability to collaborate and form relationships, so long as these relationships do not conflict with any of the provisions of this final rule or other applicable Federal and State laws and regulations. Further, we clarify that while the permitted fees set the boundaries for the fees Certified API Developers are permitted to charge and to whom those permitted fees can be charged, they do not prohibit who may pay the Certified API Developer’s permitted fee. In other words, these conditions limit the party PO 00000 Frm 00112 Fmt 4701 Sfmt 4700 from which a Certified API Developer may require payment, but they do not speak to who may pay the fee. For example, a permitted practice under these conditions could include a relationship or agreement where an API User or other party offered to pay the fee owed by the API Information Source to a Certified API Developer. This is an acceptable practice because the fee is first agreed upon between the Certified API Developer and API Information Source and subsequently paid by the API Information Source directly or by a third party on behalf of the API Information Source. We note that fees charged for ‘‘value-added services’’ can arise between an API Information Source and Certified API Developer or API User. As a general matter, we note that stakeholders should be mindful of other Federal and State laws and regulations that could prohibit or limit certain types of relationships involving remuneration. We provide additional clarity and guidance regarding the API fees that can be charged under the Condition of Certification requirements in the sections that follow. Additionally, we appreciate commenters’ requests for clarification, including a chart of actors and costs. We will take this comment into consideration as we develop educational materials to help explain the permitted fees conditions finalized in § 170.404(a)(3). Comments. Commenters suggested that one way to clarify the limits on API fees would be to require API Technology Suppliers provide fee information to ONC and for ONC to make this information publicly available, including information on individual pricing transactions. Response. We appreciate the recommendation from commenters to require Certified API Developers to provide fee information to ONC. We view fee transparency as a responsibility that a Certified API Developer can fulfill without having to send a listing of its API fees to ONC. We have finalized the provision in § 170.404(a)(2)(ii) that a Certified API Developer must publish all terms and conditions for its certified API technology, including any fees. Specifically, we have finalized in § 170.404(a)(2)(ii)(B) that any and all fees charged by a Certified API Developer for the use of its certified API technology must be described in detailed plain language, including the persons or classes of persons to whom the fee applies; the circumstances in which the fee applies; and the amount of the fee, which for variable fees must include the specific variable(s) and E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations methodology(ies) that will be used to calculate the fee. (B) Certified API Developer Permitted Fees Conditions We proposed general conditions in § 170.404(a)(3)(i)(B)(1) through (4) that an API Technology Supplier’s permitted fees must satisfy in order for such fees to be expressly permitted. Comments. We received support for the general conditions for permitted fees from commenters. Some commenters expressed appreciation for the guardrails and transparency of the permitted fees. Under the first condition, commenters sought clarity on the nature and extent of some of the permissible fees an API Technology Supplier can charge and how to model such fees, specifically regarding the ‘‘objective and verifiable’’ criteria. Another commenter supported the second condition that fees must be reasonably related to API Technology Supplier’s costs of supplying and, if applicable, supporting the API technology to the API Data Provider, especially in situations where physicians may also develop APIs or support apps. However, some commenters expressed concern with the third condition to reasonably allocate fees across all customers of the API. Commenters explained that fees could not be reasonably allocated across all customers of the API, because the number of customers will change over time. We received no comments on the fourth condition that API Technology Suppliers must ensure that fees are not based on whether the requestor or other person is a competitor who will be using the API technology in a way that facilitates competition. In addition to the general permitted fees proposed, some commenters recommended clear fee exemption for any health information provided or reported by a practice for the purpose of meeting reporting requirements. Response. We appreciate feedback from commenters. We have finalized these general conditions for permitted fees in § 170.404(a)(3)(i)(B) with some modifications as described further below. We have finalized that for all permitted fees, a Certified API Developer must: (1) Ensure that such fees are based on objective and verifiable criteria that are uniformly applied to all similarly situated API Information Sources and API Users; (2) Ensure that such fees imposed on API Information Sources are reasonably related to the Certified API Developer’s costs of supplying certified API technology to, and if applicable, support VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 certified API technology for, API Information Sources; (3) Ensure that such fees for supplying, and if applicable, supporting certified API technology are reasonably allocated among all similarly situated API Information Sources; and (4) Ensure that such fees are not based on whether API Information Sources or API Users are competitors, potential competitors, or will be using the certified API technology in a way that facilitates competition with the Certified API Developer. We have revised the term ‘‘substantially similar’’ to ‘‘similarly situated’’ in § 170.404(a)(3)(i)(B)(1) for clarity and to align with changes made in § 171.302. Additionally, in response to comments and to align with changes made in § 171.302 and § 170.404(a)(3)(i)(B)(1), we have revised the term ‘‘substantially similar’’ to ‘‘similarly situated’’ in § 170.404(a)(3)(i)(B)(3). We emphasize that this provision is meant to prevent one customer or a specific group of customers to whom the certified API technology is supplied or for whom it is supported from bearing an unreasonably high cost compared to other customers, which could lead to ‘‘special effort’’ for accessing and using APIs. We believe the final policy achieves the same goal as proposed and provides clearer guidelines for the regulated community to follow. Additionally, we have revised the phrase ‘‘classes of persons and requests’’ to ‘‘API Information Sources and API Users’’ in § 170.404(a)(3)(i)(B)(1) to clearly express the actors being charged fees by Certified API Developers. Additionally, we have revised the sentence structure and grammar in § 170.404(a)(3)(i)(B)(2) through (4) for simplification. In response to comments requesting clarity on the nature and extent of permissible fees a Certified API Developer can charge and how a Certified API Developer should model such fees, specifically regarding the ‘‘objective and verifiable’’ requirement finalized in § 170.404(a)(3)(i)(B)(1), we emphasize that there will be significant variability in the fee models and specific fees charged by each Certified API Developer. Our goal with the requirement that fees be ‘‘objective and verifiable’’ is to require Certified API Developers to apply fee criteria that, among other things, will lead the Certified API Developer to come to the same conclusion with respect to the permitted fee’s amount each time it administers a fee to an API Information Source or API User. Accordingly, the fee cannot be based on the Certified API PO 00000 Frm 00113 Fmt 4701 Sfmt 4700 25753 Developer’s subjective judgment or discretion. Comments. A few commenters suggested that ONC allow API Data Providers the ability to recoup the costs for upgrading technology. Response. This comment appears to misunderstand the scope and applicability of ONC’s authority with respect to these Condition of Certification requirements. We clarify that these Condition of Certification requirements apply only to Certified API Developers. We note that similar to any IT investment, API Information Sources (as ‘‘health care providers’’) would generally be expected to recover these costs through fees administered while delivering health care services. Additionally, if an API Information Source were to recoup such costs they would need to do so consistent with the information blocking exceptions and other applicable laws and regulations. Comments. Some commenters requested that ONC conduct evaluations after the implementation of the rule and use the results to drive future policy. Some commenters recommended a study to evaluate the real-world cost of APIs used by health systems in areas such as clinical decision support, payments, machine learning, and precision medicine. Commenters also suggested ONC conduct a study on whether these regulations improve patient access to their EHI. Response. We appreciate the evaluation recommendations. We will consider these suggestions as we implement and administer the Program. (C) Certified API Developer Prohibited Fees We proposed in 84 FR 7595 in § 170.404(a)(3)(iii)(B) that permitted fees would not include costs associated with intangible assets (including depreciation or loss of value), except the actual development or acquisition costs of such assets. Additionally, we proposed in § 170.404(a)(3)(iii)(C) that permitted fees would not include opportunity costs, except for the reasonable forward-looking cost of capital. Comments. We did not receive any comments specific to the proposal for costs associated with intangible assets other than actual development or acquisition costs of such assets. Response. We moved the proposed § 170.404(a)(3)(iii)(B) and (C) to the general conditions for permitted fees finalized in § 170.404(a)(3)(i)(C)(1) and (2), respectively, because they are general conditions on permitted fees rather than conditions for ‘‘Recovering API usage costs.’’ We did not make E:\FR\FM\01MYR3.SGM 01MYR3 25754 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations other changes to the proposed regulation text in these two sections other than updating terms to the finalized definitions in § 170.404(c). Additionally, in the discussion of the Fees Exception in this final rule (VIII.D.2.b), we discussed that one commenter expressed concern that the overlap between the Fees Exception and the Licensing Exception creates the potential for actors to recover the same costs twice. The commenter explained that licensing of IP is intended to recoup the costs of development of that IP, so where the IP is an interoperability element, the costs reasonably incurred for its development should be incorporated into the royalty rate. The commenter recommended that we be clearer that, in these circumstances, only a single recovery is permitted. In order to address this comment and align the API permitted fees with related provisions finalized in the Fees Exception (§ 170.302(a)(2)(vi)) and Licensing Exception (§ 170.303(b)(2)(iv)), we have added and finalized § 170.404(a)(3)(i)(C)(3), which states that the permitted fees in this section cannot include any costs that that led to the creation of IP if the actor charged a royalty for that IP pursuant to § 170.303 and that royalty included the development costs for the creation of the IP. We refer readers to the ‘‘Basis for Fees Condition’’ sub-section within section VIII.D.2.b for a more detailed discussion of the rationale for this addition. (i) General Examples of Prohibited Fees As discussed in the Proposed Rule in 84 FR 7481 and finalized in § 170.404(a)(3)(i)(A), any API-related fee imposed by a Certified API Developer that is not expressly permitted is prohibited. In the Proposed Rule, we provided the following non-exhaustive examples of fees for services that Certified API Developers would be prohibited from charging, and reiterate them here in the final rule for clarity: (1) Any fee for access to the documentation that a Certified API Developer is required to publish or make available under this Condition of Certification requirement. (2) Any fee for access to other types of documentation or information that a software developer may reasonably require to make effective use of certified API technology for any legally permissible purpose. (3) Any fee in connection with any services that would be essential to a developer or other person’s ability to develop and commercially distribute production-ready applications that use certified API technology. These services VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 could include, for example, access to ‘‘test environments’’ and other resources that an application developer would need to efficiently design and develop apps. The services could also include access to distribution channels if they are necessary to deploy productionready software and to production resources, such as the information needed to connect to certified API technology (e.g., service base URLs) or the ability to dynamically register with an authorization server. Comments. At least one commenter expressed concern about the openended nature of the examples of prohibited fees we provided in the Proposed Rule. In particular, that any fee in connection with any services that would be essential to a developer or other person’s ability to develop and commercially distribute productionready applications that use API technology would be prohibited. They stated that if the example were not more clearly defined and scoped, it could be used by API Users to create requirements for API Technology Suppliers beyond what would normally be considered necessary to successfully deploy apps in production. They requested ONC more clearly define ‘‘essential services’’ in final rulemaking or withdraw the reference. Response. We appreciate the feedback from commenters. We disagree with commenters that the examples are too broad. We believe that in some cases they need to be general because of the diverse and varied practices that could be used by Certified API Developers to create special effort to use certified API technology. While we understand that the generality of the example regarding ‘‘essential services’’ may at first appear difficult for Certified API Developers to follow and, per the commenter, could be creatively used by an API User to request more support than necessary, we offer the following as additional guidance: A Certified API Developer is best positioned to know what an API User, for example, needs to have access to and do programmatically in order for the API User’s application to be developed and commercially distributed as production-ready for use with certified API technology. From a Certified API Developer’s perspective, if that requires any number of mandatory steps (e.g., passing tests in sandbox/test environment, conducting a demo, submitting documentation or paperwork) in order for the application to be production-ready for use with certified API technology, then fees associated with those mandatory steps are prohibited. Conversely, fees for requirements beyond what a Certified PO 00000 Frm 00114 Fmt 4701 Sfmt 4700 API Developer considers necessary to successfully deploy applications in production are considered supplemental to the development, testing, and deployment of software applications that interact with certified API technology, and are permitted fees for value added services as finalized in § 170.404(a)(3)(iv). (D) Record-Keeping Requirements We proposed in § 170.404(a)(3)(v) that API Technology Suppliers must keep for inspection detailed records of all API technology fees charged, all costs incurred to provide API technology to API Data Providers, methodologies used to calculate such fees, and the specific costs to which such fees are attributed. We requested comment in 84 FR 7492 on whether these requirements provide adequate traceability and accountability for costs permitted under this API Condition of Certification and whether to require more detailed accounting records or prescribe specific accounting standards. Comments. A majority of commenters expressed concerns with the level of granularity proposed for record keeping in § 170.404(a)(3)(v). These commenters stated that the required recordkeeping would exceed documentation performed for any other purpose. Some commenters stated that the requirement for health IT developers to track who pays fees and how fees enter the system will cause significant administrative burden, especially on smaller vendors or vendors with business models that require less operational overhead. Additionally, they stated that the requirement for clients to maintain and potentially publicly disclose records of fees for inspection would place a burden on IT providers, and could potentially allow bigger companies to engage in practices such as predatory pricing. Commenters suggested ONC have a more scaled-back method, and simply allow patients the ability to access their EHI without charge. These commenters recommended focusing on a good conduct approach rather than prescriptive requirements. Response. We thank commenters for their feedback and perspective. We moved § 170.404(a)(3)(v) to 170.404(a)(3)(i)(D) for better organization because this provision applies to the permitted fee Condition of Certification requirements finalized in § 170.404(a)(3)(ii) through (iii). We have finalized in § 170.404(a)(3)(i)(D) that Certified API Developers must keep detailed records for inspection of all fees charged, all costs incurred to provide certified API technology to API Information Sources, methodologies E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations used to calculate such fees, and the specific costs to which fees are attributed. Considering the feedback on perceived burden, we believe transparency and documentation of API fees is necessary to mitigate unfair pricing practices that may stifle innovation or otherwise create barriers to the goals of enabling API-based access, exchange, and use of EHI without special effort. Further, we believe that the accounting practices already used by health IT developers will largely support the health IT developer to meet this requirement. Examples of these practices by health IT developers include the methods used to track their own investments, determine how to bill and issue invoices to their customers, document receipt of payment, and to maintain overall accurate financial records of business transactions. We find it difficult to believe, as some commenters appeared to indicate, that health IT developers are not already keeping such financial records and that this requirement would create substantial new documentation burden for Certified API Developers. The record-keeping requirements finalized in 170.404(a)(3)(i)(D) foster transparency and promote accountability in the Program. In response to the comments received, we have not added additional requirements for accounting records or standards. (E) Permitted Fee for Development, Deployment, and Upgrades We proposed in § 170.404(a)(3)(ii) to permit an API Technology Supplier to charge API Data Providers reasonable fees for developing, deploying, and upgrading Health IT Modules certified to § 170.315(g)(7) through (g)(11). Comments. Many commenters applauded the permitted fee related to development, deployment, and upgrading API technology. The majority supported the proposal that fees would not be permitted if they interfere with an API User’s ability to efficiently and effectively develop and deploy production-ready software. A few commenters expressed concern that our proposals regarding development, deployment, and upgrade fees were not restrictive enough. Commenters noted that API Technology Suppliers will use the allowable fees, such as for program upgrades, as a barrier to providing interoperability between systems or other applications and a means to eliminate competitive threats. Some of these commenters recommended that ONC explicitly prohibit API Technology Suppliers from charging any fees for implementing APIs and for facilitating the interoperable exchange of EHI and VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 that this blanket prohibition apply to all new and updated API technology. A few commenters noted that it is possible that API Technology Suppliers will bundle or upcharge service fees to recoup API technology development costs and API Technology Suppliers should not be allowed to charge costs for development or impose surcharges for product feature development. They noted that product feature development should be considered a cost of doing business and can be amortized as a one-time capital expense across the vendor’s entire customer base without the need for recovering costs from API Users. They emphasized that API access and use prices need to be transparent as the intent of Congress was to have APIs be made easily available and at no or low cost, not to be a source of revenue for profit. Other commenters noted that the development of the APIs themselves should be regarded as part of the license fee and the API Technology Suppliers should not be permitted to charge an additional license fee to either the API Data Provider or API User for what is an inherent part of the software. Another commenter requested that consideration be applied toward potential additional hidden integration fees. Response. We appreciate the support, concerns, and recommendations from commenters. We finalized this proposal in § 170.404(a)(3)(ii) as proposed with updated terms based on the revised finalized definitions in § 170.404(c). We refer to the discussions below and 84 FR 7488 for additional details on what Certified API Developer fees for ‘‘developing,’’ ‘‘deploying,’’ and ‘‘upgrading’’ certified API technology comprise. We also note that the nature of the costs charged under this category of permitted fees depends on the scope of the work to be undertaken by a Certified API Developer (i.e., how much or how little labor an API Information Source requires of the Certified API Developer to deploy and upgrade the certified API technology). We sincerely thank commenters for the various recommendations to prohibit or restrict fees regarding certified API technology. In order to reconcile the recommendations specific to § 170.404(a)(3)(ii) and other conditions in this final rule, we have aligned related conditions to address concerns and mitigate potential fee practices that could limit API-based access, exchange, and use of EHI by patients and other stakeholders without special effort. As finalized, we believe the fees permitted in § 170.404(a)(3)(ii) and § 170.404(a)(3)(i)(B), transparency requirements in § 170.404(a)(2), and openness and pro-competitive PO 00000 Frm 00115 Fmt 4701 Sfmt 4700 25755 conditions in § 170.404(a)(4) will ensure that fees permitted for upgrade costs will not be used as a barrier to providing interoperability between systems or other applications, or as a means to eliminate competitive threats. Additionally, the transparency requirements regarding the publication of fees finalized in § 170.404(a)(2)(ii)(B) will help prevent hidden integration fees cited by commenters. We thank commenters for recommending and noting that development of the APIs themselves should be regarded as part of a license fee and that Certified API Developers should not be permitted to charge an additional license fee for what is an inherent part of the software. In response to this recommendation, we have added a provision in § 170.404(a)(3)(i)(C)(3) that states that permitted fees in § 170.404(a)(3)(ii) through (iv) may not include any costs that led to the creation of IP, if the actor charged a royalty for that IP pursuant to the information blocking Licensing Exception (§ 171.303). This provision aligns with similar provisions included in the information blocking section and will ensure that Certified API Developers cannot earn a double recovery in instances described by the commenter. We will continue to work with stakeholders to advance policies that promote interoperability and deter practices that may stifle innovation or present barriers to the access, exchange, and use of EHI through APIs. Subject to the general conditions in § 170.404(a)(3)(i), our final policies support the ability of Certified API Developers to recover the full range of reasonable costs associated with developing, deploying, and upgrading API technology over time. It is important that Certified API Developers be able to recover these costs and earn a reasonable return on their investments so that they have adequate incentives to make continued investments in these technologies. In particular, we anticipate Certified API Developers will need to continually expand the data elements and upgrade the capabilities associated with certified APIs as the USCDI and HL7® FHIR® standard and associated implementation specifications mature. We refer readers to the information blocking section of this preamble (VIII) for additional information on activities that may constitute information blocking and for discussion about how the fees provisions in this Condition of Certification and within the information blocking section support innovation. E:\FR\FM\01MYR3.SGM 01MYR3 25756 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations Comments. Some developers expressed concern regarding balancing and distributing costs with regard to the permitted fee for developing, deploying, and upgrading technology. The commenters noted ONC proposed that the cost for development be distributed among those who will use it, which they felt was problematic in many ways, but most fundamentally because it suggests a serious misconception about how software development is funded, priced, and sold. The commenters emphasized that requiring development costs to be divided among clients purchasing the API necessitates new and complex business processes and creates unsolvable scenarios that could easily create business conflicts between API Technology Suppliers and their clients. At least one commenter suggested that ONC should consider balancing the costs associated with API development and deployment across both API Data Providers and certain API Users to ensure that third-party software application developers also bear some of the financial burden, since they stand to generate revenue from the use of their apps. Commenters asked ONC clarify why it believes it is inappropriate to pass development, deployment, and upgrade costs on to API Users. Other commenters noted that the costs for updating information systems and Health IT Modules to the new standards and requirements should not be passed on to physicians and patients. Response. We appreciate the feedback from commenters. We proposed and finalized this permitted fee for development, deployment, and upgrade costs because we believe that these costs should be negotiated solely between the Certified API Developer that supplies the capabilities and the API Information Source that implements them in their production environment. In our view, it is inappropriate for Certified API Developers to go around the API Information Source to directly impose financial cost burdens on API Users for the benefit of working with or connecting to the API Information Source. Based on our experience, the practice of a Certified API Developer going around its customer (the API Information Source) to also charge API Users erodes an API Information Source’s choice and the independence of their relationship with API Users. As such, that kind of business practice would be something that we would consider creating special effort on the part of the API Users if they had to continue to face additional fees just for permission to work with or connect to VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 an API Information Source’s certified API technology. While the development, deployment, and upgrade permitted fee is limited between the Certified API Developer and API Information Source as a way to recoup a Certified API Developer’s costs to supply certified API technology to a particular API Information Source, we again reiterate that the value added services permitted fee providers Certified API Developers a wide range of options to make additional revenue related to their certified API technology. Should API Users stand to generate revenue from the use of their apps, any fee an API Information Source may impose would not be in scope for this Condition of Certification but would be likely be covered by information blocking. Accordingly, we emphasize that such stakeholders should take care to ensure they are compliant with other Federal and State laws and regulations that may prohibit or limit certain types of relationships involving remuneration. In response to comments suggesting that costs for updating information systems and Health IT Modules to the new standards and requirements would be passed on to physicians and patients, we disagree. We emphasize that most of the information contained in a patient’s electronic record has been documented during the practice of medicine or has otherwise been captured in the course of providing health care services to patients. In our view, patients have effectively paid for this information, either directly or through their employers, health plans, and other entities that negotiate and purchase health care items and services on their behalf, and should be able to access the information via certified API technology without fees. Comments. Some developers suggested that API Technology Suppliers should be able to charge fees for access to a test environment and requested clarification as to whether an API Technology Supplier can charge for the use of sandboxes by API Users. Response. We appreciate the feedback from commenters. As detailed in the ‘‘General Examples of Prohibited Fees’’ section of the preamble text and included in the general prohibition finalized in § 170.404(a)(3)(i)(A), Certified API Developers are prohibited from charging fees in connection with any services essential to a developer or other person’s ability to develop and commercially distribute productionready applications for use with certified API technology. In general, if a test environment or sandbox is required to be used by a Certified API Developer and is essential for an application to be PO 00000 Frm 00116 Fmt 4701 Sfmt 4700 developed in order to be considered production-ready by the Certified API Developer for use with its certified API technology, then fees associated with that kind of test environment would be prohibited as they would impose special effort. However, we note that this prohibition is not globally applicable. If instead, the purpose of the testing environment was to provide specific testing above-and-beyond productionreadiness for use with certified API technology, then fees could be charged for such testing as part of the valueadded services permitted fee. Comments. A few commenters requested guidance on how ONC expects API Technology Suppliers to account for the costs incurred to develop, deploy, and upgrade the API technology, which is part of, and not necessarily separable from, the broader EHR product. Several commenters opposed the prohibition against charging for work to upgrade the broader EHR product, expressing that this is essential work needed to modernize their solutions as broader technologies evolve. One commenter noted that the Proposed Rule does not set specific guidelines on what constitutes an upgrade or how much the fee could be, and it is the commenter’s experience that EHR systems often charge fees for such services as integrating with a clinical data registry or using outside or non-preferred software. Response. We thank stakeholders for their comments. While we understand that there is overlap between features of the certified API technology and the ‘‘broader EHR product,’’ we refer specifically to development, deployment, and upgrades made to ‘‘certified API technology’’ as defined in § 170.404(c). Namely, development, deployment, and upgrades made to the capabilities of certified Health IT Modules that fulfill the API-focused certification criteria adopted at § 170.315(g)(7) through (10). In response to commenters concerned that EHR developers often charge fees for services such as integrating with a clinical data registry or using outside or nonpreferred software, we note that, as described in § 170.404(a)(3)(i)(A), Certified API Developers are prohibited from imposing fees associated with certified API technology unless included as a permitted fee in § 170.404(a)(3)(ii) through (iv). We do not include specific price information for permitted fees to develop, deploy, or upgrade API technology, because these costs are subject to change over time with new technology and varying development, deployment, and upgrade E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations efforts. Instead, we allow Certified API Developers to recover their costs (including costs that result in a reasonable profit margin for permitted fees in § 170.404(a)(3)(ii) and § 170.404(a)(3)(iv)) in providing certified API technology while being compliant with the Condition and Maintenance of Certification and Program requirements. We include descriptions of fees for developing, deploying, and upgrading API technology in the sections that follow, in which we offer additional clarity, as discussed in the Proposed Rule at 84 FR 7488, on the fees for developing, deploying, and updating API technology. (i) Fees for Developing Certified API Technology Fees for ‘‘developing’’ certified API technology comprise the Certified API Developer’s costs of designing, developing, and testing certified API technology. In keeping with our discussion at 84 FR 7488, fees for developing certified API technology must not include the Certified API Developer’s costs of updating the nonAPI related capabilities of the Certified API Developer’s existing Health IT Modules, including its databases, as part of its development of the certified API technology. As we further discussed in 84 FR 7488 in our Proposed Rule, these costs are connected to past business decisions made by the Certified API Developer and typically arise due to Health IT Modules being designed or implemented in nonstandard ways that unnecessarily increase the complexity, difficulty or burden of accessing, exchanging, or using EHI. The recovery of costs associated with updating a Certified API Developer’s non-API related Health IT Modules capabilities would be inconsistent with the Cures Act requirement that API technology be deployed ‘‘without special effort.’’ (ii) Fees for Deploying Certified API Technology Certified API Developer’s fees for ‘‘deploying’’ certified API technology comprise the Certified API Developer’s costs of operationalizing certified API technology in a production environment. Such fees include, but are not limited to, standing up hosting infrastructure, software installation and configuration, and the creation and maintenance of API Information Source administrative functions. We discussed in our Proposed Rule that a Certified API Developer’s fees for ‘‘deploying’’ certified API technology does not include the costs associated with managing the traffic of API calls that are VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 used to access the certified API technology, which a Certified API Developer can only recover under the permitted fee for usage support costs (§ 170.404(a)(3)(iii)). We emphasize that for the purpose of this Condition of Certification, we consider that certified API technology is ‘‘deployed’’ by the customer—the API Information Source—that purchased or licensed it. (iii) Fees for Upgrading Certified API Technology The Certified API Developer’s fees for ‘‘upgrading’’ certified API technology comprise the Certified API Developer’s costs of supplying an API Information Source with an updated version of certified API technology. Such costs would include the costs required to bring certified API technology into conformity with new requirements of the Program, upgrades to implement general software updates (not otherwise covered by development fees or under warranty), or developing and releasing newer versions of the certified API technology at the request of an API Information Source. The nature of the costs that can be charged under this category of permitted fees depends on the scope of the work undertaken by a Certified API Developer (i.e., how much or how little labor an API Information Source requires of the Certified API Developer to upgrade the certified API technology being supplied from one version or set of functions to the next). (F) Permitted Fee to Recover Costs of Supporting API Usage We proposed in 84 FR 7489 in § 170.404(a)(3)(iii) to permit an API Technology Supplier to charge API usage-based fees to API Data Providers to recover the API Technology Supplier’s reasonable incremental costs for purposes other than facilitating the access, exchange, or use of EHI by patients or their applications, technologies, or services. We considered ‘‘usage-based’’ fees to be the fees imposed by an API Technology Supplier to recover the costs that would typically be incurred supporting API interactions at increasing volumes and scale within established service levels. Additionally, in 84 FR 7489 under § 170.404(a)(3)(iii), we proposed that any usage-based fees associated with API technology be limited to the recovery of the API Technology Supplier’s ‘‘incremental costs.’’ Additionally, we proposed in § 170.404(a)(3)(iii)(A) that the permitted fee would not include any costs incurred by the API Technology Supplier to support uses of the API technology that facilitate a patient’s ability to access, exchange, or use their PO 00000 Frm 00117 Fmt 4701 Sfmt 4700 25757 EHI. Finally, we proposed in § 170.404(a)(3)(iii)(B)–(C) restrictions for permitted fees that were moved to the general permitted fees section finalized in § 170.404(a)(3)(i)(C). Comments. Commenters generally supported our proposal to permit an API Technology Suppliers to charge usagebased fees to API Data Providers to the extent that the API technology is used for purposes other than facilitating the access, exchange, or use of EHI by patients or their applications, technologies, or services. Response. We appreciate support from commenters and have finalized this proposal in § 170.404(a)(3)(iii) with some modification. We amended the title of the regulation text for clarity in § 170.404(a)(3)(iii) to ‘‘Permitted fee— Recovering API usage costs.’’ Additionally, we amended the regulation text to focus on usage-based fees and Certified API Developer’s reasonable incremental costs. We did not finalize the specific prohibition on permitted fees proposed in § 170.404(a)(3)(iii)(A) that the ‘‘permitted fee does not include costs incurred by the API Technology Supplier to support uses of the API technology that facilitate a patient’s ability to access, exchange, or use electronic health information.’’ We did not finalize this aspect of the provision because upon further consideration of this cost and the fee prohibition included in information blocking related to patient access, we determined that these fees remain necessary in order to allow Certified API Developers to recover incremental costs reasonably incurred during the process of hosting certified API technology on behalf of the API Information Source. We reiterate that a Certified API Developer’s ‘‘incremental costs’’ comprise the Certified API Developer’s costs that are directly attributable to supporting API interactions at increasing volumes and scale within established service levels. A Certified API Developer should ‘‘price’’ its costs of supporting access to the certified API technology by reference to the additional costs that the Certified API Developer would incur in supporting certain volumes of API use. For comments and responses related to the proposed provisions in § 170.404(a)(3)(iii)(B) and (C), we refer readers to the header ‘‘Certified API Developer Prohibited Fees.’’ Comments. We received a few comments focused on volume thresholds and incremental costs. A few commenters supported a reasonable cap for API call fees. Several recommended changing the parameters around API usage-based fees to focus on volume E:\FR\FM\01MYR3.SGM 01MYR3 25758 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations thresholds being included in any contractual language related to these fees, to ensure that any incremental costs attributable to supporting API interactions at increasing volumes and scale are addressed appropriately. Commenters noted that if an API Technology Supplier is receiving fees to develop, deploy, and upgrade API technology, it is unlikely that they would also need to charge for usage of the APIs, as long as their usage remains under a pre-determined volume threshold. A few commenters noted that the volume of requests that will be pinging APIs may compromise the performance of data retrieval and effective user experience. In order to protect against denial of service attacks whether intentional or inadvertent, they stated ONC should consider an additional throttling or rate-limiting layer or capability onto the API in order for the API to accept and digest the data being entered or extracted. A few commenters noted that our proposal could create loopholes that would enable certain organizations to charge highly burdensome, excessive fees to clinical registries to access their data. A few commenters expressed concern that this proposal is not restrictive enough. Some commenters requested that ONC provide more definitive guidance, including a range of prices based on examples from the current marketplace, to ensure providers are not charged unreasonable fees by API Technology Suppliers and can reasonably charge API Users for the cost of accessing their API technology. Response. We appreciate the feedback from commenters. This Condition of Certification requirement offers the flexibility necessary to accommodate reasonable pricing methodologies and will allow Certified API Developers to explore innovative approaches to recovering the costs associated with supporting the use of certified API technology with a permitted fee. As described in the Proposed Rule (84 FR 7489), ‘‘usage-based’’ fees are fees imposed by a Certified API Developer to recover costs typically incurred for supporting API interactions at increasing volumes and scale within established service levels. That is, ‘‘usage-based’’ fees recover costs incurred by a Certified API Developer due to the actual use of the certified API technology once it has been deployed (e.g., costs to support a higher volume of traffic, data, or number of apps via the certified API technology). Certified API Developers can adopt a range of pricing methodologies when charging for the support of API usage. We appreciate commenters’ request to VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 establish a reasonable cap for API usagebased fees, but the focus of our policy is to identify usage fees as a type of permitted fee and not to dictate a singular fee model, which we believe could limit Certified API Developers ability to create innovative fee models that serve to benefit themselves and API Information Sources. We decline to include a price cap for API usage-based fees or a range of prices for API fees based on examples from the current marketplace because we anticipate the cost of technology will change over time and so too will the way in which usage costs are calculated. Additionally, while we understand and expect that Certified API Developers and API Information Sources will deploy particular security methods to mitigate the risk of denial of service attacks and other impacts on API availability, these types of technology layers are separate from the focus of our policy on permitted API usage fees. Comments. Several commenters requested that ONC further clarify that API Technology Suppliers should not attempt to charge different fees for different API transactions as they frequently do today. Response. We appreciate this information and feedback from commenters. We clarify that Certified API Developers are permitted to charge ‘‘usage-based’’ fees to recover the costs that would typically be incurred supporting API transactions at increasing volumes and scale within established service levels. To clarify, usage-based fees recover costs incurred by a Certified API Developer related to the actual use of certified API technology once it has been deployed (e.g., costs to support a higher volume of traffic, data, or number of apps via the API Technology). We acknowledge that Certified API Developers could adopt a range of pricing methodologies when charging for the support of API usage, including potentially charging higher prices for some API transactions that incur relatively higher costs than others. However, in combination with this flexibility, Certified API Developers will still need to be mindful of not violating any overarching information blocking policies. We refer readers to a discussion in the Proposed Rule in 84 FR 7489 for additional discussions on usage-based fees. Comments. Some commenters emphasized that it is unreasonable to presume that API User-driven data overages should be the responsibility of the API Data Provider. While other commenters expressed concern that our proposal will leave providers, who are mandated to use certified EHRs that include API technology and provide PO 00000 Frm 00118 Fmt 4701 Sfmt 4700 patients with access to data via those APIs, responsible for a variety of unwarranted costs with little recourse to recover those costs. Response. While we understand the perspective from which these concerns arise, especially regarding unpredictable overuse of certified API technology, an API Information Source has financial responsibility for its overall technology infrastructure. This accountability is no different for certified API technology than it is for non-certified APIs and other interfaces that may also create costs for the API Information Source (i.e., health care provider). Given that API Users can also include an API Information Source’s own employees/ internal tools and 3rd party partners’ tools, an API Information Source is best positioned and generally accountable for its financial commitments. Again, as noted above, we do not limit who may pay for the charges an API Information Source incurs. An API Information Source should have full knowledge and ability to assess what employees, internal applications, and 3rd party services it has granted access to use and interact with its certified API technology. With respect to potential overages as a result of patient access, as we have stated before, we believe patients have effectively paid for this information, either directly or through their employers, health plans, and other entities that negotiate and purchase health care items and services on their behalf, and believe they should not be charged. Additionally, as stated in the Proposed Rule (84 FR 7489) and finalized here, usage fees for certified API technology will only apply when the Certified API Developer acts on behalf of the API Information Source to deploy its certified API technology. In scenarios where the API Information Source, such as a large hospital system, assumes full responsibility for the technical infrastructure necessary to deploy and host the certified API technology it has acquired, the volume and scale of its usage would be the API Information Source’s sole responsibility, and a Certified API Developer would not be permitted to charge usage-based fees. Instead, the Certified API Developer would be limited to charge fees under the ‘‘development, deployment, upgrade’’ permitted fee in § 170.404(a)(3)(ii). Additionally, the costs recovered under ‘‘usage-based’’ fees can only reflect ‘‘post-deployment’’ costs. As such, ‘‘usage-based’’ fees cannot include any costs necessary to prepare and ‘‘get the certified API technology up, running, and ready for use,’’ which are costs that must be E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations recovered as part of the deployment services delivered by the Certified API Developer if permitted under § 170.404(a)(3)(ii). Comments. Several commenters supported ONC’s efforts to bolster patient access, noting that the capacity to offer a patient’s access to all elements of their electronic medical record, through an API, without cost, is wellsupported in the Proposed Rule. One commenter noted that the proposed provisions regarding fees supports uses of the API technology that facilitate a patient’s ability to access, exchange, or use their EHI. The commenters noted that the clear language in the Proposed Rule will prevent any potential confusion or friction in the future. A few commenters expressed concern that application developers will attempt to leverage the patient access fee limitations by claiming to be patient facing. One commenter suggested that the proposed fee limitations regarding patient access applied only with respect to fees API Technology Providers impose on API Data Providers, should also apply to fees charged to consumerfacing application developers who in the past have been charged high fees by CEHRT developers. One commenter recommended making it clear that provider organizations and health IT developers cannot charge patients, or the apps that they use, for using patientfacing APIs. At least one commenter requested that ONC clarify that permitted usage-based fees do not apply to patients or patient designees. Response. We thank commenters for their support for restricting API-related fees. As noted above, we have reconfigured the permitted fee for usage costs in response to public comments and our assessment of the intersection of API permitted fees policies and information blocking policies. We have finalized an approach that permits Certified API Developers to recover incremental usage costs reasonably incurred during the process of hosting certified API technology on behalf of an API Information Source, which could include fees to the API Information Source for providing and supporting patient access. However, the Certified API Developers and API Information Sources cannot recover these costs from patients or the developers of applications that facilitate access to and receipt of patients’ EHI. Patients have already effectively paid for their EHI, either directly or through their employers, health plans, and other entities that negotiate and purchase health care items and services on their behalf. We refer readers to the Fees Exception in the information blocking VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 section of this final rule in VII.D.2.b, which applies to health IT developers and a broader set of actors than these Condition and Maintenance of Certification requirements, for a discussion of the restrictions on charging patients for access to their EHI. Comments. Several commenters requested that ONC provide further guidance on the types of costs that a developer could charge to permit API Data Suppliers to offer population-level queries to API Users. They requested ONC clarify that such usages fees must relate to the costs associated with actual hardware (e.g., server space) needed to support the increased volume of queries for non-patients and not the cost of implementing the population-level query functionality itself. Response. We clarify that API usage fees related to API ‘‘read’’ services for multiple patients would be calculated using a similar methodology to calculate API usage fees related to API ‘‘read’’ services for single patients. These ‘‘usage-based’’ fees are fees imposed by a Certified API Developer to recover the costs typically incurred to support API interactions for API ‘‘read’’ services for multiple patients once these services have been deployed. This could include, but not be limited to, costs to support a higher volume of traffic, data, or number of apps via the certified API technology (which could include higher costs for hardware, including server space). We appreciate the recommendation from commenters; however, we have not prescribed the centralization of all of this content. Comments. Some commenters suggested that API Technology Suppliers publish their fees on the same website as their API documentation so there is full transparency and an API Data Supplier and API User can easily understand costs before embarking upon development. Response. We appreciate the recommendation and support from commenters. As finalized under § 170.404(a)(2)(ii)(B), a Certified API Developer must publish all terms and conditions for its certified API technology, including any fees. Any and all fees charged by a Certified API Developer for the use of its certified API technology must be described in detailed, plain language, including the persons or classes of persons to whom the fee applies; the circumstances in which the fee applies; and the amount of the fee, which for variable fees must include the specific variable(s) and methodology(ies) that will be used to calculate the fee. Comments. Some commenters stated that usage-based fees may not be PO 00000 Frm 00119 Fmt 4701 Sfmt 4700 25759 appropriate. They stated that, in the case of TEFCA, HIEs and providers must be responsive to inbound requests to broadcast data and should not be charged a fee for responding to such requests. They explained that such an arrangement could be used maliciously between market participants seeking to increase the operational expenses of their competitors. Response. We appreciate this comment, but we continue to believe that that usage-based fees should be permitted subject to the conditions described in § 170.404(a)(3)(iii). We have addressed commenter’s concern regarding potential anticompetitive behavior through the final provisions in § 170.404(a)(3)(i)(B). Specifically, in § 170.404(a)(3)(i)(B)(1), a Certified API Developer must ensure that fees are based on objective and verifiable criteria that are uniformly applied for all similarly situated classes of persons and requests. In addition, under § 170.404(a)(3)(i)(B)(4), a Certified API Developer must ensure that fees are not based in any part on whether the requestor or other person is a competitor, potential competitor, or will be using the certified API technology in a way that facilitates competition with the Certified API Developer. Comments. Several commenters expressed concern about incremental costs that can be recovered by actors supporting the use of APIs for purposes other than patient access. They requested ONC clarify that recovery of incremental costs for these other purposes should not be allowed, because they believed the incremental costs do not add any efficiency to the health care system, do not benefit patients, and do not serve any other procompetitive purpose. Response. We appreciate these comments, but continue to believe that ‘‘incremental costs’’ should be allowed. A Certified API Developer’s ‘‘incremental costs’’ comprise the Certified API Developer’s costs that are directly attributable to supporting API interactions at increasing volumes and scale within established service levels. We believe a Certified API Developer should ‘‘price’’ its costs of supporting access to the certified API technology by reference to the additional costs that the Certified API Developer would incur in supporting certain volumes of API use. In practice, we expect that this means that a Certified API Developer will offer a certain number of ‘‘free’’ API calls based on the fact that, up to a certain threshold, the Certified API Developer will not incur any material costs in supporting certified API technology in addition to the costs recovered for E:\FR\FM\01MYR3.SGM 01MYR3 25760 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations deployment services. However, after this threshold is exceeded, we expect that the Certified API Developer will impose usage-based costs commensurate to the additional costs that the Certified API Developer must incur to support certified API technology use at increasing volumes and scale. We expect that Certified API Developers will charge fees that are correlated to the incremental rising of costs required to meet increased demand. For example, if, at a certain volume of API calls, the Certified API Developer needed to deploy additional server capacity, the associated incremental cost of bringing an additional server online could be passed on to the API Information Source because the certified API technology deployed on behalf of the API Information Source was the subject of the higher usage. In this example, up until the point that the threshold is reached, the additional server capacity is not required, so the Certified API Developer would not be permitted to recover the costs associated with it. Moreover, the additional server capacity would support ongoing demand up to a certain additional volume, so the Certified API Developer would not be permitted to recover the costs of further additional server capacity until the existing capacity was exhausted. (G) Permitted Fee for Value-Added Services We proposed in 84 FR 7490 and 7491 in § 170.404(a)(3)(iv) to permit an API Technology Supplier to charge fees to API Users for value-added services supplied in connection with software that can interact with the API technology. We also clarified in 84 FR 7491 that a fee will only be permitted if it relates to a service that an API User, such as a software developer, can elect to purchase, but is not required to purchase in order to develop and deploy production-ready apps for API technology. Comments. Several commenters supported our proposal to permit an API Technology Supplier to charge fees to API Users for value-added services supplied in connection with software that can interact with certified API technology. Some commenters requested certain clarifications regarding our proposal. One commenter requested that we clarify within the discussion of value-added services, that references to ‘‘app stores’’ and ‘‘listing processes’’ for software applications that register to connect with the API technology are solely intended as examples to illustrate when a fee would or would not qualify as a ‘‘value-added VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 service,’’ and are not meant to convey a requirement or expectation that API Technology Suppliers provide an app store with application listing free of charge. A few commenters requested that ONC clarify that EHR developers can charge value-add fees without triggering the information blocking provision. A couple other commenters requested additional examples of what constitutes a ‘‘value-added’’ service for which an API Technology Supplier can charge fees to an API User. Response. We thank commenters for the feedback. We have finalized § 170.404(a)(3)(iv) as proposed, with the exception of updating terms based on the definitions finalized in § 170.404(c). Our final policy permits Certified API Developers to charge fees, including a reasonable profit margin, to API Users for value-added services related to certified API technology, so long as such services are not necessary to efficiently and effectively develop and deploy production-ready software that interacts with certified API technology. We clarify that the value-added services need to be provided in connection with and supplemental to the development, testing, and deployment of productionready software applications that interact with certified API technology. A fee is permitted if it relates to a service that a software developer can elect to purchase from a Certified API Developer, but is not required to purchase in order to develop and deploy production-ready apps for certified API technology. In response to comments for clarity, we note that examples used to illustrate when a fee would or would not qualify as a ‘‘value-added service,’’ such as app store listing, are demonstrative, but not required unless otherwise noted in the regulation text. Under this condition, we permit fees for services associated with the listing and promotion of apps beyond basic application placement so long as the Certified API Developer ensures that basic access and listing in the app store is provided free of charge (if an application developer depended on such listing to efficiently and effectively develop and deploy production-ready apps for use with certified API technology). Fees charged for additional/specialized technical support or promotion of the API User’s application beyond basic access and listing services would be examples of permitted value-added services. We caution health IT developers not to over-interpret the scope of this Condition of Certification, which is focused on certified API technology. To the degree that a health IT developer administers an ‘‘app store’’ and offers value-added services associated with PO 00000 Frm 00120 Fmt 4701 Sfmt 4700 certified API technology, the Condition of Certification covers its practices related to certified API technology only. Conversely, this Condition of Certification would not apply to any practices that do not involve certified API technology. However, health IT developers would need to be mindful of any applicable information blocking rules that may apply to their app store practices given applicable facts and circumstances. Regarding the request for specific value-added fees that would not constitute information blocking, we refer readers to the information blocking section (VIII) of this preamble. (H) Request for Comment on § 170.404(a)(3) We requested comment at 84 FR 7491 on any additional specific ‘‘permitted fees’’ not addressed in our Proposed Rule (84 FR 7491) that commenters felt API Technology Suppliers should be able to recover in order to assure a reasonable return on investment. Furthermore, we requested comment on whether it would be prudent to adopt specific, or more granular, cost methodologies for the calculation of the permitted fees. We encouraged commenters to consider, in particular, whether the approach we described would be administrable and appropriately balance the need to ensure that stakeholders do not encounter unnecessary costs and other special effort with the need to provide adequate assurance to API Technology Suppliers, investors, and innovators that they will earn a reasonable return on their investments in API technology. We welcomed comments on whether the approach adequately balances these concerns and achieves our stated policy goals. We also welcomed comments on potential revisions or alternative approaches. We encouraged detailed comments that included, where possible, economic justifications for suggested revisions or alternative approaches. Comments. Commenters suggested we alter our approach to APIs so that it is tiered fee structure. They suggested that ONC could establish categories where the technology requirements designate the fees: (1) A ‘‘no fee’’ category would limit API Technology Suppliers from charging API Data Providers or API Users any fees for exchanging data in compliance with Federal requirements; (2) an ‘‘at cost’’ category would allow API Technology Suppliers to charge API Data Providers or API Users the cost of interfacing APIs with a non-API Technology Supplier’s commercial technology; and (3) a ‘‘cost plus reasonable profit’’ category would allow E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations API Technology Suppliers to charge API Data Providers or API Users a reasonable profit when conducting legitimate custom API development or creating custom apps. Response. We appreciate the recommendation from commenters, but we have not adopted a tiered fee structure in the final rule because it would require unnecessary specificity and prescribe a particular method that could have unintended effects of limiting the market’s evolution over time. We believe the current structure for prohibited and permitted fees allows for the adequate cost recovery and reasonable profit by Certified API Developers while also establishing the guardrails around which API access can be enabled without special effort. Comments. Many commenters expressed concerns related to the effect our proposals regarding API fees would have on innovation and business. Several commenters noted that the structure of permitted fees could have unintended consequences that will ultimately work to impede innovation, increase administrative burden, and focus on cost recovery rather than creation of novel ways to improve data access. Several developers stated that the proposed fee structure specifically works to sever business relationships between API Technology Providers and API Users for anything other than ‘‘value added services’’ and effectively eliminates the ability for API Users to work directly with API Technology Suppliers to innovate and accelerate API development, and to achieve truly integrated and supported products throughout the product lifecycle. They suggested that a better model would be one that gives API Data Providers rights to leverage APIs ‘‘without special effort,’’ while supporting the ability for API Technology Suppliers and API Users to voluntarily engage in direct business relationships under mutually agreeable terms that are fair and equitable. Some developers stated that the market should determine permitted fees. They stated that in order to maintain a vigorously competitive market, API Technology Suppliers must be adequately compensated for their work to create and deploy non-standard APIs and support expanding standards. They explained that without this compensation, there will be far fewer entrants into the certified health IT space and current participants will depart. A couple of developers recommended that ONC allow revenue-sharing models for certain components of certified APIs. The commenters suggested that ONC VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 should view revenue sharing arrangements as a type of market-based compensation that will ultimately benefit innovation and competition. Conversely, one commenter stated that it is essential that API Technology Suppliers be expressly prohibited from conditioning access to API technology on charging revenue-sharing or royalty agreements to API Data Providers or API Users outside of actual usage costs incurred. The commenter noted this rent-seeking behavior is anticompetitive in nature and can have a significant impact on squelching any new market entrants and allow existing health IT actors to prevent all the positive outcomes that could arise from the ONC’s proposed rules. Some developers stated that the prohibition against health IT developers charging for work to update their code structure is unreasonable, emphasizing that this is important work that is necessary for companies to be able to modernize their solutions as broader technologies evolve. Response. We appreciate these comments, but disagree with commenters regarding the potential negative effect of the final permitted fee structure on innovation. We also note that the value-added services permitted fee does permit a direct relationship between Certified API Developers and API Users. What is generally prohibited and what we noted presented ‘‘special effort’’ in the Proposed Rule were Certified API Developer practices that required an API Information Source to seek permission to use its own certified API technology from the Certified API Developer. We reiterate that complying with the requirements of this permitted fee and the information blocking exception will generally not prevent an actor from making a reasonable profit in connection with the access, exchange, or use of EHI. To be responsive to comments, we have added a provision in § 171.404(a)(3)(i)(A) to clarify this point. This final provision states that certain permitted API fees (§ 170.404(a)(3)(ii) and § 170.404(a)(3)(iv)) may include fees that result in a reasonable profit margin in accordance with the Costs Exception (§ 171.302). We believe that the allowance of reasonable profits is necessary to incentivize innovation and allow innovators to earn returns on the investments they have made to develop, maintain, and update innovations that ultimately improve health care delivery and benefit patients. Our finalized approach to API fees strikes the appropriate balance of addressing the rent-seeking and exclusionary pricing PO 00000 Frm 00121 Fmt 4701 Sfmt 4700 25761 practices noted by the commenters while enabling and supporting innovation. We also emphasize that a majority of the EHI has been generated and recorded in the course of furnishing health care services paid with public dollars through Federal programs, including Medicare and Medicaid, or directly subsidized through the tax preferences for employer-based insurance. Yet, this EHI is not readily available where and when it is needed. We believe the overwhelming benefits of publishing certified APIs that allow EHI from such technology to be accessed, exchanged, and used without special effort far outweigh the potential burden on Certified API Developers and API Information Sources. Comments. A few commenters requested that ONC clarify whether API Data Suppliers would be allowed to recoup costs from API Users in light of the information blocking provisions. A few commenters expressed confusion that fees are addressed under the API Condition and Maintenance of Certification and information blocking. The commenters suggested that ONC address fees in one consolidated section. Response. We appreciate this comment and refer readers to the information blocking section of this rule. We do not believe that a discussion of fees should be consolidated in one section for a couple of reasons. First, the information blocking provision has a much broader reach than the Condition and Maintenance of Certification requirements and regulates conduct of health IT developers of certified Health IT Modules, health care providers, health information networks, and health information exchanges. The Condition and Maintenance of Certification requirements only relate to conduct by health IT developers of certified Health IT Modules. Second, the API Condition of Certification covers a much narrower scope of potential fees, as the fees in this section are specific to certified API technology only while fees in the information blocking section generally relate to the access, exchange, or use of EHI regardless of the particular technology used. We emphasize that we have finalized a provision in § 171.302(c) that if the actor is a health IT developer subject to the Condition of Certification requirements in § 170.402(a)(4) (Assurances), § 170.404 (API), or both, the actor must comply with all requirements of such conditions for all practices and at all relevant times. Under this provision, health IT developers of certified Health IT E:\FR\FM\01MYR3.SGM 01MYR3 25762 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations Modules subject to the API Condition of Certification requirements may not charge certain types of fees and are subject to more specific cost accountability provisions than apply generally under the Costs Exception. We explain in the Costs Exception that a failure of developers to comply with these additional requirements would impose impediments to consumer and other stakeholder access to EHI without special effort and would be suspect under the information blocking provision. vi. Openness and Pro-Competitive Conditions We proposed in 84 FR 7595 in § 170.404(a)(4) that an API Technology Supplier must grant API Data Providers the sole authority and autonomy to permit API Users to interact with the API technology deployed by the API Data Provider in a non-discriminatory manner; provide all reasonably necessary support and other services to enable the effective development, deployment, and use of API technology by API Data Providers and its API Users to access, exchange, and use EHI in production environments; not impose collateral terms or agreements that could interfere with the use of API technology; and provide reasonable notice prior to making changes to its API technology or terms and conditions. Comments. The majority of commenters supported the proposed openness and pro-competitive conditions. Several commenters requested clarification about API Data Providers’ rights and responsibilities when providing access to an application of a patient’s choice. Specifically, they sought clarification on whether they can vet, deny, or limit access by applications that are using the API technology inappropriately. Another commenter proposed that app developers be required to obtain a business associate agreement (BAA) with providers prior to the application developer gaining access to a patient’s EHI on behalf of a patient. Response. We appreciate the feedback from commenters. Based on the support from commenters, we have finalized that a Certified API Developer must grant API Information Sources the independent ability to permit API Users to interact with the certified API technology deployed by the API Information Source in § 170.404(a)(4). Under the HIPAA Privacy Rule, a business associate relationship exists if an entity creates, receives, maintains, or transmits ePHI on behalf of a covered entity (directly or through another business associate) to carry out the VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 covered functions of the covered entity. HIPAA does not require a covered entity (e.g., API Information Source) or its business associate (e.g., API Technology Supplier) to enter into a business associate agreement with an app developer that does not create, receive, maintain, or transmit ePHI on behalf of or for the benefit of the covered entity (whether directly or through another business associate). However, if the app was developed to create, receive, maintain, or transmit ePHI on behalf of the covered entity (API Information Source), or was provided by or on behalf of the covered entity (directly or through its API Technology Supplier, acting as the covered entity’s business associate), then a business associate agreement would be required.106 In such cases, API Information Sources have the ability to conduct whatever ‘‘vetting’’ they deem necessary of entities (e.g., app developers) that would be their business associates under the HIPAA Rules before granting access and use of EHI to the entities. In this regard, covered entities must conduct necessary vetting in order to comply with the HIPAA Security Rule. For third-party applications chosen by individuals to facilitate their access to their EHI held by actors, there would not be a need for a BAA as discussed above. There would also generally not be a need for ‘‘vetting’’ on security grounds and such vetting actions otherwise would be an interference. Please see our discussion of ‘‘vetting’’ in the ‘‘Interference Versus Education When an Individual Chooses Technology to Facilitate Access’’ discussion in the Information Blocking section of the preamble (Section VIII). We also refer readers to our discussion of ‘‘vetting’’ versus verifying an app developer’s authenticity under the API Condition of Certification later in this section of the preamble. Comments. Several commenters requested clarification about the types of business relationships permitted between API Technology Suppliers and API Users and requested examples of permitted activities and responsibilities under each role. These comments expressed concern about prohibiting API Technology Suppliers from being able to form direct relationships with API Users for the purpose of joint development and commercialization of their products. Other commenters requested clarifications about relationships that existed prior to the involvement of an API Data Provider. 106 https://www.hhs.gov/hipaa/for-professionals/ privacy/guidance/access-right-health-apps-apis/ index.html. PO 00000 Frm 00122 Fmt 4701 Sfmt 4700 Response. We appreciate the feedback from commenters. Based on the general support, we have finalized in § 170.404(a)(4)(i)(A) that a Certified API Developer must provide certified API technology to API Information Sources on terms that are no less favorable than it provides to itself and its own customers, suppliers, partners, and other persons with whom it has a business relationship. Additionally, we have finalized in § 170.404(a)(4)(i)(B) that 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. Furthermore, we have finalized in § 170.404(a)(4)(i)(C) that a Certified API Developer must not offer different terms or services on the basis of: Competition or potential for competition and revenue or other value the other party receiving the services may receive from using the certified API technology. We note that we slightly modified the finalized requirements in § 170.404(a)(4)(i) based on the revised definitions finalized in § 170.404(c). We clarify that this rule does not prohibit Certified API Developers from forming business relationships with API Users. To the degree that a Certified API Developer seeks to charge an API User for particular services associated with its certified API technology, it would need to do so pursuant to the ‘‘valueadded services’’ permitted fee. Comments. Commenters requested clarification about how ‘‘the sole authority and autonomy to unilaterally permit connections to their health IT through certified API technology’’ applies to application registration. Specifically, they asked whether API Users are required to register once with the API Technology Supplier, or several times with each instance of API technology deployed by API Data Providers. Response. We appreciate the feedback from commenters. We refer commenters to § 170.315(g)(10)(iii) for the application registration requirements for Health IT Modules presented for certification. In general, we do not prescribe the registration paradigm that Certified API Developers create for themselves and their customers. Thus, in different scenarios, an API User may only be required to register once with an Certified API Developer, or several times with each instance of a § 170.315(g)(10)-certified Health IT Module deployed by an API Information Source. When it comes to apps that focus on the ‘‘launch-ehr’’ ‘‘SMART on FHIR Core Capability’’ from the E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations implementation specification adopted in 170.215(a)(3), such an approach will be tightly integrated with the Health IT Modules deployed by API Information Sources. Because of the tight integration between API Information Sources and Health IT Modules, registration for these apps could more often fall to the API Information Source. When it comes to apps that enable patient access, registration could be handled centrally by Certified API Developers or in a distributed manner with each API Information Source, especially in cases where API Information Sources take full responsibility for administering their § 170.315(g)(10)-certified Health IT Modules. Regarding ‘‘the sole authority and autonomy to unilaterally permit connections to their health IT through certified API technology,’’ we have finalized in 170.404(a)(4)(ii)(A) that Certified API Developer must have and, upon request, must grant to API Information Sources and API Users all rights that may be reasonably necessary to (1) access and use certified API technology in a production environment; (2) develop products and services that are designed to interact with the Certified API Developer’s API technology; and (3) market, offer, and distribute products and services associated with the Certified API Developer’s certified API technology. Additionally, we have finalized in § 170.404(a)(4)(ii)(B) that a Certified API Developer must not condition any of the rights described in § 170.404(a)(4)(ii)(A) on: (1) Receiving a fee, including but not limited to a license fee, royalty, or revenue-sharing arrangement; (2) agreeing to not compete; (3) agreeing to deal exclusively with the Certified API Developer; (4) Obtaining additional services that are not related to the certified API technology; (5) sharing intellectual property with the Certified API Developer; (6) meeting any Certified API Developer-specific testing or certification requirements; and (7) providing the Certified API Developer or technology with reciprocal access to application data. We slightly modified the conditions from the Proposed Rule for what we finalized in § 170.404(a)(4)(ii)(B) for clarity, and amended terms to the revised definitions finalized in § 170.404(c). Additionally, we clarify that while Certified API Developers are not permitted to condition the rights described in § 170.404(a)(4)(ii)(A) on receiving a fee, Certified API Developers are permitted to charge fees compliant with the permitted fees described in § 170.404(a)(3). We also clarify that ‘‘meeting any Certified API Developer- VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 specific testing or certification requirements’’ would include preconditions like registering and testing in a testing environment prior to moving to production, and meeting Certified API Developer-created certification requirements. Comments. Commenters expressed concern about software applications maintaining compatibility when upgrading API technology, and highlighted the importance of adopting backwards-compatible standards. Response. We appreciate the feedback from commenters. We share the concern expressed by commenters. We specifically consider features of standards like backwards compatibility when proposing and finalizing testing and certification requirements for the Program. As mentioned above, we have finalized the standard adopted in § 170.215(a)(1) as the base standard for the certification criterion adopted in § 170.315(g)(10) Standardized API for Patient and Population Services. We note that the standard adopted in § 170.215(a)(1) includes many FHIR resources that need to retain their compatibility over time, which will help as upgrades to newer standards occur. Additionally, we have finalized in § 170.404(a)(4)(iii) the service and support obligations required by a Certified API Developer, including the requirements that a Certified API Developer must provide all support and other services reasonably necessary to enable the effective development, deployment, and use of certified API technology by API Information Sources and API Users in production environments. These include requirements for changes and updates to API technology finalized in § 170.404(a)(4)(iii)(A), where Certified API Developers must make reasonable efforts to maintain the compatibility of its certified API technology and to otherwise avoid disrupting the use of certified API technology in production environments, and requirements for changes to terms and conditions finalized in § 170.404(a)(4)(iii)(B), where Certified API Developers must provide notice and reasonable opportunity for its API Information Source customers and registered API Users to update their applications to preserve compatibility with API technology and to comply with applicable terms and conditions. e. API Maintenance of Certification Requirements i. Authenticity Verification We proposed in 84 FR 7486 in § 170.404(a)(2)(ii)(C) to permit API Technology Suppliers to verify the PO 00000 Frm 00123 Fmt 4701 Sfmt 4700 25763 authenticity of application developers, limited to a duration of no greater than five business days of receipt of a request to register an application developer’s software with the API technology. We noted the authenticity verification process would need to be objective, apply to the application developer and not their software, and be the same for all application developers. We sought comment in 84 FR 7486 on factors that would enable registration with minimal barriers, including options and associated trade-offs. Additionally, we sought comment at 84 FR 7486 on other timing considerations for application developer authenticity verification. Comments. Commenters asked for a longer timeframe to complete the authenticity verification process of application developers. Some commenters asked to extend the authenticity verification timeframe to ten business days. Commenters suggested adding ‘‘and any receipt of any additional requested information needed in order to verify the developer’s authenticity’’ to ‘‘within five business days of receipt of an application developer’s request to register their software application with the API technology provider’s authorization server.’’ Commenters suggested various methods for verifying the authenticity of application developers and applications, including by proposing required registration information, or required attestation to model privacy guidelines or industry best practices. Other commenters suggested various approaches for verifying application developers and applications, including by working with industry to establish a verification body, privacy and security trust or certification framework, and other more detailed recommendations. Several commenters suggested requiring application developers to attest to providing a model privacy notice to patients. Commenters suggested mandating terms and conditions and consent requirements as part of the registration process. Response. We appreciate feedback from commenters. To improve the organization of these Condition and Maintenance of Certification requirements, we moved the requirements proposed in § 170.404(a)(2)(ii)(C) to the finalized § 170.404(b)(1)(i) under the combined § 170.404(b)(1), ‘‘Authenticity verification and registration for production use.’’ We accept commenters’ requests to establish a longer time period for this permitted, but not required, process to verify the authenticity of application developers E:\FR\FM\01MYR3.SGM 01MYR3 25764 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations who seek to register their software application for use with the Certified API Developer’s certified API technology. We have adopted ten business days as the timeframe by which this process would need to be completed and as a result find it unnecessary to add the text contemplating a back and forth between the Certified API Developer and API User. We recommend that Certified API Developers who elect to institute a verification process implement a process that is as automated as possible to ensure they remain in compliance with our final policy. Given that we combined authenticity verification and registration for production use in one requirement finalized in § 170.404(b)(1), we reduced the scope of these requirements to Certified API Developers with a Health IT Module certified to the certification criterion adopted in § 170.315(g)(10) to remain consistent with the scope of applicability of registration for production use from the Proposed Rule. We also note that authenticity verifications would likely occur more frequently for patient-facing applications that are not sponsored by API Information Sources. We anticipate that an API Information Source (e.g., a health care organization) that is a HIPAA covered entity would vet and enter into a HIPAA business associate agreement with a provider-facing application developer prior to using the application within their internal technical enterprise. In comparison, a patient-facing application is likely to connect to an API Information Source’s resource server using a public service base URL of a § 170.315(g)(10)-certified Health IT Module in service to the patient’s HIPAA Privacy Rule right of access (45 CFR 164.524) or based on a patient’s HIPAA authorization (45 CFR 164.508) without first establishing a relationship with the API Information Source. For patient-facing applications, and to the comments suggesting we require various modes of attestation to privacy guidelines in such contexts, we refer commenters to the information blocking provisions in section VIII for a discussion of permitted behaviors regarding privacy attestations. Comments. Commenters suggested including a warning by the API Data Provider that the application developer selected by the patient or patientdesignee is untrusted. Response. We thank commenters for their feedback. An API Information Source would not be prohibited from showing a warning to patients as part of the patient authorization for an application to receive their EHI from an VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 API Information Source. This could include a warning that an application attempting to access data on behalf of a patient is untrusted. We refer commenters to the information blocking provisions in section VIII for additional information about providing warnings to patients. ii. Registration for Production Use We proposed in 84 FR 7494 in § 170.404(b)(1) to require API Technology Suppliers to register and enable all applications for production use within one business day of completing its verification of an application developer’s authenticity. Comments. Commenters generally supported the proposed registration requirements. Most commenters suggested extending the registration timeframe to five business days. Response. We appreciate the feedback from commenters. We have reorganized this section of the regulation text for readability by combining ‘‘Authenticity verification’’ with ‘‘Registration for production use’’ under the heading ‘‘Authenticity verification and registration for production use’’ in § 170.404(b)(1). We accepted the recommendation from commenters to extend the registration timeline and have finalized in § 170.404(b)(2)(ii) a requirement for Certified API Developers with Health IT Modules certified to the certification criterion finalized in § 170.315(g)(10) to register and enable all applications for production use within five business days of completing its verification of an application developer’s authenticity pursuant to requirements finalized in § 170.404(b)(1)(i). iii. Service Base URL Publication We proposed in 84 FR 7595 in § 170.404(b)(2) to require an API Technology Supplier to support the publication of service base URLs for all of its customers, and make such information publicly available, in a computable format, at no charge. Comments. A majority of commenters supported the proposal requiring API Technology Suppliers to publish service base URLs for all of its customers. Several commenters recommended the creation of a single, publicly available repository to maintain all client endpoints. Some stakeholders recommended ONC require additional facility information be published with the service base URL. Commenters who disagreed with this proposal stated that health IT developers cannot publish client information without their consent, and that API Data Providers PO 00000 Frm 00124 Fmt 4701 Sfmt 4700 should have the sole authority to publish their endpoints. Response. We thank commenters on their feedback on our proposal requiring a Certified API Developer to publish service base URLs for all of its customers. The public availability and easy accessibility of this information is a central necessity to assuring the use of certified API technology without special effort, particularly for patient-facing applications. We agree with the points made by commenters on the need for a single or multiple publicly available repositories that maintain provider service base URLs. We encourage industry to coalesce around the development of a public resource from which all stakeholders could benefit. We believe this would help scale and enhance the ease with which service base URLs could be obtained and used. While we support the concept of repositories for service base URLs, we do not believe that creating a requirement under the Program is the appropriate mechanism to foster industry support around this concept at this time. We acknowledge that stakeholders expressed concern about Certified API Developers publishing client service base URLs and revised our approach to focus on service base URLs necessary to support patient access. We anticipate that many services related to certified API technology will be developed and made available and do not believe it is appropriate to burden Certified API Developers with publishing all service base URLs for these services for all of their customers. We considered several options, including requiring Certified API Developers to publish service base URLs for only those API Information Source customers for whom they manage/host an authorization server centrally. However, we determined that alternative options would not meet our policy interests and would lead to unnecessarily complex and burdensome approaches and would not achieve the Cures Act’s goals of enabling EHI to be accessed, exchanged, and used without special effort. Additionally, we considered requiring that all Certified API Developers with certified API technology, that is, health IT developers with a Health IT Module certified to § 170.315(g)(7) through (10), meet this requirement. However, we determined that it would be more beneficial to allow health IT developers to focus energy and resources on upgrading their technology to the certification criterion finalized in § 170.315(g)(10). Therefore, we have finalized in § 170.404(b)(2) that a Certified API Developer must publish service base URLs for all Health IT E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations Modules certified to § 170.315(g)(10) that can be used by patients to access their EHI. We further require that a Certified API Developer must publicly publish service base URLs for all customers in a machine-readable format at no charge regardless of whether the Health IT Modules certified to § 170.315(g)(10) are centrally managed by the Certified API Developer or locally deployed by an API Information Source. We note our focus for this criterion on ‘‘service base URLs for Health IT Modules certified to § 170.315(g)(10) that can be used by patients to access their EHI.’’ We believe that Certified API Developers will have adequate relationships with API Information Sources in the process of providing Health IT Modules certified to § 170.315(g)(10) and will be able to collect and publish all service base URLs that support patient access on behalf of their customers. Furthermore, we note that API Information Sources would be obligated to share such service base URLs with Certified API Developers to avoid violating the Technical Interference Information Blocking provisions as discussed further in section VIII. Certified API Developers must make available appropriately scoped service base URLs that can be used by patients to access their EHI for Health IT Modules certified to § 170.315(g)(10). iv. Providing (g)(10)-Certified APIs to API Data Providers We proposed in 84 FR 7494 in § 170.404(b)(3) that an API Technology Supplier with Health IT Modules previously certified to § 170.315(g)(8) must provide all API Data Providers Health IT Modules certified to § 170.315(g)(10) within 24 months of this final rule’s effective date. Comments. The majority of comments received urged ONC to extend the timeline beyond the 24 months proposed. Many commenters requested separate timelines for developers and providers. Several commenters recommended 36 months. Some commenters offered alternatives ideas for timelines, including a stepwise approach, or ONC only determining technical timelines, and allowing CMS to cover provider timelines. Only a few commenters encouraged faster adoption. Response. We appreciate commenters’ feedback on our proposal. Given the reduced scope of the overall updates required by this final rule, our belief that the industry is well-prepared to meet this certification criterion’s requirements once the final rule is published, and the Cure’s Act expectation that secure, standards-based VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 APIs would be made available in a timely manner, we have retained a 24 month compliance timeline, which will start from the publication date of the final rule. At that point, it will be approximately five years since the Cures Act’s passage and we believe its implementation should not be delayed any further. We also remind stakeholders that this is within 24 months of this rule’s publication compliance date for supplying all API Information Sources with Health IT Modules certified to § 170.315(g)(10) enables Certified API Developers (based on their client base and IT architecture) to determine the most appropriate timeline for development, testing, certification, and product release cycles. Thus, we have finalized in § 170.404(b)(3) that a Certified API Developer with certified API technology previously certified to the certification criterion at § 170.315(g)(8) must provide all API Information Sources with such certified API technology deployed with certified API technology certified to the certification criterion in § 170.315(g)(10) within 24 months of the publication date of the final rule. v. Compliance for Existing Certified API Technology We proposed in 84 FR 7486 that API Technology Suppliers with Health IT Modules certified to § 170.315(g)(7), (8), or (9) must revise their existing API documentation within six months from the final rule’s effective date. Comments. Some commenters supported the requirement to revise existing API documentation within six months of the final rule’s effective date. Others requested more time to allow documentation and all other websites to come into alignment before enforcement of this Condition of Certification requirement. One commenter requested clarification on which documentation requires revision within the six-month timeframe. Response. In order to align the API Condition of Certification requirements policies, we have broadened the scope of the provision finalized in § 170.404(b)(4) to apply to all API Condition of Certification requirements finalized in § 170.404(a), including § 170.404(a)(1) through (4). Given the change of scope, we renamed this section to ‘‘Compliance for existing certified API technology.’’ We considered commenters’ request for more time, but given the already delayed effective date of Part 170 we believed the proposed time of six months sufficient to enable Certified API Developers to become compliant with the Condition of Certification PO 00000 Frm 00125 Fmt 4701 Sfmt 4700 25765 requirements finalized in § 170.404(a). This additional time provides Certified API Developers with Health IT Modules already certified to § 170.315(g)(7), (8), or (9) a total of eight months from the final rule’s publication to update their policies and documentation to comply with the requirements finalized in § 170.404(a). We did not allow a longer time period than six months in § 170.404(b)(4) due to the fact that we have finalized our proposal in § 170.404(b)(3) to require Certified API Developers with Health IT Modules previously certified to the certification criterion in 170.315(g)(8) to provide § 170.315(g)(10)-certified APIs to API Information Sources within 24 months of final rule’s publication date. These policies finalized in § 170.404(b)(4) provide API Information Sources with Health IT Modules certified to § 170.315(g)(8) with 18 months of updated documentation before the new requirements finalized in § 170.404(b)(3) become effective. Setting a more delayed compliance date than the one finalized in § 170.404(b)(4) would have unreasonably delayed and ultimately diminished the benefits of the Program requirements we have finalized in this rule. In summary, we finalized in § 170.404(b)(4) that Certified API Developers with Health IT Modules certified to § 170.315(g)(7), (8), or (9) must comply with § 170.404(a) no later than six months after this final rule is published in the Federal Register, including by revising their existing business and technical API documentation and making such documentation available via a publicly accessible hyperlink that allows any person to directly access the information without any preconditions or additional steps. 5. Real World Testing The Cures Act requires, as Condition and Maintenance of Certification requirements under the Program, that health IT developers successfully test the real world use of the technology for interoperability 107 in the type of setting in which such technology would be marketed. As discussed in the Proposed Rule (84 FR 7495), the objective of real world testing is to verify the extent to which certified health IT deployed in production contexts continues to demonstrate conformance to the full scope of applicable certification criteria and functions with the intended use cases as part of the overall maintenance 107 Defined in statute in section 3000 of the Public Health Service Act (as modified by section 4003 of the Cures Act) and defined in regulation at 45 CFR 170.102. E:\FR\FM\01MYR3.SGM 01MYR3 25766 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations of a health IT’s certification. Real world testing should assess that the certified health IT is meeting the intended use case(s) of the certification criteria to which it is certified within the workflows, system architectures, and type(s) of care setting(s) for which it is marketed (advertised, promoted, or sold). For the purpose of this Condition of Certification requirement, in § 170.405(a), we proposed (84 FR 7495) that successful real world testing means: • The certified health IT continues to be compliant to the full scope of the certification criteria to which it is certified, including the required technical standards and vocabulary codes sets; • The certified health IT is exchanging electronic health information in the care and practice settings for which it is intended for use; and • Electronic health information is received by and used in the certified health IT. To fully implement the real world testing Condition of Certification requirement, we proposed Maintenance of Certification requirements that would require health IT developers to submit publicly available prospective annual real world testing plans and retrospective annual real world testing results for the certification criteria focused on interoperability to which each of its Health IT Modules is certified (84 FR 7496). Comments. Comments on the whole support the establishment of a robust process of real world testing. Several commenters expressed concerns regarding the quality and usability of health IT. Specifically, commenters indicated that issues related to health IT usability may be contributing to clinician burn-out or impacting patient safety, noting that they therefore strongly support the inclusion of robust real world testing requirements. Response. We appreciate all comments, and have finalized real world testing Condition and Maintenance of Certification requirements in § 170.405(a) and (b) as proposed, with minor adjustments to due dates and clarifications of several points in response to specific comments as discussed below. Comments. Commenters indicated that additional clarification of the real world testing requirements would make these Condition and Maintenance of Certification requirements less burdensome to implement. These commenters specifically sought additional guidance around the expectations for an appropriate testing VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 plan and method of execution. One commenter recommended that ONC provide more guidance around what care settings must be covered by test plans, and establish a minimum number of settings and test sites that are applicable for certified Health IT Modules. Response. In response to comments requesting additional guidance around expectations and acceptable methods for real world testing, we provide below additional discussion, explanation, and illustrative examples. At this time, we have decided not to establish a minimum number of settings or minimum percentage or fraction of production instances of the developer’s applicable certified Health IT Modules that must be included in the developer’s annual real world testing activities. While health IT developers are not required to test their certified health IT in each and every setting in which it is intended for use, we would expect a developer’s real world testing plan to address each type of clinical setting for which their health IT is marketed. Developers must address in their real world testing plans their choice of care and/or practice settings to test and provide a justification for their chosen approach. We also remind developers that although we are not requiring testing in every setting for which the certified health IT is marketed, we encourage real world testing in as many specific settings as feasible within each type of setting for which the certified health IT is marketed. Comments. Some commenters expressed a view that there has been too much focus on the export capabilities of systems and not enough attention paid to providers being able to ingest data received in standardized formats—such as the Continuity of Care Document (CCD) standard—from other providers, including other providers who use the same developer’s Health IT Modules certified to produce exports in conformance with the standards. Response. The interoperability focused criteria listed in § 170.405(a) include required capabilities for receiving and incorporating data in accordance with referenced standards and implementation specifications adopted by the Secretary in part 170 subpart B. We believe this appropriately aligns requirements for real world testing of Health IT Modules’ ability to ingest data with the capabilities their certifications address. Comments. A commenter recommended that, for real world testing of Health IT Modules certified to the API criterion, the final rule require health IT developers to provide a testing PO 00000 Frm 00126 Fmt 4701 Sfmt 4700 environment (or ‘‘developer sandbox’’) and require the use of a testing platform and test scripts that validate the ability of the API to meet the underlying requirements for the version of FHIR® to which Health IT Module(s) are certified, any applicable FHIR® profiles, and implementation guides. Response. As discussed in the Proposed Rule (84 FR 7496), we believe health IT developers are in the best position to design and facilitate implementation of real world testing approaches that balance the burdens of this statutory requirement with its intended assurances that certified health IT as deployed in the types of clinical settings for which it is marketed (advertised, promoted, or sold) continues to meet the Program requirements, including but not limited to interoperability performance, applicable under the certification it holds. While we recognize that testing environments can be useful for a variety of purposes, and would not generally discourage developers from offering test platforms specific to their products or participating in the development and use of open-source testing platforms, the purpose of real world testing is to demonstrate that Health IT Modules continue to perform in conformance to their certification when and as they are deployed in production environments supporting the types of clinical settings for which the Health IT Modules are marketed. Thus, real patient data and real production environments will in most cases best meet that need and should be first considered when developing real world testing plans. Mandating creation or use of testing environments for real world testing would compete for developers’ time and effort with the focus on innovative ways to best serve the purpose of the real world testing Conditions and Maintenance of Certification requirements at the least burden on their customers and end users. We have therefore not required health IT developers to provide a testing environment (or ‘‘developer sandbox’’) nor have we required the use of a testing platform or test scripts in order to satisfy real world testing Condition and Maintenance of Certification requirements. Comments. Several commenters requested that ONC be mindful of the burdens this testing could place on health care providers in terms of time and cost and take all necessary steps to minimize such burdens. Commenters specifically stated real world testing would require significant work by providers for whom, in the commenters’ stated view, there is no incentive to E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations participate in real world testing. Some commenters specifically recommended that HHS incentivize providers to participate, stating that without providers’ participation, this proposal would become an untenable requirement. One commenter requested HHS clarify whether a developer would be permitted to compensate its customers for the time the customer spends supporting the developer’s real world testing activities. Response. We thank commenters for their feedback noting the potential for health IT developers’ real world testing activities to impose burden on providers. We do appreciate the importance of recognizing that providers engage directly and actively in various types of activities supporting advancement of health IT. The fact that many of these activities could be included in robust real world testing regimes suggests that we should provide developers with extensive flexibility to develop innovative real world testing plans. We have therefore built into our real world testing policy flexibility that offers the developer a substantial opportunity to design real world testing approaches that minimize burden and fully optimize value of the real world testing activities and results to current and prospective customers. We do not believe that HHS incentives to providers participating in real world testing would be the most effective means of alleviating burdens on health care providers specifically attributable to developers’ real world testing activities. Rather, the flexibility of our policy allows for, and encourages, developers to approach real world testing in an innovative mode so that they can maximize efficiency and minimize burden of real world testing for both the developer and its customers. A wide range of practical strategies are available for developers to potentially consider in creating such optimized solutions for real world testing of their specific health IT with their particular customer base. Examples of this range of practical strategies include, but are not necessarily limited to: Avoiding some activities that satisfy only the real world testing Maintenance of Certification requirements by including in its overall real world testing plans the testing typically associated with confirming functionality of new installations and upgrades of their software; and innovating methods of measuring products’ performance in real time use through system metadata and/or feedback from health information networks and other exchange partners of their customers. VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 In response to the recommendation that developers be allowed to compensate their customers for participating in the developer’s real world testing activities, we note that nothing in our proposed or finalized policy under part 170 would prohibit that. In the event a developer concludes that its real world testing approach imposes on its customers directly participating in real world testing activities a burden that the developer would like to offset for those customers, we would not discourage the developer from considering whether there may be opportunities within the bounds of other applicable laws or regulations for developers of certified health IT to offer customers some types of burdenoffsetting compensation or other incentive for real world testing participation. Analysis, interpretation, or changes to such other law or regulation is outside the scope of this particular rulemaking action. Moreover, outside the rulemaking process, developers should be aware that ONC is not in a position to provide general guidance on Federal laws specific to compensation arrangements or advice specific to any particular circumstances or contemplated conduct related to developers compensating providers for participating in developers’ real world testing activities. However, if developers or providers may be contemplating a potential compensation arrangement related to offsetting providers’ cost or burden of engagement in developers’ real world testing, we offer as a point of information that one publicly stated purpose of the HHS Office of the Inspector General advisory opinion process is to provide meaningful advice about of the applicability of the antikickback statute or other OIG sanction statutes in specific factual situations.108 Comments. One commenter expressed concern that developers with small customer bases will have smaller pools of participants willing to undergo a lengthy process which will require significant resources and suggested developers submit results from a more limited scope of testing only every three years. Response. We reiterate that the policy we have finalized includes substantial flexibility for developers to assess how to meet the real world testing Condition and Maintenance of Certification requirements in a way that appropriately minimizes burden on the current users of their certified health IT. 108 For more information about HHS Office of the Inspector General advisory opinions and advisory opinion process, please visit: https://oig.hhs.gov/ compliance/advisory-opinions/index.asp. PO 00000 Frm 00127 Fmt 4701 Sfmt 4700 25767 Comments. A commenter expressed concern that health care providers might be unwilling to use health IT that had not yet been certified, and that this could make real world testing of Health IT Modules prior to certification impractical. Response. In our Proposed Rule (84 FR 7429), we proposed in § 170.405(a) to limit the applicability of this Condition of Certification to health IT developers with Health IT Modules that are certified to one or more 2015 Edition certification criteria focused on interoperability and data exchange. We also proposed that the real world testing Condition of Certification would be met through meeting the real world testing Maintenance of Certification requirements in § 170.405(b). We have finalized this proposal as proposed. Thus, the real world testing Condition and Maintenance of Certification requirements do not mandate testing real world use of a Health IT Module in actual production environments before it is certified. a. Unit of Analysis at Which Testing Requirements Apply Comments. One commenter requested confirmation if real world testing is required per CHPL listing, per product, or per company. Response. The real world testing Condition and Maintenance of Certification requirements apply to each developer that has at least one Health IT Module certified to at least one of the interoperability and exchange focused criteria listed in § 170.405(a), because Condition and Maintenance of Certification requirements apply to the developer of certified health IT. However, each developer of certified health IT to which the real world testing Condition and Maintenance of Certification requirements apply must conduct real world testing for each criterion within the scope of real world testing (§ 170.405(a)) to which each developer presents for certification a Health IT Module that is part of a health IT product to be listed on the CHPL are certified. A health IT developer with multiple products that are listed on the CHPL and that include one or more Health IT Module(s) certified to one or more of the criteria listed in § 170.405(a) need only submit one real world testing plan, and one real world testing results report, for any given annual cycle of real world testing, but the real world testing plan and results report must address each of the developer’s products that is listed on the CHPL. Health IT developers with multiple health IT products that may include the same Health IT Module(s) certified to one or E:\FR\FM\01MYR3.SGM 01MYR3 25768 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations more of the criteria listed in 170.405(a) have discretion to design their real world testing plans in a way that efficiently tests a combination of products that include Health IT Modules certified criteria listed in § 170.405(a) so long as testing plans and results are traceable to specific certified Health IT Modules and each criterion to which the Health IT Module(s) are certified, and address the types of settings for which the products are marketed. Because the purpose of real world testing is to test health IT products as they are deployed in production, developers of health IT products deployed through the cloud who offer their products for multiple types of clinical settings will be required to test the same capability for those different types of settings even if it uses a single instance of the deployed capability to serve all of those types of settings. b. Applicability of Real World Testing Condition and Maintenance of Certification Requirements We proposed (84 FR 7495) to limit the applicability of the real world testing Condition of Certification requirement to health IT developers with Health IT Modules certified to one or more of the certification criteria focused on interoperability and data exchange or availability listed in (then-proposed) § 170.405(a): • The care coordination criteria in § 170.315(b); • The clinical quality measures (CQMs) criteria in § 170.315(c)(1) through (c)(3); • The ‘‘view, download, and transmit to 3rd party’’ criterion in § 170.315(e)(1); • The public health criteria in § 170.315(f); • The application programming interface criteria in § 170.315(g)(7) through (g)(10); and • The transport methods and other protocols criteria in § 170.315(h). We solicited comment on whether to also include the ‘‘patient health information capture’’ certification criteria in § 170.315(e)(3), including the value of real world testing these functionalities compared to the benefit for interoperability and exchange (84 FR 7496). We also solicited comment on whether any other 2015 Edition certification criteria should be included or removed from the applicability list (to be codified at 170.405(a)) for this Condition of Certification requirement. Comments. The vast majority of commenters addressing this proposal were in support of the specific criteria proposed to be within the scope of real world testing and expressed agreement VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 that required testing should be limited to Health IT Modules certified to one or more of the certification criteria listed in § 170.405(a) as proposed. Response. We appreciate all feedback received. The list of criteria to which real world testing Condition and Maintenance of Certification requirements apply is finalized in § 170.405(a) as proposed. Comments. We received one comment supporting and two comments opposing the addition of patient health information capture criterion in § 170.315(e)(3) to the scope of real world testing. One commenter specifically recommended against including the patient health information capture criterion in § 170.315(e)(3) in real world testing because of the significant variability in how health IT certified to this criterion is implemented. They stated that this variability in the real world could make cross-implementation comparisons difficult, and stated that testing for this criterion could present a particular challenge based on difficulty they anticipated would be encountered in securing needed engagement from patients as well as the exchange partners who would presumably receive the data as a result of the patient using the ‘‘transmit’’ functionality. Commenters opposed to addition of this criterion to the real world testing Condition and Maintenance of Certification requirements also stated this addition would add cost to the developer which would then flow down to end users and be burdensome to clinician practices. Response. On balance, the comments received do not support expansion of the scope of real world testing requirements to include the patient health information capture criterion in § 170.315(e)(3) at this time. In developing the proposed list of criteria to which real world testing Condition and Maintenance of Certification requirements would apply, we concluded an initial focus on those particular criteria would strike an appropriate balance between the magnitude of the challenge represented by the new real world testing requirements and the potential benefits of their broader application. The concerns raised by the commenters recommending against adding the patient health information capture criterion in § 170.315(e)(3) to the scope of real world testing requirements at this time, combined with other comments more generally recommending against a broader scope at this time, tend to support the conclusion that the scope we proposed strikes an appropriately practical balance until we and the PO 00000 Frm 00128 Fmt 4701 Sfmt 4700 industry have benefit of experience and innovation in real world testing. Thus, the finalized list of criteria to which real world testing requirements apply (§ 170.405(a)) does not include the patient health information capture criterion in § 170.315(e)(3). Comments. A few commenters suggested expanding the scope of real world testing requirements to include the proposed ‘‘EHI export’’ criterion in § 170.315(b)(10). Response. We appreciate the confirmation that commenters supported inclusion of the ‘‘EHI export’’ criterion in § 170.315(b)(10) alongside the rest of the care coordination criteria in § 170.315(b). We have finalized the criteria listed in § 170.405(a) including, as proposed, all criteria within § 170.315(b). Comments. One commenter expressed an opinion that the initial scope of criteria is more expansive than the commenter would suggest for an introductory set, and asked that fewer criteria be required for the initial rollout of real world testing, delaying application of the requirement to more interoperability focused criteria until experience has been amassed with real world testing for a narrower selection of criteria than we had proposed. Response. Noting that the majority of comments received were supportive of the scope as proposed, we also balance suggestions such as that offered by this commenter against the Program’s needs and the purpose of the real world testing Condition and Maintenance of Certification requirements. We do not believe it would be in the best interest of the Program or the health care providers and patients who rely on certified health IT to meet their needs for interoperable health IT to narrow the applicability of the real world testing Condition and Maintenance of Certification requirements further than we proposed. We have, therefore, finalized the criteria listed in § 170.405(a) as proposed. Comments. Some commenters advocated expanding the scope of the real world testing requirement to include select functionally-based ‘‘clinical’’ criteria within § 170.315(a) that are included in the base EHR definition. Response. As explained in the Proposed Rule (84 FR 7495), we did not propose to include in the scope of real world testing functionally-based criteria, administrative criteria, or other criteria that do not focus on interoperability and exchange or availability of data. The ‘‘clinical’’ certification criteria in § 170.315(a) were noted in the Proposed Rule as an E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations example of criteria not proposed because they require only that the health IT enable the provider to record, change, and access specific types of data within the Health IT Module being certified (or within a product that includes the Health IT Module being certified to the particular criteria). However, real world testing of health IT’s ability to exchange the types of data these clinical criteria reference is addressed through the inclusion of the USCDI in the interoperability-focused criteria listed in § 170.405(a) as proposed, which is finalized as proposed. In order to successfully exchange interoperable EHI, the health IT must be able to access it, and in order to incorporate a type of data, the health IT must be able to record it. Comments. The majority of comments received specifically referencing the proposed inclusion of public health criteria in the real world testing requirement in § 170.405(a) support the importance and inclusion of the public health criteria in the scope of real world testing requirements. One commenter questioned the inclusion of the public health criteria in § 170.315(f), stating the commenter’s perception that extensive variation between registries would make this a challenging functionality to demonstrate. Response. Variations in system configurations across different public health agencies’ infrastructures may suggest different real world testing strategies may be most appropriate, or most relevant to customers, compared to what might be the case for some other criteria within the scope of real world testing. However, as noted below about testing tools, we are aware of a wide variety of resources and opportunities to test real world interoperability performance of Health IT Modules certified to the public health criteria in § 170.315(f). Because interoperability performance in actual production environments is an important feature of health IT certified to the public health criteria in § 170.315(f), and noting the support for its inclusion expressed by most commenters, and we have determined that the most appropriate course is to finalize the inclusion of the public health criteria in§ 170.315(f) in the scope of real world testing in § 170.405(a). Comments. One commenter expressed concern that some of the criteria proposed for inclusion in § 170.405(a) be re-examined because they do not include all three of the characteristics our Proposed Rule described as being demonstrated through real world testing. Examples offered included that some criteria proposed for inclusion in VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 § 170.405(a) require exporting but do not require receipt and use of electronic health information by the certified health IT. Response. We appreciate commenters’ bringing to our attention that additional discussion about the requirements would be helpful to the community. For the criteria proposed and finalized in the real world testing scope in § 170.405(a), such real world testing needs to address the interoperability characteristics and all other functionalities and capabilities applicable based on the specific criteria to which the Health IT Module is certified. For example, even if a Health IT Module is not certified to any criterion that specifically requires it to demonstrate, in order to be certified, that the Health IT Module has the capability to incorporate and use data received directly from sources outside the production environment in which it is deployed, that Health IT Module will still need to demonstrate conformance to the full scope of each criterion to which it is certified. This includes, though it is not limited to, the technical standards and vocabulary codes sets included in each criterion to which it certified. c. Testing Plans, Methods, and Results Reporting We proposed (84 FR 7496) that a health IT developers must submit an annual real world testing plan to its ONC–ACB via a publicly accessible hyperlink no later than December 15, of each calendar year for each of its certified Health IT Modules that include certification criteria specified for this Condition of Certification. We proposed (84 FR 7497) that a health IT developer must submit an annual real world testing plan to its ONC–ACB via a publicly accessible hyperlink no later than January 31, of each calendar year for the preceding calendar year’s real world testing. We proposed that the real world testing plan, which will be required to be available to ONC and the public via the CHPL no later than December 15 of each year once this final rule is effective, will need to address the health IT developer’s real world testing that will be conducted the upcoming calendar year and must include, for each of the certification criteria in scope for real world testing in § 170.405(a) and each Health IT Module certified to one or more of these criteria (84 FR 7496): • The testing method(s)/ methodology(ies) that will be used to demonstrate real world interoperability, including a mandatory focus on scenario- and use case-focused testing; PO 00000 Frm 00129 Fmt 4701 Sfmt 4700 25769 • The care and practice setting(s) that will be tested for real world interoperability, including conformance to the full scope of the certification criteria requirements, and an explanation for the health IT developer’s choice of care setting(s) to test; 109 • The timeline and plans for voluntary updates to standards and implementation specifications that ONC has approved (further discussed below); • A schedule of key real world testing milestones; • A description of the expected outcomes of real world testing; • At least one measurement/metric associated with the real world testing for each certification in scope; and • A justification for the health IT developer’s real world testing approach. We sought comment (84 FR 7497) on whether we should specify a minimum ‘‘core’’ set of metrics/measurements and examples of suggested metrics/ measurements as well as on the timing of required real world testing results reporting. We also invited comment on the annual frequency and timing of required real world testing results reporting. Comments. Most comments received supported the proposed requirement for Health IT Modules to undergo real world testing. In addition, commenters indicated that real world testing should occur on a regular basis to ensure various types of changes in the Health IT Modules or production environments have not affected functionality required by the certification. Several commenters recommended development of more specific minimum requirements for test plans and measurement of results. They further recommended that ONC provide additional guidance about what will constitute a minimally acceptable testing plan with explicit content depicting the minimum requirements for each component of the testing plan. Response. We thank commenters for their feedback. As discussed in the Proposed Rule and above, we believe health IT developers are in the best position to design and facilitate implementation of real world testing approaches that balance the burdens of this statutory requirement with its intended assurances that certified health 109 We do not specifically define or limit the care settings and leave it to the health IT developer to determine. As an example, health IT developers can consider categories, including but not limited to, those used in the EHR Incentive Programs (https:// www.cms.gov/Regulations-and-Guidance/ Legislation/EHRIncentivePrograms/Downloads/ UserGuide_QNetHospitalObjectivesCQMs.pdf); long-term and post-acute care; pediatrics; behavioral health; and small, rural, and underserved settings. E:\FR\FM\01MYR3.SGM 01MYR3 25770 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations IT meets Program requirements, including interoperability performance, applicable under the certification it holds. We have therefore finalized requirements in § 170.405(b)(1) designed to avoid the risk of a ‘‘one size fits all’’ set of testing tools (discussed at 84 FR 7496) that might not fully address the concerns raised or provide the assurances of interoperability performance sought across the various types of care settings. By establishing in § 170.405(b)(1)(iii) the topics and considerations every developer must address in its required real world testing plan but not specifying how they must address these required aspects we have provided health IT developers with a requirement that at the same time provides them with the flexibility to develop and implement successful real world testing plans that will best balance burden and value for the customers of each of their products. The ONC–ACBs will be responsible for assessing real world testing plans and results reports for completeness in comparison to what § 171.405(b)(1) requires the plan and results reports to include or address, but will otherwise not be formally evaluating the testing approach for quality as a testing approach. We note for clarity that while ONC–ACB’s will not be judging a developer’s real world testing approaches as planned or as executed, the contents of a developer’s publicly available real world testing results could be used by an ONC–ACB as part of its ongoing surveillance of certified health IT. Additionally, we have finalized our proposed requirement in § 170.405(a) and (b) that requires developers subject to the real world testing Condition and Maintenance of Certification requirements (see § 170.405(b)(2)(i)) who discover in the course of their real world testing any non-conformities with the standards, functionalities, or other requirements of any certification criterion under the Program, to address these non-conformities in order for their Health IT Modules to remain certified. This requirement will apply in the same manner to Health IT Modules certified under the SVAP flexibility in § 170.405(b)(8) or (9) as to Health IT Modules not certified under the SVAP flexibility. Thus, developers who discover non-conformity to any Program requirement(s) will be required to report those non-conformities to their ONC– ACB(s). In order to provide a clear threshold for determining whether a developer has acted on this requirement in a timely manner, we have finalized the requirement to report nonconformities within 30 days of VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 discovering them (see § 170.405(b)(2)(i)). We believe 30 days is an appropriate timeframe to allow developers the opportunity to gather all facts and report to their ONC–ACBs the details and nature of the non-conformity. Furthermore, we believe more than the 30 days would extend beyond the timeframe by which a non-conformity should be investigated by an ONC–ACB and corrective action implemented, if necessary. We are aware that by choosing not to specify particular methods, tools, or checklists of activities that must be included in real world testing, and providing instead extensive flexibility for developers to select tools and design overall methodologies based on their knowledge of their products and customers, we are asking developers to apply innovation and problem solving skills to their real world testing. We believe that the alternative of developing a catalog of detailed specifications and checklists, as some commenters suggested, would be undesirably complex, less supportive of ongoing innovation in the market, and not ultimately less burdensome for developers or their customers. As we have noted in the context of prior Program rulemaking actions, we often make additional information resources and non-binding guidance regarding real world testing available through familiar communications channels, such as the HealthIT.gov website. Comments. Several commenters expressed concerns about the burden of real world testing in specific reference to ONC–ACB processes for in-the-field surveillance of certified products’ continued conformance to applicable certification criteria. Some comments raised concerns about the burden that could be placed on developers’ customers should developers choose to rely heavily on the procedures used by ONC–ACBs for randomized or reactive in-the-field surveillance. Some comments indicated concern that ONC would expect, encourage, or view more favorably real world testing approaches that rely heavily or exclusively on use of ONC–ACB in-the-field surveillance protocols. Response. In the Proposed Rule, we stated that ‘‘developers may consider working with an ONC–ACB and have the ONC–ACB oversee the execution of the health IT developer’s real world testing plans, which could include inthe-field surveillance per § 170.556, as an acceptable approach to meet the requirements of the real world testing Condition of Certification’’ requirement (84 FR 7497). Having considered all comments received, we have decided PO 00000 Frm 00130 Fmt 4701 Sfmt 4700 not to finalize the flexibility for developers to use ONC–ACBs’ in-thefield surveillance as part of the developer’s real world testing plan. We do not believe that use or replication of methods or protocols used by ONC– ACBs for in-the-field surveillance of certified Health IT Modules would be the most effective or the least burdensome approach available to health IT developers and are concerned accepting real world testing approaches that rely on ONC–ACB in-the-field surveillance could slow rather than accelerate development of more innovative approaches to real world testing. We are also concerned that inclusion of ONC–ACB execution of inthe-field surveillance within a developer’s real world testing approach could lead to confusion as to whether the organization that is an ONC–ACB was applying in-the-field surveillance protocols in its capacity as an ONC– ACB as part of its oversight responsibilities on behalf of ONC or in its private capacity on behalf of the health IT developer. We believe it is important, to protect HIPAA covered health care providers and other HIPAA covered entities and their business associates from inadvertently violating requirements related to disclosure of health information, to maintain a clear distinction of when an organization that is an ONC–ACB is acting in the ONC– ACB capacity and when it is acting in its private capacity. We note and emphasize this because, in the event a developer may choose to engage services in support of developing or implementing the developer’s real world testing plans from an organization or entity that also happens to be an ONC–ACB, all activities undertaken by the organization or entity to develop, execute, or support the development or execution of the developer’s real world testing plan would be activities outside the ONC–ACB role. In such circumstances, the organization that is an ONC–ACB would be acting in a separate, private capacity. Note that an organization providing such private services that involve ePHI would likely be characterized under the HIPAA Rules as a business associate to the health care provider and subject to the HIPAA Rules. The oversight authorities attached to its ONC–ACB role would not apply to the organization’s requests to gain access to health care provider facilities or to EHI for purposes of providing these separate support services to health IT developers for conduct of the developers’ real world testing. E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations Comments. Several commenters sought confirmation that a test server could be used for real world testing instead of a production environment, given the permissible use of synthetic data. Response. After considering the totality of comments received, we have decided to finalize that a test server could be used for real world testing and provide the flexibility included in the Proposed Rule that allows for real world testing to occur in a production setting using real patient data in accordance with applicable laws as well as in an environment that mirrors a specific production environment used in a type of clinical setting for which the health IT is marketed. We have also decided to finalize the flexibility for the developer to use synthetic patient data in lieu of or in addition to real patient data in real or simulated/test scenarios executed in environments that mirror production environments where the health IT is deployed. However, we emphasize that the purpose of real world testing is to demonstrate that the Health IT Module(s) work as expected in real-life clinical settings. We note, as a point of potential interest for such consideration, that real world testing plans that meet the Program requirement might include observation or measurement of the health IT’s interoperability performance while actual scenarios and use cases are executed by end users on real patient data in actual operational contexts. If a developer chooses to use synthetic data, non-production (mirrored) environments, or a combination of real and synthetic data or production and mirrored environments, to complete any portion of their annual real world testing requirements, the developer must include in their real world testing plan and results submissions a specific explanation justifying how the synthetic data, mirrored environment, or both are appropriate and adequate to meet the real world testing requirement(s) for which they will be or were used. Comments. Several commenters sought confirmation that a product serving multiple care settings could complete a single test relevant to all settings and ask ONC to provide a list of eligible care settings for reference. Response. The finalized real world testing Condition and Maintenance of Certification requirements include testing each criterion listed in § 170.405(a) to which any Health IT Module(s) within the product are certified, and testing in each type of setting to which it is marketed. To satisfy these Condition and Maintenance of Certification requirements as finalized, a single VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 testing plan, protocol, or approach must address all the types of settings to which the product, with all its included Health IT Module(s), is marketed and do so with traceability to each Health IT Module of its real world performance in each type of setting for which it is marketed. We believe it is possible to construct a real world use scenario or use case that tests more than one type of setting applicable to the Health IT Module, and confirm that a developer is not required to develop unnecessarily or artificially separate scenarios or use cases across multiple types of settings to which a given developer markets its applicable Health IT Module(s). With respect to the types of settings required to be addressed by a given developer’s plan, we do not believe that additional specification is necessary because we believe each developer is well situated to know for what types of settings the developer (or its authorized resellers) has marketed, is marketing, or intends to market its Health IT Modules. For purposes of this Condition and Maintenance of Certification requirement as finalized, there is no exclusion for settings or health care provider types based on their inclusion or lack of inclusion in, or eligibility or ineligibility for, and particular Federal health care program or initiative. Therefore, the types of settings eligible to be addressed in a developer’s real world testing plan for a given year include all those to which product(s) including one or more Health IT Modules certified to one or more of the criteria listed at § 170.405(a) as of August 31 of the year in which that specific annual real world testing plan is due have been or are marketed when the real world testing plan is submitted, and/or the types of settings for which the developer anticipates marketing such product(s) in time to include them in a specific year’s real world testing activities. Comments. Several commenters requested ONC ensure that real world testing requirements do not create infrastructure for testing of public health transactions without public health involvement. Several commenters noted that public health organizations and many public health agencies already offer resources and processes used in onboarding processes for public health reporting connections and suggested these resources and processes could be used more broadly to test health IT’s real world performance on public health interoperability criteria rather than requiring creation of new or different tools. Response. We would tend to agree that relying for specific use cases on PO 00000 Frm 00131 Fmt 4701 Sfmt 4700 25771 testing infrastructures developed without appropriate involvement of key participants in the use case would not be an optimal approach. Also, we reiterate that we encourage developers to consider a variety of options and approaches before finalizing their annual real world testing plans. We would encourage developers to consider the real world testing potential of resources, tooling, and infrastructure already offered by public health organizations and agencies before embarking on efforts to develop additional tooling. We also note that, for the interoperability-focused public health criteria, alternatives that would avoid both overuse of simulation environments and asking public health agencies to engage in work unique to developers’ real world testing plans might include structured observation and measurement of interoperability performance in actual public health data reporting/exchange as well as the testing ordinarily conducted for onboarding/ confirming connectivity of newly deployed/upgraded implementations to public health data exchange infrastructures. Comments. A number of commenters expressed support of requiring the use of metrics/measurements for real world testing. One commenter stated that ONC should not allow just one measurement to suffice for real world testing of interoperability of a Health IT Module. Several commenters recommended ONC include a description of ‘‘measurement,’’ provide clarity on the role of measurement, and provide a ‘‘sample’’ or suggested set of metrics/ measurements to help foster alignment of reporting around meaningful common metrics/measurements across developers. Some commenters recommended ONC identify a core set of metrics/measures that developers would be required to include, or from which developers would be required to select specific metrics/measures to include, in their real world testing plans. Other commenters advocated against developers being required to submit testing results for a minimum ‘‘core’’ set of general metrics, providing the rationale that not all metrics will be available to all systems uniformly and suggesting that many metrics are retained in the provider’s locally integrated production systems and unavailable to the developer of any given Module(s) without considerable effort to retrieve the data. One commenter recommended requiring that each developer’s real world test plan include measures addressing all of the domains of the NQF report: E:\FR\FM\01MYR3.SGM 01MYR3 25772 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations Measurement Framework to Assess Nationwide Progress Related to Interoperable Health Information Exchange to Support the National Quality Strategy.110 Response. The comments on real world testing did not show clear, widespread support for any specific subset of available metrics as a ‘‘core’’ set or catalog that a significant portion of the affected communities (health IT developers, health care providers, and public health agencies) would generally agree should be consistently used across all developers’ real world testing plans. Thus, we have finalized the real world testing plan requirements (see § 170.405(b)(1)(iii) and real world testing results reporting requirements (see § 170.405(b)(2)(ii)) without identifying a minimum set of measures that must be used or a catalog of suggested measures from which a developer would be expected to choose in constructing its real world testing plans. We reiterate that each developer must choose a measurement approach, including at least one measurement/ metric per applicable criterion, for use in each year’s real world testing and explain the selection and relevance of its selected measures/metrics within its justification for its real world testing approach in that year’s plan and results report. Comments. Comments were received on the frequency and timing of real world testing. One commenter stated the policy should not require annual testing if the capability certified for a given criterion remains unchanged year to year, offering the example that if a Health IT Module is certified for both § 170.315(b)(1) and (b)(2) and the developer is planning to release material updates to the capabilities specific to § 170.315(b)(1), but not make any material changes specific to the Module’s certification to § 170.315(b)(2), this commenter would prefer that the Health IT Module would need to submit a testing plan and subsequent results addressing only the § 170.315(b)(1) criterion for the year the change is made. Another commenter expressed skepticism regarding the value of annual real world testing requirements, expressing a preference for an approach that developers would, after an initial cycle of post-certification real world testing of a Health IT Module, be required to re-test only when updating to National Coordinator-approved newer versions of adopted standards included in applicable criteria or when making 110 https://www.qualityforum.org/Projects/i-m/ Interoperability_2016–2017/Key_Informant_ Summary_Report.aspx (last accessed 12/17/2019). VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 major functional updates to the certified Health IT Module. One commenter who was overall not supportive of the real world testing requirement stated that developers would need a two-year cycle instead of a one-year cycle in order to adequately demonstrate compliance with full functionality testing. One commenter specifically expressed support for the annual frequency and timing of required real world testing results reporting. Response. We thank the commenters for their feedback regarding the frequency and timing of real world testing. We have finalized the requirement for annual testing in § 170.405(b)(1). Ongoing annual testing is needed to ensure that Health IT Module(s) continue to perform as intended in the types of settings where patients and health care providers continue to rely on it to meet their interoperability needs. Comments. Several commenters expressed support of the proposed real world testing plan requirements and requested we strengthen this provision to require that developers test their products within each clinical specialty to which the technology would be marketed. One commenter requested that we define with more particularity what is expected of developers during the testing to account for the differing conditions under which Health IT Modules are deployed, and how for example, the system works particular conditions like server degradation. Several other commenters suggested we provide a standardized template for use in developing test plans. Commenters described a template would include all required testing elements and promote greater consistency in the way the test plans are written by the various developers. Response. For reasons stated in the Proposed Rule (84 FR 7496) and above, we do not believe a centrally developed or standardized approach for real world testing plans is the most appropriate solution at this time. By centrally mandating or endorsing a single template in the interest of consistently formatted documentation, we are concerned that we might inadvertently discourage innovation in both testing approaches and their communication to the customer community. What the plan must include or address for each applicable criterion to which the developer’s Health IT Module(s) are certified is outlined in § 170.405(b)(1)(iii), as finalized by this rule. We believe the plan requirements finalized in the plan requirements in § 170.405(b) are specific enough to ensure the plans can be completed by PO 00000 Frm 00132 Fmt 4701 Sfmt 4700 developers and effectively reviewed for completeness by ONC–ACBs, and that both the substance and clarity or efficacy of presentation can both be examined and considered by any interested parties—from health care providers to informatics and interoperability researchers. Because individual circumstances and needs may vary even within the same type of setting or clinician specialty, it would be not be possible at this time to define a real world testing regime that eliminated all of the variability developers may have in implementing their real world testing plans. Comments. One commenter sought clarification on the total minimum number of metrics required for a developer’s real world testing plan to be considered complete and in compliance with the requirement. Response. A developer’s real world testing plan must include at least one metric for each applicable certification criteria. To ensure that we are providing clear guidance, we offer the following illustrative example: A developer with one Health IT Module that is certified to five criteria would need to include in its real world testing plan at least one specific measurement/metric associated with the real world testing for each of those five criteria. Depending on the specific criteria and the developer’s real world testing approach, this could call for up to five different measurements/ metrics, or could be addressed with fewer different measurements/metrics but a specific measurement/metric would need to be identified/attributed within the plan to each of the applicable certification criteria. Comments. A few commenters stated concerns regarding our mandatory focus on scenario- and use case-focused testing. One commenter expressed a view that this would be expensive and time consuming, stating that this expense limits scenario- and use casefocused testing in the number of settings that can realistically be tested in any given year. One commenter noted that as more settings are tested, fewer scenarios can be run per setting. Two commenters sought more information on the mandatory scenario- and use case-focused testing that will be required, recommending that Health Information Service Providers (HISPs) be able to attest to the relevant use cases and provide the proper evidence of testing associated to those scenarios. Response. In light of comments received, we can see how our use of terms that are also used in the context of ONC–ATL laboratory or ONC–ACB surveillance testing, and our reference in one instance to in-the-field E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations surveillance, could have led to an inference that our use of these terms implied we would expect to see the same or similar testing protocols used in real world testing. However, we did not propose that real world testing would require developers to set up and execute artificial scenarios or activities solely for purposes of testing. In fact, we do not encourage use of the laboratory testing or ONC–ACB in-the-field surveillance protocols to conduct real world testing, as those particular test methods, tools, and surveillance protocols were not designed and should not be relied upon for real world testing. The testing methods/methodologies need to address realistic scenarios, use cases, and workflows associated with interoperability, and we do expect developers to consider such factors as the size of the organization that production systems support, the type of organization and setting, the number of patient records and users, system components and integrations, and the volume and types of data exchange in planning for real world testing. Comments. One commenter expressed agreement that the developer is best situated to determine the most effective real world testing plan for their products. One commenter requested developers be allowed to work together with their customers to define what real world tests are. Response. The requirements we proposed and finalized provide developers the opportunity to identify, potentially in partnership with their customers, the real-life scenarios, use cases, and work flows applicable to the customer’s day-to-day use of the Health IT Module(s) to meet their interoperability needs in their production environments. d. Submission Dates We proposed that a health IT developer must submit an annual real world testing plan to its ONC–ACB via a publicly accessible hyperlink for availability to ONC and the public no later than December 15, of each calendar year, and that the plan must address all of its Health IT Modules certified to the 2015 Edition certification criteria listed in proposed in § 170.405(a) and (84 FR 7496). We proposed requiring that prior to submission to the ONC–ACB, the plan will need to 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. We proposed that the plan due in any given year will need to include all health IT certified to the 2015 Edition through August 31 of that VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 year (in other words, the August 31 that immediately preceded the December 15 due date). We further proposed that a health IT developer would submit annual real world testing results to their ONC–ACBs via a publicly accessible hyperlink no later than January 31 of each calendar year for the real world testing conducted in the preceding calendar year (84 FR 7497). We proposed that real world testing results for each certification criterion listed in § 170.405(a) would be required to address the elements required in the previous year’s testing plan, describe the outcomes of real world testing with any challenges encountered, and provide at least one measurement or metric associated with the real world testing. Comments. Some commenters expressed concerns that the annual real world testing plan due date falls in December, noting that in addition to multiple holidays widely celebrated in the U.S., December can be a busy time for many health IT developers due to various year-end requirements and necessary preparations to support customers’ quality measurement data submissions for CMS programs. Response. We understand the commenters’ concern that the proposed real world testing plan publication due date falls in the preparatory run-up to year-end deadlines, including for many developers completing preparations to support their customers’ successful clinical quality measurement data submission during CMS program windows that typically open on the first Federal business day in January. In consideration of comments received, we have made edits to the phrasing of the CFR text in § 170.405(b) to convey with more precise clarity that under the policy we have finalized, the developer is required to submit its real world testing plans so that the ONC–ACB can conduct its completeness review and publish the plan hyperlink on CHPL no later than December 15 of each year. This allows for the ONC–ACB and developer to identify and agree on the date by which the developer will actually submit its plan to the ONC– ACB, which could be well in advance of December. One practical implication of the single-deadline feature of the policy as proposed is that in order for the plans to be submitted to ONC and made publicly available by the single deadline, the ONC–ACB’s requirement to review plans for completeness per Program requirements will in many cases mean that the ONC–ACB will need the developer to submit the plan to the ONC–ACB in advance of the single deadline. We have finalized the PO 00000 Frm 00133 Fmt 4701 Sfmt 4700 25773 December 15 due date for real world testing plan publication on CHPL as proposed. We have also made clarifying edits to the finalized regulation text (see § 170.405(b)(1)) in comparison to the proposed text to more explicitly recognize the practical implication that the developers’ and ONC–ACBs’ responsibility for a single publication date for the plans means that the plan must be submitted by the developer to the ONC–ACB on a date agreed between them that allows for publication by the deadline. We encourage developers and ONC–ACBs to consider allowing at least one calendar month so that the December 15 due date for ONC–ACBs’ publication of real world testing plans will be consistently met. We also note that nothing in § 170.405 as finalized precludes a developer and ONC–ACB from agreeing on the developer submitting its annual real world testing plan to the ONC–ACB more than one month prior to December 15. We have finalized the single plan publication deadline as proposed. We did not receive comments specific to August 31 as the annual date when a Health IT Module must be certified by in order to be required to be included in the real world testing plan due that year. We have finalized this aspect of our policy as proposed in § 170.405(b)(1)(ii). Thus, developers can submit their real world testing plans as early as September 1 and on a rolling basis thereafter for products in scope for the following year, which also addresses commenter concerns. We did not receive comments specific to this point, but have removed from § 170.405(b) as finalized the language that would have specifically required the initial submission of the plan to the ONC–ACB by the developer must be by a publicly accessible hyperlink. While this remains an option, and could be the most efficient one for developers and ONC–ACBs in many instances, we believe this is an unnecessarily limiting specification of the manner of interaction between developers and ONC–ACBs in these instances. The URL or hyperlink in CHPL will not be published on CHPL until the ONC–ACB takes action to publish it, and the ONC– ACB is required to review the plan and ensure it is complete before publishing the plan link on CHPL. Comments. We received some comments that appeared to construe our intent to be that real world testing for all Health IT Modules certified as of August 31 of a given year would need to be planned, conducted, and reported within five months of that date. Comments that appeared to be based on this interpretation also expressed E:\FR\FM\01MYR3.SGM 01MYR3 25774 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations concern that this would be too much to accomplish on such an annual schedule. Response. We proposed that each developer’s annual real world testing plan required to be published by December 15 of a given year would need to address all of the developer’s Health IT Modules certified to criteria listed in § 170.405(a) as of August 31 of that year (84 FR 7496). We also proposed that this annual real world testing plan would pertain to real world testing activities to be conducted in the year following the December 15 plan publication due date. In light of comments received, we can see how we might have been more precise in how we stated that the annual results report would be due early in the year following the year in which the testing it reported was conducted. The full cycle of real world testing for a given year was never specifically proposed to be contained within a single year, considering that the plan is due in the year prior and the results report was proposed to be due in the year following the one in which a given annual round of real world testing activity occurs. Comments. Comments raised concerns that the January 31 publication deadline might not leave enough time for developers who do not or cannot complete their annual testing activities until late in the testing year to submit their results reports, and ONC–ACBs complete their required reviews, prior to the publication deadline. One commenter raised a specific concern that the proposed January 31 due date for real world testing results falls in the submission window for several CMS programs for which developers’ customers need to submit their clinical quality measurement data for the preceding year. One commenter recommended leveraging the existing quarterly update attestation process and asking developers to conduct real world testing on those items identified as major changes. Response. As with the plan due date, the practical implication of this proposal is that each developer will need to submit their results reports to their ONC–ACB sufficiently in advance of the due date for publication for the ONC–ACB to be able to complete its pre-publication responsibilities for all of the results reports and still publish no later than that due date. In theory, this means that in some cases developers could complete their real world testing relatively early in a given testing year and submit their results report for that year before the CMS submission window for that year’s measurement data even opens for the developer’s customers. However, considering the VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 comments received, we do recognize it is possible developers may for various reasons not be able to complete their annual real world testing activities until fairly late in any given testing (calendar) year. We also recognize that the data submission window for CMS programs can be a busy time for developers, and would not wish to disadvantage newer or smaller developers who may not have separate resources available to finalize a report of real world testing not concluded until late in the testing year while simultaneously supporting customers’ data submissions. In light of these comments, we have decided to finalize a deadline for publication on the CHPL of the publicly accessible hyperlink to developers’ report of real world testing conducted in the prior year at March 15 of each year (see § 170.405(b)(2)(ii)). This finalized date gives an additional six weeks for finalization and submission by developers compared to the date originally proposed. It also implements a single deadline, to which the developers and ONC–ACBs are mutually accountable, in parallel to the annual real world testing plan submission requirement in § 170.405(b)(1). We believe this strikes an appropriate balance between timely availability of annual real world testing results and recognition that some developers may need to devote a substantial amount of focus to the CMS quality measures data submission windows at the beginning of each year. Although we have opted not to mandate developers submit their results reports to their ONC–ACBs by a date providing a minimum required lead time for ONC– ACBs’ required review of the report, we would suggest that ONC–ACBs and developers consider the potential merits of allowing at least one calendar month between the developer’s initial submission of their real world testing results report to the ONC–ACB and the March 15 publication deadline. e. Real World Testing Pilot Year We acknowledged in the Proposed Rule that a subsequent final rule for that may not provide sufficient time for health IT developers to develop and submit plans for a full year of real world testing in 2020 (84 FR 7497). Therefore, we indicated in the Proposed Rule that we expected to provide an appropriate period of time for developers to submit their plans, and potentially treat 2020 as a ‘‘pilot’’ year for real world testing. We expected that the pilot testing of real world testing would match up to the fullest extent practicable with our proposed real world testing requirements (e.g., same criteria but for PO 00000 Frm 00134 Fmt 4701 Sfmt 4700 a shorter duration and without the same consequences for noncompliance). We welcomed comments on this potential approach. Comments. The majority of comments specifically addressing this point were in support of 2020 being treated as a pilot year. One commenter agreed that deferring the implementation or constructing a pilot year for the Program would be appropriate and stated their belief that 2020 may be too early even to conduct a pilot. Response. We thank commenters for their thoughts on potential piloting of real world testing and the timing of initiating real world testing requirements. In consideration of the timing of the final rule, we have decided not to finalize 2020 as a pilot year since developers will now have the majority of calendar year 2020 to develop a prospective plan for real world testing that would begin in 2021. However, we recognize that this first ‘‘performance’’ year of real world testing in 2021 presents unique challenges with respect to the development of initial plans, and we fully intend to approach both the submission of initial plans and submission of retrospective testing results for those plans (i.e., 2021 real world testing results) as learning experiences for developers that can be used to inform future iterations of real world test plans. As noted in the proposed rule (84 FR 7497), the due date for the first annual real world testing plan would be finalized based in part on the timing of the final rule. Because this final rule is publishing well in advance of the December 15 annual due date for publication of developers’ plans of real world testing activities to be conducted in the following year, we have concluded it is reasonable to require the first annual real world testing plan be published via a publicly accessible hyperlink on the CHPL no later than December 15, 2020. This initial real world testing plan must address any and all of the developer’s Health IT Modules that hold a current, valid certificate under the Program as of August 31, 2020. The real world testing plan due to be published in December 2020, will need to address the real world testing activities that will occur during calendar year 2021. The report of results for this initial (2021) annual real world test cycle will be due to be published on the CHPL no later than March 15, 2022. f. Health IT Modules Certified But Not Yet Deployed We proposed (84 FR 7497) that even if a health IT developer does not have customers or has not deployed their E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations certified Health IT Module(s) at the time the real world testing plan is due, the health IT developer would still need to submit a plan that prospectively addresses its plans for real world testing that would occur in the coming year for those Health IT Modules that had been certified on or before August 31 of the calendar year in which the plan is due (the calendar year immediately preceding the calendar year during which testing addressed by any given annual real world testing plan will take place). If a health IT developer has not yet deployed their certified Health IT Module to any real world users when the annual real world testing results are due for that module, we proposed that the developer would need to report as such to meet the proposed Maintenance of Certification requirement. Comments. We received no comments on this proposal. Response. We have finalized this proposal. Any Health IT Module certified to at least one criterion within the scope of real world testing as of August 31 of a given year must be addressed by its developer’s real world testing plan for the subsequent year that must be published via publicly accessible hyperlink on the CHPL by the December 15 due date (see § 170.405(a)). This requirement applies regardless of whether that Health IT Module is in actual real world use prior to December 15 (or the earlier date by which the developer and ONC–ACB agree the developer will submit its annual real world testing plan to the ONC–ACB to ensure the developer and ONC–ACB meet single, December 15, deadline for the plan to have been reviewed for completeness and published on CHPL). To ensure precise clarity about the effect of the August 31 reference date for purposes of real world testing requirements, we reiterate that if a developer has at least one Health IT Module certified to at least any one criterion within the real world testing scope of applicability as of August 31 of a given year, the real world testing Condition and Maintenance of Certification requirements apply to that developer and the developer must submit an annual real world testing plan for that year, addressing each of their Health IT Module(s) certified to any (one or more) criteria listed in § 170.405(a) and that plan must meet the requirements in § 170.405(b)(1)(iii) for each module and criterion. Only developers who have no Health IT Module(s) certified to any criterion within the real world testing scope of applicability as of August 31 of a given year need not submit a real world testing plan that year and would not be VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 required to perform real world testing in the subsequent year. g. Standards Version Advancement Process (SVAP) As discussed in the Proposed Rule (84 FR 7497), as newer versions 111 become available for adopted standards and implementation specifications included in the certification criteria subject to the real world testing Condition and Maintenance of Certification requirements, we believe that a health IT developer’s ability to conduct ongoing maintenance on its certified Health IT Module(s) to incorporate these newer versions of Secretary-adopted standards and implementation specifications (‘‘standards’’) is essential to support interoperability in the real world. Updated versions of standards reflect insights gained from real-world implementation and use. They also reflect industry stakeholders’ interests to improve the capacity, capability, and clarity of such standards to meet new, innovative business needs, which earlier standards versions cannot support. Therefore, as part of the real world testing Condition of Certification, we proposed a Maintenance of Certification flexibility that we refer to as the Standards Version Advancement Process (SVAP).112 This flexibility would permit health IT developers to voluntarily use in their certified Health IT Modules newer versions of adopted standards so long as certain conditions are met. As we stated in the Proposed Rule, these conditions are not limited to but notably include successful real world testing of the Health IT Module using the new version(s) subsequent to the inclusion of these newer standards and implementation specification versions in the Health IT Module’s certification. We proposed to establish the SVAP not only to meet the Cures Act’s goals for interoperability, but also in response to the continuous stakeholder feedback that ONC has received through prior rulemakings and engagements, which requested that ONC establish a predictable and timely approach within the Program to keep 111 We note that standards developing organizations and consensus standards bodies use various nomenclature, such as ‘‘versions’’ or ‘‘releases,’’ to identify updates to standards and implementation specifications. 112 Regulation text implementing the real world testing Condition and Maintenance of Certification requirement was proposed in § 170.405, including but not limited to SVAP-specific provisions proposed in § 170.405(b)(5). The SVAP-specific provisions have now been finalized in § 170.405(b)(8) and (9) (see section VII.B.5.g of this final rule). PO 00000 Frm 00135 Fmt 4701 Sfmt 4700 25775 pace with the industry’s standards development efforts. The SVAP we proposed, with corresponding proposed revisions for §§ 170.500 and 170.555, introduces two types of administrative flexibility for health IT developers participating in the Program (84 FR 7498). First, for those health IT developers with existing certified Health IT Module(s), such Health IT Modules could be upgraded to a new version of an adopted standard within the scope of the certification and have support for that updated version of the standard reflected on the Health IT Module’s certificate so long as: Such version was approved by the National Coordinator for use in the Program; and the developer satisfied all requirements of the SVAP including demonstration of conformance through an acceptable means (84 FR 7498 through 7500). For purposes of the SVAP as applied to updates to Health IT Modules with certificates to criteria listed in § 170.405(a) that include prior version(s) 113 of the standards, acceptable means of demonstrating conformance include but are not necessarily limited to self-declaration of conformance, as proposed in 84 FR 7499 and finalized in this final rule. Second, for those health IT developers presenting health IT for certification to a criterion listed in § 170.405(a), a National Coordinator-approved newer version of a standard included in one of these criteria could be used in lieu of or in addition to the version of that standard incorporated by reference in § 170.299 (84 FR 7498). However, for purposes of the SVAP as applied to health IT that is presented for certification to any criterion listed in § 170.405(a), developer self-declaration is an acceptable means of demonstrating conformance only where there is not yet another conformance method available that can be validly used for that version of that standard (84 FR 7499 through 7500). The regulation text codifying requirements for health IT developers to avail themselves of each of the proposed types of administrative flexibility was proposed (84 FR 7595 through 7596) in § 170.405(b)(5). Corresponding revisions to § 170.550 and § 170.555 were proposed in 84 FR 7598. We proposed that the SVAP would be available only for National Coordinatorapproved newer versions of standards and implementation specifications (‘‘standards’’) that have already been 113 Prior versions for this purpose could include those incorporated by reference in § 170.299, National Coordinator approved newer versions, or a mix of such versions for any or all of the standards adopted by the Secretary in subpart B of part 170 that are included in a given criterion. E:\FR\FM\01MYR3.SGM 01MYR3 25776 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations adopted into the Program by the Secretary through rulemaking in accordance with applicable law including the Administrative Procedures Act (5 U.S.C. 553) and sections 3001 and 3004 of the Public Health Service Act (PHSA) (42 U.S.C. 300jj–1 and 42 U.S.C. 300jj–11) (84 FR 7498). We have finalized this aspect of the standards version advancement flexibility as proposed. Under current law and the finalized SVAP flexibility, a standard must be initially adopted by the Secretary through rulemaking before the National Coordinator can approve the use of newer updated versions of that standard in the Program. We also proposed that a health IT developer would be able to choose which of the updated standards versions approved by the National Coordinator for use in certification to include in its updated certified Health IT Module and would be able to do so on an itemized basis (84 FR 7499). We stated in the Proposed Rule that we welcomed comments on any and all aspects of our proposed SVAP as an option available to developers through maintenance requirements as part of the real world testing Condition and Maintenance of Certification requirements (84 FR 7500). We also invited comments on our proposal to allow in conjunction with this maintenance flexibility the opportunity for developers to elect to present health IT for initial testing and certification either to more advanced versions or to the prior adopted versions of the standards included in regulatory text as of the date the Health IT Modules are presented for certification. Comments. Comments were strongly supportive of the SVAP. Several commenters recommended the description of this process include recognition of the fact that developers and systems might need to maintain operational support for previously adopted versions of standards to avoid potential adverse effects on data access, exchange, and use. Response. We have finalized the SVAP in § 170.405(b)(8) and (9) to provide the flexibility for which stakeholders’ comments expressed support. This flexibility includes the option for a Health IT Module to be certified to the standards versions incorporated by reference in § 170.299 and/or one or more National Coordinator-approved updated versions of standards included in the criteria listed in § 170.405(a). Thus, once the National Coordinator has approved for use in the Program more advanced version(s) of any standard(s) applicable to any of the criteria listed in VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 § 170.405(a), a health IT developer will have flexibility to choose on an itemized basis which of the National Coordinatorapproved updated standards versions they wish to have included in their Health IT Module certification(s). Using the SVAP flexibility does not require a developer cease supporting prior version releases of standards referenced by applicable certification criteria. Comments. Several commenters expressed concerns about the effect of an uneven pace of advanced version implementatio