25642 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

DEPARTMENT OF HEALTH AND a. Adoption of the United States Core Data b. USCDI Standard—Data Classes Included HUMAN SERVICES for Interoperability (USCDI) as a c. USCDI Standard—Relationship to Standard Content Exchange Standards and Office of the Secretary b. Electronic Prescribing Implementation Specifications c. Clinical Quality Measures—Report 2. Clinical Notes C-CDA Implementation d. Electronic Health Information (EHI) Specification 45 CFR Parts 170 and 171 Export 3. Unique Device Identifier(s) for a RIN 0955–AA01 e. Application Programming Interfaces Patient’s Implantable Device(s) C-CDA f. Privacy and Security Transparency Implementation Specification 21st Century Cures Act: Attestations 4. Electronic Prescribing Criterion Interoperability, Information Blocking, g. Security Tags and Consent Management a. Electronic Prescribing Standard and and the ONC Health IT Certification 3. Modifications To the ONC Health IT Certification Criterion Certification Program b. Electronic Prescribing Transactions Program 4. Health IT for the Care Continuum 5. Clinical Quality Measures—Report AGENCY: Office of the National 5. Conditions and Maintenance of Criterion Coordinator for Health Information Certification Requirements 6. Electronic Health Information (EHI) 6. Information Blocking Export Criterion Technology (ONC), Department of C. Costs and Benefits a. Single Patient Export To Support Patient Health and Human Services (HHS). II. Background Access ACTION: Final rule. A. Statutory Basis b. Patient Population Export to Support 1. Standards, Implementation Transitions Between Health IT Systems SUMMARY: This final rule implements Specifications, and Certification Criteria c. Scope of Data Export certain provisions of the 21st Century 2. Health IT Certification Program(s) d. Export Format Cures Act, including Conditions and B. Regulatory History e. Initial Step Towards Real-Time Access Maintenance of Certification C. General Comments on the Proposed f. Timeframes requirements for health information Rule g. 2015 Edition ‘‘Data Export’’ Criterion in technology (health IT) developers under III. Deregulatory Actions for Previous § 170.315(b)(6) Rulemakings 7. Standardized API for Patient and the ONC Health IT Certification Program A. Background Population Services Criterion (Program), the voluntary certification of 1. History of Burden Reduction and 8. Privacy and Security Transparency health IT for use by pediatric health care Regulatory Flexibility Attestations Criteria providers, and reasonable and necessary 2. Executive Orders 13771 and 13777 a. Encrypt Authentication Credentials activities that do not constitute B. Deregulatory Actions b. Multi-Factor Authentication information blocking. The 1. Removal of Randomized Surveillance 9. Security Tags and Consent Management implementation of these provisions will Requirements Criteria advance interoperability and support 2. Removal of the 2014 Edition From the a. Implementation With the Consolidated the access, exchange, and use of Code of Federal Regulations CDA Release 2.1 3. Removal of the ONC-Approved b. Implementation With the Fast electronic health information. The rule Accreditor From the Program Healthcare Interoperability Resources also finalizes certain modifications to 4. Removal of Certain 2015 Edition (FHIRr) Standard the 2015 Edition health IT certification Certification Criteria and Standards 10. Auditable Events and Tamper- criteria and Program in additional ways a. 2015 Edition Base EHR Definition Resistance, Audit Reports, and Auditing to advance interoperability, enhance Certification Criteria Actions on Health Information health IT certification, and reduce b. Drug-Formulary and Preferred Drug Lists C. Unchanged 2015 Edition Criteria— burden and costs. c. Patient-Specific Education Resources Promoting Interoperability Programs d. Common Clinical Data Set Summary Reference Alignment DATES: Record—Create; and Common Clinical V. Modifications To the ONC Health IT Effective date: This final rule is Data Set Summary Record—Receive Certification Program effective on June 30, 2020. e. Secure Messaging A. Corrections Incorporation by reference: The 5. Removal of Certain ONC Health IT 1. Auditable Events and Tamper Resistance incorporation by reference of certain Certification Program Requirements 2. Amendments publications listed in the rule was a. Limitations Disclosures 3. View, Download, and Transmit to 3rd approved by the Director of the Federal b. Transparency and Mandatory Party Register as of June 30, 2020. Disclosures Requirements 4. Integrating Revised and New Compliance date: Compliance with 45 6. Recognition of Food and Drug Certification Criteria Into the 2015 CFR 170.401, 170.402(a)(1), and 45 CFR Administration Processes Edition Privacy and Security part 171 is required by November 2, a. FDA Software Precertification Pilot Certification Framework Program B. Principles of Proper Conduct for ONC- 2020. b. Development of Similar Independent ACBs FOR FURTHER INFORMATION CONTACT: Program Processes—Request for 1. Records Retention Michael Lipinski, Office of Policy, Information 2. Conformance Methods for Certification Office of the National Coordinator for IV. Updates To the 2015 Edition Certification Criteria Health Information Technology, 202– Criteria 3. ONC-ACBs To Accept Test Results From 690–7151. A. Standards and Implementation Any ONC-ATL in Good Standing Specifications 4. Mandatory Disclosures and SUPPLEMENTARY INFORMATION: 1. National Technology Transfer and Certifications Table of Contents Advancement Act C. Principles of Proper Conduct for ONC- 2. Compliance With Adopted Standards ATLs—Records Retention I. Executive Summary and Implementation Specifications VI. Health IT for the Care Continuum A. Purpose of Regulatory Action 3. ‘‘Reasonably Available’’ to Interested A. Health IT for Pediatric Setting B. Summary of Major Provisions and Parties 1. Background and Stakeholder Convening Clarifications B. Revised and New 2015 Edition Criteria 2. Recommendations for the Voluntary 1. Deregulatory Actions for Previous 1. The United States Core Data for Certification of Health IT for Use in Rulemakings Interoperability Standard (USCDI) Pediatric Care 2. Updates to the 2015 Edition Certification a. USCDI 2015 Edition Certification a. 2015 Edition Certification Criteria Criteria Criteria b. New or Revised Certification Criteria

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00002 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25643

B. Health IT and Opioid Use Disorder c. Records Access to access, exchange, or use EHI due to Prevention and Treatment—Request for d. Corrective Action the infeasibility of the request not be Information e. Certification Ban and Termination considered information blocking? VII. Conditions and Maintenance of f. Appeal e. Health IT Performance Exception— Certification Requirements for Health IT g. Suspension When will an actor’s practice that is Developers h. Proposed Termination implemented to maintain or improve A. Implementation 4. Public Listing of Certification Ban and health IT performance and that is likely B. Provisions Terminations to interfere with the access, exchange, or 1. Information Blocking 5. Effect on Existing Program Requirements use of EHI not be considered information 2. Assurances and Processes blocking? a. Full Compliance and Unrestricted 6. Coordination With the Office of 2. Exceptions That Involve Procedures for Implementation of Certification Criteria Inspector General Fulfilling Requests To Access, Exchange, Capabilities 7. Applicability of Conditions and or Use EHI b. Certification to the ‘‘Electronic Health Maintenance of Certification a. Content and Manner Exception—When Information Export’’ Criterion Requirements for Self-Developers will an actor’s practice of limiting the c. Records and Information Retention VIII. Information Blocking content of its response to or the manner d. Trusted Exchange Framework and the A. Statutory Basis in which it fulfills a request to access, Common Agreement—Request for B. Legislative Background and Policy exchange, or use EHI not be considered Information Considerations information blocking? 3. Communications 1. Purpose of the Information Blocking b. Fees Exception—When will an actor’s a. Background and Purpose Provision practice of charging fees for accessing, b. Condition of Certification Requirements 2. Policy Considerations and Approach to exchanging, or using EHI not be c. Maintenance of Certification Information Blocking considered information blocking? Requirements 3. General Comments Regarding c. Licensing Exception—When will an 4. Application Programming Interfaces Information Blocking Exceptions actor’s practice to license a. Statutory Interpretation and API Policy C. Relevant Statutory Terms and Provisions interoperability elements in order for Principles 1. ‘‘Required by Law’’ EHI to be accessed, exchanged, or used b. API Standards and Implementation 2. Health Care Providers, Health IT not be considered information blocking? Specifications Developers, Exchanges, and Networks E. Additional Exceptions—Request for c. Standardized API for Patient and a. Health Care Providers Information Population Services b. Health IT Developers of Certified Health 1. Exception for Complying With Common d. API Condition of Certification IT Agreement for Trusted Exchange Requirements c. Health Information Networks and Health 2. New Exceptions e. API Maintenance of Certification Information Exchanges F. Complaint Process Requirements 3. Electronic Health Information G. Disincentives for Health Care 5. Real World Testing 4. Price Information—Request for Providers—Request for Information a. Unit of Analysis at which Testing Information IX. Registries Request for Information Requirements Apply 5. Interests Promoted by the Information X. Patient Matching Request for Information b. Applicability of Real World Testing Blocking Provision XI. Incorporation by Reference Condition and Maintenance of a. Access, Exchange, and Use of EHI XII. Collection of Information Requirements Certification Requirements b. Interoperability Elements A. ONC–ACBs c. Testing Plans, Methods, and Results 6. Practices That May Implicate the B. Health IT Developers Reporting Information Blocking Provision XIII. Regulatory Impact Analysis d. Submission Dates a. Prevention, Material Discouragement, A. Statement of Need e. Real World Testing Pilot Year and Other Interference B. Alternatives Considered f. Health IT Modules Certified But Not Yet b. Likelihood of Interference C. Overall Impact Deployed c. Examples of Practices Likely to Interfere 1. Executive Orders 12866 and 13563— g. Standards Version Advancement Process With Access, Exchange, or Use of EHI Regulatory Planning and Review (SVAP) 7. Applicability of Exceptions Analysis h. Updating Already Certified Health IT a. Reasonable and Necessary Activities 2. Executive Order 13771—Reducing Leveraging SVAP Flexibility b. Treatment of Different Types of Actors Regulation and Controlling Regulatory i. Health IT Modules Presented for c. Establishing That Activities and Costs Certification Leveraging SVAP Practices Meet the Conditions of an a. Costs and Benefits Flexibility Exception b. Accounting Statement and Table j. Requirements Associated With All D. Exceptions to the Information Blocking 3. Regulatory Flexibility Act Health IT Modules Certified Leveraging Definition 4. Executive Order 13132—Federalism SVAP Flexibility 1. Exceptions That Involve not Fulfilling 5. Unfunded Mandates Reform Act of 1995 k. Advanced Version Approval for SVAP Requests To Access, Exchange, or Use Regulation Text l. Real World Testing Principles of Proper EHI Conduct for ONC-ACBs a. Preventing Harm Exception—When will I. Executive Summary m. Health IT Module Certification & an actor’s practice that is likely to A. Purpose of Regulatory Action Certification to Newer Versions of interfere with the access, exchange, or Certain Standards use of EHI in order to prevent harm not ONC is responsible for the 6. Attestations be considered information blocking? implementation of key provisions in 7. EHR Reporting Criteria Submission b. Privacy Exception—When will an actor’s Title IV of the 21st Century Cures Act C. Compliance practice of not fulfilling a request to (Cures Act) that are designed to advance D. Enforcement access, exchange, or use EHI in order to interoperability; support the access, 1. ONC Direct Review of the Conditions protect an individual’s privacy not be exchange, and use of electronic health and Maintenance of Certification considered information blocking? information (EHI); and address Requirements c. Security Exception—When will an occurrences of information blocking. 2. Review and Enforcement Only by ONC actor’s practice that is likely to interfere 3. Review Processes with the access, exchange, or use of EHI This final rule implements certain a. Initiating Review and Health IT in order to protect the security of EHI not provisions of the Cures Act, including Developer Notice be considered information blocking? Conditions and Maintenance of b. Relationship With ONC-ACBs and ONC- d. Infeasibility Exception—When will an Certification requirements for health ATLs actor’s practice of not fulfilling a request information technology (health IT)

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00003 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25644 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

developers, the voluntary certification B. Summary of Major Provisions and and implementation specification of health IT for use by pediatric health Clarifications updates. In consideration of public comments, the final rule adds only two providers, and reasonable and necessary 1. Deregulatory Actions for Previous new technical certification criteria and activities that do not constitute Rulemakings information blocking. The final rule also two new attestation-structured privacy implements parts of section 4006(a) of Since the inception of the Program, and security certification criteria. the Cures Act to support patients’ access we have aimed to implement and administer the Program in the least a. Adoption of the United States Core to their EHI in a form convenient for burdensome manner that supports our Data for Interoperability (USCDI) as a patients, such as making a patient’s EHI policy goals. Throughout the years, we Standard more electronically accessible through have worked to improve the Program We noted in the Proposed Rule that, the adoption of standards and with a focus on ways to reduce burden, as part of continued efforts to ensure the certification criteria and the offer flexibility to both developers and availability of a minimum baseline of implementation of information blocking providers, and support innovation. This data classes that could be commonly policies that support patient electronic approach has been consistent with the available for interoperable exchange, access to their health information at no principles of E.O. 13563 on Improving ONC adopted the 2015 Edition cost. Additionally, the final rule Regulation and Regulatory Review ‘‘Common Clinical Data Set’’ (CCDS) modifies the 2015 Edition health IT (February 2, 2011), which instructs definition and used the CCDS shorthand certification criteria and ONC Health IT agencies to ‘‘periodically review its in several certification criteria. Certification Program (Program) in other existing significant regulations and However, the CCDS definition also ways to advance interoperability, determine whether any such regulations began to be used colloquially for many enhance health IT certification, and should be modified, streamlined, different purposes. As the CCDS reduce burden and costs. expanded, or repealed so as to make the definition’s relevance grew outside of its agency’s regulatory program more regulatory context, it was often viewed In addition to fulfilling the Cures effective or less burdensome in as a ceiling to the industry’s collective Act’s requirements, the final rule achieving the regulatory objectives.’’ To data set for access, exchange, and use. contributes to fulfilling Executive Order that end, we have historically, where In addition, we noted in the NPRM that (E.O.) 13813. The President issued E.O. feasible and appropriate, taken as we continue to move toward value- 13813 on October 12, 2017, to promote measures to reduce burden within the based care, the inclusion of additional health care choice and competition Program and make the Program more data classes beyond the CCDS would be across the United States. Section 1(c) of effective, flexible, and streamlined. necessary. In order to advance the E.O., in relevant part, states that We reviewed and evaluated existing interoperability, we proposed to remove government rules affecting the United regulations and identified ways to the CCDS definition and its references States health care system should re- administratively reduce burden and from the 2015 Edition and replace it inject competition into health care implement deregulatory actions through with the ‘‘United States Core Data for markets by lowering barriers to entry guidance. In this final rule, we have Interoperability 1’’ (USCDI). We and preventing abuses of market power. finalized new deregulatory actions that proposed to adopt the USCDI as a Section 1(c) also states that government will reduce burden for health IT standard, naming USCDI Version 1 rules should improve access to and the developers, providers, and other (USCDI v1) in § 170.213 and quality of information that Americans stakeholders. We have finalized five incorporating it by reference in need to make informed health care deregulatory actions in section III.B: (1) § 170.299. The USCDI standard would decisions. For example, as mentioned Removal of a requirement to conduct establish a set of data classes and randomized surveillance on a set constituent data elements required to above, the final rule establishes percentage of certified products, support interoperability nationwide. To application programming interface (API) allowing ONC-Authorized Certification achieve the goals set forth in the Cures requirements, including for patients’ Bodies (ONC–ACBs) more flexibility to Act, we indicated that we intended to access to their health information identify the right approach for establish and follow a predictable, without special effort. The API surveillance actions; (2) removal of the transparent, and collaborative process to approach also supports health care 2014 Edition from the Code of Federal expand the USCDI, including providing providers’ independence to choose the Regulations (CFR); (3) removal of the stakeholders with the opportunity to ‘‘provider-facing’’ third-party services ONC-Approved Accreditor (ONC–AA) comment on the USCDI’s expansion. We they want to use to interact with the from the Program; (4) removal of certain also noted that once the USCDI is certified API technology they have 2015 Edition certification criteria; and adopted by the Secretary in regulation, acquired. In addition, the final rule (5) removal of certain Program health IT developers would be allowed provides the Secretary of Health and requirements. We have not finalized a to take advantage of a new proposed Human Services’ (Secretary) sixth deregulatory action we proposed, flexibility we called the ‘‘Standards interpretation of the information related to recognition of the Food and Version Advancement Process’’ (SVAP) blocking definition as established in the Drug Administration (FDA) Software (see 84 FR 7497 through 7500, see also Cures Act and the application of the Precertification Program, as comments section VII.B.5 of this final rule). In information blocking provision by and the early stage of development of order to advance interoperability, we identifying reasonable and necessary the FDA program indicate finalization have finalized the adoption of the activities that would not constitute would be premature at this time. USCDI standard. Because the USCDI is information blocking. Many of these adopted as a standard and the SVAP is 2. Updates to the 2015 Edition finalized, the SVAP will allow a activities focus on improving patient Certification Criteria developer to voluntarily have their and health care provider access to EHI This final rule updates the 2015 products certified to newer, National and promoting competition. Edition to remove several certification Coordinator approved versions of the criteria. It also updates some certification criteria to reflect standard 1 https://www.healthit.gov/uscdi.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00004 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25645

USCDI in the future without waiting for d. Electronic Health Information (EHI) data are the focus. The API certification rulemaking to update the version of the Export criterion requires the use of the Health ® USCDI listed in the regulations. We proposed to adopt a new 2015 Level 7 (HL7 ) Fast Healthcare Interoperability Resources (FHIR®) b. Electronic Prescribing Edition certification criterion, referred to as ‘‘EHI export’’ in § 170.315(b)(10) in standard Release 4 and references We have finalized an update to the the Proposed Rule. The criterion’s several standards and implementation electronic prescribing National Council proposed conformance requirements specifications adopted in § 170.213 and for Prescription Drug Programs (NCPDP) were intended to provide a means to § 170.215 to support standardization SCRIPT standard in 45 CFR 170.205(b) export the entire EHI a certified health and interoperability. This certification from NCPDP SCRIPT standard version IT product produced and electronically criterion will align industry efforts around FHIR Release 4 and advance 10.6 to NCPDP SCRIPT standard version managed to support two contexts: (1) interoperability of API-enabled ‘‘read’’ 2017071 for the electronic prescribing Single patient EHI export and (2) for services for single and multiple patients. certification criterion (§ 170.315(b)(3)). patient EHI export when a health care ONC and the Centers for Medicare & provider is switching health IT systems. f. Privacy and Security Transparency Medicaid Services (CMS) have The proposals did not require the Attestations historically maintained aligned e-Rx exported data to be in a specific We have adopted two new privacy and medication history (MH) standards standardized format. Rather, we and security certification criteria to ensure that the current standard for proposed to require that such an export requiring transparency attestations from certification to the electronic be in a computable, electronic format developers of certified health IT as part prescribing criterion supports use of the made available via a publicly accessible of the updated 2015 Edition privacy and current Part D e-Rx and MH standards. hyperlink. We noted that this security certification framework. The This helps advance alignment with transparency would facilitate the attestations will serve to identify CMS’ program standards. subsequent interpretation and use of the whether or not certified health IT In a final rule published April 16, exported information. supports encrypting authentication We have finalized the criterion with 2018, CMS finalized its update of its credentials and/or multi-factor modifications in response to public Part D standards to NCPDP SCRIPT authentication (MFA). While these comment. We have refined the scope of standard version 2017071 for e-Rx and criteria provide increased transparency, data a Health IT Module certified to MH, effective January 1, 2020 (83 FR they do not require new development or § 170.315(b)(10) must export, and 16440). In addition to continuing to implementation to take place. As part of aligned the criterion to the definition of reference the transactions previously ONC’s ongoing commitment to advance EHI we finalized in § 170.102 and included in § 170.315(b)(3), and in transparency about certified health IT § 171.102. The finalized criterion products, ONC will list the developers’ keeping with CMS’ final rule, we have requires a certified Health IT Module to adopted all of the additional NCPDP attestation responses on the Certified electronically export all of the EHI, as Health IT Product List (CHPL). SCRIPT standard version 2017071 defined in § 171.102, that can be stored transactions that CMS adopted in 42 at the time of certification by the g. Security Tags and Consent CFR 423.160(b)(2)(iv). Furthermore, we product, of which the Health IT Module Management have adopted the same electronic Prior is a part. We finalized the 2015 Edition In the 2015 Edition final rule (80 FR Authorization (ePA) request and Cures Update ‘‘EHI export’’ criterion in 62646, Oct. 16, 2015), we adopted two response transactions supported by § 170.315(b)(10) but did not finalize its ‘‘data segmentation for privacy’’ (DS4P) NCPDP SCRIPT standard 2017071 inclusion in the 2015 Edition Base certification criteria, one for creating a proposed by CMS in the Medicare Electronic Health Record (EHR) summary record according to the DS4P Program; Secure Electronic Prior definition, as proposed. Our intention standard (§ 170.315(b)(7)) and one for Authorization for Medicare Part D with this criterion, in combination with receiving a summary record according proposed rule (84 FR 28450). Some other criteria set forth in this final rule, to the DS4P standard (§ 170.315(b)(8)). adopted transactions are required to is to advance the interoperability of Certification to these 2015 Edition DS4P demonstrate conformance to the health IT as defined in section 4003 the criteria only required security tagging of updated § 170.315(b)(3) criterion, while Cures Act, including the ‘‘complete Consolidated-Clinical Document other transactions are optional. access, exchange, and use of all Architecture (C–CDA) documents at the c. Clinical Quality Measures—Report electronically accessible health document level. As noted in the 2015 information.’’ Edition final rule (80 FR 62646), In this final rule, we have removed certification to these criteria is not e. Application Programming Interfaces the Health Level 7 (HL7®) Quality linked to meeting the Certified EHR (APIs) Reporting Document Architecture Technology definition (CEHRT) used in (QRDA) standard requirements in the We have adopted a new API CMS programs. 2015 Edition ‘‘Clinical Quality certification criterion in Since the 2015 Edition final rule, the Measures—report’’ criterion in § 170.315(g)(10) to replace the health care industry has engaged in § 170.315(c)(3) and, in their place, ‘‘application access—data category additional field testing and required Health IT Modules to support request’’ certification criterion implementation of the DS4P standard. the CMS QRDA Implementation Guide (§ 170.315(g)(8)), and added it to the Stakeholders also shared with ONC— (IGs).2 This will help reduce the burden updated 2015 Edition Base EHR through public forums, listening for health IT developers and remove definition. This new ‘‘standardized API sessions, and correspondence—that certification requirements that do not for patient and population services’’ only tagging C–CDA documents at the support quality reporting for CMS certification criterion focuses on document level did not permit programs. supporting two types of API-enabled providers the flexibility to address more services: (1) Services for which a single complex use cases for representing 2 https://ecqi.healthit.gov/qrda-quality-reporting- patient’s data is the focus and (2) patient privacy preferences. Based on document-architecture. services for which multiple patients’ public comment, in this final rule, we

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00005 Fmt 4701 Sfmt 4700 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 evaluation conducted by the ONC–ACB specialties and sites of service. Over current 2015 Edition DS4P criteria to for Health IT Modules’ compliance with time, we have taken steps to make the Security tags—Summary of Care (send) certification criteria by use of Program modular, more open and and Security tags—Summary of Care conformity methods approved by the accessible to different types of health IT, (receive). We also updated the National Coordinator for Health and better able to advance functionality requirements for these criteria to Information Technology (National that is generally applicable to a variety support security tagging at the Coordinator). We also have finalized the of care and practice settings. We document, section, and entry levels. addition of § 170.523(r) to require ONC– considered a wide range of factors This change better reflects the purpose ACBs to accept test results from any specific to the provisions in the Cures of these criteria and enables adopters to ONC-Authorized Testing Laboratory Act to support providers of health care support a more granular approach to (ONC–ATL) in good standing under the for children. These include: The security tagging clinical documents for Program and compliant with the ISO/ evolution of health IT across the care exchange. IEC 17025 accreditation requirements continuum, the costs and benefits In finalizing this more granular consistent with the requirements set associated with health IT, the potential approach for security tagging forth in §§ 170.520(b)(3) and 170.524(a). regulatory burden and compliance Consolidated Clinical Document We believe these new and revised PoPC timelines, and the need to help advance Architecture (C–CDA) documents, we provide necessary clarifications for health IT that benefits multiple medical note that we do not specify rules or ONC–ACBs and promote stability specialties and sites of service involved requirements for the disposition of among the ONC–ACBs. We also have in the care of children. In consideration tagged data or any requirements on finalized the update of § 170.523(k) to of these factors, and to advance health care providers related to data broaden the requirements beyond just implementation of section 4001(b) of the segmentation for privacy. The use cases the Medicare and Medicaid EHR Cures Act specific to pediatric care, we for which health IT certified to these Incentive Programs (now renamed the held a listening session where criteria might be implemented would be Promoting Interoperability (PI) Programs stakeholders could share their clinical driven by other applicable Federal, and referenced as such hereafter) and knowledge and technical expertise in State, local, or tribal law and are outside provided other necessary clarifications. pediatric care and pediatric sites of the scope of the certification criteria. We We have finalized a revised PoPC for service. Through the information recognize that the tagging of documents ONC–ATLs. The finalized revision learned at this listening session and our is not a fully automated segmentation of clarifies that the records retention analysis of the health IT landscape for the record but rather a first, provision includes the ‘‘life of the pediatric settings, we identified existing technological step or tool to support edition’’ as well as three years after the 2015 Edition criteria, as well as new or health IT developers implementing retirement of an edition related to the revised 2015 Edition criteria proposed technology solutions for health care certification of Complete EHRs and in the Proposed Rule, that could benefit providers to replace burdensome Health IT Modules. providers of pediatric care and pediatric manual processes for tagging sensitive 4. Health IT for the Care Continuum settings. In this final rule, we have information. identified the already existing 2015 We also proposed to adopt a new Section 4001(b) of the Cures Act Edition certification criteria and the 2015 Edition certification criterion, includes two provisions related to new or revised 2015 Edition criteria ‘‘consent management for APIs’’ in supporting health IT across the care adopted in this final rule that support § 170.315(g)(11), to support data continuum. The first instructs the the voluntary certification of health IT segmentation and consent management National Coordinator to encourage, for pediatric care and pediatric settings. through an API in accordance with the keep, or recognize through existing Consent Implementation Guide (IG). authorities the voluntary certification of We also elaborate on our next steps to However, in response to comments, we health IT for use in medical specialties support pediatric care and pediatric have chosen not to finalize our proposal and sites of service where more settings through the development, for this criterion at this time. technological advancement or adoption, certification, and use of health integration is needed. The second IT, including the continued support of 3. Modifications to the ONC Health IT outlines a provision related to the a pediatrics health IT web page on Certification Program voluntary certification of health IT for www.healthit.gov/pediatrics and the In this final rule, we have finalized use by pediatric health providers to future development of informational corrections to the 2015 Edition privacy support the health care of children. resources. and security certification framework (80 These provisions align closely with our We also recognize the significance of FR 62705) and relevant regulatory core purpose to promote interoperability the opioid epidemic confronting our provisions. We also have finalized and to support care coordination, nation and the importance of helping to corrections to the relevant current patient engagement, and health care support the health IT needs of health Certification Companion Guides (CCGs). quality improvement initiatives. care providers committed to preventing We have adopted new and revised Advancing health IT that promotes and inappropriate access to prescription Principles of Proper Conduct (PoPC) for supports patient care when and where opioids and to providing safe, ONC–ACBs. We have finalized it is needed continues to be a primary appropriate treatment. Therefore, we clarification that the records retention goal of the Program. This means health requested public comment on how our provision includes the ‘‘life of the IT should support patient populations, existing Program requirements and the edition’’ as well as three years after the specialized care, transitions of care, and proposals in the Proposed Rule may retirement of an edition related to the practice settings across the care support use cases related to Opioid Use certification of Complete EHRs and continuum. Disorder (OUD) prevention and Health IT Modules. We also have We have explored how we might treatment and if there were additional finalized revisions to the PoPC in work with the health IT industry and areas that we should consider for § 170.523(h) to clarify the basis for with specialty organizations to effective implementation of health IT to certification, including to permit a collaboratively develop and promote help address OUD prevention and certification decision to be based on an health IT that supports medical treatment. We received over 100

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00006 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25647

comments in responses to this RFI, Secretary, the developer will not take has contracts/agreements in existence which we are actively reviewing. any action that constitutes information that contravene the requirements of this blocking as defined in section 3022(a) of Condition of Certification, the developer 5. Conditions and Maintenance of the PHSA or any other action that may must notify all affected customers, other Certification Requirements inhibit the appropriate exchange, persons, or entities that the prohibition We have established in this final rule, access, and use of EHI. We have or restriction within the contract/ certain Conditions and Maintenance of finalized our proposed implementation agreement will not be enforced by the Certification requirements for health IT of this provision through several health IT developer. In response to developers based on the Conditions and Conditions of Certification and comments, we have finalized in Maintenance of Certification accompanying Maintenance of § 170.403(b)(2)(ii) that health IT requirements outlined in section 4002 of Certification requirements, which are developers are required to amend their the Cures Act. The Program’s set forth in § 170.402. We have also contracts/agreements to remove or make Conditions and Maintenance of adopted more specific Conditions and void such provisions only when the Certification requirements express Maintenance of Certification contracts/agreements are next modified initial requirements for health IT requirements, which are also set forth in for other purposes and not within the developers and their certified Health IT § 170.402, for certified health IT proposed period of time from the Module(s) as well as ongoing developers to provide assurances to the effective date of this final rule. requirements that must be met by both Secretary that it does not take any other health IT developers and their certified action that may inhibit the appropriate Application Programming Interfaces Health IT Module(s) under the Program. exchange, access, and use of EHI. These (APIs) In this regard, we have implemented the requirements serve to provide further As a Condition of Certification Cures Act Conditions of Certification clarity under the Program as to how requirement in section 4002 of the Cures requirements with further specificity as health IT developers must meet our Act requires health IT developers to it applies to the Program and requirements as promulgated under the publish APIs that allow ‘‘health implemented any accompanying Cures Act. information from such technology to be Maintenance of Certification accessed, exchanged, and used without requirements as standalone Communications special effort through the use of APIs or requirements to ensure that the The Cures Act also requires as a successor technology or standards, as Conditions of Certification requirements Condition and Maintenance of provided for under applicable law.’’ The are not only met but continually being Certification requirement under the Cures Act’s API Condition of met through the Maintenance of Program that health IT developers do Certification requirement also states that Certification requirements. In this rule, not prohibit or restrict communications a developer must, through an API, we capitalize ‘‘Conditions of about certain aspects of the performance ‘‘provide access to all data elements of Certification’’ and ‘‘Maintenance of of health IT and the developers’ related a patient’s electronic health record to Certification’’ when referring to business practices. We have finalized the extent permissible under applicable Conditions and Maintenance of (in § 170.403) provisions that permit privacy laws.’’ The Cures Act’s API Certification requirements established developers to impose certain types of Condition of Certification requirement for the Program under section 4002 of limited prohibitions and restrictions in section 4002 includes several key the Cures Act for ease of reference and that strike a balance between the need phrases and requirements for health IT to distinguish from other conditions. to promote open communication about health IT, and related developer developers that go beyond the technical Information Blocking business practices, with the need to functionality of the Health IT Modules Section 4002 of the Cures Act requires protect the legitimate business interests they present for certification. This final that a health IT developer, as a of health IT developers and others. The rule captures both the technical Condition and Maintenance of provisions identify certain narrowly- functionality and behaviors necessary to Certification requirement under the defined types of communications, such implement the Cures Act API Condition Program, not take any action that as communications required by law, of Certification requirement. constitutes information blocking as made to a government agency, or made Specifically, we have adopted new defined in section 3022(a) of the Public to a defined category of safety standards, new implementation Health Service Act (PHSA). We have organization, which will receive specifications, a new certification adopted the information blocking ‘‘unqualified protection’’ under our criterion, and have modified the Base Condition of Certification requirement Program. Under this policy, developers EHR definition. In addition, we have in § 170.401 as proposed. As finalized, will be prohibited from imposing any finalized detailed Condition and the Condition of Certification prohibitions or restrictions on such Maintenance of Certification requirement prohibits any health IT protected communications. Based on requirements for health IT developers. developer under the Program from public comment received, we have also Real World Testing taking any action that constitutes finalized provisions that allow health IT information blocking as defined by developers certified under the Program The Cures Act also added a new section 3022(a) of the PHSA. We have to place limitations on certain types of Condition and Maintenance of also finalized that definition in communications, including screenshots Certification requirement that health IT § 171.103. and video. developers must successfully test the We have adopted Maintenance of real world use of health IT for Assurances Certification requirements proposed in interoperability in the type(s) of Section 4002 of the Cures Act also § 170.403(b) with modifications. A setting(s) in which such technology requires that a health IT developer, as a health IT developer must not impose or would be marketed. This provision is Condition of Certification requirement enforce any contractual requirement critical to advancing transparency under the Program, provide assurances that contravenes the requirements of regarding Health IT Modules’ to the Secretary that, unless for this Condition of Certification. performance and to users having legitimate purpose(s) as specified by the Furthermore, if a health IT developer information that could be crucial to

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00007 Fmt 4701 Sfmt 4700 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 affected customers of their plans to Condition and Maintenance of health IT. update their certified health IT, and the Certification requirements under the As discussed in section VII.B.5 of this update’s anticipated impact on their Program, provide to the Secretary an final rule, we have established in existing certified health IT and attestation to all of the other Conditions § 170.405 real world testing Condition customers, specifically including but of Certification required in section and Maintenance of Certification not limited to whether, and if so for how 3001(c)(5)(D) of the PHSA, except for requirements that include Maintenance long, the health IT developer intends to the ‘‘EHR reporting criteria submission’’ of Certification requirements to update continue supporting the prior Condition of Certification requirement Health IT Modules certified to certain version(s) 3 of the standard(s) to which in § 3001(c)(5)(D)(vii). We have finalized certification criteria (see § 170.405(b)(3) the Health IT Module has already been regulation text implementing the Cures through (7) and section IV.B of this final certified, in addition to the National Act’s ‘‘attestations’’ Condition of rule preamble) to ensure this certified Coordinator-approved newer version(s) Certification requirement in § 170.406. technology meets its users’ needs for included in a planned update. Under § 170.406 as finalized by this widespread and continued We have finalized our proposal (84 FR rule, health IT developers will attest interoperability. 7501) to establish in § 170.523(p) a new twice a year to compliance with the As finalized, real world testing PoPC for ONC–ACBs that requires Conditions and Maintenance of Condition and Maintenance of ONC–ACBs to review and confirm that Certification requirements (except for Certification requirements apply to each health IT developer with one or the EHR reporting criteria submission health IT developers with one or more more Health IT Module(s) certified to requirement, which would be metrics Health IT Module(s) certified to specific any one or more of the criteria listed in reporting requirements separately certification criteria focused on § 170.405(a) submits real world testing implemented through a future interoperability and data exchange that plans and real world results on a rulemaking). We believe requiring are listed in § 170.405(a), as discussed timeframe that allows for the ONC–ACB attestations every six months under in section VII.B.5 of this final rule. to confirm completeness of all plans and § 170.406(b) will properly balance the Under these Condition and Maintenance results by applicable annual due dates. need to support appropriate of Certification requirements, health IT The specific annual due dates finalized enforcement with our desire to limit the developers must submit publicly in § 170.523(p) differ from those burden on health IT developers. In this available annual real world testing plans proposed as, and for the reasons, regard, we have also identified methods as well as annual real world testing discussed in section VII.B.5 of this final to make the process as simple and results for health IT certified to the rule preamble. Once completeness is efficient for health IT developers as criteria identified in § 170.405(a). We confirmed, ONC–ACBs must make the possible (e.g., 30-day attestation have also finalized a flexibility that we plans available to ONC and the public window, web-based form submissions, have named the Standards Version via the Certified Health IT Product List and attestation alert reminders). Advancement Process (SVAP). Under (CHPL).4 We have also finalized, with We have also finalized that this flexibility, health IT developers will clarifying revisions, the PoPC proposed attestations will be submitted to ONC– have the option to update their health in § 170.523(m) to require ONC–ACBs to ACBs. We have finalized a new PoPC in IT that is certified to the criteria aggregate and report to ONC no less § 170.523(q) that an ONC–ACB must identified in § 170.405(a) to use more than quarterly all updates successfully review these submissions for advanced version(s) of the adopted made to support National Coordinator- completion and share the health IT standard(s) or implementation approved newer versions of Secretary- developers’ attestations with us. We specification(s) included in the criteria, adopted standards in certified health IT would then make the attestations provided such versions are approved by pursuant to the developers having publicly available through the CHPL. the National Coordinator for use in voluntarily opted to avail themselves of health IT certified under the Program. the SVAP flexibility. We also finalize in EHR Reporting Criteria Submission Similarly, we have finalized our § 170.523(t) the new PoPC for ONC– The Cures Act specifies that health IT proposal (84 FR 7497 through 7500) that ACBs that requires them to ensure that developers be required, as Condition health IT developers presenting health developers seeking to take advantage of and Maintenance of Certification IT for initial certification to one of the the SVAP flexibility provide the requirements under the Program, to criteria listed in § 170.405(a) would advance notice required in submit reporting criteria on certified have the option to certify to National § 170.405(b)(8) to all affected customers health IT in accordance with the EHR Coordinator-approved newer version(s) and its ONC–ACB, and comply with all Reporting Program established under of one or more of the Secretary-adopted other applicable requirements. section 3009A of the PHSA, as added by standards or implementation the Cures Act. We have not yet Attestations specifications applicable to the established an EHR Reporting Program. criterion. All health IT developers Section 4002(a) of the Cures Act Once we establish such program, we voluntarily opting to avail themselves of requires that a health IT developer, as will undertake rulemaking to propose the SVAP flexibility must ensure that and implement the associated Condition their annual real world testing plans 3 In the near term, many of these prior versions and Maintenance of Certification and real world testing results are likely to be the same versions adopted by the Secretary and incorporated by reference in subpart requirements for health IT developers. submissions address all the versions of B of 45 CFR part 170. Over time, however, we Enforcement all the standards and implementation anticipate increasing frequency of prior versions specifications to which each Health IT certified including National Coordinator-approved Section 4002(a) of the Cures Act adds newer versions of these Secretary-adopted (in section 3001(c)(5)(D) of the PHSA) Module is certified. In addition, we standards. have finalized in § 170.405(b)(8)(i) the 4 Although real world testing plans and results Program requirements aimed at requirement that health IT developers will not be immediately available upon publication addressing health IT developers’ actions with existing certifications to criteria of this final rule, an overview of the CHPL is and business practices through the listed in § 170.405(a) who wish to avail available at https://chpl.healthit.gov/#/resources/ Conditions and Maintenance of overview (last accessed 07/12/2019). For additional themselves of the SVAP flexibility must information on how to navigate the CHPL, please Certification requirements, which notify both their ONC–ACB and their refer to the CHPL Public User Guide. expands the current focus of the

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00008 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25649

Program requirements beyond the the exceptions are limited to certain applicable conditions of the exception. certified health IT itself. Equally activities that we believe are important However, failure to meet the conditions important, Cures Act section 4002(a) to the successful functioning of the U.S. of an exception does not automatically also provides that the Secretary may health care system, including promoting mean a practice constitutes information encourage compliance with the public confidence in health IT blocking. A practice failing to meet all Conditions and Maintenance of infrastructure by supporting the privacy conditions of an exception only means Certification requirements and take and security of EHI, and protecting that the practice would not have action to discourage noncompliance. patient safety and promoting guaranteed protection from CMPs or We, therefore, have finalized our competition and innovation in health IT appropriate disincentives. The practice proposed enforcement framework for and its use to provide health care would instead be evaluated on a case- the Conditions and Maintenance of services to consumers. Second, each by-case basis to assess the specific facts Certification requirements in §§ 170.580 exception is intended to address a and circumstances (e.g., whether the and 170.581 to encourage consistent significant risk that regulated practice would be considered to rise to compliance with the requirements. individuals and entities (i.e., health care the level of an interference, and whether More specifically, we have finalized our providers, health IT developers of the actor acted with the requisite intent) proposed corrective action process in certified health IT, health information to determine whether information § 170.580 for ONC to review potential or networks, and health information blocking has occurred. known instances where a Condition or exchanges) will not engage in these In addition to establishing the Maintenance of Certification reasonable and necessary activities exceptions, we have defined and requirement under the Program has not because of potential uncertainty interpreted terms that are present in been met or is not being met by a health regarding whether they would be section 3022 of the PHSA (such as the IT developer. We have also finalized in considered information blocking. Third, types of individuals and entities §§ 170.580 and 170.581 our proposal to and last, each exception is intended to covered by the information blocking utilize, with minor modifications, the be tailored, through appropriate provision). We have also finalized new processes previously established for conditions, so that it is limited to the terms and definitions that are necessary ONC direct review of certified health IT reasonable and necessary activities that to implement the information blocking in the enforcement of the Conditions it is designed to exempt. provision. We have codified the and Maintenance of Certification The eight exceptions are set forth in information blocking section in a new requirements. Where we identify section VIII.D of this final rule. The five part of title 45 of the Code of Federal noncompliance, our first priority will be exceptions finalized in §§ 171.201–205, Regulations, part 171. and discussed in section VIII.D.1.a–e of to work with the health IT developer to C. Costs and Benefits remedy the matter through a corrective this final rule, involve not fulfilling action process. However, under certain requests to access, exchange, or use EHI. Executive Orders 12866 on Regulatory circumstances, ONC may ban a health These exceptions are intended to Planning and Review (September 30, IT developer from the Program and/or prevent harm and protect patient safety, 1993), and 13563 on Improving terminate the certification of one or promote the privacy and security of EHI, Regulation and Regulatory Review more of its Health IT Modules. excuse an actor from responding to (February 2, 2011), direct agencies to requests that are infeasible, and address assess all costs and benefits of available 6. Information Blocking activities that are reasonable and regulatory alternatives and, if regulation Section 4004 of the Cures Act added necessary to promote the performance of is necessary, to select regulatory section 3022 of the PHSA (42 U.S.C. health IT. The three exceptions finalized approaches that maximize net benefits 300jj–52, ‘‘the information blocking in §§ 171.301–303, and discussed in (including potential economic, provision’’). Section 3022(a)(1) of the section VIII.D.2.a–c of this final rule, environmental, public health and safety PHSA defines practices that constitute involve procedures for fulfilling effects, distributive impacts, and information blocking when engaged in requests to access, exchange, or use EHI. equity). A regulatory impact analysis by a health care provider, or a health These exceptions describe when an (RIA) must be prepared for major rules information technology developer, actor’s practice of limiting the content of with economically significant effects exchange, or network. Section its response to or the manner in which ($100 million or more in any one year). 3022(a)(3) authorizes the Secretary to it responds to a request to access, OMB has determined that this final rule identify, through notice and comment exchange, or use EHI will not be is an economically significant rule as rulemaking, reasonable and necessary considered information blocking; when the costs associated with this final rule activities that do not constitute an actor’s practice of charging fees, could be greater than $100 million per information blocking for purposes of the including fees that result in a reasonable year. Accordingly, we have prepared an definition set forth in section 3022(a)(1). profit margin, for accessing, exchanging, RIA that to the best of our ability We identify eight reasonable and or using EHI will not be considered presents the costs and benefits of this necessary activities as exceptions to the information blocking; and when an final rule. information blocking definition, each of actor’s practice to license We have estimated the potential which does not constitute information interoperability elements for EHI to be monetary costs and benefits of this final blocking for purposes of section accessed, exchanged, or used will not be rule for health IT developers, health 3022(a)(1) of the PHSA. The exceptions considered information blocking. care providers, patients, ONC–ACBs, apply to certain activities that are likely An actor will not be subject to ONC–ATLs, and the Federal to interfere with, prevent, or materially enforcement actions under the Government (i.e., ONC), and have discourage the access, exchange, or use information blocking provision for civil broken those costs and benefits out into of EHI, but that would be reasonable monetary penalties (CMP) or the following categories: (1) and necessary if certain conditions are appropriate disincentives if the actor’s Deregulatory actions (no associated met. practice satisfies at least one exception. costs); (2) updates to the 2015 Edition In developing and finalizing the final In order to satisfy an exception, each health IT certification criteria; (3) exceptions, we were guided by three relevant practice by an actor at all Conditions and Maintenance of overarching policy considerations. First, relevant times must meet all of the Certification requirements for a health

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00009 Fmt 4701 Sfmt 4700 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 1. Standards, Implementation under section 3001(c), and subsequently Conditions and Maintenance of Specifications, and Certification Criteria determine whether to propose the Certification requirements; and (5) The HITECH Act established two new adoption of any grouping of such information blocking. Federal advisory committees, the HIT standards, implementation We note that we have rounded all Policy Committee (HITPC) and the HIT specifications, or certification criteria. estimates to the nearest dollar and all Standards Committee (HITSC). Each The Secretary is required to publish all estimates are expressed in 2017 dollars was responsible for advising the determinations in the Federal Register. Section 3004(b)(3) of the PHSA, as it is the most recent data available to National Coordinator for Health which is titled Subsequent Standards address all cost and benefit estimates Information Technology (National Activity, provides that the Secretary consistently. We also note that we did Coordinator) on different aspects of shall adopt additional standards, not have adequate data to quantify some standards, implementation implementation specifications, and of the costs and benefits within this specifications, and certification criteria. certification criteria as necessary and RIA. In those situations, we have Section 3002 of the PHSA, as consistent with the schedule published described the non-quantified costs and amended by section 4003(e) of the Cures by the HITAC. We consider this benefits of our provisions; however, Act, replaced the HITPC and HITSC provision in the broader context of the such costs and benefits have not been with one committee, the Health HITECH Act and Cures Act to continue accounted for in the monetary cost and Information Technology Advisory to grant the Secretary the authority and benefit totals below. Committee (HIT Advisory Committee or discretion to adopt standards, We estimated that the total cost for HITAC). After that change, section implementation specifications, and this final rule for the first year after it 3002(a) of the PHSA established that the certification criteria that have been is finalized (including one-time costs), HITAC would advise and recommend to based on the cost estimates outlined recommended by the HITAC and the National Coordinator on different endorsed by the National Coordinator, above and throughout this RIA, would, aspects of standards, implementation on average, range from $953 million to as well as other appropriate and specifications, and certification criteria, necessary health IT standards, $2.6 billion with an average annual cost relating to the implementation of a of $1.8 billion. We estimate that the implementation specifications, and health IT infrastructure, nationally and certification criteria. total perpetual cost for this final rule locally, that advances the electronic (starting in year two), based on the cost access, exchange, and use of health 2. Health IT Certification Program(s) estimates outlined above, would, on information. Further described in Under the HITECH Act, section average, range from $366 million to $1.3 section 3002(b)(1)(A) of the PHSA, this 3001(c)(5) of the PHSA provides the billion with an average annual cost of included providing the National National Coordinator with the authority $840 million. Coordinator with recommendations on a to establish a program or programs for We estimated the total annual benefit policy framework to advance the voluntary certification of health IT. for this final rule, based on the benefit interoperable health IT infrastructure, Specifically, section 3001(c)(5)(A) estimates outlined above, would range updating recommendations to the policy specifies that the National Coordinator, from $1.2 billion to $5.0 billion with framework, and making new in consultation with the Director of the primary estimated annual benefit of $3.1 recommendations, as appropriate. National Institute of Standards and billion. Section 3002(b)(2)(A) identified that in Technology (NIST), shall keep or II. Background general, the HITAC would recommend recognize a program or programs for the to the National Coordinator, for voluntary certification of health IT that A. Statutory Basis purposes of adoption under section is in compliance with applicable The Health Information Technology 3004 of the PHSA, standards, certification criteria adopted under this for Economic and Clinical Health implementation specifications, and subtitle (i.e., certification criteria (HITECH) Act, Title XIII of Division A certification criteria and an order of adopted by the Secretary under section and Title IV of Division B of the priority for the development, 3004 of the PHSA). The certification American Recovery and Reinvestment harmonization, and recognition of such program(s) must also include, as Act of 2009 (the Recovery Act) (Pub. L. standards, specifications, and appropriate, testing of the technology in 111–5), was enacted on February 17, certification criteria. Similar to the accordance with section 13201(b) of the 2009. The HITECH Act amended the process previously required of the HITECH Act. Overall, section 13201(b) Public Health Service Act (PHSA) and former HITPC and HITSC, the HITAC of the HITECH Act requires that with created ‘‘Title XXX—Health Information will develop a schedule for the respect to the development of standards Technology and Quality’’ (Title XXX) to assessment of policy recommendations and implementation specifications, the improve health care quality, safety, and for the Secretary to publish in the Director of National Institute of efficiency through the promotion of Federal Register. Standards and Technology (NIST) shall health IT and electronic health Section 3004 of the PHSA identifies a support the establishment of a information (EHI) exchange. process for the adoption of health IT conformance testing infrastructure, The 21st Century Cures Act standards, implementation including the development of technical (hereinafter the ‘‘Cures Act’’) was specifications, and certification criteria test beds. The same HITECH Act enacted on December 13, 2016, to and authorizes the Secretary to adopt provision (section 13201(b)) also accelerate the discovery, development, such standards, implementation indicates that the development of this and delivery of 21st century cures, and specifications, and certification criteria. conformance testing infrastructure may for other purposes. The Cures Act, Pub. As specified in section 3004(a)(1), the include a program to accredit L. 114–255, included Title IV—Delivery, Secretary is required, in consultation independent, non-Federal laboratories which amended portions of the HITECH with representatives of other relevant to perform testing. Act (Title XIII of Division A of Pub. L. Federal agencies, to jointly review Section 4001 of the Cures Act 111–5) by modifying or adding certain standards, implementation amended section 3001(c)(5) of the PHSA provisions to the PHSA relating to specifications, and certification criteria to instruct the National Coordinator to health IT. endorsed by the National Coordinator encourage, keep, or recognize, through

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00010 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25651

existing authorities, the voluntary certification criteria (‘‘2015 Edition advance interoperability and support certification of health IT under the health IT certification criteria’’ or ‘‘2015 the access, exchange, and use of program for use in medical specialties Edition’’) and a new 2015 Edition Base electronic health information and is the and sites of service for which no such EHR definition. The 2015 Edition subject of this final rule. technology is available or where more established the capabilities and C. General Comments on the Proposed technological advancement or specified the related standards and Rule integration is needed. Section implementation specifications that 3001(c)(5)(C)(iii) in particular identifies CEHRT would need to include to, at a Comments. Numerous commenters that the Secretary, in consultation with minimum, support the achievement of expressed support for the overall relevant stakeholders, shall make ‘‘meaningful use’’ by eligible clinicians, direction of the Proposed Rule. recommendations for the voluntary eligible hospitals, and critical access Numerous commenters also expressed certification of health IT for use by hospitals under the Medicare and support for the policy goals expressed in pediatric health providers to support the Medicaid EHR Incentive Programs (EHR the Proposed Rule, including: Reduced care of children, as well as adopt Incentive Programs) (now referred to as health care costs; improved public certification criteria under section 3004 the Promoting Interoperability (PI) health surveillance; improved care to support the voluntary certification of Programs) 5 when the 2015 Edition is coordination, continuity of care, and health IT for use by pediatric health required for use under these and other shared access of data between patient providers. The Cures Act further programs referencing the CEHRT and provider; improved quality and amended section 3001(c)(5) of the PHSA definition. The 2015 Edition final rule patient safety; increased cost and by adding section 3001(c)(5)(D), which also made changes to the ONC HIT quality transparency; greater provides the Secretary with the Certification Program. The final rule efficiencies; and better health outcomes authority to require, through notice and adopted a proposal to change the for patients. A few commenters also comment rulemaking, Conditions and Program’s name to the ‘‘ONC Health IT commended our interest in ways to use Maintenance of Certification Certification Program’’ from the ONC health IT to address opioid use requirements for the Program. HIT Certification Program, modified the disorders. Many commenters also Program to make it more accessible to appreciated detailed context for the B. Regulatory History other types of health IT beyond EHR provisions in the Proposed Rule. Many The Secretary issued an interim final technology and for health IT that commenters stated that the proposed rule with request for comments on supports care and practice settings provisions and standards will provide January 13, 2010, (75 FR 2014), which beyond the ambulatory and inpatient opportunities for innovation as well as adopted an initial set of standards, settings, and adopted new and revised increase the ability of health care implementation specifications, and PoPC for ONC–ACBs. providers to connect new tools and certification criteria. On March 10, After issuing a proposed rule on services to their systems. 2010, we published a proposed rule (75 March 2, 2016, (81 FR 11056), we A number of commenters commended FR 11328) that proposed both a published a final rule titled, ‘‘ONC our responsiveness to the health care temporary and permanent certification Health IT Certification Program: community, including patients, in program for the purposes of testing and Enhanced Oversight and drafting the rule. A few commenters certifying health IT. A final rule Accountability’’ (81 FR 72404) (‘‘EOA suggested that the existing language in establishing the temporary certification final rule’’) on October 19, 2016. The the rule should remain mostly program was published on June 24, EOA final rule finalized modifications unchanged as ONC drafts the final rule. 2010, (75 FR 36158), and a final rule and new requirements under the Many commenters commended us for establishing the permanent certification Program, including provisions related to collaborating with public- and private- program was published on January 7, our role in the Program. The final rule sector partners in developing the 2011, (76 FR 1262). We have issued created a regulatory framework for our Proposed Rule. Specifically, some multiple rulemakings since these initial direct review of health IT certified commenters expressed appreciation for rulemakings to update standards, under the Program, including, when our work with CMS and their implementation specifications, necessary, requiring the correction of companion Interoperability and Patient certification criteria, and the non-conformities found in health IT Access Proposed Rule. A number of certification program, a history of which certified under the Program and commenters shared that they look can be found in the October 16, 2015 suspending and terminating forward to working with us and CMS as final rule titled, ‘‘2015 Edition Health certifications issued to Complete EHRs the health care industry progresses Information (Health IT) Certification and Health IT Modules. The final rule toward an interoperable system, making Criteria, 2015 Edition Base Electronic also sets forth processes for us to it easier for small independent practices Health Record (EHR) Definition, and authorize and oversee accredited testing and providers to move to value-based ONC Health IT Certification Program laboratories under the Program. In care. Modifications’’ (80 FR 62602) (‘‘2015 addition, it includes provisions for Response. We appreciate the support Edition final rule’’). A final rule expanded public availability of certified expressed by many commenters. This corrections and clarifications notice was health IT surveillance results. final rule maintains the direction of the published for the 2015 Edition final rule On March 4, 2019, the Secretary Proposed Rule, and we too look forward on December 11, 2015, (80 FR 76868), published a proposed rule titled, ‘‘21st to ongoing collaboration with public to correct preamble and regulatory text Century Cures Act: Interoperability, and private sector partners as we errors and clarify requirements of the Information Blocking, and the ONC implement the provisions of this final Common Clinical Data Set (CCDS), the Health IT Certification Program’’ (84 FR rule. 2015 Edition privacy and security 7424) (‘‘Proposed Rule’’). The Proposed Comments. A few commenters certification framework, and the Rule proposed to implement certain recommended that the final rule include mandatory disclosures for health IT provisions of the Cures Act that would additional resources to assist with developers. readability and ease of understanding. The 2015 Edition final rule 5 https://www.federalregister.gov/d/2018-16766/ Response. We thank commenters for established a new edition of p-4. their feedback. As we did with the

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00011 Fmt 4701 Sfmt 4700 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 and time required to record health comments requesting the issuance of an resources such as infographics, fact information in EHRs for clinicians; (2) IFR or a SNPRM. We believe that the sheets, webinars, and other forms of reduce the effort and time required to advance posting of the Proposed Rule educational materials and outreach. meet regulatory reporting requirements on the ONC website, the initial 60-day Many of the education materials can be for clinicians, hospitals, and health care comment period, and the 30-day found on www.HealthIT.gov/curesrule. organizations; and (3) improve the extension, provided adequate time for Comments. Several commenters functionality and intuitiveness (ease of comment, especially given the large expressed the opinion that the use of use) of EHRs. volume of comments received. EHRs—and health IT, more generally— In addition to the final strategy As discussed in the information has negatively affected the quality of mentioned above, we refer readers to blocking section of the Proposed Rule health care delivery and that the section III of this final rule, Deregulatory (84 FR 7508), after hearing from Proposed Rule will exacerbate this Actions for Previous Rulemakings, for stakeholders and based on our findings issue. Some of these commenters stated more information on how we have from our 2015 Report to Congress,8 we that the need to input information into worked to improve the Program with a concluded that information blocking is EHRs during office visits has resulted in focus on ways to reduce burden, offer a serious problem and recommended clinicians spending less time flexibility to both health IT developers that Congress prohibit information communicating with patients, and some and providers, and support innovation. blocking and provide penalties and noted the impact of data entry on Comments. We received several enforcement mechanisms to deter these clinician burnout. A few commenters comments from a variety of stakeholders harmful practices. Congress responded made a similar point that use of EHRs to extend the 60-day comment period by enacting the Cures Act on December has reduced productivity and, as a for the Proposed Rule, stating that due 13, 2016, with many provisions result, increased health care spending. to the depth and complexity of the specifying a need for swift Response. We thank commenters for policies proposed, it would be critical implementation. It has been three years their feedback. We are aware of the for the public to have extended time to since the Cures Act was enacted and challenges stakeholders have provide sufficient and thoughtful information blocking remains a serious experienced in using EHRs and health comments to advance shared goals and concern. This final rule includes IT more broadly. In the Cures Act, shape the interoperability landscape. provisions that will address information Congress identified the importance of Response. In response to stakeholder blocking and cannot be further delayed. easing regulatory and administrative inquiries to extend the 60-day public We have taken multiple actions to burdens associated with the use of EHRs comment period and based on the stated address some expressed concerns and health IT. Specifically, through goals of the Proposed Rule to improve regarding the timing of the Conditions section 4001(a) of the Cures Act, interoperability and patient access to and Maintenance of Certification Congress directed the Department of health information for the purposes of requirements as well as the Health and Human Services to establish promoting competition and better care, comprehensiveness of the information a goal, develop a strategy, and provide we extended the comment period for the blocking proposals. These actions recommendations to reduce EHR-related Proposed Rule for an additional 30 days include some burden reduction by burdens that affect care delivery. which ended on June 3, 2019. removing certain certification criteria, To that end, on November 28, 2018, Comments. A number of commenters narrowing the scope of certain we, in partnership with CMS, released recommended delaying the final rule by certification criteria, and increasing the a draft Strategy on Reducing Regulatory issuing an Interim Final Rule (IFR) with compliance timeline with criteria. For and Administrative Burden Relating to comment. Commenters noted that many purposes of information blocking, we the Use of Health IT and EHRs 6 for organizations are providing comments have established compliance date for 45 public comment. This draft strategy that include new information blocking CFR part 171 that is six months, rather reflects input HHS received through exceptions and that we will not be able than sixty days, after the date this final several wide-reaching listening sessions, to incorporate such suggestions into the rule publishes in the Federal Register. written input, and stakeholder outreach. final rule without an opportunity for We have also focused the scope of EHI, We released the final report on February comment. Several commenters stated and provided new and revised 21, 2020. Reflective of public comment, that an IFR was appropriate due to the exceptions that are actionable and the final Strategy on Reducing significance and breadth of the reduce burden. One of these new Regulatory and Administrative Burdens Proposed Rule, as well the magnitude of exceptions (see § 171.301(a) and section Relating to the Use of Health IT and changes proposed and that an IFR VIII.D.2.a of this final rule) includes a EHRs 7 targets burdens tied to regulatory would allow for additional opportunity provision by which, until 24 months and administrative requirements that for stakeholder comment. after this rule is published in the HHS can directly impact through the Several commenters recommended Federal Register, an actor’s conduct can rulemaking process. The report’s that ONC consider issuing a satisfy the conditions of the Content and strategies, recommendations, and policy Supplemental Notice of Proposed Manner Exception (§ 171.301) if they shifts aim to give clinicians more time Rulemaking (SNPRM) to seek additional provide at least the content that is to focus on what matters—caring for comments on the information blocking within the USCDI in response to a their patients. Based on stakeholder provisions. Some of these commenters request for access, exchange, or use of input, the final strategy outlines three stated that new definitions and terms EHI. Because of these reasons and those overarching goals designed to reduce introduced in the Proposed Rule need noted above, we decline to issue an IFR clinician burden: (1) Reduce the effort additional clarification and an SNPRM or SNPRM. Rather, we have issued this would enable ONC to propose such final rule to support interoperability, 6 https://www.healthit.gov/sites/default/files/ clarifications and seek feedback on empower patient control of their health page/2018–11/Draft%20Strategy modified proposals. care, and instill competition in health %20on%20Reducing%20Regulatory Response. We recognize the %20and%20Administrative care markets. %20Burden%20Relating.pdf. importance of allowing enough time for 7 https://www.healthit.gov/sites/default/files/ comment given the breadth of the 8 https://www.healthit.gov/sites/default/files/ page/2020-02/BurdenReport_0.pdf. Proposed Rule and acknowledge the reports/info_blocking_040915.pdf.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00012 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25653

III. Deregulatory Actions for Previous ONC introduced further means to was followed by E.O. 13777, titled Rulemakings reduce regulatory burden, increase ‘‘Enforcing the Regulatory Reform regulatory flexibility, and promote Agenda’’ (February 24, 2017). E.O. A. Background innovation in the 2014 Edition Release 13777 provides further direction on 1. History of Burden Reduction and 2 final rule (79 FR 54430) published on implementing regulatory reform by Regulatory Flexibility September 11, 2014. The 2014 Edition identifying a process by which agencies Release 2 final rule established a set of must review and evaluate existing Since the inception of the ONC Health optional 2014 Edition certification regulations and make recommendations IT Certification Program (Program), we criteria that provided flexibility and for repeal or simplification. have aimed to implement and alternative certification pathways for In order to implement these administer the Program in the least health IT developers and providers regulatory reform initiatives and burdensome manner that supports our based on their specific circumstances. policies, ONC reviewed and evaluated policy goals. Through the years, we The 2014 Edition Release 2 final rule existing regulations in the year leading have worked to improve the Program also simplified the Program by to the issuance of the 21st Century with a focus on ways to reduce burden, discontinuing the use of the ‘‘Complete Cures Act: Interoperability, Information offer flexibility, and support innovation. EHR’’ certification concept beginning Blocking, and the ONC Health IT This approach has been consistent with with the 2015 Edition (79 FR 54443). Certification Program Proposed Rule the principles of Executive Order (E.O.) In the 2015 Edition final rule, we did (Proposed Rule) (84 FR 7424 through 13563 on Improving Regulation and not ‘‘carry forward’’ certain 2014 7610). During our review, we sought to Regulatory Review (February 2, 2011), Edition certification criteria into the identify ways to further reduce which instructs agencies to periodically 2015 Edition, such as the ‘‘image administrative burden, to implement review its existing significant results,’’ ‘‘patient list creation,’’ and deregulatory actions through guidance, regulations and ‘‘determine whether any ‘‘electronic medication administration and to put forth deregulatory actions in such regulations should be modified, record’’ criteria. We determined that this final rule that will reduce burden streamlined, expanded, or repealed so these criteria did not advance for health IT developer, providers, and as to make the agency’s regulatory functionality or support interoperability other stakeholders. program more effective or less (80 FR 62682 through 62684). We also Prior to publishing the Proposed Rule, burdensome in achieving the regulatory did not require all health IT to be on August 21, 2017, ONC issued Relied objectives.’’ To that end, we have certified to the ‘‘meaningful use Upon Software Program Guidance.10 historically taken measures where measurement’’ certification criteria for Health IT developers are permitted to feasible and appropriate to reduce ‘‘automated numerator recording’’ and use ‘‘relied upon software’’ 11 to burden within the Program and make ‘‘automated measure calculation’’ (80 demonstrate compliance with the Program more effective, flexible, and FR 62604 and 62605), which the 2014 certification criteria adopted at 45 CFR streamlined. Edition had previously required. Based part 170, subpart C. Historically, in For example, in the 2014 Edition final on stakeholder feedback and Program cases where a Health IT Module is rule (77 FR 54164, Sept. 4, 2012), we administration observations, we also paired with multiple ‘‘relied upon revised the certified electronic health permitted testing efficiencies for the software’’ products for the same record technology (CEHRT) definition to 2015 Edition ‘‘automated numerator capability, health IT developers were provide flexibility and create regulatory recording’’ and ‘‘automated measure required to demonstrate compliance for efficiencies by narrowing required calculation’’ criteria by removing the the same certification criterion with functionality to a core set of capabilities live demonstration requirement of each of those ‘‘relied upon software’’ (i.e., the Base EHR definition) plus the recording data and generating reports products in order for the products to be additional capabilities each eligible (80 FR 62703). Health IT developers listed on the Certified Health IT Product clinician, eligible hospital, and critical may now self-test their Health IT List (CHPL). With the guidance issued access hospital needed to successfully Modules’ capabilities and submit the on August 21, 2017, health IT achieve the applicable objective and resulting reports to the ONC-Authorized developers could demonstrate measures under the EHR Incentive Testing Laboratory (ONC–ATL) to verify compliance with only one ‘‘relied upon Programs (now referred to as the compliance with the ‘‘meaningful use software’’ product for a criterion/ Promoting Interoperability (PI) measurement’’ criterion.9 In order to capability. Once the health IT developer Programs). ONC has also supported further reduce burden for health IT demonstrates compliance with a more efficient testing and certification developers, in our 2015 Edition final minimum of one ‘‘relied upon software’’ methods and reduced regulatory burden rule, we adopted a more straightforward product, the developer can have through the adoption of a gap approach to privacy and security multiple, additional ‘‘relied upon certification policy. As explained in the certification requirements and clarified software’’ products for the same 2014 Edition final rule (77 FR 54254) which requirements apply to each criterion/capability listed on the CHPL and the 2015 Edition final rule (80 FR criterion within the regulatory (https://chpl.healthit.gov/). This 62681), as modified by the 2015 final functional areas (80 FR 62605). approach reduces burden for health IT developers, ONC–ATLs, and ONC- rule with corrections and clarifications 2. Executive Orders 13771 and 13777 at 80 FR 76868, where applicable, gap Authorized Certification Bodies (ONC– certification allows for the use of a On January 30, 2017, the President ACBs). previously certified health IT product’s issued E.O. 13771 on Reducing On September 21, 2017, ONC test results for certification criteria Regulation and Controlling Regulatory announced a deregulatory action to identified as unchanged. Developers Costs, which requires agencies to reduce the overall burden for testing have been able to use gap certification identify deregulatory actions. This order for more efficient certification of their 10 https://www.healthit.gov/sites/default/files/ 9 https://www.healthit.gov/test-method/ relieduponsoftwareguidance.pdf. health IT when updating from the 2011 automated-numerator-recording and https:// 11 ‘‘Relied upon’’ software is defined in the 2011 Edition to the 2014 Edition and from the www.healthit.gov/test-method/automated-measure- final rule establishing the permanent certification 2014 Edition to the 2015 Edition. calculation. program (76 FR 1276).

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00013 Fmt 4701 Sfmt 4700 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 reactive surveillance (for example, supported the proposal to revise certification criteria.12 ONC reviewed complaint-based surveillance) or § 170.556(c) by changing the the 2015 Edition test procedures and randomized surveillance. Previously requirement that ONC–ACBs must changed 30 of the 2015 Edition test finalized regulations in § 170.556(c)(2) conduct in-the-field, randomized procedures from requiring ONC–ATL required ONC–ACBs to proactively surveillance to specify that ONC–ACBs evaluation to requiring only attestation surveil two percent of the certificates may conduct in-the-field, randomized by health IT developers that their they issue annually. As discussed in the surveillance, including the removal of product has capabilities conformant Proposed Rule, in the time since the two § 170.556(c)(2). Commenters noted that with those specified in the associated percent randomized surveillance since ONC–ACBs would still be certification criterion/criteria.13 This requirement was finalized, stakeholders required to perform reactive deregulatory action reduced burden and had expressed concern that the benefits surveillance, and would be permitted to costs program-wide, while still of in-the-field, randomized surveillance conduct randomized surveillance of maintaining the Program’s high level of may not outweigh the time commitment their own accord, the regulatory integrity and assurances. The total required by providers, particularly if no requirement to conduct randomized testing cost savings for health IT non-conformities are found (84 FR surveillance on a specified portion of developers have been estimated 7434). We noted in the Proposed Rule certified health IT would be between $8.34 and $9.26 million. ONC– that, in general, health care providers unnecessary. Commenters supporting ATLs also benefitted by having more had expressed that reactive surveillance this proposal praised the deregulatory time and resources to focus on tool- (e.g., surveillance based on user action as allowing more flexibility for based testing (for interoperability- complaints) is a more logical and ONC–ACBs. A number of commenters oriented criteria) and being responsive economical approach to surveillance. were generally supportive of the to any retesting requirements that may Consistent with our September 21, 2017, proposal and applied the caveat that if arise from ONC–ACB surveillance exercise of enforcement discretion on an ONC–ACB did voluntarily conduct activities. Health care providers and implementation of randomized randomized surveillance, they should 14 other users of certified health IT did not surveillance by ONC–ACBs, we not do so repeatedly on the same Health lose confidence in the Program because proposed in the Proposed Rule to IT Module. These commenters indicated health IT developers were still required eliminate certain regulatory randomized a preference that the requirements in to meet certification criteria surveillance requirements (84 FR 7434). § 170.556(c)(6) regarding the requirements and maintain their In the Proposed Rule, we specifically consecutive selection of certified health products’ conformance to the full scope proposed to revise § 170.556(c) by IT for randomized surveillance remain. of the associated criteria, including changing the requirement that ONC– Several commenters were supportive of when implemented in the field and in ACBs must conduct in-the-field, removing randomized surveillance production use. ONC and ONC–ACBs randomized surveillance to specify that requirements and indicated they found continue to conduct surveillance ONC–ACBs may conduct in-the-field, this appropriate in view of the activities and respond to end-user randomized surveillance (84 FR 7434). Conditions and Maintenance of complaints. We further proposed to remove Certification enhancements to the § 170.556(c)(2), which specified that B. Deregulatory Actions Program as directed by the Cures Act, ONC–ACBs must conduct randomized while others noted that reactive In the Proposed Rule, we proposed surveillance for a minimum of two surveillance may be more effective in (84 FR 7434 through 7439) and sought percent of certified health IT products surfacing and correcting non- comment on six specific deregulatory per year. We also proposed to remove conformities. A number of commenters actions. Having considered the the requirements in § 170.556(c)(5) did not support the proposal, with many comments received on the proposals, regarding the exclusion and exhaustion expressing concerns that this could be which are summarized below, we have of selected locations for randomized or be perceived to be a reduction in decided to finalize five of the six surveillance. Additionally, we proposed oversight of developers or could reduce proposed deregulatory actions and not to remove the requirements in providers’ confidence that certified to finalize the proposal to recognize the § 170.556(c)(6) regarding the Health IT Modules would meet their FDA Software Precertification Pilot consecutive selection of certified health needs. While a majority of commenters Program. We refer readers to section XIII IT for randomized surveillance. As speaking to surveillance burdens on (Regulatory Impact Analysis) of this noted in the Proposed Rule, without health care providers indicated the final rule for a discussion of the these regulatory requirements, ONC– removal of mandatory randomized estimated cost savings from these ACBs would still be required to perform surveillance would, on the whole, finalized deregulatory actions. reactive surveillance, and would be reduce burden on health care providers, permitted to conduct randomized 1. Removal of Randomized Surveillance several expressed concerns about surveillance of their own accord, using Requirements whether providers can discern when a the methodology identified by ONC ONC–ACBs are required under product does not meet certification with respect to scope (§ 170.556(c)(1)), § 170.556 to conduct surveillance of requirements or know where and how to selection method (§ 170.556(c)(3)), and certified health IT to ensure that health report their concerns about their the number and types of locations for IT continues to conform with and certified health IT’s conformance to in-the-field surveillance function as required by the full scope of Program requirements. A few (§ 170.556(c)(4)). the certification requirements. commenters suggested that the Comments. A substantial number of Surveillance is categorized as either increased emphasis on reactive commenters supported removing the surveillance (particularly in some requirements for randomized 12 https://www.healthit.gov/buzz-blog/healthit- commenters’ view because ONC is surveillance. Many commenters certification/certification-program-updates-support- removing randomized surveillance efficiency-reduce-burden/. requirements in advance of the full 13 https://www.healthit.gov/sites/default/files/ 14 https://www.healthit.gov/sites/default/files/ policy/selfdeclarationapproachprogramguidance17- ONC_Enforcement_Discretion_Randomized_ implementation of the EHR Reporting 04.pdf. Surveillance_8-30-17.pdf. Program called for by section 4002 of

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00014 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25655

the Cures Act) indicates a need for when the certified health IT they rely on include sufficient detail on which to act. additional guidance to help providers is not performing its certified functions In general, submitters should provide as and particularly clinicians understand as they expect and their health IT much detail as possible about the how to recognize and report potential developer is unresponsive or fails to developer, product name, and version of non-conformities in the certified health resolve non-conformities with Program the certified health IT as well as their IT they use. requirements. Reactive surveillance by specific concerns about the certified Response. We thank commenters for ONC–ACBs, informed and focused by health IT’s performance. their input and reiterate our continued end-user complaints, has always been 2. Removal of the 2014 Edition From the commitment to sustaining the integrity an essential component of the Program’s Code of Federal Regulations of our Program, including ensuring oversight and assurance of continued robust oversight of certified health IT conformity of certified Health IT In the March 4, 2019 Proposed Rule, products while avoiding unnecessary Modules when deployed in the field. we also proposed to remove the 2014 burdens on all program stakeholders. While we encourage users to begin Edition from the Code of Federal Having considered all comments seeking troubleshooting and issue Regulations (CFR), which includes received, in context of the totality of resolution support from the developer of standards and functionality now updates we proposed to the Program, we their health IT—because the developer significantly outmoded (84 FR 7434). have concluded that the removal of the is often in the best position to act most We noted that removal of the 2014 regulatory requirements for ONC–ACBs promptly to resolve problems with their Edition would make the 2015 Edition to conduct randomized surveillance is products’ performance—we also the new baseline for health IT consistent with enhancing Program encourage the user to share their certification. The 2015 Edition, efficiency while maintaining its concerns with the ONC–ACB that including the additional certification efficacy. We leave ONC–ACBs the certified the health IT in question when criteria, standards, and requirements option to conduct randomized the developer has not addressed users’ adopted in this final rule, will better surveillance as they determine concerns that their certified health IT is enable interoperability and the access, necessary or appropriate to support not performing as it is certified to exchange, and use of electronic health continued conformance to Program perform. As we recognize that users may information, as discussed in the requirements by Health IT Modules they in some circumstances need, or for Proposed Rule (84 FR 7434), and its have certified. We also note that ONC– purposes potentially including but not adoption and implementation by ACBs that choose to conduct limited to their own preferences may providers is expected to yield the randomized surveillance will still be wish, to share their concerns about their estimated costs savings described (84 FR required to use the methodology certified health IT’s performance or 7563 and 7564) within the Regulatory identified by ONC with respect to scope other health IT matters directly with Impact Analysis (section XIV) of the (§ 170.556(c)(1)), selection method ONC, we invite health IT users and all Proposed Rule and in the Regulatory (§ 170.556(c)(3)), and the number and other interested parties to share their Impact Analysis section (section XIII) of types of locations for in-the-field health IT-related feedback or concerns this final rule. surveillance (§ 170.556(c)(4)). While we with ONC through the Health IT To implement the removal of the 2014 appreciate concerns that removal of Feedback Form on our HealthIT.gov Edition from the CFR, we proposed (84 requirements in § 170.556(c)(6) website.15 Depending on the nature of a FR 7434 and 7435) to remove the 2014 regarding the consecutive selection of specific feedback message, we may Edition certification criteria (§ 170.314) certified health IT creates a potential contact the submitter for additional and related standards, terms, and that the same Health IT Module(s) could information and, in some instances, may requirements from the CFR. In regard to be selected for randomized surveillance share the information provided with terms, we proposed to retire the 2014 in consecutive years, we are unaware of other appropriate entities—such as but Edition-related definitions found in evidence suggesting that ONC–ACBs not limited to the ONC–ACBs who § 170.102, including the ‘‘2014 Edition choosing to implement randomized certify the products about which we Base EHR,’’ ‘‘2014 Edition EHR surveillance would do so in a manner receive feedback, as they are often in the certification criteria,’’ and ‘‘Complete that would tend to erode its efficacy by best position to assess and respond to EHR, 2014 Edition.’’ As explained in the over-sampling some products at the feedback expressing concerns about 2015 Edition final rule (80 FR 62719), expense of under-sampling others. conformance of specific certified criteria the ability to maintain Complete EHR Rather than retain a regulatory provision used by Health IT Modules in certification is only permitted with intended to counterbalance a regulatory production environments. All health IT certified to the 2014 Edition requirement for randomized information submitted through the certification criteria. Because this surveillance of a required minimum Health IT Feedback Form is carefully concept was discontinued for the 2015 percent of certified products each year, reviewed and helps us to improve our Edition, we proposed (84 FR 7435) to we believe it is more appropriate at this awareness and ability to address health remove § 170.545 and any references to time to remove the restriction on IT-related issues and challenges. Also, Complete EHR from the regulation text consecutive selection of the same Health we note for clarity that persons sharing in conjunction with the removal of the IT Module(s) or location(s) for health IT-related concerns with ONC via 2014 Edition. We also proposed (84 FR randomized surveillance and monitor the Health IT Feedback Form have the 7435) to remove references to the 2014 the results of this and other Program option to remain anonymous and this Edition from the Common Clinical Data enhancements finalized in this rule for option has been chosen by some Set (CCDS) definition and effectively any indication that we may need to submitters. However, we wish to note replace it with a new government- further adjust regulatory requirements that anonymous submissions will unique standard, the United States Core in the future. prevent us from acquiring additional Data for Interoperability (USCDI). We We thank commenters for bringing to information to fully follow up on a proposed (84 FR 7435) to remove the our attention that health care providers matter if the submission does not standards and implementation may be uncertain about how or where specifications found in §§ 170.200, they can engage the ONC Health IT 15 https://www.healthit.gov/form/healthit- 170.202, 170.204, 170.205, 170.207, Certification Program for assistance feedback-form. 170.210, and 170.299 that are only

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00015 Fmt 4701 Sfmt 4700 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 Base EHR,’’ ‘‘2014 Edition EHR inspection, and quality management certification criteria. Adopted standards certification criteria,’’ and ‘‘Complete systems) from specific assessment of a that are also referenced in the 2015 EHR, 2014 Edition’’ definitions. As certification body’s ability to apply their Edition would remain. Finally, we explained in the 2015 Edition final rule accredited ISO/IEC 17065 capabilities to proposed (84 FR 7435) to remove (80 FR 62719), the ‘‘Complete EHR’’ the Program’s certification scheme requirements in § 170.550(f) and any concept was discontinued for the 2015 requirements. The commenter noted other requirements in subpart E, Edition. Therefore, in conjunction with that this might place a greater burden on §§ 170.500 through 170.599, which are the removal of the 2014 Edition, we also ONC staff than did the Program specific to the 2014 Edition and do not remove in this final rule § 170.545 and structure that included an ONC–AA. apply to the 2015 Edition. all other references to ‘‘Complete EHR’’ Finally, one of the commenters in As discussed in the Proposed Rule (84 from the regulation text. Moreover, in support of removing the ONC–AA from FR 7435), in order to avoid regulatory finalizing the removal of the 2014 the Program requested additional conflicts, we took into consideration the Edition from the CFR, we also finalize clarification about criteria and processes final rule released by CMS on November removal of the standards and that will be used for accreditation of 16, 2017, titled ‘‘Medicare Program; CY implementation specifications found in certification bodies following removal of 2018 Updates to the Quality Payment §§ 170.200, 170.202, 170.204, 170.205, the ONC–AA from the Program. Program; and Quality Payment Program: 170.207, 170.210, and 170.299 that are Response. We thank all commenters Extreme and Uncontrollable referenced only in the 2014 Edition for their thoughtful feedback. Upon Circumstance Policy for the Transition certification criteria. Adopted standards consideration of all comments received Year’’ (82 FR 53568). This Quality that are also referenced in the 2015 on this proposal, we have finalized it as Payment Program (QPP) final rule Edition, as modified by this final rule, proposed. As noted in the preamble to permits eligible clinicians to use EHR remain in the CFR. We also retained the the Proposed Rule (84 FR 7435), ONC’s technology certified to either the 2014 CCDS definition in § 170.102 but experience with administering the PoPC or 2015 Edition certification criteria, or removed the standards and for ONC–ACBs as well as issuing a combination of the two for the CY implementation specifications that necessary regulatory changes (e.g., 2018 performance period. This QPP reference the 2014 Edition. ONC–ACB surveillance and reporting final rule also states that the 2015 Additionally, we finalized the removal requirements in the 2015 Edition final Edition certified EHR technology of requirements in § 170.550(f) and any rule) has demonstrated that ONC on its (CEHRT) will be required starting with other requirements in subpart E, own has the capacity to provide the the CY 2019 QPP program year (82 FR §§ 170.500 through 170.599, that are appropriate oversight of ONC–ACBs. 53671). Therefore, we proposed (84 FR specific to the 2014 Edition and do not Therefore, we believe removal of the 7435) the effective date of removal of apply to the 2015 Edition. ONC–AA will reduce the Program’s the 2014 Edition certification criteria administrative complexity and burden and related standards, terms, and 3. Removal of the ONC-Approved while maintaining its effectiveness. We requirements from the CFR would be Accreditor From the Program anticipate providing updated the effective date of this final rule. We proposed to remove the ONC–AA information about ONC’s updated Comments. The majority of the from the Program (84 FR 7435). The processes for approval and oversight of comments received supported removing ONC–AA’s role is to accredit certification bodies through familiar the 2014 Edition certification criteria certification bodies for the Program and mechanisms including but not from the Code of Federal Regulations. to oversee the ONC–ACBs. However, necessarily limited to the HealthIT.gov Commenters supporting the removal years of experience and changes with website prior to the effective date of this noted that it will reduce confusion and the Program have led ONC to conclude final rule, and on an ongoing basis as acknowledges that standards and that, in many respects, the role of the needed or otherwise appropriate to functionality in the 2014 Edition are ONC–AA to oversee ONC–ACBs is now ensure effective transparency about this now significantly outmoded. Some duplicative of ONC’s oversight. More aspect of the Program. commenters requested the removal be specifically, ONC’s experience with To finalize this deregulatory action, delayed until the end of CY 2019. administering the Principles of Proper we have removed the definition for Response. We thank commenters for Conduct (PoPC) for ONC–ACBs as well ‘‘ONC-Approved Accreditor or ONC– their support. We have finalized the as issuing necessary regulatory changes AA’’ from § 170.502. We also removed removal of the 2014 Edition from the (e.g., ONC–ACB surveillance and §§ 170.501(c), 170.503, and 170.504 CFR as proposed, including making the reporting requirements in the 2015 regarding requests for ONC–AA status, removal effective as of the effective date Edition final rule) has demonstrated that ONC–AA ongoing responsibilities, and of this final rule (60 days after the rule ONC on its own has the capacity to reconsideration for requests for ONC– is published in the Federal Register). provide the appropriate oversight of AA status. Regarding correspondence The 2015 Edition was the sole edition ONC–ACBs. Therefore, we believe and communication with ONC, we have permitted to meet the CEHRT definition removal of the ONC–AA will reduce the revised § 170.505 to remove specific beginning in the CY 2019 program year. Program’s administrative complexity references to the ‘‘ONC–AA’’ and This final rule is published in CY 2020. and burden. ‘‘accreditation organizations requesting Therefore, the removal is not in conflict Comments. All but one commenter ONC–AA status.’’ We also have with CMS’ regulatory requirements for specifically addressing this proposal finalized our proposal to sunset the QPP. were in support of removing the ONC– policies reflected in the final rule titled To finalize removal of the 2014 AA. The one commenter opposed to the ‘‘Permanent Certification Program for Edition from the CFR, we have removed, proposal stated concerns related to de- Health Information Technology; effective as of the effective date of this coupling accreditation to ISO/IEC 17065 Revisions to ONC-Approved Accreditor final rule, the 2014 Edition certification standards (an internationally recognized Processes’’ (76 FR 72636), and to criteria in § 170.314. We also finalized standard for bodies certifying products, remove § 170.575, which established a removal of terms and definitions processes, and services to provide process for addressing instances where specific to the 2014 Edition from assurance of compliance with specified the ONC–AA engages in improper § 170.102, including the ‘‘2014 Edition requirements such as initial testing, conduct or does not perform its

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00016 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25657

responsibilities under the Program. discussed in the preamble to the these data. However, a few commenters Because the regulations promulgated in Proposed Rule (84 FR 7435), the expressed concern that removing this this prior final rule relate solely to the removal of these criteria supports and other requirements would be a role of the ONC–AA, we have finalized burden and cost reductions for health IT disincentive to maintain the the removal of those requirements. developers and health care providers by functionality in the future, and some Accordingly, we also revised the eliminating the need to: Design and commenters expressed concern about application process for ONC–ACB status meet these specific certification ONC’s ability to continue to provide in § 170.520(a)(3) to require functionalities; prepare, test, and certify effective oversight and require documentation, with an appropriate health IT in certain instances; adhere to correction if developers do not ensure scope, that confirms that the applicant associated reporting and disclosure the functionalities perform safely and has been accredited to ISO/IEC 17065 by requirements; maintain and update effectively. Commenters stated that any accreditation body that is a certifications for these specific certified while many developers will still signatory to the Multilateral Recognition functionalities; and participate in continue to support the functionalities Arrangement (MLA) with the surveillance of health IT certified to proposed for removal, eliminating the International Accreditation Forum these criteria and standards. certification requirement may allow for (IAF), in place of the ONC–AA i. Problem List developers to provide a ‘‘stripped- accreditation documentation down’’ product at a lower price point requirements. Similarly, instead of We proposed to remove the 2015 and, in absence of CEHRT definition to requiring the ONC–AA to evaluate the Edition ‘‘problem list’’ certification guide the providers, mislead conformance of ONC–ACBs to ISO/IEC criterion (§ 170.315(a)(6)) from the 2015 independent and small providers into 17065, we revise § 170.523(a) to simply Edition (84 FR 7436). As we noted in unwittingly acquiring certified health IT require ONC–ACBs to maintain the Proposed Rule, the functionality in that does not fully meet their needs. this criterion was first adopted as a 2011 accreditation in good standing to ISO/ Response. As discussed in the Edition certification criterion to support IEC 17065. This means that ONC–ACBs preamble to the Proposed Rule, a the associated meaningful use Stage 1 would need to continue to comply with criterion specific to the ‘‘problem list’’ objective and measure for recording ISO/IEC 17065 and requirements functionality was first adopted in the specific to the ONC Health IT problem list information. This 2015 2011 Edition, specifically to ensure Certification Program scheme. Edition ‘‘problem list’’ criterion support for the associated meaningful functionally remains relatively the same 4. Removal of Certain 2015 Edition use Stage 1 objective and the measure as the 2011 Edition and has exactly the Certification Criteria and Standards for recording problem list information same functionality as the 2014 Edition under the CMS PI Programs. The Having reviewed and analyzed the ‘‘problem list’’ criterion. We proposed to ‘‘recording’’ objective and measure is no 2015 Edition, we proposed to remove remove this criterion because the longer a part of the CMS PI Programs. certain certification criteria and criterion no longer supports the However, the functionality remains standards as discussed in the Proposed ‘‘recording’’ objective and measure of widespread among EHR systems used Rule (84 FR 7435 through 7437) and the CMS PI Programs as such objective by health care providers. While this below. We stated (84 FR 7435) that we and measure no longer exist.16 prevalence may be due in part to its believe the removal of these criteria and Additionally, we stated the inclusion in the Certified EHR standards will reduce burden and costs functionality is sufficiently widespread Technology definition, without for health IT developers and health care among health care providers since it has substantive changes, since the 2011 providers by eliminating the need to: been part of certification and the Edition, we believe the more significant Design and meet specific certification Certified EHR Technology definition reason that this functionality is widely functionalities; prepare, test, and certify since the 2011 Edition and has not available is because it is essential to health IT in certain instances; adhere to substantively changed with the 2015 clinical care, and therefore, that the associated reporting and disclosure Edition. Furthermore, we stated in the market will and should drive its requirements; maintain and update Proposed Rule that the functionality is continued presence in EHR systems certifications for certified essential to clinical care and would be regardless of certification requirements. functionalities, and participate in in EHR systems absent certification, While we also appreciate the concerns routine surveillance (84 FR 7435). particularly considering the limited of commenters about the need for health Although we did not expressly state it certification requirements. IT to support the accurate recording of in the Proposed Rule preamble, the Comments. A number of commenters patients’ problems and the standards- burdens and costs reduced by removal expressed support for removing the based exchange of that information, we of certain criteria from the 2015 Edition ‘‘problem list’’ certification criterion reiterate that the interoperability- would be those associated with the from the 2015 Edition and ‘‘Base EHR’’ focused criteria that will remain in the needs we discussed in the preamble (84 definition. Several of those expressing Base EHR definition and reference the FR 7435) specifically in connection to support for the removal of this criterion USCDI will ensure that any system of the criteria we proposed to remove, specifically noted that the inclusion of certified health IT meeting the Base EHR which are those that had been set forth the same data elements in the USCDI definition is capable of using and in § 170.315(a)(6), (7) and (8), (10) and should suffice to ensure continued exchanging data on a patient’s problems (11), and (13), (b)(4) and (5), and (e)(2) ability of certified health IT to record using content, format, and other (as the text of 45 CFR part 170 stood and facilitate access and exchange of prior to this final rule). standards applicable to each mode of exchange (e.g., standardized API and C– a. 2015 Edition Base EHR Definition 16 By stating in the NPRM that the objective and measure no longer exist, we meant in the CMS PI CDA). Moreover, these interoperability- Certification Criteria (formerly EHR Incentive) Programs. The authority focused criteria will be subject not only We proposed to remove certain citation for this statement is the December 15, 2015 to the Program’s familiar initial CMS Final Rule ‘‘Medicare and Medicaid Programs; certification criteria from the 2015 Electronic Health Record Incentive Program-Stage 3 certification testing and in-the-field Edition that had been included in the and Modifications to Meaningful Use in 2015 reactive surveillance requirements but 2015 Edition Base EHR definition. As Through 2017’’ (80 FR 62761 and 62785). also to the new Condition and

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00017 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25658 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

Maintenance of Certification set of required certification (§ 170.315(a)(7)). The ‘‘recording’’ requirements for developers to test functionalities that the health IT used objective and measure of the CMS PI annually their certified Health IT by eligible clinicians must have in order Programs that the ‘‘medication list’’ Modules’ interoperability performance to qualify for the CMS incentive criterion was originally adopted to in the types of real world settings for programs as CEHRT. support has since been retired from the which they are sold. Using certified health IT improves CMS Programs. However, the After consideration of all comments care coordination through the electronic functionality remains widespread received, and for the reasons noted in exchange of clinical-care documents. It among EHR systems used by health care the preamble to the Proposed Rule and provides a baseline assurance that the providers. While this prevalence may be above, we have finalized the removal of technology will perform clinical-care due in part to its inclusion in the the ‘‘problem list’’ certification criterion and data-exchange functions in Certified EHR Technology definition (§ 170.315(a)(6)). We further note that accordance with interoperability since the 2011 Edition, we believe this upon the effective date of this final rule, standards and user-centered design. functionality is widely available and the ‘‘problem list’’ certification criterion ii. Medication List used in more significant part because it is removed from the 2015 Edition and is essential to clinical care and, We proposed to remove the 2015 the criterion will no longer be included therefore, the market will and should in the 2015 Edition ‘‘safety-enhanced Edition ‘‘medication list’’ certification criterion (§ 170.315(a)(7)) (84 FR 7436). drive its continued presence in EHR design’’ criterion. This criterion, in systems regardless of certification § 170.315(g)(3), specifies the user- As we noted in the Proposed Rule, the 2015 Edition ‘‘medication list’’ criterion requirements. While we also appreciate centered design testing that must be the concerns of commenters about the applied to particular EHR functionality remains functionally the same as the need for health IT to support clinicians’ submitted for certification. However, in 2011 Edition and 2014 Edition ability to access, maintain, use, and response to specific commenters’ ‘‘medication list’’ criteria. As also exchange accurate and up-to-date concerns about the impact of removing discussed in the Proposed Rule, a information on their patients’ current the functionally-based problem list functionally-based ‘‘medication list’’ medication lists and medication history, criterion on our ability to take action criterion was first adopted as a 2011 we repeat for clarity and emphasis that where developers may retain the Edition certification criterion to support the interoperability-focused criteria that functionality, but fail to ensure it does the associated meaningful use Stage 1 will remain in the Base EHR definition, not pose a danger to patient safety or objective and measure for recording public health, we note that our medication list information. The and their inclusion of the USCDI, will responsibility, pursuant to section ‘‘medication list’’ criterion that we ensure that any system of certified 3001(b) of the PHSA, includes ensuring proposed to remove does not require use health IT meeting the Base EHR certified health IT does not pose a risk of a specific vocabulary standard to definition is capable of using and to patient safety or public health, and is record medications. exchanging data on a patient’s not limited to measuring the conformity Comments. Comments on the medications using content, format, and of the health IT to specific certification proposal to remove the ‘‘medication other standards applicable to each mode criteria. As discussed in the ‘‘ONC list’’ criterion were somewhat mixed. of exchange (e.g., standardized API Health IT Certification Program: While a number of comments expressed consistent with § 171.315(g)(10), or Enhanced Oversight and support for the removal of the exchange of C–CDA documents using Accountability’’ (EOA) rule which was ‘‘medication list’’ criterion from the the transport standards and other proposed in 81 FR 11056, and finalized 2015 Edition as duplicative of protocols in § 171.202). We recognize in 81 FR 72404 in 2016, ONC has the medication data included in the USCDI the critical importance of providers’ and authority to address suspected or a number of commenters expressed patients’ ability to have, use, and confirmed non-conformities to the concerns with, and a few commenters exchange medications information to requirements under the ONC Health IT indicated opposition to, the removal of avoid harms that can arise from Certification Program if the certified the ‘‘medication list’’ criterion. A few interactions and duplications of health IT is causing or contributing to commenters raised concerns specific to therapeutic effects amongst newly serious risks to public health or safety elimination of the ‘‘medication list’’ prescribed drugs and those the patient (81 FR 72406). The EOA final rule criterion in view of the need to respond may already be taking. While the established in § 170.580 a regulatory to the opioids crisis. One commenter clinical importance of maintaining and framework for ONC’s direct review of expressed concern in the context of both referencing current, reconciled health IT certified under the Program, the medication list and the drug- medication lists is not limited to those which expressly addresses the potential formulary and preferred drug lists medications with significant risks of for ONC to initiate direct review if we criteria as to whether the removal of misuse or dependency, we agree that it have a reasonable belief that certified these criteria could potentially impact is highlighted by the urgent need to health IT may not conform to the patients’ drug costs. Several comments ensure opioids are prescribed and used requirements of the Program because the also expressed the same concerns for only with due care when clinically certified health IT may be causing or eliminating the ‘‘medication list’’ that necessary. We believe this clinical contributing to conditions that present a were expressed in regard to removal of importance supports the expectation serious risk to public health or safety. the ‘‘problem list’’ criterion, which are that the market will ensure this With respect to health care providers’ summarized above, regarding whether functionality is maintained and will selection of certified health IT products, developers will continue to include the drive innovations that improve its we would encourage all providers to functionality and maintain its safe usability for the clinicians who use it in consider the Base EHR or Certified EHR performance. the course of caring for their patients. Technology (CEHRT) definition as a Response. We thank commenters for Moreover, the inclusion of medication useful starting point. Certain health care their input. Upon consideration of all information in interoperability-focused payment programs, including the CMS comments received on this proposal, we criteria in § 170.405(a) will ensure PI Programs, require the use of certified have finalized the removal of the certified health IT can access, use, and health IT. CMS refers to the minimum ‘‘medication list’’ criterion exchange medications data according to

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00018 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25659

applicable content and formatting medication allergies, and does not ‘‘medication allergies’’ functionally- standards, which the ‘‘medication list’’ directly support interoperability as the based criterion. functionality did not ensure. This criterion does not require representation We note that once removed from the interoperability of the data is critical to of medication allergies in standardized 2015 Edition, the ‘‘medication allergy reducing clinician burden related to nomenclature. The criterion no longer list’’ criterion will also no longer be manually entering updated drug lists supports a ‘‘recording’’ objective and included in the 2015 Edition ‘‘safety- and necessary to enable use of measure of the CMS PI Programs as such enhanced design’’ criterion. However, as medication information by clinical objective and measure no longer exist. noted in context of removed criteria decision support functionalities. The This 2015 Edition ‘‘medication allergy above, ONC’s responsibility, pursuant to interoperability-focused criteria will list’’ criterion remains functionally the section 3001(b) of the PHSA includes also be subject not only to the Program’s same as the 2011 Edition and 2014 ensuring certified health IT does not familiar initial certification testing and Edition ‘‘medication allergy list’’ pose a risk to patient safety or public in-the-field reactive surveillance criteria. The functionality is essential to health. Our responsibility for certified requirements but also to the new clinical care and would be in EHR health IT and patient safety or public Condition and Maintenance of systems absent certification. health is not limited to measuring the Certification requirements for Comments. Comments on the conformity of the health IT to specific developers to test annually their proposed removal of the ‘‘medication certification criteria. As discussed in the certified Health IT Modules’ allergy list’’ criterion were mixed, with EOA rule, ONC has the authority to interoperability performance in the several commenters supportive of the address suspected or confirmed non- types of real world settings for which removal noting that the criterion would conformities to the requirements under they are marketed. be redundant now that medication the Health IT Certification Program if We note that once removed from the allergy data will be included in the the certified health IT is causing or 2015 Edition, the criterion will no USCDI. Commenters expressed concern contributing to serious risks to public longer be included in the 2015 Edition with the removal of the criterion and health or safety (81 FR 72406). The EOA ‘‘safety-enhanced design’’ criterion in questioned the ubiquity of the final rule established in § 170.580 a § 170.315(g)(3). However, as noted medication allergy list functionality and regulatory framework for ONC’s direct above in context of the ‘‘problem list’’ whether health IT developers would review of health IT certified under the criterion, ONC’s responsibility, continue to support the functionality if Program, which expressly addresses the pursuant to section 3001(b) of the not required by ONC regulations. potential for ONC to initiate direct PHSA, includes ensuring certified Response. We thank commenters for review if we have a reasonable belief health IT does not pose a risk to patient their input. Upon consideration of all that certified health IT may not conform safety or public health. Our comments received on this proposal, we to the requirements of the Program responsibility for certified health IT and have finalized the removal of the because the certified health IT may be patient safety or public health is not ‘‘medication allergy list’’ certification causing or contributing to conditions limited to measuring the conformity of criterion (§ 170.315(a)(8)). The that present a serious risk to public the health IT to specific certification ‘‘recording’’ objective and measure of health or safety. criteria. As discussed in the EOA rule, the CMS PI Programs that this criterion iv. Smoking Status ONC has the authority to address was originally adopted to support has suspected or confirmed non- since been retired from the CMS We proposed to remove the 2015 conformities to the requirements under Programs. However, the functionality Edition ‘‘smoking status’’ criterion the Health IT Certification Program if remains widespread among EHR (§ 170.315(a)(11)), which would include the certified health IT is causing or systems. While this prevalence may be removing it from the 2015 Edition Base contributing to serious risks to public due in part to its inclusion in the EHR definition (84 FR 7436). We had health or safety (81 FR 72406). The EOA Certified EHR Technology definition previously adopted a 2015 Edition final rule established in § 170.580 a since the 2011 Edition, its importance to ‘‘smoking status’’ certification criterion regulatory framework for ONC’s direct clinical care suggests the market will that does not reference a standard. review of health IT certified under the drive ongoing availability and However, the CCDS definition, which Program, which expressly addresses the enhancement of this functionality over we proposed to remove from regulation potential for ONC to initiate direct time. Furthermore, because medication in favor of adopting the new USCDI review if we have a reasonable belief allergies are included in the USCDI, all standard, required smoking status to be that certified health IT may not conform systems of certified health IT meeting coded in accordance with a standard to the requirements of the Program the Base EHR definition will be required value set of eight SNOMED CT® codes because the certified health IT may be to be able to exchange and use defined in § 170.207(h). As with other causing or contributing to conditions medication allergy information functionality that was included in 2014 that present a serious risk to public according to applicable content and Edition, we believe this functionality is health or safety. formatting standards, which the now widespread. Further, smoking ‘‘medication allergies’’ criterion did not status data will continue to be required iii. Medication Allergy List ensure. This interoperability is critical to be available for access and exchange We proposed to remove the 2015 to reducing clinician burden related to via the USCDI. Edition ‘‘medication allergy list’’ manually entering updated drug lists Comments. Comments on this certification criterion (§ 170.315(a)(8)). and necessary to enable use of proposal were mixed, with a number of The functionality in this criterion was medication information by clinical commenters expressing support for the first adopted as a 2011 Edition decision support functionalities. We removal of ‘‘smoking status’’ criterion in certification criterion to support the believe that requiring the the Program and several noting that it is associated meaningful use Stage 1 interoperability of medication allergy not needed or duplicative in the context objective and measure for recording information will facilitate innovation of Program requirements to support the medication allergies information. The and improvement in health IT’s ability USCDI. A few commenters stated criterion does not require use of a to meet clinicians’ and patients’ needs concerns that eliminating the vocabulary standard to record more than would the continuation of the requirement would provide a

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00019 Fmt 4701 Sfmt 4700 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 SNOMED CT® codes referenced in the enhancements to smoking status data the function in the future. Several value set adopted in § 170.207(h). These standardization moving forward are commenters expressing concerns about eight codes reflected an attempt to outside the scope of this section, we removal of this criterion noted its capture smoking status in a consistent will not address them in specific detail importance to patient care and to public manner. Stakeholder feedback indicated here. However, we note that the USCDI health, raising points such as the use of that these eight codes do not v1 references as the standard for smoking status as a key determinant to appropriately and accurately capture all smoking status information SNOMED classify cases of some reportable clinically relevant patient smoking CT®, U.S. Edition.17 conditions, such as carbon monoxide statuses. Accordingly, we proposed to Having considered all comments poisoning. Concerns raised by no longer require use of only the received on this proposal, we have commenters opposed to removing specific eight SNOMED CT® codes for finalized the removal of the eight-code smoking status data from providers’ representing smoking status and remove value set standard and removed and EHR systems included potential for the value set standard by deleting and reserved § 170.207(h). additional provider burden, such as that reserving § 170.207(h). b. Drug-Formulary and Preferred Drug Comments. Comments specifically related to providing complete case List Checks reporting data and responding to public addressing this proposal were generally health requests for additional supportive of removing the specific We proposed to remove the 2015 information on patient smoking status value set of eight SNOMED CT® codes, Edition ‘‘drug-formulary and preferred during case investigation processes. though many also noted the importance drug list checks’’ criterion in Response. We thank commenters for of continuing to require health IT § 170.315(a)(10). their input. Upon consideration of the certified under the Program to retain the Comments. Some commenters comments, we have finalized the ability to include or access, exchange, expressed concern that this criterion’s removal of the ‘‘smoking status’’ and use appropriately standardized removal could negatively impact criterion (§ 170.315(a)(11)). While we smoking status information. Several prescribers’ ability to help their patients continue to believe that accurate, up-to- comments made specific suggestions manage their prescription drug date information on a patient’s smoking related to broadening or revising the expenses. Although several commenters status and history has significant vocabulary standard requirements for supported the removal of this criterion clinical value, we believe that its smoking status information going in principle, a number of comments importance to clinical care provides forward. Other commenters suggested expressed concerns about the effect of adequate motivation for the market to adding other forms of tobacco use, removal of the ‘‘drug-formulary and drive ongoing availability and including smokeless and second hand, preferred drug list checks’’ and other enhancement of this functionality over as well as e-cigarette (vaping) use. criteria from the Program on health care time. Because smoking status Response. We appreciate all providers’ ability to comply with CMS information is included in the USCDI, commenters’ input and note that no and State-specific regulatory all systems of certified health IT comments received raised concerns that requirements for successful meeting the Base EHR definition will are not addressed by inclusion of participation in the Medicare Quality now be required to be able to exchange smoking status information in the Payment Program (QPP), or the and use smoking status information USCDI, which all interoperability- Medicare or Medicaid PI Programs. One according to applicable content and focused criteria within the 2015 Edition commenter, noting that the Drug- formatting standards. The ‘‘smoking Base EHR definition, as revised through Formulary and Preferred Drug List status’’ recording functionality criterion this final rule, reference. As is the case Checks criterion is associated with the we have removed did not ensure with patient problems, medications, and CMS e-prescribing objective measures smoking status information was medication allergies, we believe having that CMS has finalized for 2019 and captured in a structured, interoperable smoking status information available for subsequent performance years manner and interoperability of this data standards-based exchange is an specifically, recommended coordination is critical to reducing clinician burden important facilitator of better care and with CMS to ensure alignment across related to maintaining complete, current more effective public health reporting the policies maintained by these two smoking status information. It is also with less data-related burden on components of HHS. necessary to enable use of smoking clinicians and less need for follow-up Response. We thank commenters for status information by clinical decision by public health professionals to their input. As discussed in the support and public health reporting compensate for case reporting data that Proposed Rule (84 FR 7437), the 2015 functionalities. We believe that is incomplete or is not fully Edition ‘‘drug-formulary and preferred interoperability and exchange of interoperable. As is the case with the drug list checks’’ criterion does call for smoking status information through the other removed criteria that were focused functionality to check drug formulary interoperability-focused certification on internal recording capabilities, we and preferred drug lists, but does not criteria that reference the USCDI believe the market can, will, and should require use of any specific standard will better facilitate innovation be the primary driver for the ongoing interoperability standards. The 2015 and improvement in health IT’s ability maintenance and enhancement of Edition ‘‘drug-formulary and preferred to meet clinicians’ and patients’ needs functionalities for end users to record or drug list checks’’ criterion does not than would continuation of the modify these data. Furthermore, the include functionality or advance ‘‘smoking status’’ functionally-based Program’s focus is more appropriately interoperability beyond what was recording criterion. spent on ensuring that certified health required by the 2014 Edition ‘‘drug- IT supports interoperable access, use, formulary checks’’ criterion. While we Removal of Specific USCDI Smoking and exchange of these data as the key Status Code Set facilitator for more coordinated patient 17 For more information on finalized policy Along with the ‘‘smoking status’’ care and for ongoing innovation and regarding adoption of the USCDI standard, see section IV.B.1 of this final rule. USCDI v1 can be criterion, we proposed to remove the improvement in both provider- and accessed freely and directly in its entirety at https:// requirement to code smoking status patient-facing functionalities. Because www.healthit.gov/isa/sites/isa/files/inline-files/ according to the eight smoking status comments on revisions or USCDIv12019revised2.pdf.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00020 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25661

believe this functionality is fairly that, based on the number of health IT supporting the patient electronic access ubiquitous now due in part to the products that have been certified for this to health information objective and widespread adoption of health IT functionality as part of 2014 Edition measure, which is expected to remain certified to the 2014 Edition, we do not certification and already for 2015 operational for Medicaid until January believe it is necessary to continue to Edition, we believe that health IT’s 1, 2022; after 2021, there will be no require certification to it under the ability to identify appropriate patient further incentives under the Medicaid Program in order to ensure it remains education materials is widespread now Promoting Interoperability Program (84 widely available. Instead, we believe, among health IT developers and their FR 42592). We, therefore, will permit prescribers’ and patients’ interest in customers (e.g., health care providers). ONC–ACBs to issue certificates for this assuring patients can get the We also noted that we have recently criterion up until January 1, 2022, to medications they need at the best seen innovative advancements in this align with the requirements of the CMS available value will provide adequate field, including the use of automation Medicaid PI Program (84 FR 42592). We motivation for the market to drive and algorithms to provide appropriate have included a provision in ongoing availability and enhancement education materials to patients in a § 170.550(m)(1) to only allow ONC– of this functionality over time, timely manner. These advancements ACBs to issue certificates for this including through increasing use of help limit clinical workflow criterion until January 1, 2022. relevant interoperability standards interruptions and demonstrate the use d. Common Clinical Data Set Summary essential to making this functionality and promise of health IT to create Record—Create; and Common Clinical more affordable and seamlessly reliable efficiencies and improve patient care. Data Set Summary Record—Receive at scale than is feasible in the absence As such, we stated that removal of this of interoperability driven by ubiquitous criterion would prevent certification As stated in the proposed rule (84 FR use of open standards. Because the from creating an unnecessary burden for 7437), we assessed the number of ‘‘drug-formulary and preferred drug list developers and providers and an products certified to the 2015 Edition checks’’ criterion we proposed to impediment to innovation. ‘‘Common Clinical Data Set summary remove does not require use of Comments. Some commenters record—create’’ (§ 170.315(b)(4)) and standards or directly drive expressed concern related to this ‘‘Common Clinical Data Set summary interoperability, we do not believe its functionality not yet being consistently record—receive’’ (§ 170.315(b)(5)) continued inclusion in the Program used by all providers and to whether criteria that have not also been certified would provide sufficient value to removal of this criterion may create a to the 2015 Edition ‘‘transitions of care’’ providers or patients to justify the barrier to successful participation for criterion (§ 170.315(b)(1)) that also burden on developers and providers of providers in the Medicaid PI Program. requires health IT be capable of creating meeting Program compliance One commenter noted that providers’ and receiving Common Clinical Data Set requirements specific to this criterion. workflow changes to use this (CCDS) Summary Records using the We also recognize the importance of functionality are substantial and same interoperability standards. We ensuring alignment between ONC expressed concern related to providers explained that, based on our findings of Health IT Certification Program potentially not undertaking such only two unique products certified only regulations and the CMS regulations changes if the criteria were not required to these criteria and not to the that reference them. We have been and to be included in health IT and used by ‘‘transitions of care’’ criterion at the will continue to work in close providers. time of the drafting of the Proposed partnership with our CMS colleagues to Response. While we continue to Rule, there appears to be little market ensure that our regulations remain recognize the importance of patient and demand for certification to 2015 Edition aligned, and that we provide affected provider interaction to promote positive ‘‘Common Clinical Data Set summary stakeholders with the information they health outcomes, we also believe that record—create’’ (§ 170.315(b)(4)) and need to understand how the rules work this criterion, narrowly focused on a ‘‘Common Clinical Data Set summary together and how to succeed under specific functionality not connected to record—receive’’ (§ 170.315(b)(5)) CMS’ PI Programs using health IT interoperability, is no longer the best criteria alone. Therefore, we proposed to certified under ONC’s Program. We, way to encourage innovation and remove these certification criteria from therefore, permit ONC–ACBs to issue advancement in health IT’s ability to the 2015 Edition. certificates for this criterion up until support clinician-patient interactions Comments. The comments we January 1, 2022 to align with the and relationships. received on this proposal supported this requirements of the CMS Medicaid PI Having reviewed all comments removal. Program, as this criterion is associated received on this proposal, we have Response. We thank commenters for with measures under the Medicaid decided not to remove the ‘‘patient- their support and have finalized program that will continue through specific education resources’’ criterion removal of the 2015 Edition ‘‘Common 2021; after 2021 there will be no further from the Program at this time. We Clinical Data Set summary record— incentives under the Medicaid recognize the importance of ensuring create’’ (§ 170.315(b)(4)) and ‘‘Common Promoting Interoperability Program (84 alignment between ONC Health IT Clinical Data Set summary record— FR 42592). We have not finalized our Certification Program regulations and receive’’ (§ 170.315(b)(5)) criteria. proposal to remove the criterion from the CMS regulations that reference e. Secure Messaging the CFR but included a provision in them. We will continue to work in close § 170.550(m)(1) to only allow ONC– partnership with our CMS colleagues to We proposed to remove the 2015 ACBs to issue certificates for this ensure that our regulations remain Edition ‘‘secure messaging’’ criterion criterion until January 1, 2022. aligned and that we provide affected (§ 170.315(e)(2)). As explained in the stakeholders with the information they Proposed Rule (84 FR 7437), ONC c. Patient-Specific Education Resources need to understand how the rules work strongly supports patient and provider We proposed to remove the 2015 together and how to succeed under CMS communication, as well as protecting Edition ‘‘patient-specific education incentive programs using health IT the privacy and security of patient resources’’ certification criterion in certified under ONC’s Program. CMS information, but no longer believes that § 170.315(a)(13) (84 FR 7437). We stated has identified this criterion as a separate certification criterion focused

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00021 Fmt 4701 Sfmt 4700 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 We, therefore, will permit ONC–ACBs to 5. Removal of Certain ONC Health IT receive secure messages between health issue certificates for this criterion up Certification Program Requirements care providers and patients is necessary. until January 1, 2022 to align with the We proposed to remove certain This criterion would also no longer be requirements of the CMS Medicaid PI mandatory disclosure requirements and associated with an objective or measure Program (84 FR 42592). We have a related attestation requirement under under the CMS PI Programs based on included a provision in § 170.550(m)(1) the Program. As discussed in the proposals and determinations in recent to only allow ONC–ACBs to issue Proposed Rule (84 FR 7437), we believe CMS rulemakings (83 FR 41664; 83 FR certificates for this criterion until removal of these requirements will 35929). January 1, 2022. reduce costs and burden for Program Comments. Several comments Limiting certificates to this criterion stakeholders, particularly for health IT specifically referencing this proposal for this period will help spur further developers and ONC–ACBs. were supportive of removing this innovations in patient engagement criterion. A number of commenters while helping to reduce regulatory a. Limitations Disclosures expressed concern with the removal of burdens and costs for health IT We proposed to remove the ‘‘secure messaging’’ criterion, developers and health care providers. § 170.523(k)(1)(iii)(B), which requires including whether removal of this The other 2015 Edition certification ONC–ACBs to ensure that certified criterion may create a barrier to criteria that support patient engagement, health IT includes a detailed description successful participation for providers in such as the 2015 Edition ‘‘view, of all known material information the CMS PI Programs. Other download, and transmit to 3rd party,’’ concerning limitations that a user may commenters expressed concerns about ‘‘API,’’ and ‘‘patient health information encounter in the course of continued availability of secure digital capture’’ certification criteria better implementing and using the certified endpoints for health care providers. support interoperability and innovation health IT, whether to meet ‘‘meaningful Some commenters noted that some in patient engagement. We have seen use’’ objectives and measures or to providers and patients might prefer to developers integrate secure messaging achieve any other use within the scope continue using ‘‘secure messaging’’ functionality as part of other patient of the health IT’s certification. We functionality in lieu of other options for engagement features, such as patient a variety of purposes for which they proposed to remove portals, and integrate messaging with currently use it, while others expressed § 170.523(k)(1)(iv)(B) and (C), which access to and exchange of clinical and concern that the separate ‘‘secure state that the types of information messaging’’ functionality will disappear administrative data. These integrated required to be disclosed include, but are from the market if no longer supported technologies currently in use offer more not limited to: (B) Limitations, whether by ONC requirements. Commenters comprehensive options for providers by contract or otherwise, on the use of expressed that options for data access and patients to interact and share any capability to which technology is and exchange, such as portals and APIs, information via a secure platform and certified for any purpose within the might satisfy providers’ and patients’ may render the separate ‘‘secure scope of the technology’s certification; needs for interoperable communication. messaging’’ criterion and functionality or in connection with any data However, commenters expressed a redundant to robust integrated options. generated in the course of using any concern that these options may not We also believe removing the capability to which health IT is ensure continued availability to new standalone ‘‘secure messaging’’ criterion certified; (C) limitations, including but market entrants’ health IT without will encourage the market to pursue not limited to technical or practical requiring the technology to interact with other innovative means of offering limitations of technology or its developer- or system-specific interfaces. patient engagement and interaction capabilities, that could prevent or Response. We thank commenters for functionalities that providers and impair the successful implementation, their input. Having reviewed all patients want, with the convenience and configuration, customization, comments received on this proposal, we efficiency they demand. Thus, we maintenance, support, or use of any have decided not to remove the ‘‘secure believe that the removal of this criterion capabilities to which technology is messaging’’ criterion from the Program will help reduce burden and costs certified; or that could prevent or limit at this time. We recognize the without negative impact on current or the use, exchange, or portability of any importance of ensuring alignment future innovations in patient data generated in the course of using between ONC Health IT Certification engagement and secure information any capability to which technology is Program regulations and the CMS exchange. In response to the concern certified. regulations that reference them. We will about new market entrants being able to Comments. Most of the comments continue to work in close partnership receive data needed to serve their specifically referencing this proposal with our CMS colleagues to ensure that customers, we note that the ‘‘view, were supportive. A few commenters our regulations remain aligned and that download, and transmit to 3rd party’’ raised concerns regarding the utility of we provide affected stakeholders with criterion remains available for patients mandatory disclosures to health care the information they need to understand who wish to send their health providers, their health information how the rules work together and how to information to a third party of the exchange partners, and ONC, with some succeed under CMS incentive programs patient’s choice. Other remaining commenters offering suggestions for using health IT certified under ONC’s interoperability-focused criteria, such as how ONC could use disclosures Program. CMS has identified this ‘‘transitions of care,’’ ensure that information in the future. A few criterion as supporting the coordination systems of health IT certified to at least commenters’ concerns specifically of care through patient engagement those criteria remaining in the ‘‘Base referenced the disclosure of costs objective and measure, which is EHR’’ definition will remain capable of information. expected to remain operational for supporting providers’ use of new Response. We thank commenters for Medicaid until January 1, 2022; after entrant and other third party health IT their input. We have finalized removal 2021 there will be no further incentives of their choosing without requiring that of § 170.523(k)(1)(iii)(B) and under the Medicaid Promoting health IT to integrate or interface with § 170.523(k)(1)(iv)(B) and (C), as Interoperability Program (84 FR 42592). their certified health IT. proposed (84 FR 7437 and 7438). As

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00022 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25663

discussed in the Proposed Rule (84 FR disclosures per § 170.523(k)(1) to that promotes innovation, protects 7438), these specific disclosure specified parties (e.g., potential patient safety, and avoids regulatory requirements are superseded by the customers or anyone inquiring about a duplication. The FDASIA Health IT Cures Act information blocking product quote or description of Report of April 2014,19 contained a provision and Conditions of services). As discussed in the Proposed proposed strategy and recommendations Certification requirements, which we Rule (84 FR 7438), we believe this on an appropriate, risk-based regulatory proposed to implement in the same provision is no longer necessary and framework pertaining to health IT that Proposed Rule (84 FR 7424). As also that its removal is appropriate to further promotes innovation, protects patient noted in the Proposed Rule (84 FR reduce administrative burden for health safety, and avoids regulatory 7438), we proposed (84 FR 7465 and IT developers and ONC–ACBs. duplication. Public comments, received 7466) a complementary Condition of Comments. The majority of prior to the report’s publication and Certification requirement that commenters specifically discussing this after,20 recommended that health IT developers would be prohibited from proposal expressed support for the developers/manufacturers apply a single taking any action that could interfere removal of the PoPC in § 170.523(k)(2). process that satisfies the requirements of with a user’s ability to access or use A few commenters expressed concern all agencies, and existing safety and certified capabilities for any purpose that the high degree of transparency quality-related processes, systems, and within the scope of the technology’s ONC noted in the Proposed Rule might standards should be leveraged for certification discussed further in section not be maintained as they noted a patient safety in health IT. On July 27, VII.2. possibility that the PoPC requiring the 2017, FDA announced a voluntary We also note here to ensure clarity ONC–ACBs to ensure the developers Software Precertification Pilot Program that we did not propose, and have not submitted an attestation, and, in turn, as part of a broader Digital Health finalized, a complete removal of the the developers’ obligation to make the Innovation Action Plan.21 It was transparency requirements in attestation, may be driving the currently developed in order to create a tailored § 170.523(k)(1). Requirements under observed levels of transparency. approach toward recognizing the unique § 170.523(k)(1) other than those Response. We thank commenters for characteristics of digital technology by specifically proposed for removal will their input. We have decided to finalize looking first at the firm, rather than remain in place. The transparency the removal of the PoPC in primarily at each product of the firm, as requirements remaining in place § 170.523(k)(2). We appreciate the is currently done for traditional medical include: § 170.523(k)(1)(iii)(A), which importance of holding health IT products. The FDA plans to explore describes the plain language detailed developers accountable for meeting all whether and how pre-certified description of all known material requirements of participation in the companies that have demonstrated a information concerning additional types Program, including meeting or culture of quality, patient safety, and of costs that a user may be required to exceeding the minimum required organizational excellence could bring pay to implement or use the Complete transparency disclosures. We believe certain types of digital health products EHR or Health IT Module’s capabilities, that the needed transparency and to market either without FDA premarket whether to meet meaningful use accountability will be maintained and review or with a more streamlined FDA objectives and measures, or to achieve enhanced by certain Condition and premarket review. any other use within the scope of the Maintenance of Certification a. FDA Software Precertification Pilot health IT’s certification; and requirements we have finalized in this Program § 170.523(k)(1)(iv)(A) specification that rule, which include the assurances and the types of information required by attestations specifically discussed in We proposed (84 FR 7438 and 7439) § 170.523(k)(1)(iii) include, but are not section VII.2 in relation to this proposed to establish processes that would limited to, additional types of costs or removal of § 170.523(k)(2). We believe provide health IT developers that can fees (whether fixed, recurring, that the removal of the PoPC document holding pre-certification transaction-based, or otherwise) requirements in § 170.523(k)(2) will under the FDA Software Precertification imposed by a health IT developer (or likely aid in the avoidance of Pilot Program with exemptions to the any third party from whom the unnecessary costs and burden for ONC Health IT Certification Program’s developer purchases, licenses, or Program stakeholders, particularly requirements for testing and obtains any technology, products, or health IT developers and ONC–ACBs. certification of its health IT to the 2015 services in connection with its certified Edition ‘‘quality management systems’’ health IT) to purchase, license, 6. Recognition of Food and Drug criterion (§ 170.315(g)(4)) and the 2015 implement, maintain, upgrade, use, or Administration Processes Edition ‘‘safety-enhanced design’’ otherwise enable and support the use of Section 618 of the Food and Drug criterion (§ 170.315(g)(3)), as these capabilities to which health IT is Administration Safety and Innovation criteria are applicable to the health IT certified; or in connection with any data Act (FDASIA), Public Law 112–144, developer’s health IT presented for generated in the course of using any required that the Food and Drug capability to which health IT is Administration (FDA), in consultation 19 https://www.fda.gov/downloads/AboutFDA/ CentersOffices/ certified. with ONC and the Federal OfficeofMedicalProductsandTobacco/CDRH/ b. Transparency and Mandatory Communications Commission (FCC) CDRHReports/UCM391521.pdf. 20 Disclosures Requirements (collectively referred to as ‘‘the https://www.federalregister.gov/documents/ Agencies’’ 18 for this final rule), develop 2013/05/30/2013-12817/food-and-drug- We proposed to remove the Principle administration-safety-and-innovation-act-fdasia- a report containing a proposed strategy request-for-comments-on-the, https://blogs.fda.gov/ of Proper Conduct (PoPC) in and recommendations on an fdavoice/index.php/2014/04/fda-seeks-comment- § 170.523(k)(2), which requires ONC– appropriate, risk-based regulatory on-proposed-health-it-strategy-that-aims-to- ACBs to ensure health IT developers’ framework pertaining to health IT, promote-innovation/ and https:// www.regulations.gov/document?D=FDA-2014-N- adherence to a requirement that the including mobile medical applications, health IT developer submit an 0339-0001. 21 https://www.fda.gov/MedicalDevices/ attestation that it will disclose all of the 18 ONC is not an agency, but an office within the DigitalHealth/DigitalHealthPreCertProgram/ information in its mandatory Department of Health and Human Services. Default.htm.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00023 Fmt 4701 Sfmt 4700 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 of ONC’s Program at lower burden on IV. Updates to the 2015 Edition ‘‘recognition’’ could, depending on the those developers for whom dual Certification Criteria final framework of the FDA Software participation is a need or an appealing In order to capture and share patient Precertification Pilot Program, be option. Several commenters noted data efficiently, health care providers applicable to the functionally-based potential for recognition of developers need health IT that store data in 2015 Edition ‘‘clinical’’ certification who achieve precertification status structured formats. Structured data criteria (§ 170.315(a)). We noted in the under the FDA’s program to streamline allows health care providers to easily Proposed Rule that the proposed or offer them a low-burden option for retrieve and transfer patient ‘‘recognition’’ could also be appropriate satisfying certain requirements under information, and use health IT in ways to address any or all of the following ONC’s Program. However, several that can aid patient care. We proposed functionally-based 2015 Edition criteria commenters urged that obtaining FDA to update the 2015 Edition by adopting in the event their proposed removal a limited set of revised and new 2015 were not finalized: ‘‘problem list’’ precertification status should not be the Edition certification criteria, including (§ 170.315(a)(6)), ‘‘medication list’’ only way a developer could satisfy any new standards, to support these (§ 170.315(a)(7)), ‘‘medication allergy requirement under ONC’s Program, objectives. Some of these criteria and list’’ (§ 170.315(a)(8)), ‘‘drug-formulary noting that a developer of one or more standards are included in the Certified and preferred drug list checks’’ certified Health IT Modules that is EHR Technology (CEHRT) definition (§ 170.315(a)(10)),’’ and ‘‘smoking newer to the market or simply smaller used for participation in HHS Programs, status’’ (§ 170.315(a)(11)). and not engaged in development of We noted (84 FR 7439) that despite software subject to FDA regulation such as the Promoting Interoperability proffered benefits including alignment could find the FDA Software (PI) Programs (formerly the EHR Incentive Programs), some are required with both EOs 13563 and 13771 Precertification Program’s requirements to be met for participation in the ONC regarding deregulatory, less a higher hurdle to entering or remaining Health IT Certification Program, and burdensome, and more effective in the ONC-certified health IT market regulatory schemes and programs, and some, though beneficial, are sector than the ONC requirements the unassociated with the CEHRT definition serving as a regulatory relief for those recognition might replace. health IT developers qualifying as small and not required for participation in any businesses under the Regulatory Response. Considering commenters’ HHS program, including the ONC Flexibility Act (84 FR 7587 and 7588), concerns and the maturity of the FDA Health IT Certification Program there may be reasons not to adopt such Software Precertification Program— (Program). a ‘‘recognition’’ approach. We noted as which remains in a pilot phase at the Comments. We received a few examples of such reasons that time this final rule is being drafted—we comments in support of our approach to stakeholders may not agree that the FDA have decided not to finalize recognition modify the 2015 Edition health IT Software Precertification Program of the FDA Software Precertification certification criteria. One commenter sufficiently aligns with our Program, Program at this time. However, we commended ONC for proposing logical and that stakeholders may have anticipate continuing to consult and updates to the 2015 Edition certification operational concerns. Accordingly, we coordinate with our colleagues at FDA criteria, rather than overhauling the welcomed comments on these and other and to monitor the details and Program or establishing a new edition of certification, stating iterative changes aspects of our proposed ‘‘recognition’’ experience of the FDA Software will provide stability and allow the approach, including the 2015 Edition Precertification Program as it continues industry to adapt to new market forces. certification criteria that should be to mature. We continue to believe that Commenters stated that this incremental eligible for ‘‘recognition.’’ there may be potential for recognition of Comments. The majority of approach best serves the health care the FDA Software Precertification commenters commended ONC’s efforts provider and health IT developer Program to contribute in the future to to recognize the FDA Software community. One commenter applauded Precertification Program. However, most our ongoing goals of reducing burden ONC for proposing logical updates to commenters expressed concerns that and promoting innovation while the 2015 Edition health IT certification FDA’s program was not yet mature maintaining or enhancing the assurance criteria and recommended that ONC enough to assess the degree of alignment that the ONC Health IT Certification continue to seek to maximize the impact to the ONC Health IT Certification Program provides, but we have not of these certification changes and Program. Many commenters expressed finalized our proposal at this time. pursue all opportunities to simplify existing criteria. concerns that the FDA Software b. Development of Similar Independent Precertification Pilot Program focuses However, a number of commenters Program Processes—Request for on development and business practices, requested that ONC put forth a new Information with a potential for streamlining edition and suggested varied approaches requirements for pre-market clearance of In the Proposed Rule (84 FR 7439), we to a new edition. Commenters suggested specific functionalities, while ONC’s included a request for information (RFI) that ONC clearly delineate the certification Program focuses less on related to the development of similar difference between the editions by creating a new naming convention for development practices and more on independent processes to those of the certification of individual software the updated criteria, such as a version FDA Software Precertification Program products as meeting Program-specified number. Others recommended a 2020 for purposes of our Program. We requirements for functionality and Edition or the corresponding year in interoperability, including conformance received 21 comments on this RFI and which this rule is effective. Still other with specific interoperability standards. appreciate the input provided by commenters recommended the Many of these commenters indicated commenters. We will continue to proposed updated 2015 Edition be that until the FDA program is more fully consider whether to develop similar renamed to the 2021 Edition instead of mature they would prefer to reserve independent processes and whether this renamed with a Release 2 at end of the judgment on how recognition could or should be included in future existing name. Some commenters should be structured to satisfy the needs rulemaking. identified the scope of the proposed

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00024 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25665

changes as the reason ONC should this final rule. Instead, a health IT such significant burden must be establish the updates as a new edition developer would update their certified considered in health IT policy of certification criteria rather than Health IT Module, notify the ONC–ACB decisions. simply updating the 2015 Edition. that they have done so, and make the Further, we believe the scope of the However, the majority of commenters update available their customers. updates and the impact on health IT recommending a new edition based Additionally, unlike prior certification developers and health care providers their concern on the potential confusion edition rulemakings, the certification must be considered in tandem— among providers who purchase and use criteria updated to address compliance meaning that an entirely new edition certified health IT resulting from with the USCDI do not include new should only be established when the different products available under the functionality nor do they require a scope of the updates is significant same label. complete redesign of Health IT Modules enough to warrant the impacts of Response. We thank commenters for certified to such certification criteria. As implementation. When the scope of their input on the tradeoffs associated noted in the Proposed Rule, the updates updates does not warrant with modifying the current 2015 Edition to the CCDS to create the USCDI were implementation of an entirely new versus creating a new edition. We intentionally limited to a modest edition of certification criteria, we considered a variety of factors when we expansion that most health IT believe it is appropriate to update the framed our proposals. First, we developers already supported, were existing criteria. For example the 2015 reviewed the scope of each proposed already working toward, or should be Edition included new criteria that were update and the cumulative scope of the capable of updating their health IT to neither built upon nor updated to proposals overall for health IT support in a timely manner. Please see existing criteria in the 2014 Edition, developers and sought to identify Table 1 for a list of all certification which was significantly different than whether it would be more appropriate to criteria changes. the 2011 Edition. In contrast, health IT require health IT developers developers have been able to employ In consideration of the impact our participating in the Program to regular or cyclical updates without approach would have on health care implement updates to Health IT modifying all Health IT Modules providers, we note that impact and Modules certified to the 2015 Edition or certified to unchanged criteria in order potential burden for providers is of to test and certify health IT products to to implement updates to existing particular importance given that an entirely new edition of certification certification criteria such as the annual CY2019 was the first performance year criteria. Second, we considered the updates to CMS eCQMs or for changes impact that either approach would have where eligible clinicians (ECs), eligible made to public health reporting on health care providers, including how hospitals, dual-eligible hospitals, and standards. In such cases, the changes such updated Health IT Modules or critical access hospitals (CAHs) may be implemented by health IT products certified to a new edition participating in CMS programs— developers in the manner most would be implemented by providers including the CMS Promoting appropriate for their product and their participating in CMS programs. Interoperability Program and the customers, such as through routine We have considered the impact on Quality Payment Program/Merit-based service and maintenance rather than a health IT developers related to the scope Incentive Payment System—were completely new implementation. of the individual updates as well as the required to use health information In order to understand the impact cumulative scope of all updates to the technology certified to the 2015 Edition these updates would have on 2015 Edition adopted in this final rule to meet the requirements of the CMS participants in the CMS programs which (see also section XIII Regulatory Impact CEHRT definition. If we were to adopt reference them for use by program Analysis). In this final rule, we have a new edition of certification criteria, participants, we compare these updates only adopted two new technical CMS programs would have to consider to the current definition of CEHRT certification criteria in § 170.315(b)(10) establishing a new CEHRT definition established by CMS at 42 CFR 495.4 for and § 170.315(g)(10) to which health IT and a subsequent requirement for eligible hospitals, CAHs and Medicaid developers seeking to upgrade their program participants who have only eligible professionals and at 42 CFR products will need to present Health IT recently completed a full edition update 414.1305 for eligible clinicians in MIPS. Modules for certification. Unlike the to their technology used for program For 2019 and subsequent years, the CMS new criteria introduced in prior participation. Historically, with a new CEHRT definition specifies the use of certification edition rulemakings, both edition of certification criteria, health IT EHR technology certified to 2015 of these new criteria are an expansion developers have packaged Health IT Edition including technology that meets or modification of existing criteria Modules certified to new, modified, and the 2015 Edition Base EHR definition in within the 2015 Edition which are unchanged criteria into a wholly new § 170.102, as well as other certified currently in use in certified health IT. certified product. Historical data technology necessary to be a meaningful The new criteria in § 170.315(b)(10) indicates that these complete updates to user. The updates finalized in this final relates to the 2015 Edition criteria in the edition are particularly challenging rule impact both certification criteria § 170.315(b)(6) with an expansion of the for both health IT developers seeking included in the Base EHR definition as data and a removal of the specificity for certification and for health care well as criteria required for applicable the standard requirement. The new providers as they place deadlines for a objectives and measures. Specifically, Standardized API criteria in significant number of health IT this final rule updates several criteria § 170.315(g)(10) relates to the 2015 developers to support and implement currently applicable for certified Health Edition API criteria with an expansion new products for a significant number IT Modules used by CMS program of security requirements and the of health care providers simultaneously. participants for the CMS objectives and addition of applicable standards. For the As a result, the burden of updating the measures necessary to be a meaningful remainder of the updated criteria, a technology is compounded for both user, including: developer would not be required to health IT developers and health care • Revisions to the electronic present a Health IT Module for providers. While ONC does not itself prescribing criterion in § 170.315(b)(3) certification in order to update a place any such requirements on health to reference an updated e-prescribing certified product in accordance with care providers, we believe the risk of standard;

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00025 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25666 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

• Revisions relating to the drug- for all prescriptions (80 FR 62833). (CHPL),22 which is the tool that health formulary and preferred drug list checks Second, as it does not remove the care providers and the general public criterion in § 170.315(a)(10) to include product from the market, any providers may use to identify the specific at 170.550(m)(1) to only allow ONC– who are using the current functionality certification status of a product at any ACBs to issue certificates for this may continue to use the technology for given time, to explore any certification criterion until January 1, 2022; their purposes. For the replacement of actions for a product, and to obtain a • Replacement of the API criterion in the API criterion in § 170.315(g)(8) with CMS Certification ID for a product used § 170.315(g)(8) with a new API criterion a new Standardized API criterion in when participating in CMS programs. in § 170.315(g)(10) referencing an API § 170.315(g)(10) referencing an API While we retain the overall 2015 Edition standard and related security standards; standard and related security standards, title, we will distinguish the 2015 • Revisions to several criteria to we reiterate that health IT developers Edition certification criteria from the reference the USCDI and implement have 24 months from the date of new or revised criteria adopted in this other standards updates (see Table 1 for final rule by referring to the new or publication of this final rule to update specifics); and revised criteria as the 2015 Edition their technology and make such • Revisions to § 170.315(c)(3), to Cures Update on the CHPL for products available to their customers. The 2015 update quality reporting standards. that are certified. The CHPL will also Edition final rule adopted an API In general, health IT developers have differentiate to what standards the 24 months from the publication date of criterion in § 170.315(g)(8) which was health IT will be certified and will allow the final rule to make technology implemented by many health IT health care providers to identify if and certified to these updated criteria developers using the underlying when a specific Health IT Module has available to their customers, and during standard adopted in this final rule for been updated. This will help to this time developers may continue the Standardized API criterion in eliminate some of the confusion among supporting technology certified to the § 170.315(g)(10). This common use providers who are seeking to prior version of certification criteria for impacted our decision to adopt the understand the certification and update use by their customers. For providers standard in our update to the 2015 the status of the product they are participating in CMS programs, this Edition (see also section VII.B.4.c currently using. It can also be a resource means they can continue to use the Standardized API for Patient and for providers who may be making a new certified technology they have available Population Services). We, therefore, purchase of certified health IT to make to them to support program believe that both the scope of the an informed decision about which participation and can work with their updates and the potential impact on products support the most up to date developers to implement any updates in health IT developers and health care available standards and functionality. a manner that best meets their needs. providers do not constitute sufficient We further note that, while in the past For the revisions to electronic justification for the potential burden ONC has largely relied on creating a prescribing criterion in § 170.315(b)(3) associated with adopting an entirely new edition to implement changes to and to the quality reporting standards, new edition of certification criteria. certification criteria, in each case, those in § 170.315(c)(3), the updates adopted Instead, we believe it is most reasonable changes included some updates to for certified health IT align specifically and effective for these updates to be part existing criteria, but also criteria with changes already required by CMS of the existing 2015 Edition as modified containing functionality and standards for use by health care providers. This in this final rule. that were entirely new and did not build means health IT developers are already on the prior edition. In addition, the implementing and supporting these We acknowledge the concerns of Cures Act set in motion a shift for the updates. The implementation of these commenters who expressed the ONC Health IT Certification Program by updates is driven by other requirements potential risk of confusion about the including Conditions and Maintenance and so repackaging such updates in a updates among their customers and how of Certification requirements which new edition (or a new product) would to best communicate that a product allowed for processes such as the create a redundancy and could have meets the updated version of a given Standards Version Advancement unintended cost burden on health care certification criterion. We strongly Process (SVAP) flexibility within real providers. For the updates to the criteria encourage health IT developers to work world testing, which allows better referencing the USCDI, as noted with their customers to promote alignment to industry efforts for previously, we based the USCDI on the understanding of these updates. In standards advancement while existing CCDS with modest expansion addition, we have taken several maintaining accountability. These new that most health IT developers already mitigating steps. First, we revisited our provisions help to remove barriers for supported, were already working proposed regulatory structure and standards development and version toward, or should be capable of revised it so that the structure more updates, which limit a health IT updating their health IT to support in a clearly reflects if a change is updating developer’s ability to provide timely manner. Finally, for the removal the previously adopted standard, or a individually relevant, timely, and of the drug-formulary and preferred more significant change to the criterion innovative solutions to their clients. drug list checks in § 170.315(a)(10), we such as adding a new standard. This This change is consistent with our note that the removal from the Program maintains the prior 2015 Edition approach to adopt incremental updates has negligible impact on health care regulatory structure for the majority of in this final rule rather than to adopt a providers. the updates except for § 170.315(b)(10) complete new edition of certification First, as discussed in past CMS and (g)(10) as discussed previously, and criteria. This final rule is the first time regulations related to the use of these establishes a more clear sense of scope. we have executed on the concept of functionalities by participants in CMS Second, in order to support effective Maintenance of Certification programs, health care providers have requirements for existing certificates, communication of the updates, we are noted that while formulary checks are a and we foresee the potential for future promising approach, the utility of the implementing a practical approach to facilitate transparency using the specific functionality that is certified is 22 ONC Certified Health IT Product List: https:// not necessarily consistently applicable Certified Health IT Product List chpl.healthit.gov.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00026 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25667

rulemakings to include incremental Please see Table 1 for a list of all updates to certification criteria when certification criteria changes. such updates are appropriate. TABLE 1—2015 EDITION CURES UPDATE

New/revised/ Certification criteria Reference removed/time- 2015 Edition cures update—timing Impact on CMS promoting interoperability (PI) limited certification programs

Problem list ...... § 170.315(a)(6) ..... Removed ...... Effective date of final rule (60 days after publi- Removed from 2015 Edition Base EHR defini- cation). tion. Medication list ...... § 170.315(a)(7) ..... Removed ...... Effective date of final rule (60 days after publi- Removed from 2015 Edition Base EHR defini- cation). tion. Medication allergy list .. § 170.315(a)(8) ..... Removed ...... Effective date of final rule (60 days after publi- Removed from 2015 Edition Base EHR defini- cation). tion. Drug Formulary and § 170.315(a)(10) ... Time-limited Cer- ONC–ACBs only permitted to issue certificates PI Measures: Preferred Drug List tification. for this criterion until January 1, 2022. —e-Rx Checks. —-Query of PDMP Operational for Medicaid until January 1, 2022. Smoking status ...... § 170.315(a)(11) ... Removed ...... Effective date of final rule (60 days after publi- Removed from 2015 Edition Base EHR defini- cation). tion. Patient-specific Edu- § 170.315(a)(13) ... Time-limited Cer- ONC–ACBs only permitted to issue certificates Operational for Medicaid until January 1, 2022 cation Resource. tification. for this criterion until January 1, 2022. Supports Patient Electronic Access to Health Information Objective Measure. Transitions of Care ...... § 170.315(b)(1) ..... Revised ...... Update to USCDI/C–CDA companion guide PI Measures: within 24 months after the publication date of —Support Electronic Referral Loops by final rule. Sending Health Information —Support Electronic Referral Loops by Re- ceiving and Incorporating Health Information. Clinical information rec- § 170.315(b)(2) ..... Revised ...... Update to USCDI/C–CDA companion guide PI Measures: onciliation and incor- within 24 months after the publication date of —Support Electronic Referral Loops by Re- poration. final rule. ceiving and Incorporating Health Information. Electronic prescribing .. § 170.315(b)(3) ..... Revised ...... Update standard within 24 months after the PI Measures: publication of final rule. —e-Prescribing. Common Clinical Data § 170.315(b)(4) ..... Removed ...... Effective date of final rule (60 days after publi- Set summary cation). record—create. Common Clinical Data § 170.315(b)(5) ..... Removed ...... Effective date of final rule (60 days after publi- Set summary cation). record—receive. Data Export ...... § 170.315(b)(6) ..... Time-limited Cer- ONC–ACBs may only issue certificates until 36 Removed from 2015 Edition Base EHR defini- tification. months after the publication date of the final tion effective date of the final rule (60 days rule. after publication). Security tags—sum- § 170.315(b)(7) ..... Revised ...... Document, section, and entry (data element) mary of care—send. level; or Document level for the period until 24 months after publication date of final rule. Security tags—sum- § 170.315(b)(8) ..... Revised ...... Document, section, and entry (data element) mary of care—re- level; or Document level for the period until ceive. 24 months after publication date of final rule. Care plan ...... § 170.315(b)(9) ..... Revised ...... Update to C–CDA companion guide within 24 months after publication date of final rule. EHI export ...... § 170.315(b)(10) ... New ...... Update within 36 months of publication date of final rule. Clinical quality meas- § 170.315(c)(3) ..... Revised ...... Effective date of final rule (60 days after publi- PI Programs. ures (CQMs)—report. cation). Auditable events and § 170.315(d)(2) ..... Revised ...... Update to new ASTM standard within 24 tamper-resistance. months after publication date of final rule. Audit report(s)...... § 170.315(d)(3) ..... Revised ...... Update to new ASTM standard within 24 months after publication date of final rule. Auditing actions on § 170.315(d)(10) ... Revised ...... Update to new ASTM standard within 24 health information. months after publication date of final rule. Encrypt authentication § 170.315(d)(12) ... New ...... Effective date of final rule (60 days after publi- credentials. cation) (New and updated certifications only). Multi-factor authentica- § 170.315(d)(13) ... New ...... Effective date of final rule (60 days after publi- tion (MFA). cation) (New and updated certifications only). View, Download, and § 170.315(e)(1) ..... Revised ...... Update to USCDI/C–CDA companion guide PI Measure: Transmit to 3rd Party. within 24 months after publication date of —Provide Patients Electronic Access to final rule. Their Health Information. Secure Messaging ...... § 170.315(e)(2) ..... Time-limited Cer- ONC–ACBs only permitted to issue certificates Operational for Medicaid until January 1, 2022 tification. for this criterion until January 1, 2022. Supports the Coordination of Care through Patient Engagement Objective. Transmission to public § 170.315(f)(5) ...... Revised ...... Update to USCDI/C–CDA companion guide PI Measure: health agencies— within 24 months after publication date of —Electronic Case Reporting. electronic case re- final rule. porting. Consolidated CDA cre- § 170.315(g)(6) ..... Revised ...... Update to USCDI/C–CDA companion guide ation performance. within 24 months after publication date of final rule. Application Access— § 170.315(g)(8) ..... Time-limited Cer- 24 months after publication date of final rule ... PI Measure: Data Category Re- tification. —Provide Patients Electronic Access to quest. Their Health Information.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00027 Fmt 4701 Sfmt 4700 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

New/revised/ Certification criteria Reference removed/time- 2015 Edition cures update—timing Impact on CMS promoting interoperability (PI) limited certification programs

Application Access—All § 170.315(g)(9) ..... Revised ...... Update to USCDI/C–CDA companion guide PI Measure: Data Request. within 24 months after publication date of —Provide Patients Electronic Access to final rule. Their Health Information. Standardized API for § 170.315(g)(10) ... New ...... Update within 24 months of publication date of Added to the 2015 Edition Base EHR defini- patient and popu- final rule. tion. lation services. 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 work done by organizations such as clinical quality measure (eCQM) data to Specifications HL7®. They noted that such work CMS. incorporates public health inputs, and 1. National Technology Transfer and 2. Compliance With Adopted Standards stated that it is critical for there to be Advancement Act and Implementation Specifications sufficient discussion and consideration The National Technology Transfer of all stakeholder concerns in adopting In accordance with Office of the and Advancement Act (NTTAA) of 1995 such critical technologies such as Federal Register regulations related to (15 U.S.C. 3701 et. seq.) and the Office FHIR®. ‘‘incorporation by reference,’’ 1 CFR of Management and Budget (OMB) Response. We thank commenters for part 51, which we follow when we Circular A–119 23 require the use of, their feedback. We clarify that many of adopt proposed standards and/or wherever practical, technical standards the standards we adopt in this final rule implementation specifications in a final that are developed or adopted by are developed and/or adopted by rule, the entire standard or voluntary consensus standards bodies to voluntary consensus standards bodies, implementation specification document carry out policy objectives or activities, except where we found that a is deemed published in the Federal with certain exceptions. The NTTAA government unique standard is more Register when incorporated by reference and OMB Circular A–119 provide appropriate. We are aware of no therein with the approval of the Director exceptions to electing only standards voluntary consensus standards that of the Federal Register. Once published, developed or adopted by voluntary could serve as an alternative for the compliance with the standard and/or consensus standards bodies, namely following purposes in this final rule. implementation specification includes when doing so would be inconsistent In this final rule, we use voluntary the entire incorporated document, with applicable law or otherwise consensus standards except for: unless we specify otherwise. For • ® impractical. Agencies have the The standard adopted in § 170.213, example, for the HL7 FHIR U.S. Core discretion to decline the use of existing the United States Core Data for Implementation Guide (IG) STU 3.1.0 voluntary consensus standards if Interoperability (USCDI), Version 1 (v1), adopted in this final rule (see section determined that such standards are is a hybrid of government unique policy VII.B.4), health IT certified to inconsistent with applicable law or (i.e., determining which data to include certification criteria referencing this IG otherwise impractical, and instead use a in the USCDI) and voluntary consensus would need to demonstrate compliance government-unique standard or other standards (i.e., the vocabulary and code with all mandatory elements and standard. In addition to the set standards attributed to USCDI data requirements of the IG. If an element of consideration of voluntary consensus elements). We have placed time the IG is optional or permissive in any standards, the OMB Circular A–119 limitations on the predecessor to this way, it would remain that way for recognizes the contributions of standard, the Common Clinical Data Set testing and certification unless we standardization activities that take place (CCDS) definition, under this rule, and specified otherwise in regulation. In outside of the voluntary consensus replaced it with the USCDI in all such cases, the regulatory text would standards process. Therefore, in applicable criteria except for the data preempt the permissiveness of the IG. instances where use of voluntary export criterion in § 170.315(b)(6), on which we have also placed a time limit. 3. ‘‘Reasonably Available’’ to Interested consensus standards would be Parties inconsistent with applicable law or We refer readers to the ‘‘Revised and otherwise impracticable, other New 2015 Edition Criteria’’ in section The Office of the Federal Register has IV.B of this preamble. established requirements for materials standards should be considered that • meet the agency’s regulatory, The standards adopted in (e.g., standards and implementation § 170.205(h)(3) and (k)(3). We replaced specifications) that agencies propose to procurement or program needs, deliver ® favorable technical and economic the current HL7 QRDA standards with incorporate by reference in the Code of outcomes, and are widely utilized in the government unique standards, the CMS Federal Regulations (79 FR 66267; 1 marketplace. Implementation Guide for Quality CFR 51.5(b)). To comply with these Comments. A couple of commenters Reporting Document Architecture: requirements, in section XI stated that they do not support Federal Category I; Hospital Quality Reporting; (‘‘Incorporation by Reference’’) of this programs’ use of the NTTAA voluntary Implementation Guide for 2019, and the preamble, we provide summaries of, consensus standards exceptions, and CMS Implementation Guide for Quality and uniform resource locators (URLs) to, asked that the involved Federal Reporting Document Architecture: the standards and implementation programs continue to utilize consensus- Category III; Eligible Clinicians and specifications we have adopted and based standards developed through Eligible Professionals Programs; subsequently incorporate by reference Implementation Guide for 2019, that in the Code of Federal Regulations. To 23 https://www.whitehouse.gov/sites/ will more effectively support the note, we also provide relevant whitehouse.gov/files/omb/circulars/A119/revised_ associated certification criterion’s use information about these standards and circular_a-119_as_of_1_22.pdf. case, which is reporting electronic implementation specifications

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00028 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25669

throughout the relevant preamble policy ‘‘definition’’ to identify electronic and collaborative process to expand the discussions and regulation text sections health information, for access, exchange USCDI, including providing of the final rule. and use, including associated stakeholders with the opportunity to vocabulary codes, has had its comment on the USCDI’s expansion. We B. Revised and New 2015 Edition drawbacks. While ONC’s ‘‘CCDS’’ indicated that once the Secretary adopts Criteria definition served its designed purpose the first version of the USCDI through 1. The United States Core Data for (to reduce repetitive text in each of the rulemaking, which we proposed in Interoperability Standard (USCDI) certification criteria in which it is § 170.213 in the Proposed Rule, health As we noted in the Proposed Rule, the referenced), the term CCDS, and the IT developers would be allowed to take initial focus of the Program was to data set it represents, also began to be advantage of the ‘‘Standards Version used by outside organizations such as Advancement Process’’ (SVAP) support the Medicare and Medicaid 24 EHR Incentive Programs (76 FR 1294) the Argonaut Project for additional flexibility. The SVAP (which we proposed in § 170.405(b) and which is now referred to as the Promoting use cases beyond the C–CDA and ONC’s Health IT Certification Program. As discussed in section VII.B.5, below) Interoperability (PI) Programs. As such, these organizations identified the need would permit health IT developers to the 2014 Edition certification criteria to expand the content of the CCDS, the voluntarily implement and use a newer mirrored those functions specified by CCDS definition in regulation became a version of a Secretary-adopted standard the CMS PI Programs objectives and limitation to developing additional data such as the USCDI, subject to certain measures for providers demonstrating access, exchange, and uses outside of conditions including a requirement that meaningful use (MU) of certified health ONC’s programs. As we move towards the newer version is approved for use by IT. In order to improve efficiency and value-based care and the inclusion of the National Coordinator, and does not streamline the common data within our Data Classes that go beyond clinical conflict with requirements under other Program’s certification criteria, we data, and as part of ONC’s continued applicable law. We received a number created a single definition for all the efforts to evaluate the availability of a of comments regarding these proposals, required data that could be referenced minimum baseline of Data Classes that which are outlined in the subsections for all applicable certification criteria. must be commonly available for below. We created the term ‘‘Common MU Data interoperable exchange, we Comments. We received broad Set’’ to encompass the common set of acknowledge the need to change and support for the adoption of version 1 of MU data types/elements (and associated improve our regulatory approach to the the USCDI as a new standard defining vocabulary standards) for which CCDS. Therefore, in order to advance critical health care data to promote certification would be required across interoperability by adopting new data interoperability. Some commenters from several certification criteria (77 FR and vocabulary codes sets that support health plans, while supportive of 54170). data exchange, we proposed to remove patient and provider access to health The 2015 Edition final rule modified the ‘‘Common Clinical Data Set’’ in care data, voiced concerns about health the Program to make it open and § 170.315(b)(4) and § 170.315(b)(5), and plans being required to make data accessible to more types of health IT, its references throughout the 2015 available in the USCDI standard. Other and health IT that supports various care Edition and replace it with the ‘‘United commenters noted that USCDI v1 does and practice settings beyond those States Core Data for Interoperability’’ not include data classes and elements included in the CMS PI Programs (80 FR (USCDI) standard. This first version of that pertain to all health care settings, 62604). In comparison to the previous USCDI will be designated ‘‘version 1 including public health, and would editions, the 2015 Edition focused on (v1).’’ The USCDI standard aims to therefore not be broadly applicable to all identifying health IT components achieve the goals set forth in the Cures health care settings. necessary to establish an interoperable Act by specifying a common set of data Response. We thank commenters for nationwide health information classes and elements that have been their support of the adoption of USCDI infrastructure, fostering innovation and designed to improve data usage and v1 as a standard. We wish to clarify that opening new market opportunities, and interoperable data exchange. the adoption of version 1 of the USCDI allowing for more health care provider We proposed to adopt the USCDI v1 as a standard for our Program is not and patient choices in electronic health as a standard defined in § 170.102. Here, specific to a setting of care, a health care information access and exchange. In ‘‘Standard’’ is defined as a ‘‘technical, specialty, or a specific category of health order to align with this approach, we functional, or performance-based rule, IT user. Nor is the USCDI specific to a made changes in the 2015 Edition final condition, requirement, or specification particular content exchange standard rule that resulted in updated vocabulary that stipulates instructions, fields, (e.g., HL7 C–CDA, HL7 FHIR, HL7 V2, and content standards to improve and codes, data, materials, characteristics, or and NCPDP SCRIPT). Rather, it applies advance interoperability and health actions.’’ The USCDI standard would be to the certification of health IT and information exchange (80 FR 62604). composed of Data Classes, which may certified health IT’s ability to send and The 2015 Edition final rule further be further delineated into groupings of receive the Data Elements defined by expanded accessibility and availability specific Data Element(s). For example, USCDI without requirements regarding of data exchanged by updating the ‘‘patient demographics’’ is a Data Class, functionality, user interface, or the use definition of Base EHR in the 2015 and within that Data Class there is of those Data Elements in exchange. Edition to include enhanced data ‘‘patient name,’’ which is a Data While some users may find few export, transitions of care, and Element. As noted in section IV.B.1.b, opportunities to exchange these Data application programming interface (API) for the overall structure and Elements, many will exchange these capabilities, all of which previously organization of the USCDI, please Data Elements frequently, and we required that, at a minimum, the CCDS consult www.healthIT.gov/USCDI. believe that all health care providers be available (80 FR 62602 through We noted in the Proposed Rule (84 FR should have certified health IT that can 62604). 7441) that ONC intended to establish provide them with a means to We further noted in the Proposed and follow a predictable, transparent, appropriately share and access the Rule (84 FR 7440) that the regulatory USCDI data set when exchanging data approach to using and referencing a 24 https://argonautwiki.hl7.org/Main_Page. with other providers. Accordingly, we

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00029 Fmt 4701 Sfmt 4700 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 information exchange. Once adopted in testing plan as discussed in section our proposal regarding the USCDI and this final rule, health IT developers VII.B.5 of the Proposed Rule.26 health IT certification. For the purposes would be required to update their Comments. The majority of of the ONC Health IT Certification certified health IT to support the USCDI commenters supported the proposed Program, specific certification criteria v1 for all certification criteria affected adoption of USCDI v1 and incorporation are the way the USCDI comes into by this proposed change. We also of the USCDI into the revised and new effect. For example, the USCDI is proposed conforming changes in the certification criteria. Some commenters referenced as part of the data sections below to update the following expressed concern that incorporation of requirements in the updated formerly CCDS-dependent 2015 Edition the USCDI into the ‘‘transmission to ‘‘transitions of care’’ certification certification criteria to incorporate the public health agencies—electronic case criterion (§ 170.315(b)(1)), which also USCDI standard: reporting’’ certification criteria could specifies that for certification to that • ‘‘transitions of care’’ have a negative impact on data received criterion, the C–CDA must be used as (§ 170.315(b)(1)); by public health reporting programs. the syntax to hold all of the USCDI data. • ‘‘view, download, and transmit to Some commenters stressed the need for As we explained, we believe that the 3rd party’’ (§ 170.315(e)(1)); reasonable adoption timelines. Some adoption of USCDI v1 for all certified • ‘‘transmission to public health suggested a longer adoption and health IT will advance interoperability agencies—electronic case reporting’’ implementation timeline for by ensuring utilization of common data (§ 170.315(f)(5)); incorporation of the USCDI as part of and vocabulary code sets, and that • ‘‘consolidated CDA creation certified health IT. standardization will support both performance’’ (§ 170.315(g)(6)); and Response. ONC acknowledges that electronic exchange and usability of the • ‘‘application access—all data some entities, such as public health data. Furthermore, because ONC will request’’ (§ 170.315(g)(9)). agencies, may need to consider what the establish and follow a predictable, We did not include the ‘‘data export’’ expanded set of data the USCDI v1 transparent, and collaborative process to criterion (§ 170.315(b)(6)) in the offers may mean to their reporting expand future versions of USCDI, proposed list of criteria that would be programs and requirements. To be clear, including providing stakeholders with revised to include the USCDI standard the USCDI’s existence as a stand-alone the opportunity to comment on draft because we proposed to remove the standard will not impact or change USCDI’s expansion, stakeholders will ‘‘data export’’ criterion (§ 170.315(b)(6)) public health reporting requirements. have ample opportunities to advance and instead proposed to adopt a However, certain data now included in additional Data Classes and Data criterion that we referenced as ‘‘EHI the USCDI, such as clinical notes, Elements relevant to a wide range of export’’ in the Proposed Rule would now become more readily health care use cases. After (§ 170.315(b)(10)). For similar reasons, available for public health reporting and consideration of these comments and we did not include the ‘‘application a State’s public health program’s policy the overall support of commenters, we access—data category request’’ criterion may need to be revisited if a State seeks have adopted the USCDI v1 as a (§ 170.315(g)(8)) because we proposed to to make use of the ‘‘new’’ data the standard in § 170.213. replace it with the API certification adoption of the USCDI stands to make We have also extended the criterion (§ 170.315(g)(10)) that derives more easily available, and more usable compliance timelines with which a its data requirements from the USCDI. upon receipt. We also believe that the health IT developer needs to update to We also proposed, as a Maintenance proposed 24-month timeline for the USCDI, therefore, we have not of Certification requirement updating certified health IT to comply removed the CCDS definition from (§ 170.405(b)(3)) for the real world with the new USCDI standard in § 170.102 as proposed but revised it to testing Condition of Certification § 170.213 is an adequate remove references to 2014 Edition requirement (§ 170.405(a)), that health implementation timeline, based on standards and provided time limitations IT developers with health IT certified to other adoption timelines with similar for when health IT developers need to the five above-identified certification technical complexities. We, therefore, update to the USCDI. criteria prior to the effective date of this have finalized revisions for the five final rule would have to update such above-identified formerly CCDS- a. USCDI 2015 Edition Certification certified health IT to the proposed dependent 2015 Edition certification Criteria revised standards (84 FR 7441 and criteria to incorporate the USCDI We proposed (84 FR 7441) to adopt 7596). We further proposed, as a standard. the USCDI Version 1 (USCDI v1) in Maintenance of Certification We have finalized a modification to § 170.213.25 The USCDI is a requirement (§ 170.405(b)(3)) for the real the regulation text for these criteria standardized set of health Data Classes world testing Condition of Certification based on public comment related to and constituent Data Elements that requirement (§ 170.405(a)), that health mitigating the risk of potential would be required to support IT developers must provide the updated confusion caused by updates to existing nationwide electronic health certified health IT to all their customers criteria. As discussed earlier in this with health IT previously certified to preamble (section IV), we received 25 We note that USCDI v1 is an updated version the identified criteria no later than 24 public comment requesting that all and distinguished from the Draft United States Core months after the effective date of this revised criteria be included in a new Data for Interoperability (USCDI) previously made edition of certification criteria. At the available for public review and comment in the final rule (84 FR 7441 and 84 FR 7596). course of its development as a prospective standard. For the purposes of meeting this start of section IV, we discuss in The data classes and elements in the USCDI v1 compliance timeline, we noted that we response to these comments that we do were proposed in § 170.213 and defined in the expected health IT developers to update not believe the creation of a new edition Proposed Rule, and an additional USCDI v1 is appropriate given that the scope of document with technical standards information was their certified health IT and notify their posted electronically concurrent with the ONC–ACB on the date at which they the updates to the 2015 Edition is tied publication of the Proposed Rule in order to have reached compliance. We noted that provide the public adequate time to fully review 26 The finalized real world testing Condition and and comment on both the proposed regulation and developers would also need to factor Maintenance of Certification requirements are the USCDI v1 technical information. these updates into their next real world discussed in section VII.B.5 of this final rule.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00030 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25671

to standards updates required to keep permitted to issue certificates to this USCDI. We recognize that the USCDI v1 pace with current industry practices. certification criteria after 36 months as proposed represents a modest change However, we do plan to distinguish the after the publication date of this final over the current CCDS definition. As we 2015 Edition certification criteria from rule. As discussed in the ‘‘EHI export’’ indicated in the Proposed Rule (84 FR the updated criteria in this final rule by section below, we have retained 7441), we view this initial version of the referring to them as the 2015 Edition § 170.315(b)(6) ‘‘as is,’’ without updates USCDI standard as a starting point to Cures Update on the CHPL. to the USCDI. Thus, health IT support improved interoperability. We However, as Health IT Modules are developers with health IT certified to are also sensitive to requirements updated to the new standards over time, the prior certification criterion in related to the development and there is a need to define what is § 170.315(b)(6) do not have to update implementation of adopting the USCDI required for certification and what is such certified health IT to the revisions standard. In the interests of maintaining required for compliance to prior listed above, but are permitted to our proposed implementation timeline certification. Therefore, we have maintain or seek new Health IT Module of 24 months from the publication of finalized that for criteria being updated certification to this criterion should they this final rule, and after consideration of from the CCDS to the USCDI, 24 months desire this functionality. these comments and the overall support of commenters, we have finalized the after publication date of the final rule b. USCDI Standard—Data Classes adoption of the Data Classes and shall be applicable for a transition from Included the CCDS to the USCDI. We have elements of the USCDI standard as finalized that for the period until 24 As we noted in the Proposed Rule (84 proposed, with changes outlined in the months after the publication date of the FR 7441), the USCDI Version 1 (USCDI subsections below. Additionally, in final rule, the CCDS remains applicable v1) and its constituent Data Elements order to address the error pointed out to for certified Health IT Modules until incorporated recommendations we had us via comments in the Procedures Data such Health IT Modules are updated to accepted from public comments we had Class, as was stated in the draft USCDI the USCDI. This means that upon the previously received on our Draft USCDI v1,28 we clarified that the American 27 effective date of the rule, for the and Proposed Expansion Process, Dental Association’s Code on Dental identified criteria the following apply which we published January 5, 2018 as Procedures and Nomenclature (CDT) for certification and compliance: well as initial feedback on that draft should be used for Dental Procedures in • The USCDI, or from the Health IT Advisory Committee, the USCDI v1, not SNODENT as was • The CCDS for the period up to 24 both of which occurred prior to the erroneously stated in the draft USCDI months after the publication date of the publication of the Proposed Rule. The v1. final rule. standard we proposed to adopt in With respect to the USCDI’s This allows for developers to plan the § 170.213 also reflected and expansion in future years, ONC will transition for their products more acknowledged the burden that rapidly establish and follow a predictable, effectively and supports certification expanding the USCDI v1 beyond the transparent, and collaborative process to continuity. We have finalized a CCDS could cause. As a result, the expand the USCDI, which will provide modification to the regulation text to USCDI v1 that we proposed was a stakeholders with the opportunity to require the USCDI, or the CCDS for the modest expansion of the CCDS, which comment on the USCDI’s expansion and period lasting until 24 months after the we indicated that most health IT to advance additional Data Classes and publication date of the final rule. developers already supported, were Data Elements relevant to a wide range We have finalized this modification to already working toward, or should be of use cases related to health care. Prior the regulation text for the following capable of updating their health IT to to this final rule, we published our criteria: support in a timely manner. Therefore, initial thinking as well as examples of • ‘‘transitions of care’’ in our Proposed Rule, we outlined only Data Classes and Data Elements that we (§ 170.315(b)(1)); the delta between the CCDS and the believed could be appropriate to • ‘‘view, download, and transmit to USCDI v1. For the overall structure and propose for adding to the USCDI.29 We 3rd party’’ (§ 170.315(e)(1)); organization of the USCDI standard, we have also solicited feedback and • ‘‘transmission to public health urged stakeholders to consult recommendations from the HITAC. As agencies—electronic case reporting’’ www.healthIT.gov/USCDI. we evaluated public comments and (§ 170.315(f)(5)); Comments. We received numerous • conducted our own research prior to the ‘‘consolidated CDA creation comments proposing new Data Classes, issuance of this final rule, we also performance’’ (§ 170.315(g)(6)); and Data Elements, and other changes • wanted to identify for stakeholders ‘‘application access—all data within the USCDI beyond those we another potential source that could be request’’ (§ 170.315(g)(9)). included in the Proposed Rule. used to focus efforts around new USCDI We have finalized in § 170.405(b)(3), Comments recommended including new Data Classes and Data Elements. As is as a Maintenance of Certification Data Elements and/or classes within the noted throughout this rule, the HL7® requirement under the real world testing USCDI v1 related to encounter data, FHIR® standard represents health Condition of Certification requirement, financial transaction and insurance information in what are called ‘‘FHIR that health IT developers with health IT data, and specialty-specific Data resources.’’ When it comes to logically certified to the five above-identified Elements related to cancer treatment, organizing FHIR resources that relate to certification criteria prior to the social determinants of health, and more. one another and share common effective date of this final rule, would Another commenter identified an error properties, FHIR uses a concept called have to update such certified health IT in the Procedures Data Class citing the a ‘‘compartment.’’ Through the to the revisions within 24 months of the wrong code set for dental procedures in standards development process a publication date of this rule. the USCDI v1. ‘‘Patient Compartment’’ has been As of this final rule’s effective date, Response. We thank the many the ‘‘data export’’ criterion in commenters for their input on the 28 https://www.healthit.gov/sites/default/files/ § 170.315(b)(6) is no longer required as draft-uscdi.pdf. a part of the 2015 Edition Base EHR 27 https://www.healthit.gov/sites/default/files/ 29 https://www.healthit.gov/sites/default/files/ definition. ONC–ACB’s will not be draft-uscdi.pdf (January 5, 2018). draft-uscdi.pdf.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00031 Fmt 4701 Sfmt 4700 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 Comments. There was general support recommended the use of the U.S. Postal resources that are associated with a from commenters for updating Service address format to improve patient. The Patient Compartment ‘‘minimum standard’’ code sets address data quality. Commenters also ‘‘includes any resources where the requirements to the newest versions of recommended additional elements of subject of the resource is the patient, these code sets as part of the update address and phone number indicating and some other resources that are from CCDS to the USCDI. One effective period (e.g., current address, directly linked to resources in the commenter recommended adopting the former address); use (e.g., mobile phone patient compartment.’’ This organizing Data Class requirement first, followed number, landline, etc.), and email framework provides a potentially rich by a delayed requirement of updated address. set of a Data Classes and Data Elements versions of the ‘‘minimum standards’’ Response. We thank the commenters to consider for inclusion in the USCDI, code sets, in order to allow for their recommendations and agree including clinical, encounter, specialty, implementers more time to make that these additional Data Elements can and financial data. As ONC looks to changes to their systems. be useful to provide better care and make its own investments to advance Response. We do not believe that assist with patient matching. In the implementation experience adopting the corresponding ‘‘minimum consideration of these comments, we associated with prospective USCDI Data standards’’ code sets that are updated in have finalized the addition of the Classes and Data Elements, we intend to the USCDI v1 would impose a following Data Elements within the leverage the Patient Compartment to significant burden on implementers. In Patient Demographics Data Class: guide our thinking. In addition, we will consideration of the overall support • ‘‘current address’’; also look to and encourage industry to from commenters, we have finalized our • ‘‘previous address’’; look at other organizing frameworks proposal that the USCDI v1 include the • ‘‘phone number’’; such as the Clinical Quality/Clinical newest versions of the ‘‘minimum • ‘‘phone number type’’; and Decision Support realms and the payer- standard’’ code sets available at the time • ‘‘email address.’’ to-provider community (e.g., DaVinci of finalization of this final rule. We have We further clarify that ‘‘phone Project 30) to help identify data that not, however, finalized the proposal for number’’ and ‘‘phone number type’’ would be best to focus on for USCDI the 2015 Edition ‘‘family health history’’ must be represented using the same expansion. criterion (§ 170.315(a)(12)), the 2015 standards, ITU–T E.123 (02/2001) and Edition ‘‘transmission to immunization ITU–T E.164, as already adopted for this i. Updated Versions of Vocabulary registries’’ criterion (§ 170.315(f)(1)), data in 45 CFR 170.207(q) and Standard Code Sets and the 2015 Edition ‘‘transmission to referenced in the 2015 Edition We proposed (84 FR 7441) that the public health agencies—syndromic ‘‘transitions of care’’ certification USCDI v1 would include the newest surveillance’’ criterion (§ 170.315(f)(2)) criterion (§ 170.315(b)(1)(iii)(G)). versions of the ‘‘minimum standard’’ to reference the newest versions of the We appreciate commenters’ code sets included in the CCDS ‘‘minimum standard’’ code sets for these recommendations to use the U.S. Postal available at publication of this final criteria, because the flexibility already Service Postal Addressing Standards, rule. We requested comment on that exists to use newer versions of code sets which include address formatting proposal and on whether it could result included in these criteria. We note that guidance and a variety of products to in any interoperability concerns. We for these certification criteria, health IT improve address quality, such as also noted that criteria such as the 2015 developers may take advantage of the address element standardization and Edition ‘‘family health history’’ criterion previously established 31 flexibility to validation which are published and (§ 170.315(a)(12)), the 2015 Edition seek certification to newer versions of available for public use.32 The U.S. ‘‘transmission to immunization the ‘‘minimum standards’’ code with Postal Service Postal Addressing registries’’ criterion (§ 170.315(f)(1)), § 170.555. Standards include standardized names and the 2015 Edition ‘‘transmission to ii. Address and Phone Number for common unit identifiers, line by line public health agencies—syndromic acceptance requirements for mail surveillance’’ criterion (§ 170.315(f)(2)) We proposed (84 FR 7442) new Data services, and overall address format reference ‘‘minimum standard’’ code Elements in the USCDI v1 for ‘‘address’’ guidance that has been specifically sets; however, we indicated that we and ‘‘phone number.’’ We noted that the designed to support labelling of mail were considering updating the versions inclusion of ‘‘address’’ (to represent the items for acceptance by the U.S. Postal of these standards listed and postal location for the patient) and Service automated sorting processes. We incorporated by reference in part 170 ‘‘phone number’’ (to represent the acknowledge the potential for its use subpart B that are referenced by these patient’s telephone number) would within health IT to improve patient criteria from the versions adopted in the improve the comprehensiveness of matching. However, while the U.S. 2015 Edition final rule. health information for patient care. We Postal Service Postal Addressing We also noted, for purposes of clarity, further noted that the inclusion of these Standards include a single that consistent with § 170.555, unless Data Elements was consistent with the representation for certain data elements the Secretary prohibits the use of a list of patient matching Data Elements (such as rendering apartment as apt, newer version of an identified minimum already specified in the 2015 Edition building as bldg, floor as fl, etc.) they standard code set for certification, ‘‘transitions of care’’ certification also allow variations for other data health IT could continue to be certified criterion (§ 170.315(b)(1)(iii)(G)), which elements, such as ‘‘acceptable’’ and or upgraded by developers to a newer supports the exchange of patient health ‘‘preferred’’ spellings and abbreviations version of an identified minimum information between providers of for street and city names. This may standard code set than that included in patient care. result in multiple ‘‘valid’’ addresses. To USCDI v1 or the most recent USCDI Comments. Commenters unanimously reconcile this variation, the U.S. Postal version that the National Coordinator supported the addition of address and Service provides a file listing preferred has approved for use in the Program phone numbers to the USCDI v1. The using the SVAP flexibility. majority of commenters on this proposal 32 U.S. Postal Service: Postal Addressing Standards (Publication 28) available at https:// 30 http://www.hl7.org/about/davinci/index.cfm. 31 77 FR 54163, 54268–69 (September 4, 2012). pe.usps.com/text/pub28/welcome.htm.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00032 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25673

city and State combinations as well as certified health IT at this time. We again v1. Some commenters opposed their a file of street name and zip code encourage the further development and inclusion or believed the inclusion of combinations and the resulting use of standardized approaches for these Data Elements should be optional aggregated address would then require address validation and will continue to since pediatric vital signs are not manual reconciliation. We believe the monitor and analyze such efforts for applicable to all specialties and would U.S. Postal Service Postal Addressing consideration in future rulemaking. add implementation burden and cost Standards may be useful guidance for iii. Pediatric Vital Signs without benefit. One commenter stated health IT developers. However, because that only the measurements and of the variation, the required use of As proposed (84 FR 7442), the USCDI associated metadata (units of measure, reference files, and the manual v1 included the pediatric vital sign data date/time measurement taken, method reconciliation necessary for elements, which are specified as of measurement), not the calculated implementation, we have not adopted optional health information in the 2015 percentiles according to applicable the U.S. Postal Service Postal Edition CCDS definition. The proposed pediatric growth charts, should be Addressing Standards as a required pediatric vital signs included: head required as part of the exchange of standard for the address Data Elements occipital-frontal circumference for patient data. One commenter within the USCDI. We encourage the children less than 3 years of age, BMI recommended adding the nutritional use of standardized elements to percentile per age and sex for youth 2– status Data Element ‘‘mid-arm accurately represent patient address 20 years of age, weight for age per length circumference.’’ Finally, several including use of standardized references and sex for children less than 3 years of commenters suggested or requested in the U.S Post Service Postal age, and the reference range/scale or clarification on the pediatric vital signs Addressing Standards where applicable. growth curve, as appropriate. As Data Elements we proposed (84 FR In addition, we will continue to work explained in section VI.A.2 of this final 7442). Specifically, stakeholders in the with standards developing organizations rule, the inclusion of pediatric vital sign pediatric community asked for to evaluate potential solutions to Data Elements in the draft USCDI v1 clarification of the proposed pediatric improve patient matching, including align with the provisions of the Cures vital sign ‘‘weight for age per length and considering the potential adaptability of Act related to health IT to support the sex for children less than 3 years of the U.S. Postal Service formats for health care of children. Prior to the age,’’ noting it does not correspond to health IT use cases. publication of the Proposed Rule, any existing pediatric growth charts. stakeholders emphasized the value of Rather, they noted that there is a growth The U.S. Postal Service also maintains pediatric vital sign data elements to chart ‘‘weight-for-length’’ for children web based tools for address validation better support the safety and quality of less than 3 years of age. services and provides implementation care delivered to children. We also note guidance to integrate these tools into in our Proposed Rule and in the 2015 Response. We recognize that the technical workflows for IT systems in e- Edition proposed rule (80 FR 16818 and adoption of these Data Elements has the commerce and other industries. We 16819) that the Centers for Disease potential to add burden and cost for agree that these address validation tools Control and Prevention (CDC) some health IT products, but we believe have the potential to greatly improve recommends as part of best practices the the inclusion of these Data Elements can address data quality, and we encourage use of these pediatric vital signs for contribute significantly to the health IT developers and other relevant settings of care in which pediatric and longitudinal care of patients. Pediatric health IT users such as health adolescent patients are seen. The care is not isolated to a single specialty information networks to explore availability of a reference range/scale or or setting of care, and clinicians mechanisms by which such address growth curve would help with proper providing health care for children— validation might support patient interpretation of the measurements for especially those providing care for matching. While not specifically the BMI percentile per age and sex and children with complex conditions—may designed for patient matching and other weight for age per length and sex. practice in a wide range of settings health care related applications, USPS Further, we noted our belief that the using a wide range of health IT systems. address validation has been piloted in inclusion of this health information in Many key stakeholders believe that the these settings. To adapt the address the USCDI v1 was the appropriate next ability to capture, calculate, and validation tool to a health care purpose step after first specifying them as transmit key pediatric growth data using requires the services of a third party optional in the CCDS definition as part health IT is critical to providing care to with licensing of the tool and the of the 2015 Edition rulemaking (80 FR these populations as well as development of a bespoke process to 62695), and as a means of supporting communicating with other providers, execute the tool. The aggregated patient patient access to their EHI in a parent/guardians, and patients. We also address could then be compared against longitudinal format through certified note that adoption of the USCDI the USPS address on file and the patient health IT (see section 3009(e)(2)(A)(i) of standard and its Data Classes and data could be amended where the PHSA as amended by the Cures elements is not specific as to its usage inaccurate, appended where Act). We recognized, however, that within a setting of care, a health care incomplete, or a linked record of certain health IT developers and their specialty, or by a specific category of secondary address data could be created customers may not find these health IT user; rather it applies to depending on the percent of confidence capabilities and information useful. certified health IT’s ability to send and in the specific match. This process Therefore, we requested comment on receive those Data Elements without would then require manual the inclusion of pediatric vital signs in requirements regarding functionality, reconciliation. The results of these the USCDI v1, including the potential user interface, or the use of those Data pilots indicate significant complexity benefits and costs for all stakeholders Elements in exchange. While some users and burden associated with stemming from its inclusion in the may find few opportunities to exchange implementation of this process. Given USCDI v1. these Data Elements, many will these burdens, we believe it would not Comments. Commenters generally exchange these Data Elements be appropriate to require the integration supported the inclusion of the pediatric frequently. As we have noted of this distinct functionality into vital signs Data Elements in the USCDI previously, we believe that the adoption

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00033 Fmt 4701 Sfmt 4700 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 during electronic health information those defined by C–CDA. Some advance interoperability by ensuring exchange. We additionally noted that commenters recommended adding compliance with new data and clinical notes can be composed of text certain note types—including continuity vocabulary codes sets that support the generated from structured (pick-list and/ of care, operative, and nursing notes— data. or check the box) fields as well as while others recommended removing We also appreciate the commenter’s unstructured (free text) data. We some of the proposed note types. In suggestion for an additional Data explained that a clinical note may particular, Laboratory/Pathology Report Element. As we have noted, ONC will include the assessment, diagnosis, plan Narrative note types were thought to be establish and follow a predictable, of care and evaluation of plan, patient duplicative of content in the Laboratory transparent, and collaborative process to teaching, and other relevant data points. Data Class and element Value/Results. expand the USCDI, which will provide We recognized that a number of Some commenters recommended stakeholders with the opportunity to different types of clinical notes could be Imaging Narrative not be used, but advance additional Data Classes and useful for stakeholders. We indicated added to a new Data Class, Diagnostic Data Elements relevant to a wide range our understanding that work is being Tests, which would combine Laboratory of use cases related to health care. done in the community to focus on a and Radiology tests and results. Regarding the request to clarify and subset of clinical notes. We considered Response. We thank commenters for better define these proposed pediatric three options for identifying the their support and recommendations. vital signs, we note that these Data different ‘‘note types’’ to adopt in While we recognize that there may be Elements, as written and proposed, were USCDI v1. The first option we alternative methods of organizing previously included as optional health considered allowed for the community different clinical note types, we believe information in the 2015 Edition CCDS to offer any and all recommended notes. there is value in grouping all clinical definition. The discrepancy between the The second option we considered set a notes into a single Data Class within the adopted pediatric vital signs and minimum standard of eight note types. USCDI. As we noted above and in the standardized pediatric growth charts This option was derived from the eight Proposed Rule, we have adopted the was not identified previously. note types identified by the Argonaut eight note types identified by the Therefore, we wish to clarify that the Project participants.34 The third option Argonaut Project participants because it above-referenced pediatric vital signs we identified looked to the eleven HL7 unites public and private interests include both the vital measurements Consolidated Clinical Document toward the same goal. As we indicated, and the percentiles used in the Architecture (C–CDA) document types the eight selected note types are a following growth charts currently identified in the C–CDA Release 2.1, minimum bar and, in the future, the recommended by the Centers for Disease which also included the note types USCDI could be updated to include Control and Prevention: 33 for infants being identified by the Argonaut Project other clinical note types. The eight birth to 36 months of age: Weight-for- participants. We ultimately proposed selected note types reflect the most length; and head occipital-frontal the second option because it unites clearly and consistently recommended circumference for age; and for children public and private interests toward the set of clinical note type. While a variety 2–20 years of age: Body mass index same goal. We indicated that the eight of additional note types were (BMI) for age. selected note types were a minimum bar recommended, there was no consensus In consideration of these comments, and, in the future, the USCDI could be for additional note types beyond these we have finalized the following updated to include other clinical notes. eight. In consideration of these pediatric Data Elements in the Vital Specifically, we proposed to include the comments, we have finalized the Signs Data Class of the USCDI v1: Head following clinical note types for both clinical notes as a Data Class in the occipital-frontal circumference inpatient and outpatient (primary care, USCDI v1, with only the following eight percentile (Birth to 36 Months); weight- emergency department, etc.) settings in clinical note types for both inpatient for-length percentile (Birth to 36 USCDI v1 as a minimum standard: (1) and outpatient (primary care, emergency Months); body mass index (BMI) Discharge Summary note; (2) History & department, etc.) settings as a minimum percentile (2–20 Years of Age); and the Physical; (3) Progress Note; (4) standard as proposed: (1) Discharge reference range/scale or growth curve, Consultation Note; (5) Imaging Summary Note; (2) History & Physical; as appropriate. Narrative; (6) Laboratory Report (3) Progress Note; (4) Consultation Note; Narrative; (7) Pathology Report (5) Imaging Narrative; (6) Laboratory iv. Clinical Notes Narrative; and (8) Procedures Note (84 Report Narrative; (7) Pathology Report We proposed (84 FR 7442) to include FR 7442). We requested comment on Narrative; and (8) Procedures Note. in the USCDI v1 a new Data Class whether to include additional note We wish to further clarify that we entitled ‘‘clinical notes.’’ ‘‘Clinical types as part of the USCDI v1. have adopted the new Clinical Notes notes’’ was included in the proposed Comments. Commenters broadly Data Class in order to enable capture USCDI v1 based on significant feedback supported adding ‘‘clinical notes’’ as a and exchange of free text clinical from the industry since the 2015 Edition new Data Class to the USCDI v1, in information categorized by the above final rule. We also received similar particular to enable the use of free text clinical note types. We refer feedback during the Trusted Exchange for data exchange. Several commenters commenters to our response in section Framework and Common Agreement requested clarity as to whether the IV.B.1.d of the final rule—Clinical Notes (TEFCA) stakeholder sessions and proposal to adopt this new Data Class C–CDA Implementation Specification— public comment period. As we noted, would require the capture and exchange that addresses the relationship of the ‘‘clinical notes’’ have been identified by of unstructured, or ‘‘raw’’ or ‘‘free’’ text, clinical notes Data Class to C–CDA stakeholders as highly desirable data for narrative clinical information or more implementation specification. interoperable exchange. The free text comprehensive documents such as We also seek to clarify two points. portion of the clinical notes was most First, that these clinical note types are often relayed by clinicians as the data 34 Link to the Clinical Notes Argonaut Project content exchange standard agnostic. identified (to clarify: Seven bullets are listed, They should not be interpreted or they sought, but were often missing however, we split laboratory and pathology note types into their own note) http://wiki.hl7.org/ associated with the specific C–CDA 33 https://www.cdc.gov/growthcharts/index.htm. index.php?title=201805_Clinical_Notes_Track. Document Templates that may share the

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00034 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25675

same name. Secondly, we clarify that provenance Data Elements, such as the available and after ONC has consulted at these note types are required to be identity of the individual or entity the least five CEHRT developers. represented in their plain-text form data was obtained from or sent by Response. We acknowledge that these when included in various content (sometimes discussed in standards Data Elements may not be able to fully exchange standards (e.g., C–CDA, FHIR) working groups as the provenance of the support the needs of all use cases, but as may be applicable to the certification data’s ‘‘last hop’’), would be essential to we believe their adoption will improve criteria in which the USCDI is include as part of the USCDI v1 the trustworthiness and reliability of referenced. standard. We acknowledged that there is data being exchanged. For this Data currently work to help define Class, it appears that many commenters v. Provenance provenance in a standard robust over-interpreted our proposal and the We proposed (84 FR 7442) for the manner, and that we anticipated effect of having these data in the USCDI. USCDI v1 to include a new Data Class, adopting the industry consensus once it As we noted earlier, the adoption of the entitled ‘‘provenance.’’ As we indicated, became available. USCDI standard and its Data Classes stakeholders 35 have identified Comments. Commenters and elements is not specific as to its ‘‘provenance’’ as valuable for overwhelmingly supported the addition usage within a setting of care, a health interoperable exchange. Stakeholders of provenance as a new Data Class for care specialty, or by a specific category also referenced the provenance of data USCDI v1. Several commenters stated of health IT user. Rather it applies to as a fundamental need to improve the that the proposed elements were certified health IT’s ability to send and trustworthiness and reliability of the insufficient for the purpose of audit logs receive those Data Elements without data being exchanged. Provenance for use and disclosure of health data, requirements regarding functionality, describes the metadata, or extra citing the existing standard specification user interface, or the use of those Data information about data, that can help ASTM E2147.36 Other commenters Elements in exchange. Therefore, with answer questions such as who created stated that these proposed elements did respect to our reference to provenance the data and when. not apply to all use cases of exchanged data in the USCDI, we have no preset In the Proposed Rule, we noted that data and requested clarification notion or explicit upfront requirement the inclusion of ‘‘provenance’’ as a Data regarding applicability, including for how this data should be used. We Class in the USCDI v1 would also whether provenance would have to be believe that having provenance data is complement the Cures Act requirement created for elements created before the highly impactful, essential for in section 4002(a) to support the implementation deadline of USCDI v1. trustworthy interoperability, and will exchange of data through the use of Because this is a new Data Class, some generate greater value for stakeholders APIs. This approach differs from the commenters also requested additional as they identify new ways to put this exchange of data via the C–CDA. While time to adopt and implement this new data to use. C–CDAs are often critiqued due to their requirement. Some commenters stated Regarding ‘‘author’’ as a Data Element relative ‘‘length,’’ the C–CDA represents that there could be ambiguity in within the provenance Data Class, we the output of a clinical encounter and designating ‘‘author’’ for certain clinical agree that significant practical scope includes relevant context. The same will information such as patient-reported challenges may arise. Our analysis of not always be true in an API context. medications, while in certain other the concerns raised by commenters APIs facilitate the granular exchange of cases, there could be multiple authors identified a risk of unintended burden data and, as noted in the original 2015 for the same clinical information, such and potential risk of error and Edition final rule, offer the potential to as clinical notes. Additionally, some misattribution associated with this aggregate data from multiple sources commenters suggested that the ‘‘author’’ particular Data Element. In most use using a web or mobile application (80 be limited to only a limited set of Data cases, the inclusion of author FR 62675). The inclusion of provenance Elements and not to all the Data organization and author time stamp is would help retain the relevant context Elements. Another commenter sufficient to convey provenance. As a so the recipient can better understand specifically addressed several concerns result, we have not finalized the the origin of the data. related to the definition of ‘‘author’’ for ‘‘author’’ as a required Data Element We proposed to further delineate the this purpose. Commenters specifically within the provenance Data Class in provenance Data Class into three Data stated they understood author to be the USCDI. However, we understand that Elements: ‘‘the author,’’ which person entering the data into the EHR, for exchanging certain data elements, represents the person(s) who is but noted that data may also be such as ‘‘clinical notes,’’ it is critical to responsible for the information; ‘‘the historical, captured from a device, also send the ‘‘author’’ information if author’s time stamp,’’ which indicates started by a patient and completed by available. Our analysis of the various the time the information was recorded; clinical staff, entered by a patient, content exchange standards and and ‘‘the author’s organization,’’ which entered by resident/students working specifications (e.g., C–CDA and FHIR) would be the organization the author is under a supervising physician, or indicates that even though the ‘‘author’’ associated with at the time they reported by a patient. The commenter Data Element is not explicitly required interacted with the data (84 FR 7442). noted that there are additional in USCDI, the health IT specifications in We indicated that we identified these documentation scenarios such as which USCDI Data Elements are three Data Elements as fundamental for dictation to scribes or other medical represented also set specific data data recipients to have available and staff, which conflate ‘‘responsibility’’ for element requirements for certain noted that they are commonly captured authorship, and that defining author for contexts. For example, in the context of and currently available through every Data Element can be complex. clinical notes, these content exchange standards. We requested comment on Finally, one health IT developer standards require health IT systems to the inclusion of these three Data recommended a 36-month be capable of exchanging ‘‘author’’ Elements and whether any other implementation period to begin only information when it is available. after test procedures, implementation Further, ‘‘author’’ is treated as a ‘‘Must 35 https://www.healthit.gov/topic/interoperability/ guides, and test and validation tools are Support’’ data element in the FHIR US trusted-exchange-framework-and-common- Core Implementation Guide STU 3.1.0 agreement. 36 https://www.astm.org/Standards/E2147.htm. and has a ‘‘SHALL’’ constraint (with

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00035 Fmt 4701 Sfmt 4700 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– This would also be consistent with the entire USCDI, a USCDI Data Class, or CDA 2.1. As we have noted previously, C–CDA 2.1 ‘‘Allergy and Intolerance’’ some or all of the Data Elements within we believe that the proposed 24-month section. a given Data Class or classes. We further timeline for updating certified health IT Response. We thank the commenters indicated that, to our knowledge, all to comply with the new USCDI standard for their input. While we appreciate that Data Classes in the USCDI v1 can be in § 170.213 is an adequate there may be some risk associated with supported by commonly used ‘‘content implementation timeline and will the adoption of a new Data Element, we exchange’’ standards, including HL7 C– maintain this requirement as finalized believe this alternative approach better CDA Release 2.1 and FHIR. earlier in this section. aligns with other standards representing We received no comments on this Therefore, in consideration of the substance reactions, including specific proposal and we have finalized comments received, we have finalized medication allergies, and this alignment our proposal to make USCDI v1 agnostic the provenance Data Class in the USCDI enhances patient safety. Additionally, as to ‘‘content exchange standard’’ as v1 and the following two Data Elements: we agree with the commenter who described. • ‘‘author time stamp,’’ which suggested renaming this new Data Class 2. Clinical Notes C–CDA indicates the time the information was to align with FHIR and C–CDA Implementation Specification recorded; and approaches. • ‘‘author organization,’’ which In consideration of comments, we In conjunction with our proposal to would be the organization the author is have finalized the creation of a Data adopt the USCDI v1, we proposed to associated with at the time they Class in USCDI v1 entitled ‘‘Allergies adopt the HL7 CDA® R2 IG: C–CDA interacted with the data. and Intolerances,’’ instead of Templates for Clinical Notes R1 We believe these two provenance Data ‘‘Substance Reactions’’ from the original Companion Guide, Release 1 in Elements, ‘‘author organization’’ and USCDI v1 proposal. The Allergies and § 170.205(a)(5) (‘‘C–CDA Companion ‘‘author time stamp,’’ within the USCDI Intolerances Data Class in USCDI v1 Guide’’). The C–CDA Companion Guide v1, which are also used in the C–CDA consists of the following Data Elements: provides supplemental guidance and and FHIR-based certification criteria we ‘‘Substance—(Medication),’’ additional technical clarification for have adopted that incorporate the ‘‘Substance—(Drug Class),’’ and specifying data in the C–CDA Release USCDI, will serve as a foundation on ‘‘Reaction.’’ ‘‘Substance—(Medication)’’ 2.1.37 As we noted in the Proposed Rule which industry stakeholders can must be represented by RxNorm codes (84 FR 7443), the proposed USCDI v1 subsequently work together to build out and ‘‘Substance—(Drug Class)’’ must be included new Data Classes, such as additional provenance data represented by SNOMED CT codes. The ‘‘clinical notes,’’ which were further requirements in the USCDI. As noted addition of the ‘‘Substance—(Drug supported through the C–CDA above, we have not finalized the Class)’’ better represents when an Companion Guide. For example, the C– proposed Data Element ‘‘the author,’’ individual may have a reaction to an CDA Companion Guide provides which represents the person(s) who was entire drug class as opposed to a specifications for clinical notes by responsible for the information. specific medication. Additionally, we indicating that clinical notes should be believe having the Allergy and recorded in ‘‘note activity’’ and requires vi. Medication Data Request for Intolerances Data Class separated from references to other discrete data, such as Comment the Medication Class will accommodate ‘‘encounters.’’ The C–CDA Companion In the Proposed Rule, we proposed potential additions of other substance Guide also enhances implementation of (84 FR 7443) that the USCDI v1 Data Elements such as food, the updated 2015 Edition certification ‘‘Medication’’ Data Class include two environmental, and biologic agents. The criteria that reference the C–CDA constituent Data Elements within it: Data Element ‘‘Reaction’’ is meant to Release 2.1 (§ 170.205(a)(4)). As noted Medications and Medication Allergies. include, but is not limited to, by stakeholders, the C–CDA Release 2.1 With respect to the latter, Medication medication allergies. As the USCDI is includes some optionality and Allergies, we requested comment on an updated over time to include substances ambiguity with respect to Data Element alternative approach. This approach other than medications, we can also see components, such as the locations and would remove the Medication Allergies the need to have substance reactions value sets. We attempted to address Data Element from the Medication Data updated as part of this Data Class. To some of this optionality by clarifying Class and add it to a new Data Class reflect this change, we have updated the requirements using Certification titled ‘‘Substance Reactions,’’ which terminology in the regulatory text in Companion Guides (CCGs) 38 and by would include the concept of § 170.315 to remove ‘‘medication specifying in the CCDS definition where ‘‘Medication Allergies.’’ The new allergy’’ and replace with ‘‘allergy and certain data should be placed in the C– ‘‘Substance Reactions’’ Data Class intolerance.’’ CDA Release 2.1 templates (e.g., ‘‘goals’’ would include the following Data in the goals section).39 The C–CDA Elements: ‘‘Substance’’ and ‘‘Reaction,’’ c. USCDI Standard—Relationship to Companion Guide, which was released and include SNOMED CT as an Content Exchange Standards and in August, 2015, provides similar, but additional applicable standard for non- Implementation Specifications additional C–CDA implementation medication substances. In recognition of the evolution of structure. For example, race and Comments. The majority of standards over time and to facilitate ethnicity are required Data Elements in commenters supported the creation of a updates to newer versions of standards, the USCDI and must be included in C– new Data Class ‘‘Substance Reactions’’ we proposed (84 FR 7443) that the CDA exchanges if known, or they may but requested we preserve the USCDI v1 (§ 170.213) would be agnostic be marked with a nullFlavor value Medication Allergy element because of as to ‘‘content exchange’’ standard. As ‘‘UNK’’ (unknown) if not known. The patient safety concerns related to the we noted, the USCDI v1 establishes adoption of an entirely new Data ‘‘data policy’’ and does not directly 37 http://www.hl7.org/implement/standards/ _ _ Element. One commenter supported the associate with the content exchange product brief.cfm?product id=447. 38 https://www.healthit.gov/topic/certification- change but recommended the new Data standards and implementation ehrs/2015-edition-test-method. Class name be aligned with the HL7 specifications which, given a particular 39 https://www.healthit.gov/sites/default/files/ FHIR resource ‘‘AllergyIntolerance.’’ context, may require the exchange of the topiclanding/2018-04/2015Ed_CCG_CCDS.pdf.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00036 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25677

C–CDA Release 2.1 is unclear on the documents are the same except for the requirements. The Health Level 7 (HL7) location and value set, but the C–CDA document header. Two commenters CDA R2 Implementation Guide: C–CDA Companion Guide clarifies the location recommended review of the Common Supplemental Templates for Unique and value set. We noted in the Proposed Well Concise Consolidated CDA white Device Identification (UDI) for Rule that the adoption of the C–CDA paper. Implantable Medical Devices, Release Companion Guide would align with our Response. We thank the commenters 1–US Realm (UDI IG Release 1), goal to increase the use of consistent for their suggestions and support. identifies changes needed to the C–CDA implementation of standards among During the past few months, industry to better facilitate the exchange of the health IT developers and improve stakeholders updated the C–CDA individual UDI components in the interoperability. We proposed to adopt Companion Guide to a newer version to health care system when devices are this C–CDA Companion Guide to best address how clinical notes should implanted in a patient. The UDI support best practice implementation of be handled in the C–CDA. In components include the Device USCDI v1 Data Classes and 2015 Edition consideration of the update to the C– Identifier (DI) and the following certification criteria that reference C– CDA Companion Guide and the individual production identifiers: The CDA Release 2.1 (§ 170.205(a)(4)). The comments, we have finalized the lot or batch number, serial number, criteria include: adoption of the most up-to-date version, manufacturing date, expiration date, • ‘‘transitions of care’’ HL7 CDA R2 IG: C–CDA Templates for and distinct identification code. As this (§ 170.315(b)(1)); Clinical Notes STU Companion Guide, new IG had been recently published, we • ‘‘clinical information reconciliation Release 2 in § 170.205(a)(5) (‘‘C–CDA requested comment on whether we and incorporation’’ (§ 170.315(b)(2)); Companion Guide’’) and have should add this UDI IG as a requirement • ‘‘care plan’’ (§ 170.315(b)(9)); incorporated by reference in § 170.299. in § 170.299(f)(35) for health IT to adopt • ‘‘view, download, and transmit to This includes adoption of the USCDI v1 in order to meet the requirements for 3rd party’’ (§ 170.315(e)(1)); and the associated Data Classes. content exchange using C–CDA. In • ‘‘consolidated CDA creation In order to align ‘‘clinical information addition, we indicated that we did not performance’’ (§ 170.315(g)(6)); and reconciliation and incorporation’’ have a reliable basis on which to • ‘‘application access—all data (§ 170.315(b)(2)) with the updated Data estimate how much it would cost to request’’ (§ 170.315(g)(9)). Classes in the USCDI v1 as proposed in meet the requirements outlined in the We proposed, as a Maintenance of 84 FR 7441, we have replaced the UDI IG; and, therefore, we requested Certification requirement for the real ‘‘medication allergies’’ data element in comment on the cost and burden of world testing Condition of Certification § 170.315(b)(2)(iii)(D)(2) criterion to complying with this proposed requirement, that health IT developers ‘‘Allergies and Intolerances’’ Data Class requirement. with health IT certified to the six above- and require reconciliation of all the data Comments. Commenters unanimously identified certification criteria prior to elements in ‘‘Allergies and supported adoption of the UDI IG the effective date of a subsequent final Intolerances’’ Data Class, which Release 1 as a new requirement for rule would have to update such certified includes Substance (Medication), health IT to meet the requirements for health IT to the proposed revisions (84 Substance (Drug Class), and Reaction the USCDI UDI Data Class. One FR 7443).40 We further proposed as a Data Elements. We have revised the commenter requested additional Maintenance of Certification regulation text (§ 170.315(b)(2)) to align guidance regarding the determination of the ‘‘person responsible for the requirement for the real world testing with this change. We decline to accept information’’ contained in the ‘‘Device’’ Condition of Certification requirement, the recommendation to adopt the entry. None of the commenters provided that health IT developers would be CommonWell specification as we a basis of estimate for the cost to meet required to provide the updated believe the criterion is best met the requirements outlined in the UDI IG certified health IT to all their customers following the C–CDA specification published by HL7. Release 1. with health IT previously certified to Response. We thank the commenters the identified criteria no later than 24 We have additionally finalized the timeline for the update to the use of the for their support. As we noted earlier, months after the effective date of a final the adoption of the USCDI standard and rule (84 FR 7443). For the purposes of C–CDA companion guide of 24 months after the publication date of this final its Data Classes and elements is not meeting that compliance timeline, we specific as to its usage within a setting indicated that we expected health IT rule for the following criteria: • of care, a health care specialty, or by a developers to update their certified ‘‘transitions of care’’ (§ 170.315(b)(1)); specific category of health IT user; health IT without new mandatory • rather it applies to certified health IT’s testing and notify their ONC–ACB on ‘‘clinical information reconciliation and incorporation’’ (§ 170.315(b)(2)); ability to send and receive those Data the date at which they have reached • Elements without requirements compliance. Developers would also ‘‘care plan’’ (§ 170.315(b)(9)); • ‘‘view, download, and transmit to regarding functionality, user interface, need to factor these updates into their 3rd party’’ (§ 170.315(e)(1)); or the use of those Data Elements in next real world testing plan as discussed • ‘‘consolidated CDA creation exchange. Therefore, we do not specify in section VII.B.5 of the Proposed who must enter such data. 41 performance’’ (§ 170.315(g)(6)); and Rule. • ‘‘application access—all data We note also that the C–CDA Comments. One commenter request’’ (§ 170.315(g)(9)). Companion Guide referenced in supported the use of C–CDA for Clinical subsection (d) below of this final rule Notes. One commenter sought clarity on 3. Unique Device Identifier(s) for a now includes the content of the UDI IG testing for Clinical Notes conformance Patient’s Implantable Device(s) C–CDA Release 1 named in the Proposed Rule. to C–CDA 2.1, noting that all C–CDA Implementation Specification In consideration of comments, we have We noted in the Proposed Rule (84 FR finalized the proposed UDI Data Class 40 We proposed to codify this requirement in 7443) our awareness of a recently within the USCDI v1, and have adopted § 170.405(b)(4) (84 FR 7596). the UDI Organizer Template defined in 41 The finalized real world testing plan published implementation guide (IG) by requirements, codified in § 170.405(b)(2) are HL7 that provides further guidance on the UDI IG Release 1 and subsequently discussed in section VII.B.5 of this final rule. the unique device identifier (UDI) published as Appendix B of the HL7®

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00037 Fmt 4701 Sfmt 4700 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 based on stakeholder feedback and CMS 2017071 transactions are inaccurate. To Clinical Notes, Release 2.1 Companion policies at the time. the extent that a pharmacy conducts Guide, Release 2—US Realm, October In addition to continuing to reference electronic prescribing with prescribers 2019, as a new requirement for Health the current transactions included in e-prescribing Part D covered drugs for IT Modules to meet the requirements for § 170.315(b)(3), in keeping with CMS’ Part D eligible individuals, those C–CDA-based exchange. We note that Modernizing Part D and Medicare pharmacies are required to use the the UDI Organizer Template, though Advantage To Lower Drug Prices and NCPDP SCRIPT version 2017071 subsequently published in Appendix B Reduce Out-of-Pocket Expenses final standard. While there may not be 2015 of the HL7 CDA R2 IG: C–CDA rule (84 FR 23832), we also proposed in Edition certification criteria to which Templates for Clinical Notes STU 84 FR 7445 and in § 170.315(b)(11) to pharmacy information systems can be Companion Guide, Release 2, September require the support of all of the NCPDP certified, the Part D rules require 2019, remains substantially unchanged SCRIPT standard version 2017071 support of the standard under the Part from its previous publication in the UDI transactions CMS has adopted for the D E-prescribing Program. Thus, we IG Release 1 in November 2018 and has Part D E-prescribing regulations in 42 believe the mismatch concerns raised by been thoroughly reviewed and subjected CFR 423.160(b)(2)(iv). Given the January commenters are unfounded. As a to balloting and a public comment 1, 2020 effective date in CMS general matter, Part D prescribers need process. rulemaking (83 FR 16440) and the health IT systems capable of conducting effective date of this final rule, we have compliant transactions (regardless of 4. Electronic Prescribing Criterion finalized our proposed update to the ONC certification) and so too do Part D new version of the standard for the We proposed to adopt a new version receiving pharmacies. ONC health IT electronic prescribing criterion in of the NCPDP SCRIPT standard in 45 certification will provide an added layer § 170.315(b)(3) instead of creating a new CFR 170.205(b)(1), specifically NCPDP of assurance for Part D prescribers that criterion as proposed in 84 FR 7427 in SCRIPT standard version 2017071 (84 their e-Rx systems have been tested and § 170.315(b)(11). Unlike other criteria in FR 7444). Because we proposed to adopt certified as being capable of accurately this final rule that allow testing to either a new standard for electronic conducting the adopted NCPDP SCRIPT version of a required standard until 24 standard version 2017071 prescribing (e-Rx), we also proposed to months after the publication date of this transactions.42 adopt a new certification criterion in final rule, we will not allow certification In addition, we received several § 170.315(b)(11) for the proposed e-Rx testing to version 10.6 of the NCPDP comments related to the readiness of PIS standard to replace the old standard in SCRIPT standard, as the implementation for specific transactions beyond those § 170.315(b)(3). The proposed new date for CMS’ new Part D E-prescribing defined for Part D. We include these certification criterion reflected our Program of January 1, 2020 has passed. comments as applicable in the proposed adoption of NCPDP SCRIPT However, based on stakeholder discussion of each transaction below. standard version 2017071 as well as all feedback, we have finalized a transition We reiterate that PIS are outside the transactions adopted for the CMS period in 45 CFR 170.405(b)(4)(ii) of 24 scope of the ONC Health IT Certification Medicare Part D E-prescribing Program months from the date of publication of Program, and we acknowledge the (84 FR 23832). These proposals were this final rule for certification so challenge of pharmacy readiness to made to realign ONC’s Health IT developers may test and certify to the support all transactions at this time, but Certification Program (Program) policies updated criterion with all associated if they conduct e-Rx for part D covered with those of CMS’ Part D E-prescribing transactions. drugs prescribed to Part D eligible rules. ONC and CMS have historically Comments. The majority of Medicare beneficiaries, they will be aligned standards adopted under their commenters were supportive of our required to use the standard we are programs such as those for e-Rx and proposal and recommended moving to adopting for our program by the medication history (MH) to ensure that the NCPDP SCRIPT standard version Medicare Part D e-Rx Program—so if entities regulated under both schemes 2017071 for the e-Rx certification they do e-prescribing at all, we expect can comply with the different programs’ criterion in alignment with CMS’ that they will be able to conduct requirements. For this reason, we stated adoption of the standard for the Part D transactions using the standard adopted that should our proposal to adopt the E-prescribing Program. However, a here. Generally, the goal of certification new e-Rx criterion (§ 170.315(b)(11)) be number of commenters expressed is to ensure that Health IT Modules finalized prior to January 1, 2020, we concern that while EHRs or other voluntarily submitted for the Program also proposed to permit continued electronic prescribing systems may are capable of conducting the certification to the current 2015 Edition become certified, pharmacy information transactions as specified. This ensures ‘‘electronic prescribing’’ criterion systems (PIS) lack a similar certification that providers have the capability to use (§ 170.315(b)(3)) that references NCPDP program and associated standards and the certified product for these SCRIPT standard version 10.6 for the technical capability requirements, thus transactions where feasible. For this period of time in which that version of creating a mismatch between the e- reason, we have finalized the the NCPDP SCRIPT standard would prescribing system requirements for transactions as described below for continue to be used in the CMS EHR users and PIS users. Several certified Health IT Modules and Medicare Part D E-prescribing Program commenters specifically noted that PIS, encourage pharmacy information system or the CMS Promoting Interoperability which send or receive these developers to advance their capacity to Programs. Finally, we proposed in 84 transactions, are not required to adopt support a nationwide network of fully FR 7445 that once NCPDP SCRIPT the capability to support these interoperable pharmacy information standard version 10.6 is no longer used transactions as they are out of scope for systems. in those Programs, we would no longer the Program. Comments. As noted, the majority of permit certification to that criterion and Response. First, we note that the commenters were supportive of the would remove it from the Code of comments suggesting that pharmacies proposal to remove the 2015 Edition Federal Regulations, and that we would on the sending or receiving end of Part consider setting an effective date for D e-Rx transactions are not required to 42 https://www.govinfo.gov/content/pkg/FR-2015- such actions in a subsequent final rule utilize NCPDP SCRIPT standard version 10-16/pdf/2015-25597.pdf.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00038 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25679

certification criterion (codified in their products to use the NCPDP scope, that these 24 months from the § 170.315(b)(3)) that references NCPDP SCRIPT standard version 2017071 to date of publication from this final rule SCRIPT standard version 10.6 and meet CMS’ compliance requirements enable continued compliance and replace it with an updated e-Rx criterion . . .’’ This guidance also noted that oversight associated with other (proposed to be codified in ONC would discontinue certification of capabilities in § 170.315(b)(3) that are § 170.315(b)(11)). Commenters new products to the electronic not applicable for Part D, and for which requested that ONC work with CMS on prescribing certification criterion using conformance is still required. a smooth transition and timeline that version 10.6 of the NCPDP SCRIPT We have finalized this 24-month would allow adequate time for the standard as of January 1, 2020. period for the update for this criterion development, testing, and full adoption In consideration of the comments we under the real world testing provisions of these updates. A number of received, we have finalized our proposal in § 170.405(b)(5) as follows: commenters stated that the NCPDP to update the electronic prescribing (e- • Electronic Prescribing. A health IT SCRIPT standard version 2017071 is not Rx) NCPDP SCRIPT standard used for developer with health IT certified to backward compatible with NCPDP electronic prescribing in the 2015 § 170.315(b)(3) prior to June 30, 2020, SCRIPT standard version 10.6, and Edition to NCPDP SCRIPT standard must: therefore there should be no transition version 2017071, which results in a new Æ Update their certified health IT to period where both standards are e-Rx standard becoming the baseline for be compliant with the revised versions applicable. Commenters sought clarity certification. As the effective date of this of this criterion adopted in on the timing of the change and final rule will occur after January 1, § 170.315(b)(3)(ii); and 2020, we have not finalized our expressed concerns that developers and Æ Provide its customers of the proposal to permit new products to providers may face operational issues in previously certified health IT with continue to be certified to the prior their adoption of version 2017071 of the certified health IT that meets paragraph standard until the January 1, 2020 date. NCPDP SCRIPT standard by January 1, (b)(5)(i) of this section by May 2, 2022. 2020. Commenters recommended that Instead, we discontinued certification of ONC allow certification timelines that new products to the former electronic a. Electronic Prescribing Standard and support compliance with Part D while prescribing criterion using the NCPDP Certification Criterion SCRIPT standard version 10.6 to align allowing adequate time to mitigate the Comments. Commenters expressed with CMS requirements. We have risk associated with the additional concerns about standardization requirements for certification to the finalized this update as a modification to the existing certification criterion generally within the context of e- proposed criterion. prescribing. Several commenters Response. We appreciate the support rather than as a separate new certification criterion to allow for a expressed concern about using the expressed by commenters as well as the NCPDP SCRIPT standard version concern about maintaining alignment smooth transition, and to allow for continuity with the certification(s) 2017071, the RxNorm standard, as a between required standards across HHS. requirement for e-prescribing, and other We note that the CMS requirement for issued to Health IT Modules for § 170.315(b)(3) prior to January 1, 2020 standards such as Fast Healthcare Part D e-Rx transactions includes a Interoperability Resources (FHIR). One compliance date of January 1, 2020, and that are updated under the ONC guidance. This approach will also commenter further stated that only that industry feedback notes a inventory (packaging or unit dose consistent and deliberate move toward continue to allow for compliance with the January 1, 2020 timeline for CMS’ strength) codes are standardized in readiness for the adoption of the new Medicare Part D e-Rx and Medication RxNorm, and that drug regimens should standard for Part D e-Rx, including by History standards. be standardized and made computable health IT industry leaders supporting As noted by commenters, we in RxNorm for safety reasons. Another pharmacy implementation. We believe understand that there is a lack of commenter noted that RxNorm does not that this overall industry readiness backward compatibility between the index brand names exhaustively with a supports our adoption of the update to two standards. In order to allow for a single unique ID for each branded drug, the standard for certification purposes reasonable transition period to but that current indexing only allows for and to be in alignment with the required certification to the full set of NCPDP generic-level interoperability and only standard update for Part D e-Rx SCRIPT transactions and other at unit dose level. One commenter purposes. In response to the request for requirements defined in the updated e- expressed concern that the criterion as a smooth transition and continuity of Rx certification criterion, we have proposed does not appear to support certification for health care providers, framed our Maintenance of Certification medication assisted treatment (MAT) for we have finalized a revision to the in section 45 CFR 170.405(b)(5)(ii) with opioid use disorder (OUD) and other existing criterion in § 170.315(b)(3) flexibility that will allow health IT long-acting medications. Another rather than removing and replacing the developers up to 24 months from the commenter stated a hope that standards criterion. In order to support the date of publication of this final rule to such as the NCPDP SCRIPT version transition to the new standard for Part test and certify to the updated criterion 2017071 standard can ease data D, at the request of stakeholders, ONC reflective of all NCPDP SCRIPT 2017071 integration into the workflow, lessen issued guidance 43 in the third quarter of transactions to demonstrate full burden, and help achieve greater CY2019 stating, ‘‘. . . developers of conformance with the updated criterion. compliance with policy and legal 2015 Edition certified Health IT After January 1, 2020, use of the NCPDP requirements for querying State Modules certified to the e-prescribing SCRIPT 10.6 standard will be prohibited prescription drug monitoring programs criterion adopted at 45 CFR under the Part D program, so we do not (PDMP). Another commenter supported 170.315(b)(3) are permitted to update expect or anticipate health IT systems the adoption of the NCPDP SCRIPT certified to § 170.315(b)(3) will conduct standard version 2017071 because the 43 For Part D covered drugs prescribed for Part D Part D transactions using that standard. standard supports the prescribing of eligible individuals. ONC Electronic Prescribing Certification Companion Guide: https:// We also recognize, however, for the compound medications and the sig (i.e., www.healthit.gov/test-method/electronic- purposes of maintaining a product instructions) field is not limited to 140 prescribing. certificate with § 170.315(b)(3) in its characters.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00039 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25680 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

Some commenters also provided indicator that the receiving entity must transactions to specify which suggestions to improve the NCPDP evaluate for accurate reporting. We are transactions are finalized as required for SCRIPT 2017071 standard and its also aware that many PDMPs across the Health IT Modules for purposes of availability to the public by the country accept reporting of medication obtaining or retaining certification to standards developing organization. history transactions containing § 170.315(b)(3), which are optional for Another commenter stated that today’s buprenorphine, naltrexone, and other Health IT Modules for purposes of NCPDP standards are not in an API- medications that could be used in the obtaining or retaining certification to ready format, and recommended CMS treatment of OUD. § 170.315(b)(3), and any other and ONC collaborate with NCPDP to We thank commenters for their input § 170.315(b)(3) requirements below. explore API FHIR standards specific to related to improvements that could be Additional public comment received the HL7 Da Vinci Project for a January made to the NCPDP SCRIPT version and related responses are grouped 2022 effective date or later. A few 2017071 standard, however NCPDP is a below based on the comment’s relation commenters stated that because many member-driven standards developing to the specific transactions. We note that NCPDP standards are not openly organization that requires membership ‘‘optional’’ for the purposes of accessible and require a paid in order to participate in standards certification does not mean, and should membership to obtain the technical developing and to access standards and not be interpreted as, ‘‘optional’’ for Part specifications, our adoption could limit implementation guides. We appreciate D E-prescribing Program compliance. To widespread adoption and a the suggestion to provide a direct link the extent that prescribers and standardized implementation to the appropriate NCPDP SCRIPT pharmacies conduct electronic nationwide. Several commenters standard implementation guide, but we prescribing with Part D covered drugs suggested that ONC adopt FHIR as a have no authority over the business prescribed for Part D eligible standard for the Program, and for the e- processes of standards developing individuals they will be required to use Rx criterion specifically. We also organizations like NCPDP. We the NCPDP SCRIPT 2017071 standard to received several comments that are out encourage any and all participants with conduct those transactions under the of scope which are not addressed in this an interest in improving the standard to Part D E-prescribing Program. Thus, a rulemaking. engage with NCPDP. Regarding the transaction designated as ‘‘optional’’ for Response. We appreciate the recommendation for ONC to collaborate the purposes of certification means a commenters’ consideration of the with NCPDP to explore FHIR, we health IT developer can elect to have standards. We note that RxNorm is a appreciate the suggestion and support that transaction explicitly tested as part standard maintained by the National any advancements in technical of certification for its product or can Library of Medicine (NLM). ONC standards and frameworks that support choose not to do so—either will allow adopted RxNorm to represent interoperability. At this time, NCPDP its product to be certified to medication information as a vocabulary SCRIPT standard version 2017071 has § 170.315(b)(3). We reiterate that standard in § 170.207(d) (80 FR 62612). not been mapped to FHIR, but ONC will comments regarding CMS’ January 1, We encourage all developers who have continue to monitor the industry for 2020 timeline are out of scope as we experience with, and feedback relevant opportunities to align the ONC Health cannot change CMS’ policy or its to, RxNorm to contact NLM. As a IT Certification Program with industry timeline. reminder, RxNorm is considered a developments. minimum standard code set under the Comments. Five commenters fully b. Electronic Prescribing Transactions Program, and developers are permitted supported all proposed transactions and In addition to adopting the NCPDP to upgrade their products to comply requirements detailed in the Proposed SCRIPT version 2017071 standard for with a newer version of RxNorm Rule. The vast majority of commenters the transactions that are listed in the without adversely affecting a product’s noted concerns about the proposed current ‘‘electronic prescribing’’ certification status pursuant to 45 CFR criterion specific to the transactions criterion (§ 170.315(b)(3)), we also 170.555(b)(2) as long as no other law proposed for adoption in the proposed to adopt and require prohibits such action. § 170.315(b)(11) e-Rx certification conformance to all of the NCPDP In reference to the OUD prevention criterion; details in support or not in SCRIPT version 2017071 standard and treatment-related concerns that support of adoption as proposed are transactions CMS adopted in 42 CFR commenters expressed, we note that the further detailed for each type of 423.160(b)(2)(iv). We proposed this NCPDP SCRIPT 2017071 standard does transaction below. As a whole, the updated 2015 electronic prescribing support the exchange of medicines used primary concerns for the transactions criterion to therefore include the in medication-assisted treatment (MAT) and requirements as proposed include following transactions: for opioid use disorder treatment the following: (1) EHRs are required to i. Create and Respond to New purposes. An electronic prescription of comply with the new transactions and controlled substances transaction requirements, while receiving pharmacy Prescriptions (NewRx, NewRxRequest, containing a MAT drug such as information systems are not; (2) lack of NewRxResponseDenied) buprenorphine can be sent from a pharmacy adoption and readiness, as We proposed in 84 FR 7444 to enable prescriber to a pharmacy through the sufficient adoption should occur prior a user to perform the related electronic specified transactions, and the updated to making the transactions required; and transactions for NewRx, NewRxRequest § 170.315(b)(3) criterion also requires (3) implementation of the proposed and NewRxResponseDenied. A NewRx the inclusion of a reason for the transactions and requirements is transaction is a new prescription from a prescription using resource intensive, if not prohibitive, in prescriber to a pharmacy so that it can or order to meet the January 1, 2020 be dispensed to a patient. A elements, or optionally, the technology deadline set by CMS. Several NewRxRequest is a request from a must be able to receive and transmit the commenters suggested either an pharmacy to a prescriber for a new reason for the prescription using the extension or that certain transactions prescription for a patient. A element. In should be made optional. NewRxResponseDenied is a denied addition, the RxHistoryRequest Response. We appreciate all of the response to a previously sent transaction contains a patient consent public comments and have modified the NewRxRequest (if approved by the

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00040 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25681

prescriber, a NewRx would be sent Comments. Most commenters adoption in place before it is a instead). A NewRxResponseDenied supported the proposed adoption of the certification requirement. response may occur when the RxChangeRequest and Response. We thank commenters for NewRxRequest cannot be processed or if RxChangeResponse transactions. One their overall support of the proposed information is unavailable. commenter recommended against CancelRx and CancelRxResponse Comments. While the NewRx adoption until industry adoption is transactions. In light of the commenters’ transaction received unanimous support more widely spread across retail overall support for the proposed as a required transaction for adoption in pharmacies and demonstrates value. CancelRx transactions and in order to the updated § 170.315(b)(3) criterion, Response. Because the majority of support patient safety and the free flow the vast majority of commenters commenters were in support of of communication between prescribers opposed adopting the NewRxRequest adoption of the RxChangeRequest and and pharmacies, we have included these and NewRxResponseDenied RxChangeResponse transactions as transactions as required in the revised transactions as required transactions proposed, we have included these § 170.315(b)(3) electronic prescribing primarily due to a lack of adoption by transactions as required in the updated criterion. We reiterate that although PIS the PIS involved in the exchange. § 170.315(b)(3) electronic prescribing are outside the scope of the ONC Health Several commenters stated that the criterion. Additionally, we note that IT Certification Program, we encourage NewRxRequest and pursuant to the certification criterion, pharmacy information system NewRxResponseDenied is not yet in health IT presented for certification developers to advance their capacity to broad use. A commenter who supported must be capable of including the reason support a nationwide network of fully adoption of NewRxRequest and for the prescription as referenced in the interoperable PIS. Additionally, we note NewRxRequestDenied believed that updated § 170.315(b)(3)(ii) or that pursuant to the certification they may be beneficial for electronic § 170.315(b)(3)(ii)(D) in the criterion, health IT presented for prescribing of controlled substances RxChangeRequest and certification must be capable of (EPCS) and noted that pharmacies have RxChangeResponse transactions. including the reason for the prescription expressed interest in implementation. as referenced in the updated iii. Request and Respond to Cancel § 170.315(b)(3)(ii) or Response. In consideration of public Prescriptions (CancelRx, § 170.315(b)(3)(ii)(D) in the CancelRx comments, we have adopted NewRx as CancelRxResponse) transaction. a required transaction, and NewRxRequest and We proposed in 84 FR 7444 to enable iv. Request and Respond to Renew NewRxResponseDenied as optional a user to perform the related electronic Prescriptions (RxRenewalRequest, transactions in the updated transactions for CancelRx and RxRenewalResponse) § 170.315(b)(3) electronic prescribing CancelRxResponse. A CancelRx We proposed in 84 FR 7444 to enable criterion. We have finalized these latter transaction is a request from a prescriber a user to perform the related electronic two transactions as optional in response to a pharmacy to not fill a previously transactions for RxRenewalRequest and to commenters’ concerns regarding a sent prescription. A CancelRx must RxRenewalResponse. An lack of adoption by the PIS that would contain pertinent information for the RxRenewalRequest transaction be involved in the exchange. pharmacy to be able to find the originates from a pharmacy to request Additionally, we note that pursuant to prescription in their system (patient, additional refills beyond those the certification criterion, health IT medication (name, strength, dosage, originally prescribed. An presented for certification must be form), prescriber, and prescription RxRenewalResponse transaction capable of including the reason for the number if available). A originates from a prescriber to respond prescription as referenced in the CancelRxResponse is a response from a to the request from the pharmacy. updated § 170.315(b)(3)(ii) or pharmacy to a prescriber to Comments. Commenters supported § 170.315(b)(3)(ii)(D) in the NewRx acknowledge a CancelRx, and is used to adoption of the RxRenewalRequest and transaction. denote if the cancellation is approved or RxRenewalResponse transactions as denied. ii. Request and Respond to Change proposed. One commenter stated that Comments. The majority of public Prescriptions (RxChangeRequest, these transactions could be comments reflected support for RxChangeResponse) implemented after the CMS deadline of finalizing CancelRx and January 1, 2020 without loss of current We proposed in 84 FR 7444 to enable CancelRxResponse as required functionality. Another commenter said a user to perform the related electronic transactions. One commenter stated that that these transactions are widely used transactions for RxChangeRequest and the CancelRx transaction will reduce in the industry and provide great value RxChangeResponse. An cost and improve patient safety, as to end users. RxChangeRequest transaction originates patients may have remaining refills Response. We appreciate the support from a pharmacy and may be sent to a available that are subsequently modified for the RxRenewalRequest and prescriber to: Request a change in the based on a physician’s new assessment. RxRenewalResponse transactions and original prescription (new or fillable); Another commenter noted that certified have included these transactions as validate prescriber credentials; request a technology currently supports CancelRx required in the updated § 170.315(b)(3) review by a prescriber of the drug transactions in version 10.6 of the electronic prescribing criterion. We requested; or obtain prior authorization NCPDP SCRIPT standard and reiterate that the entire updated from the payer for the prescription. An encouraged developers to upgrade their § 170.315(b)(3) criterion and RxChangeResponse transaction technology to support CancelRx requirements must be met before originates from a prescriber to respond transactions in NCPDP SCRIPT standard certification can be granted. to: A prescription change request from version 2017071, as these transactions Additionally, we note that pursuant to a pharmacy; a request for a prior provide great value to end users. One the certification criterion, health IT authorization from a pharmacy; or a commenter expressed concern for presented for certification must be prescriber credential validation request pharmacy readiness for CancelRx, and capable of including the reason for the from a pharmacy. felt there should be sufficient industry prescription as referenced in the

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 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 EHRs receive all fill notifications and Response. We appreciate all § 170.315(b)(3)(ii)(D) in the subsequently use logic to bring the comments we have received on the use RxRenewalRequest and clinician’s attention to only important of the RxHistoryRequest and RxRenewalResponse transactions. indicators. RxHistoryResponse transactions. We agree with the commenter that the v. Receive Fill Status Notifications Response. We appreciate all of the RxHistoryRequest and (RxFill, RxFillIndicatorChange) comments that supported the RxFill transaction and the RxHistoryResponse transactions support We proposed in 84 FR 7444 to enable RxFillIndicatorChange transaction. After data integration between health IT a user to perform the related electronic consideration of comments received on systems such as EHRs and other transactions for RxFill and the RxFill and RxFillIndicatorChange information technology systems such as RxFillIndicatorChange. An RxFill transactions, we have adopted the PDMPs, and encourage any efforts made transaction is sent from a pharmacy to RxFill transaction as required and the by developers to fully integrate a prescriber or long term and post-acute RxFillIndicatorChange transaction as prescription and other health data into care (LTPAC) facility indicating the optional in the updated § 170.315(b)(3) a provider’s workflow within allowable FillStatus (dispensed, partially electronic prescribing criterion. We law. We reiterate that ONC does not dispensed, not dispensed or returned to encourage further development and have control over State laws that govern stock, or transferred to another innovation to address the concerns that PDMPs. We will continue to monitor pharmacy) of the new, refill, or resupply we heard from commenters, and we will regulatory and industry advancements prescriptions for a patient. continue to monitor advancements in in this area and will take them into RxFillIndicator informs the pharmacy of standards and technology for future consideration in future rulemaking. We the prescriber’s intent for fill status rulemaking. We reiterate that PIS are have adopted these transactions as notifications for a specific patient/ outside the scope of the ONC Health IT required in the updated § 170.315(b)(3) medication. An RxFillIndicatorChange Certification Program and encourage electronic prescribing criterion. is sent by a prescriber to a pharmacy to pharmacy information system Additionally, we note that pursuant to indicate that the prescriber is changing developers to advance their capacity to the certification criterion, health IT the types of RxFill transactions that support a nationwide network of fully presented for certification must be were previously requested, and in interoperable PIS. Additionally, we note capable of including the reason for the which the prescriber may modify the fill that pursuant to the certification prescription as referenced in the status of transactions previously updated § 170.315(b)(3)(ii) or selected or may cancel future RxFill criterion, health IT presented for certification must be capable of § 170.315(b)(3)(ii)(D) in the transactions. RxHistoryResponse transaction. Comments. While the RxFill including the reason for the prescription transaction received unanimous support as referenced in the updated vii. Ask the Mailbox If There Are Any as a required transaction, the vast § 170.315(b)(3)(ii) or Transactions (GetMessage) majority of comments opposed adopting § 170.315(b)(3)(ii)(D) in the RxFill We proposed in 84 FR 7444 to enable the RxFillIndicatorChange as proposed transaction. a user to perform the electronic due to a lack of industry adoption and vi. Request and Receive Medication transaction GetMessage for Ask the broad use by PIS. One commenter stated History (RxHistoryRequest, Mailbox. This transaction is used by the that there has not been a significant use RxHistoryResponse) prescriber or pharmacy when asking the case for the RxFillIndicatorChange mailbox if there are any transactions. It transaction to prescribers. A few We proposed in 84 FR 7444 to enable is the basis for the mechanism used by commenters suggested that ONC wait to a user to perform the related electronic a prescriber or pharmacy system to require the RxFillIndicatorChange until transactions for RxHistoryRequest and receive transactions from each other, this transaction is more widely adopted RxHistoryResponse. An from a payer, or from the Risk by both prescribers and pharmacies and RxHistoryRequest transaction is a Evaluation and Mitigation Strategy value is realized in the industry, and request from a prescriber to a pharmacy (REMS) Administrator via a switch suggested either removing for a list of medications that have been acting as a mailbox. RxFillndicatorChange from the prescribed, dispensed, claimed, or Comments. Approximately half of proposed criterion or making this indicated by a patient. An commenters opposed adoption of the transaction optional. Another RxHistoryResponse is a response to an GetMessage transaction and the other commenter argued that RxHistoryRequest containing a patient’s half supported adoption in the updated RxFillIndicatorChange should be medication history. It includes the § 170.315(b)(3) electronic prescribing optional as development to support this medications that were dispensed or criterion. Commenters not in support of transaction in NCPDP SCRIPT standard obtained within a certain timeframe, the GetMessage transaction asserted that version 2017071 would be resource and optionally includes the prescriber it is not in use by prescribers and that intensive. Commenters in support of the that prescribed it. it is an obsolete method of message adoption of the RxFillIndicatorChange Comments. Commenters supported retrieval. Commenters in support of transaction stated it is the only way to adoption of the RxHistoryRequest and adoption argued that it is applicable alter the prescriber notification RxHistoryResponse transactions as when not transacting with real-time preferences in an ambulatory or acute proposed. One commenter also stated messaging, and should be adopted as an setting outside of a fillable message. that both transactions could facilitate optional transaction. Commenters supporting adoption of the EHR and other health IT data integration Response. We thank commenters for RxFillIndicatorChange transaction with PDMP systems, yet noted that in their input. After careful consideration further noted that, historically, the lack many cases, State law or policy of all comments received, and in our of prescriber control over notification prohibits data integration between EHRs ongoing efforts to align with CMS Part messages may have had an impact on and PDMPs. Another commenter stated D requirements, we have determined to hindering adoption. One commenter that these transactions are widely used adopt the GetMessage transaction as suggested that, in lieu of the in the industry and provide great value optional for the updated § 170.315(b)(3) RxFillIndicatorChange transaction, to end users. electronic prescribing criterion.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00042 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25683

viii. Relay Acceptance of a Transaction § 170.315(b)(3)(ii) or existing order. An example use case is Back to the Sender (Status) § 170.315(b)(3)(ii)(D). when a medication supply for a resident Response. We appreciate all is running low (e.g., 2–3 doses) and a We proposed in 84 FR 7444 to enable comments in support of the Error new supply is needed from the a user to perform the related electronic transaction and have included this pharmacy. In such a circumstance, the transaction to relay acceptance of a transaction as required in the updated LTPAC organization sends the Resupply transaction back to the sender. A Status § 170.315(b)(3) electronic prescribing transaction as a way to notify the transaction in response to any criterion. As an acknowledgement, we pharmacy that an additional supply for applicable transaction other than agree that the NCPDP SCRIPT version the medication is needed. GetMessage indicates acceptance and 2017071 standard does not support the Comments. Commenters expressed responsibility for a request. A Status reason for the prescription in the Error concern over adopting this transaction transaction in response to GetMessage transaction, and we have modified that as a required transaction for a few indicates that no mail is waiting for requirement to reflect this. reasons. Some commenters noted that pickup. A Status transaction cannot be the Resupply transaction is only x. Respond That a Transaction held in an electronic mailbox and may applicable to LTPAC practice settings Requesting a Return Receipt Has Been not contain an error. for management of on-site pharmacy Received (Verify) Comments. Commenters supported inventory and for communication adoption of the Status transaction as We proposed in 84 FR 7445 to enable between a LTPAC facility and a proposed. Two commenters noted that a user to perform the related electronic contracted pharmacy. Other since the transaction is an transaction for Verify. This transaction commenters mentioned that PIS on the acknowledgement, it would not contain is a response to a pharmacy or sending or receiving end of the the reason for the prescription as prescriber indicating that a transaction transaction are not required to support referenced in the updated requesting a return receipt has been this transaction. Some commenters § 170.315(b)(3)(ii) or received. Verifications result when a stated that this transaction is not widely § 170.315(b)(3)(ii)(D). ‘‘return receipt requested’’ flag is set in adopted among prescribers, and that it Response. We appreciate all the original request. Upon receiving a should not be adopted until this occurs. comments in support of the Status transaction with ReturnReceipt set, it is Two commenters requested that we transaction and have included this the responsibility of the receiver to either remove the transaction from the transaction as required in the updated either generate a Verify in response to final rule or make the Resupply § 170.315(b)(3) electronic prescribing the request (recommended), or generate transaction optional. Other commenters criterion. As an acknowledgement, we a Status in response to this request, stated that while this transaction may be agree that the NCPDP SCRIPT version followed subsequently by a free- beneficial in the future, it was their 2017071 standard does not support the standing Verify transaction. This opinion that it is premature to require conveying the reason for the transaction notifies the originator that the Resupply transaction in the prescription in the Status transaction, the transaction was received at the electronic prescribing criterion at this and have modified the requirement to software system. It is not a notification time. reflect this. of action taking place, since time may Response. We appreciate all elapse before the ultimate response to comments related to the Resupply ix. Respond That There Was a Problem the transaction may take place. transaction and have included this With the Transaction (Error) Comments. Commenters supported transaction as optional in the updated adoption of the Verify transaction as § 170.315(b)(3) electronic prescribing We proposed in 84 FR 7444 to enable proposed. Two commenters noted that criterion. We are aware of several ONC- a user to perform the related electronic since the transaction is an certified EHRs and other health IT that transaction for Error response. This acknowledgement, it would not contain were either designed exclusively for, or transaction indicates an error has the reason for the prescription as were expressly designed to support, occurred and that the request was referenced in the updated LTPAC providers in addition to other terminated. An Error can be generated § 170.315(b)(3)(ii) or institutions, and encourage those and when there is a communication problem § 170.315(b)(3)(ii)(D). other developers to undergo or when the transaction actually had an Response. We appreciate all certification testing to the Resupply error. An Error can be held in an comments in support of the Verify transaction. Additionally, we note that electronic mailbox, as it may be transaction and have included this pursuant to the certification criterion, signifying to the originator that a transaction as required in the updated health IT presented for certification transaction was unable to be delivered § 170.315(b)(3) electronic prescribing must be capable of including the reason or encountered problems in the criterion. As an acknowledgement, we for the prescription as referenced in the acceptance. The Error must be a agree that the NCPDP SCRIPT standard updated § 170.315(b)(3)(ii) or different response than a Status, since version 2017071 does not support the § 170.315(b)(3)(ii)(D) in the Resupply the communication between the system reason for the prescription in the Verify transaction. We reiterate that PIS are and the mailbox must clearly denote the transaction, and we have modified that outside the scope of the ONC Health IT actions taking place. An Error is a requirement to reflect this. Certification Program and encourage response being delivered on behalf of a pharmacy information system xi. Request to Send an Additional previous transaction, while Status developers to advance their capacity to Supply of Medication (Resupply) signifies no more mail. support a nationwide network of fully Comments. Commenters supported We proposed in 84 FR 7445 to enable interoperable PIS. adoption of the Error transaction as a user to perform the related electronic proposed. Two commenters noted that transaction for Resupply. This xii. Communicate Drug Administration since the transaction is an transaction is a request from a Long Events (DrugAdministration) acknowledgement, it would not contain Term and Post-Acute Care (LTPAC) We proposed in 84 FR 7445 to enable the reason for the prescription as organization to a pharmacy to send an a user to perform the related electronic referenced in the updated additional supply of medication for an transaction for DrugAdministration.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00043 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25684 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

This transaction communicates drug RxTransferConfirm. The LTPAC facility, on behalf of a administration events from a prescriber RxTransferRequest transaction is used prescriber, to a pharmacy recertifying or care facility to the pharmacy or other when the pharmacy is asking for a the continued administration of a entity. It is a notification from a transfer of one or more prescriptions for medication order. An example use is prescriber or care facility to a pharmacy a specific patient to the requesting when an existing medication order has or other entity that a drug pharmacy. The RxTransferResponse been recertified by the prescriber for administration event has occurred (e.g., transaction is the response to the continued use. a medication was suspended or RxTransferRequest which includes the Comments. Commenters expressed administration was resumed). prescription(s) being transferred or a concern over adopting the Comments. Commenters expressed rejection of the transfer request. It is Recertification transaction as proposed concern over adopting this transaction sent from the transferring pharmacy to primarily because it is only applicable as a required transaction for a few the requesting pharmacy. The to LTPAC practice settings. One reasons. Some commenters noted that RxTransferConfirm transaction is used commenter stated that LTPAC the DrugAdministration transaction is by the pharmacy receiving (originally organizations interested in potentially only applicable to LTPAC practice requesting) the transfer to confirm that using e-prescribing transactions rated settings and is therefore not relevant to the transfer prescription has been Recertification as a low priority the scope of all certified health IT received and the transfer is complete. transaction type, suggesting that there products, though one commenter noted Comments. The vast majority of may not be a wide user base interested that there could be possible value of this commenters expressed concerns with in using it. transaction in ambulatory and acute the proposal to adopt Response. We appreciate all care settings as well. In addition, one RxTransferRequest, comments in support of the commenter reported LTPAC RxTransferResponse, and Recertification transaction. In light of organizations interested in potentially RxTransferConfirm transactions as commenters concerns, we have adopted using e-prescribing transactions rated proposed because they are only used in this transaction as optional in the DrugAdministration as a low priority pharmacy-to-pharmacy transactions and updated § 170.315(b)(3) electronic transaction type, meaning there may not are not applicable to EHRs. Further, two prescribing criterion. We are aware of be a wide user base interested in commenters noted that PIS are not several ONC-certified EHRs and other implementing it. required to support these transactions. health IT that were either designed Response. We appreciate comments Conversely, the two commenters that expressly for or in support of LTPAC related to the DrugAdministration supported these transactions cited the providers, among other institutions, and transaction and have included this benefit of allowing pharmacies to encourage those and other developers to transaction as optional in the updated transfer unfilled controlled substance undergo certification testing to the § 170.315(b)(3) electronic prescribing prescriptions, including Schedule 2, criterion. We are aware of several ONC- between pharmacies. Recertification transaction. certified EHRs and other health IT that Response. We thank commenters for xv. Complete Risk Evaluation and were either designed exclusively for, or their input. We proposed to require all Mitigation Strategy (REMS) are used in support of, LTPAC of the NCPDP SCRIPT 2017071 standard Transactions (REMSInitiationRequest, providers, and encourage those and transactions CMS adopted in 42 CFR REMSInitiationResponse, other developers to undergo 423.160(b)(2)(iv) to illustrate our REMSRequest, and REMSResponse) certification testing to the continued dedication to establish and DrugAdministration transaction. In light maintain complementary policies to We proposed in 84 FR 7445 to enable of the commenters’ concerns, we have ensure that the current standard for a user to perform the related electronic adopted the DrugAdministration certification to the electronic transactions for REMSInitiationRequest, transaction as optional because the ONC prescribing criterion permits use of the REMSInitiationResponse, Health IT Certification Program is current Part D e-Rx and MH standards. REMSRequest, and REMSResponse. agnostic to care settings and programs, With consideration of comments, and With CMS’ adoption of these yet still supports many different use because it was not the intent of this transactions in their recently issued cases. This allows the ONC Health IT certification criterion to include final rule associated with e-Rx for Certification Program to support pharmacy specific transactions for the Medicare Part D (42 CFR multiple program and setting needs, purposes of certification, we have 423.160(b)(2)(iv)(W)–(Z)), we believe including but not limited to the adopted RxTransferRequest, that it will be beneficial to include these Promoting Interoperability Programs RxTransferResponse, and four REMS transactions as part of this and long term and post-acute care. RxTransferConfirm as optional in the certification criterion: Because the transaction will be optional updated § 170.315(b)(3) electronic REMSInitiationRequest, in the updated (b)(3) criterion, prescribing criterion. We reiterate that REMSInitiationResponse, developers whose clients do not support PIS are outside the scope of the ONC REMSRequest, and REMSResponse. long term care settings will not be Health IT Certification Program and Furthermore, under the Food and required to demonstrate their capacity encourage pharmacy information system Drug Administration Amendments Act to send this transaction. developers to advance their capacity to (FDAAA) of 2007 (Pub. L. 110–85), the support a nationwide network of fully Food and Drug Administration (FDA) xiii. Request and Respond to Transfer interoperable PIS. requires REMS from a pharmaceutical One or More Prescriptions Between manufacturer if the FDA determines that Pharmacies (RxTransferRequest, xiv. Recertify the Continued a REMS is necessary to ensure the RxTransferResponse, Administration of a Medication Order benefits of a drug outweigh the risks RxTransferConfirm) (Recertification) associated with the drug. In support of We proposed in 84 FR 7445 to enable We proposed in 84 FR 7445 to enable our sister agencies’ work, we therefore a user to perform the related electronic a user to perform the related electronic proposed to include the REMS transactions for RxTransferRequest, transaction for Recertification. This transactions as part of this certification RxTransferResponse and transaction is a notification from a criterion.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00044 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25685

Comments. The vast majority of ways that would streamline the process SCRIPT standard version 2017071 for a commenters supported adoption of for exchanging clinical and financial variety of reasons, including improving REMSInitiationRequest, data amongst prescribers and payers for efficiencies in the prior authorization REMSInitiationResponse, prior authorization and improve process, improving patient outcomes, REMSRequest, and REMSResponse as patients’ access to needed medications. reducing point-of-sale rejections, optional, not required, transactions. Electronic prior authorization (ePA) increasing health IT developer adoption, Those in support of the transactions as automates this process by allowing and improving the Medicare Part D proposed suggested that ONC should providers to request and respond to member experience. Several develop strategies to encourage electronic prior authorization commenters indicated that lack of providers to consciously consider and transactions within their workflow. vendor support for the ePA transactions appropriately act on alerts to reduce the Using electronic prior authorization is a major barrier to physician use of the risk that these messages can easily be (ePA) transactions in the NCPDP transactions. One commenter also clicked through and missed, particularly SCRIPT standard version 2017071 suggested ONC adopt the NCPDP if that provider is experiencing alert provides a standard structure for SCRIPT standard version 2013101 prior fatigue. Multiple reasons were provided exchanging prior authorization (PA) authorization transactions. by commenters who stated that the questions and answers between Response. We thank commenters for proposed REMS transactions should be prescribers and payers, while allowing their feedback. In consideration of adopted as optional in the proposed payers to customize the wording of the comments, we have adopted the ePA certification criterion. These reasons questions. Electronic prior authorization transactions in the NCPDP SCRIPT included the state of system readiness transactions will additionally support standard version 2017071 as optional and adoption by manufacturers, REMS the automation of the collection of data for the updated § 170.315(b)(3) administrators, and pharmacy required for PA consideration, allowing electronic prescribing criterion. We information systems. Another a health IT developer to systemically believe the adoption of the ePA commenter stated that these REMS pull data from a patient’s medical transactions included in version transactions are not yet in widespread record. The efficiency gains offered by 2017071 of the NCPDP SCRIPT standard use and should be piloted before being the ePA transactions in the NCPDP as optional transactions aligns with required as they require extensive SCRIPT standard version 2017071 are CMS’ proposals for Part D ePA. We note design and development effort. the primary driver behind the that this final rule allows only for the Response. Given comments in support development of this new capability. We voluntary certification of Health IT of the REMSInitiationRequest, believe the adoption of the ePA Modules by health IT developers to REMSInitiationResponse, transactions included in version REMSRequest, and REMSResponse support these transactions, and does not 2017071 of the NCPDP SCRIPT standard require the certification, adoption, or transactions, we have included these as optional transactions aligns with transactions as optional in the updated use of such Health IT Modules by health CMS’ proposals for Part D ePA, and care providers for this or any other § 170.315(b)(3) electronic prescribing therefore, will not be adopting NCPDP criterion. We encourage commenters, purpose. We also note that SCRIPT standard version 2013101 as development, testing, and developers, and other stakeholder to suggested by the commenter. On June review and provide feedback on implementation to support these 17, 2019, CMS issued the Secure transactions are important first steps sections related to REMS (https:// Electronic Prior Authorization for www.healthit.gov/isa/allows-a- toward integrating pharmacies in the Medicare Part D proposed rule (84 FR prescriber-communicate-a-rems- prior authorization process for Part D 28450), including a proposed new administrator) and all other electronic prescriptions, while supporting transaction standard for the Medicare prescribing use cases on the ONC widespread industry adoption and Prescription Drug Benefit program’s Interoperability Standards (ISA) and reducing burden on providers. We refer (Part D) e-prescribing program. Under post suggested edits and updates on readers to the ONC Strategy on this proposal, Part D plan sponsors these transactions as the industry Reducing Regulatory and would be required to support version advances. We encourage manufacturers, Administrative Burden Relating to the 2017071 of the NCPDP SCRIPT standard 44 REMS administrators, and pharmacy Use of Health IT and EHRs, drafted in for four ePA transactions, and information system developers to adopt partnership with CMS, for further these and other NCPDP SCRIPT prescribers would be required to use discussion of potential opportunities to standard version 2017071 transactions that standard when performing ePA ease related clinician burden through to improve safe prescribing practices transactions for Part D covered drugs improved health IT enabled processes. they wish to prescribe to Part D eligible and patient safety, and encourage xvii. Reason for the Prescription developers to test their capacity to send individuals. While not currently and receive REMS messages by utilizing adopted as part of the Part D eRx For each transaction specified, the the testing tools that are available. standard, the NCPDP SCRIPT standard technology must be able to receive and version 2017071 includes eight transmit the reason for the prescription. xvi. Electronic Prior Authorization transactions that would enable the Comments. Commenters supported prescribers to initiate medication ePA The Part D E-prescribing prior continued adoption of the reason for the requests with Part D plan sponsors at authorization process in 84 FR 28450 prescription in specific electronic the time of the patient’s visit. The eight through 28458 requires that providers prescribing transactions. Some transactions are: PAInitiationRequest, supply additional clinical information commenters noted that some of the PAInitiationResponse, PARequest, to verify that the medication can be proposed transactions would not PAResponse, PAAppealRequest, covered under the Medicare Part D contain the reason for the prescription PAAppealResponse, PACancelRequest, benefit. The prior authorization process as referenced in the updated is intended to promote better clinical and PACancelResponse. decision-making and ensure that Comments. Several commenters 44 https://www.healthit.gov/topic/usability-and- patients receive medically necessary recommended the adoption of the ePA provider-burden/strategy-reducing-burden-relating- prescription drugs. We are looking for transactions available in the NCPDP use-health-it-and-ehrs.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00045 Fmt 4701 Sfmt 4700 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 Response. We thank the commenter and benefit information to providers. In § 170.315(b)(3)(ii)(D). for the input. Because this requirement the absence of that or another similar Response. We thank commenters for is out of scope for the Proposed Rule in standard, CMS has adopted policies their feedback. We reiterate our decision that we did not propose to change this requiring the development and/or to require Health IT Modules seeking conformance requirement, we decline to implementation of Real Time Benefit certification to the updated electronic relax or retire the requirement for oral Transaction (RTBT) standards in the prescribing certification criterion to be liquid medications to be prescribed in Part D e-Rx Program in the context of capable of including the reason for the mL units. When we first adopted this recent rulemaking. On May 16, 2019, prescription as referenced in the requirement for the 2015 Edition CMS issued the Modernizing Part D and updated § 170.315(b)(3)(ii) or Proposed Rule, several commenters Medicare Advantage to Lower Drug § 170.315(b)(3)(ii)(D) within relevant were supportive of improving patient Prices and Reduce Out-of-Pocket electronic prescription transactions to safety through use of the metric Expenses final rule, which includes a support patient safety and align with standard for dosing, but recommended requirement under the electronic HHS goals to expand safe, high quality that this requirement only apply to oral prescribing standards that Part D plan health care. Health IT certified to the liquid medications. Incorrect dosage is a sponsors implement one or more updated § 170.315(b)(3) criterion must common error with liquid medication, electronic real-time benefit tools that are have the capacity to enable a user to often resulting from confusion between capable of integrating with at least one receive and transmit the reason for the different dose measurements (e.g., mL prescriber’s electronic prescribing prescription using the diagnosis and teaspoons). If these measurements system or electronic health record no elements: or are confused with each other, too much later than January 1, 2021 (84 FR , or optionally, the or too little of the medicine can be 23832). One commenter recommended technology must be able to receive and given. This requirement is also in that CMS and ONC coordinate with transmit the reason for the prescription alignment with NCPDP SCRIPT NCPDP on requirements for real-time using the element, implementation recommendations. benefit functionality. We are also aware of industry efforts to develop a and be consistent with the International xix. Signatura (Sig) Element Statistical Classification of Diseases and consumer-facing real-time pharmacy The Signatura (Sig) element is used to ® Related Health Problems (ICDs) sent in benefit functionality FHIR -based support electronic prescribing for the the diagnosis element(s). The implementation guide that we anticipate consistent expression of patient element defines the will be balloted in 2020. ONC will directions for use by relaying this indication for use of the medication as continue to monitor these efforts and information between a prescriber and a meant to be conveyed to the patient, and consider proposing the NCPDP RTPB pharmacist. It must be legible, is included in the Sig. This requirement standard or a similar standard to enable unambiguous, and complete to ensure would apply to the following NCPDP real-time benefit transactions in future the prescriber’s instructions for use of SCRIPT standard version 2017071 rulemaking. the medication are understood. For each transactions that we have adopted in transaction, the technology must be able xxi. Other Comments Received Outside this criterion (see discussion above): to receive and transmit the reason for the Scope of This Rule NewRx, RxChangeRequest, the prescription using the indication We note that we received several RxChangeResponse, CancelRx, elements in the SIG Segment. comments specifically addressing the RxRenewalRequest, Comments. One commenter requested electronic prescribing of controlled RxRenewalResponse, RxFill, that the Sig element be required rather substances and prescription drug RxHistoryResponse, Resupply, than optional to aid in future monitoring programs. We note that RxTransferRequest, RxTranferResponse, medication reconciliation and clinical these specific comments are outside the REMSInitiationRequest, reporting. Another commenter noted scope of the proposals finalized in this REMSInitiationResponse, that the NCPDP SCRIPT standard rule. However, we note that we REMSRequest, REMSResponse, version 2017071 allows for an increase included a discussion of these topics in PAInitiationRequest, in Sig length. relation to the discussion of the RFI on PAInitiationResponse, PARequest, Response. Given the lack of attention OUD prevention and treatment in the PAResponse, PAAppealRequest, paid to and support for modifying the Proposed Rule in 84 FR 7461. PAAppealResponse, PACancelRequest, electronic prescribing criterion for Sig 5. Clinical Quality Measures—Report and PACancelResponse. from optional to required, we have Criterion xviii. Oral Liquid Medications decided to retain Sig as optional in the updated § 170.315(b)(3) criterion. As In the 2015 Edition final rule, ONC Limit a user’s ability to prescribe all discussed in the Reason for Prescription adopted four clinical quality measure oral liquid medications in only metric section, health IT may optionally seek (CQM) certification criteria, standard units of mL (i.e., not cc). certification to the updated electronic § 170.315(c)(1) CQMs—record and Comments. While not within the prescribing criterion by demonstrating export, § 170.315(c)(2) CQMs—import scope of the Proposed Rule, one their capacity to receive and transmit and calculate, § 170.315(c)(3) CQMs— commenter did not support the the reason for the prescription using the report, and § 170.315(c)(4) CQMs—filter continued requirement to prescribe oral Sig element. (80 FR 62649 through 62655). These liquids in ‘‘mL’’ units. The commenter four criteria were adopted with the supported the use of metric units, but xx. Real Time Pharmacy Benefit intent to support providers’ quality did not agree with the requirement of While development is still currently improvement activities and in the ONC Health IT Certification Program underway by NCPDP, the Real-Time electronically generating CQM reports to limit this to only milliliters. The Pharmacy Benefit (RTPB) standard is for reporting with certified health IT to commenter recommended that the unit not yet complete. When complete, the programs such as the EHR Incentive of measure used by a prescriber be at RTPB standard is expected to facilitate Programs, Quality Payment Program, their discretion, as long as it is the ability for pharmacy benefit payers/ and Comprehensive Primary Care plus appropriate for the dosage. processors to communicate formulary initiative. The ‘‘CQMs—report’’

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00046 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25687

certification criterion (§ 170.315(c)(3)) require that health IT certified to the § 170.315(c)(3), and to require that included an optional certification current 2015 Edition CQMs—report health IT certified to the criterion provision for demonstrating that the criterion support the CMS QRDA IGs support the proposed CMS QRDA IGs. health IT can create Quality Reporting (84 FR 7446). We stated that this change Some commenters observed that the Document Architecture (QRDA) reports would directly reduce burden on health main use cases for the certified QRDA in the form and manner required for IT developers and indirectly providers export functionality (which is specific submission to CMS programs, which is as they would no longer have to develop to CMS eCQMs) are to support direct in accordance with CMS’ QRDA and support two forms of the QRDA data submission to CMS at the Implementation Guide (IGs). standard. conclusion of reporting periods, to The CMS QRDA IGs provide technical We also solicited comment in the enable use of third party data guidance and specific requirements for Proposed Rule on the future possibility submission Health IT Modules to meet implementing the HL7 QRDA Category of FHIR-enabled APIs replacing or CMS reporting requirements, and to I (QRDA I) and Category III (QRDA III) complementing QRDA-based quality support data extraction for registry standards for reporting to CMS quality reporting. We also noted in the reporting for participation in CMS reporting programs.45 The CMS QRDA Proposed Rule that the Fast Health programs such as MIPS. Commenters IGs include the formal template Interoperability Resources (FHIR®) noted that while in some cases the definitions and submission criteria for standard offers the potential for extraction of data using a QRDA may submitting QRDA documents to the supporting quality improvement and also support other use cases—for Comprehensive Primary Care Plus reporting needs, and holds the potential example for a registry—because of the (CPC+) and Merit Based Incentive of being a more efficient and specificity of the criteria to the CMS Payments System (MIPS) Programs. interoperable standard to develop, eCQMs, such a transaction using the Some of the conformance statements in implement, and utilize to conduct certified functionality is primarily for the HL7 QRDA standards have been quality reporting through APIs. We CMS reporting. Commenters noted the further constrained to meet the specific believe until the potential benefits of use of the CMS QRDA IG does not requirements from these CMS programs. FHIR® APIs can be realized for quality impede use of the data for other The CMS QRDA IGs also only list the reporting, and that solely requiring the purposes. Finally, commenters noted templates specifying CMS-specific CMS QRDA IGs for the updated 2015 that ONC should continue to provide reporting requirements from the base Edition ‘‘CQMs—report’’ criterion will health IT developers the flexibility to HL7 QRDA standards. QRDA I is an balance the burden on developers, while offer a non-certified QRDA functionality individual-patient-level report. It still ensuring module users’ abilities to that could support eCQMs beyond those contains quality data for one patient for meet their quality reporting obligations included for CMS programs. One one or more electronic clinical quality to CMS (84 FR 7446). commenter observed that while some measures (eCQMs). QRDA III is an To support the proposal, we proposed health IT systems also provide tools for aggregate quality report. A QRDA III to incorporate by reference in § 170.299 internal quality performance report contains quality data for a set of the latest annual CMS QRDA IGs, monitoring, those tools often do not rely patients for one or more eCQMs. specifically the 2019 CMS QRDA I IG on the generation of QRDA exports. Since the 2015 Edition final rule was for Hospital Quality Reporting 46 Some commenters reported that the published, we have gained additional (§ 170.205(h)(3)) and the 2019 CMS technical support of multiple versions of QRDA standards is unnecessary. certification experience and received QRDA III IG for Eligible Clinicians and Other commenters recommended feedback from the industry that health Eligible Professionals maintaining only the HL7 standard or IT certified to the ‘‘CQMs—report’’ (§ 170.205(k)(3)).47 We noted in the offering certification to the HL7 criterion (§ 170.315(c)(3)) are only/ Proposed Rule that developers would be standard as an optional alternative to primarily being used to submit eCQMs able to update certified health IT to the CMS QRDA IG. One commenter who to CMS for participation in CMS’ newer versions of the CMS QRDA IGs recommended maintaining both the HL7 programs. Therefore, as a means of through the real world testing standard and the CMS QRDA IGs reducing burden, we proposed to Maintenance of Certification provision ® suggested that ONC cite the CMS remove the HL7 CDA Release 2 for standards and implementation version(s) of the QRDA IG as a technical Implementation Guide: QRDA I; Release specification updates in § 170.405(b). 1, Draft Standard for Trial Use (DSTU) resource in the same manner the C–CDA We also proposed that a Health IT companion guide is cited for the Release 3 (US Realm), Volume 1 Module would need to be certified to (§ 170.205(h)(2)), as well as the QRDA transition of care criteria and only both standards to ensure flexibility for require certifying to the HL7 version. Category III, Implementation Guide for Health IT Module users. We solicited CDA® Release 2 (§ 170.205(k)(1)) and These commenters agreed that comment on whether to consider an developers should not have to certify to the Errata to the HL7 Implementation approach that would permit Guide for CDA® Release 2: QRDA both HL7 QRDA and CMS QRDA IGs, certification to only one of the standards but suggested if a developer passed Category III, DSTU Release 1 (US depending on the care setting for which Realm), September 2014 certification for the CMS QRDA IGs, the Health IT Module is designed and they should be deemed to have achieved (§ 170.205(k)(2)) standard requirements implemented. (HL7 QRDA standards) from the current certification to the HL7 QRDA standard Comments. The majority of as well. Commenters noted that the 2015 Edition CQMs—report criterion in commenters were supportive of the § 170.315(c)(3), and we also proposed to CMS QRDA apply specifications to the proposal to remove the HL7 QRDA HL7 QRDA to support CMS eCQM standard requirements from the 2015 45 The following resources provide additional reporting requirements. information on the differences between the CMS Edition CQMs—report criterion in Other commenters specifically stated QRDA and the HL7 QRDA standards: https:// that the HL7 QRDA should remain as an ecqi.healthit.gov/system/files/QRDA_HQR_2019_ 46 https://ecqi.healthit.gov/system/files/QRDA_ optional certification criterion, since CMS_IG_final_508.pdf (pg. 38) and https:// HQR_2019_CMS_IG_final_508.pdf. ecqi.healthit.gov/sites/default/files/2019-07/2020- 47 https://ecqi.healthit.gov/system/files/2019_ other organizations (e.g., certain CMS-QRDA-III-Eligible-Clinicians-and-EP-IG- CMS_QRDA_III_Eligible_Clinicians_and_EP_IG- hospital accreditation organizations 07182019-508.pdf (pg. 18). 508.pdf. such as The Joint Commission) use the

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00047 Fmt 4701 Sfmt 4700 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 current 2015 Edition ‘‘CQMs—report’’ collaboration through standards the same style for submission across criterion, but also to the other 2015 developing organizations (SDOs) to programs. They recommended that the Edition CQM criteria and the prior 2014 refine standards. HL7 QRDA IG persist as a continuing Edition CQM criteria. This specificity is Therefore, as a means of reducing option in the Program to enhance intended to provide assurances through burden, we have finalized our proposal alignment with other standards and C– testing and certification of the accuracy to remove the HL7 QRDA standard CDA, and to encourage a base standard and standardization of CMS program requirements from the 2015 Edition alignment across implementers such as measures across platforms, while CQMs—report criterion in CMS and The Joint Commission. They recognizing that it would not be § 170.315(c)(3). We maintain our stated that citing only to the CMS QRDA possible to specifically test to the entire position that this would directly reduce IG may lead to misalignment with the universe of potential eCQMs in use by burden on health IT developers and base standards and reduce incentives to health care providers. Because of this indirectly for health care providers as update the base standard. dependency, testing and certification of there would no longer be a requirement Some commenters expressed concern both the HL7 QRDA for CQMs-report to develop and support two forms of the over the proposed removal of HL7 and the CMS QRDA IG is redundant to QRDA standard. We note that this does QRDA standards from the original 2015 support eCQM data reporting. not preclude developers from Edition CQMs, stating it may undermine This has a dual impact on our continuing to support the underlying private sector efforts to self-regulate and considerations to finalize our proposal standard, especially where such stated that the removal of the HL7 to require only the CMS QRDA IG. First, standard may support reporting or QRDA may not achieve the envisioned for use cases that are not related to CMS health information exchange for other burden reduction through the mere eCQM reporting, the certified quality or public health purposes. elimination of developers’ need to functionality would not specifically Instead, we are simply not requiring certify and maintain multiple standards. support third party non-CMS eCQM testing and certification of any such While some commenters suggested that reporting requirements, and so the standards, thereby eliminating testing removing HL7 QRDA from the modification to the functionality does and certification burden from a criterion certification criteria could simplify the not change the inability to use the that is at this time scoped to the purpose reporting process by recognizing the certified version of the functionality for of reporting for CMS quality programs. widespread use of CMS’ QRDA IGs, they such purposes. Second, for those use Comments. A few commenters did not noted that the HL7 QRDA is currently cases involving registries or other third support the proposal but instead the standard for most EHR systems and parties that are implementing or recommended that CMS adopt the HL7 questioned how ONC proposed to supporting CMS eCQM reporting, use of QRDA standard and do away with its implement this change given the the CMS QRDA IG could additionally own. However, several commenters prominence of HL7 standards in EHR support such purposes. In addition, we offered suggestions to CMS on the systems. Several commenters noted that are not restricting health IT developers development of the CMS QRDA IG and the disconnect between what the from creating and providing to the alignment to the HL7 QRDA certification testing required, and how customers a non-certified functionality standard. A number of commenters the standard was really being used in that supports the HL7 QRDA for the noted the National Technology Transfer the industry (primarily but not extraction of data for eCQMs that are not and Advancement Act of 1995 principle exclusively to meet the CMS QRDA IG) CMS eCQMs. We note that this is not a that Federal agencies are generally created unnecessary certification testing change from the prior policy allowing required to use technical standards that burden, and asserted that the adoption such flexibility. The prior certification are developed by voluntary consensus of the CMS proprietary IG was more for the QRDA IG included testing of standards bodies rather than a appropriate than to maintain HL7 CMS eCQMs only and it neither proprietary standard specific to an HHS QRDA. supported nor restricted any program. Commenters also stated if Response. We thank commenters for development of a QRDA functionality CMS wanted to retain certain aspects of their support for the proposal and for non-CMS eCQMs. its standard, it should work with HL7 to comments regarding the versions of We also agree that this approach will get these vetted, balloted and approved standards. We understand the concerns support closer alignment between the for inclusion within the HL7 standard. expressed in opposition to this testing to the CMS QRDA IG Commenters also recommended proposal, and we appreciate specifically specifications for a certified health IT working with SDOs or other the identification of potential risk for module and the technical requirements organizations to sufficiently support the elimination of the HL7 standard as for CMS program reporting. As part of CMS QRDA IGs. Some commenters applicable for other use cases. As noted the development of the CMS QRDA IGs, suggested that consolidation of QRDA previously, since the 2015 Edition final CMS strives to use the annual update standards would be more likely result in rule was published (October 16, 2015), process to resolve issues with CQMs reducing provider burdens than what we have gained received feedback from based on updates to clinical guidelines ONC proposed. the industry that health IT certified to and to advance the requirements as the Response. We thank the commenters the ‘‘CQMs—report’’ criterion standard for reporting eCQM data for their recommendations to improve (§ 170.315(c)(3)) are only or primarily matures. In this way, aligning the the CMS QRDA IGs, or for CMS to work being used to submit eCQMs to CMS for criterion to the CMS program toward including the aspects of CMS participation in CMS’ programs. In requirements that it specifically QRDA IGs that they require for their addition, we note that while the HL7 supports allows for alignment between program operations in SDO-balloted and QRDA may be used for other purposes, these efforts as well as allowing for approved consensus standards. Specific the ‘‘CQMs—report’’ criterion continued updates through the suggestions for CMS IG development are (§ 170.315(c)(3)) is specific to the CMS standards version advancement process. outside the scope of this rule. ONC had eCQMs specified for participation in We also believe our finalized proposal previously included the HL7 QRDA CMS reporting programs and no other will not impede private sector standards for certification in the 2015 eCQMs are tested under that criterion. initiatives as the CMS IGs support the Edition in order to potentially support This specificity applies not only to the continued efforts by public/private a broader range of use cases than

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00048 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25689

reporting for CMS programs. However, participants in certain CMS programs capture and export’’ criterion in the specificity of the criterion to the (e.g., should a program expand from § 170.315(c)(1) criteria includes CMS eCQMs limits the utility of the hospital-based only to include demonstrating the capability to export a certified functionality beyond use with ambulatory measures). These QRDA I report specific to the eCQM CMS eCQMs and as stated in the commenters recommended the adoption being tested—which would support use Proposed Rule, since the 2015 Edition of a requirement for certified Health IT case noted by the commenter to final rule, ONC and CMS received Modules to calculate and export both combine data across multiple significant stakeholder feedback that CMS QRDA I patient-level reports for ambulatory systems. We have not health IT modules certified to the Hospital Quality Reporting and CMS proposed and have not finalized a ‘‘CQMs—report’’ criteria at 170.314(c)(3) QRDA III aggregate summary reports for change to the 2015 Edition ‘‘CQM— in the 2014 Edition and 170.315(c)(3) for Eligible Clinicians and Eligible capture and export’’ criterion in the 2015 Edition are used only or Professionals. These commenters noted § 170.315(c)(1). We further note that primarily for reporting to CMS that if a certified Health IT Module can health IT developers may leverage programs. While we reiterate that these only send an aggregate report without a QRDA file formats for a wide range of comments are outside the scope of this patient level report, then this would use cases and that our inclusion of the rule, we will continue to take this and greatly diminish the ability to verify the CMS QRDA I and QRDA III IGs does not other feedback into consideration and underlying calculations. However, prohibit the use of the QRDA standard will continue to work with CMS, commenters recommended that ONC for any other purpose. As noted above, standards developing organizations, and clarify that the transition to CMS QRDA we have finalized the adoption of the health IT industry partners to explore I IG-based reports (patient-level, QRDA CMS QRDA IGs for the ‘‘CQMs—report’’ the concerns raised in relation to I IG for Hospital Quality Reporting) does criterion in § 170.315(c)(3) for which the reducing burden and promoting not necessarily mean that a hospital Health IT Module is presented for interoperable standards for quality quality measure must be certified by any certification. reporting. system (i.e., an ambulatory Health IT Comments. The majority of Comments. Commenters provided Module can certify to only CMS QRDA commenters supported the proposal to mixed feedback on whether the updated III IG requirements). Commenters also adopt the latest CMS QRDA IGs at the 2015 Edition ‘‘CQMs—report’’ criterion sought clarity that the transition to time of final rule publication, as CMS should require adherence to both CMS QRDA III reports (aggregate-level, IG for updates their QRDA IGs annually to QRDA IGs, specifically the 2019 CMS Eligible Clinicians and Eligible support the latest eCQM specifications QRDA I IG for Hospital Quality Professionals) does not necessarily and only accepts eCQM reporting to the Reporting 48 and the 2019 CMS QRDA mean that an ambulatory quality latest version. However, a few III IG for Eligible Clinicians and Eligible measure must be certified by any system commenters recommended that ONC Professionals.49 The majority of (i.e., a hospital system can certify to monitor this part of the certification commenters recommended that to only hospital measures). Finally, one process for unintended consequences reduce burden, ONC should consider a commenter noted that certifying since CMS’ IGs are updated on a yearly certification approach that permits ambulatory quality measures for the basis. Some commenters noted that developers to seek certifications based QRDA I to a hospital IG is not effective given the lack of alignment with timing, eCQM measures and standards will on the care setting(s) their health IT and will interfere with the use case of continue to lack testing. Other modules are intended serve. For using QRDA I to combine data between commenters recommended the IGs be example, commenters suggested that multiple ambulatory systems such as for updated in alignment with updates to ONC should only require certification to group reporting. the certification standards. A few the 2019 QRDA I IG for Hospital Quality Response. We thank commenters for commenters requested clarification of Reporting if a Health IT Module is their comments regarding whether a the effective dates and asked ONC to designed exclusively for the reporting of Health IT Module should be certified to evaluate and propose a timeline for the hospital measures, and only require both CMS QRDA IG standards or implementation of an alignment certification to the 2019 QRDA III IG for whether to consider an approach that between the programs. In addition, Eligible Clinicians and Eligible permits certification to only one of the commenters asked for clarification on Professionals when a Health IT Module standards depending on the care setting whether ONC will propose penalties for is designed exclusively for the reporting for which the Health IT Module is providers who may be unable to meet of ambulatory measures. In instances in designed and implemented. We agree the timeline if it is insufficient. which both populations are served, the with commenters that our certification Response. We thank commenters for developer would then seek certification approach should prevent unintended their input and have adopted the latest to both standards. Commenters burden by tailoring the requirements to CMS QRDA IG versions available at the suggested this approach would avoid the type of measures being tested. This time of publication of this final rule. For the unnecessary burden of certifying to would mean that for the updated details on the latest CMS QRDA IGs, we a standard that the Health IT Module certification criterion ‘‘CQMs—report’’ refer readers to the CMS QRDA I was not intended to serve. Other in § 170.315(c)(3) a Health IT Module Implementation Guide for Hospital commenters stated that the certification testing only ambulatory measures would Quality Reporting and CMS QRDA III requirements should ensure that test only with the CMS QRDA III IG for Implementation Guide for Eligible certified Health IT Modules can support ambulatory measures and a Health IT Clinicians and Eligible Professionals quality measure reporting by all Module testing only inpatient measures available on the eCQI Resource Center potential users, especially given the would test only with the QRDA I CMS website.50 We note that CMS updates potential expansion of eligible IG for inpatient measures. A Health IT Module supporting both ambulatory and 50 The Electronic Clinical Quality Improvement 48 https://ecqi.healthit.gov/system/files/QRDA_ inpatient measures would be required to (eCQI) Resource Center. CMS QRDA I HQR_2019_CMS_IG_final_508.pdf. test to both the CMS QRDA I IG and the Implementation Guide for Hospital Quality 49 https://ecqi.healthit.gov/system/files/2019_ Reporting and CMS QRDA III Implementation CMS_QRDA_III_Eligible_Clinicians_and_EP_IG- CMS QRDA III IG. We clarify that Guide for Eligible Clinicians and Eligible 508.pdf. testing for the 2015 Edition ‘‘CQM— Continued

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00049 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25690 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

the CMS eCQMs on an annual basis as measures that utilize population-based recommended that, in addition to the well as the CMS QRDA IGs for reporting electronic clinical data. adoption of the CMS IGs under the to CMS programs. As in prior years Response. We thank commenters for § 170.315(c)(3) criterion, that the CMS going back to the 2014 Edition, HHS their support. We believe there are IGs replace the corresponding HL7 will continue to update the Cypress potential benefits to be gained by QRDA IGs as ONC’s Program standard testing tool to support health IT exploring both near-term, program under the § 170.315(c)(1) criterion developer testing to the most recent specific implementations of APIs to (which currently references QRDA I annual update. We note that CMS has support current quality reporting exclusively) and § 170.315(c)(2) previously required that EHR submission mechanisms such as for criterion (which currently references technology used for eCQM reporting be CMS eCQM reporting as well as the only QRDA I as standard, but also certified to all eCQMs but does not need long-term potential to reimagine quality involves use of QRDA III for purposes to be recertified each time it is updated measurement by leveraging API of verifying appropriate calculation of to a more recent version of the eCQM technologies. We believe that these measures from imported QRDAs). electronic specifications, unless the technology approaches could help Response. We thank commenters for EHR technology is supporting new providers and payers, including CMS, input and clarifications. While we eCQMs or functionality (such as the move from the current approach, in appreciate comments suggesting ‘‘CQM—filter’’ criterion in which providers are required to changes to § 170.315(c)(1) ‘‘CQMs— § 170.315(c)(4)) (84 FR 42505). This calculate and submit results on specific record and export,’’ and § 170.315(c)(2) approach allows for continued updates quality measures, to one in which ‘‘CQMs—import and calculate,’’ the to and testing of eCQMs while payers, including CMS, could obtain recommended changes are outside the minimizing the burden on developers clinical data for quality measurement scope of our proposal. Therefore, while and providers to support those updates directly through an API. This could we may consider these in time for each annual performance potentially include the ability to obtain recommendations for future Program period. Finally, we note that ONC has clinical data for a defined group or rulemaking, we have not adopted the no authority to set requirements, sample set of patients to assess quality suggested changes to § 170.315(c)(1) incentives, or penalties for health care across patient populations, as well as to ‘‘CQMs—record and export,’’ or providers related to the use of health IT, compare clinical data for patients over § 170.315(c)(2) ‘‘CQMs—import and and we direct readers to CMS for time to assess quality impacts through calculate in this final rule. information on health IT requirements longitudinal measurement. We believe As noted previously, we have in CMS programs. emerging innovative standards are now finalized the update to the ‘‘CQMs— Comments. The majority of available to support such models, report’’ criterion in § 170.315(c)(3) to commenters agreed with ONC’s specifically the ability to respond with require that health IT developers use the assessment in the Proposed Rule that clinical data for a defined group or CMS QRDA IG appropriate to the quality reporting is not yet ready to sample set of patients using the bulk measures being submitted for testing transition to FHIR and that more testing data capabilities in FHIR Release 4. We and certification to read as follows: and validation of FHIR is needed before note that readiness for such an ‘‘Clinical quality measures—report. requiring a new API-based reporting approach, both for recipients of quality Enable a user to electronically create a functionality as a part of the Program. data and for health IT developers data file for transmission of clinical Some commenters supported the supporting quality improvement quality measurement data in accordance adoption of FHIR Release 4-enabled solutions, is not yet mature for adoption with the applicable implementation APIs as a replacement for QRDA-based of such a criterion in the Program. specifications specified by the CMS reports, but stated that published However, we are committed to implementation guides for Quality documentation aligning HL7 C–CDA, continuing to work with HHS partners, Reporting Document Architecture QRDA, and/or FHIR standards to CMS’ health care providers, health IT (QRDA), category I, for inpatient ‘‘Quality Data Model,51’’ which is an developers and SDOs to explore the measures in § 170.205(h)(3) and CMS information model that defines potential for such solutions in the QRDA, category III, for ambulatory relationships between patients and future. measures in § 170.205(k)(3).’’ Comments. Several commenters clinical concepts in a standardized 6. Electronic Health Information (EHI) recommended additional changes not format to enable electronic quality Export Criterion performance measurement and that considered in the Proposed Rule. For would allow for more consistent eCQM example, one commenter recommended We proposed to adopt a new 2015 reporting and improved interoperability ONC require that to be certified in Edition certification criterion referred to in clinical quality feedback between § 170.315(c)(1) ‘‘CQMs—record and as ‘‘EHI Export’’ in § 170.315(b)(10). The health systems and data registries. Other export,’’ § 170.315(c)(2), ‘‘CQMs— criterion’s conformance requirements commenters stated that FHIR standards import and calculate,’’ and were intended to support two contexts will likely strengthen standardized data § 170.315(c)(3) ‘‘CQMs—report,’’ a in which we believed that all EHI element availability and flexibility to Health IT Module be certified in a produced and electronically managed improve the types of eCQMs that may be minimum of 9 eCQMs instead of one by a developer’s technology should be developed, and suggested that CMS eCQM and that the § 170.315(c)(1) made readily available for export as a continue to work with the National criterion should require the ability to capability of certified health IT. First, Quality Forum, measure stewards, and export all patients for a given eCQM. we proposed in § 170.315(b)(10)(i) at 84 measure developers to advance both Currently, the ability to export a QRDA FR 7447 that health IT certified to this existing evidence-based measures (e.g., I file can be limited to one patient at a criterion would support single patient either administrative or hybrid time. Commenters noted that this EHI export upon a valid request by a measures) and evolving outcome limitation defeats the purpose of data patient or a user on the patient’s behalf. interoperability and does not advance Second, we proposed in Professionals. Available at: https:// the goals of ONC to increase access to § 170.315(b)(10)(ii) at 84 FR 7447 that ecqi.healthit.gov/qrda. data and the interoperability of Health the proposed criterion would support 51 https://ecqi.healthit.gov/qdm. IT Modules. And another commenter the export of all EHI when a health care

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00050 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25691

provider chooses to transition or migrate export’’ criterion at 84 FR 7446 of the stored at the time of certification by the information to another health IT system. Proposed Rule (§ 170.315(b)(10)). We product, of which the Health IT Module Third, we proposed in have considered commenters’ concerns, is a part. We emphasize that such § 170.315(b)(10)(iii) that the export support, and recommendations and ‘‘stored’’ data applies to all EHI and is format(s) used to support the exports adopted a revised version of this agnostic as to whether the EHI is stored must be made available via a publicly certification criterion. This final in or by the certified Health IT Module accessible hyperlink, including keeping certification criterion is designed to or in or by any of the other ‘‘non- the hyperlink up-to-date with the align with section 4006(a) of the Cures certified’’ capabilities of the health IT current export format. Act, which requires the Secretary, in product of which the certified Health IT At the time of the Proposed Rule, we consultation with the National Module is a part. The scope of EHI indicated our belief that this proposed Coordinator, to promote policies that applies across the product as a whole as certification criterion provided a useful ensure that a patient’s EHI is accessible a means to further promote the access, first step toward enabling patients to to that patient and the patient’s exchange, and use of EHI for the use have electronic access to their EHI and designees, in a manner that facilitates cases required to be supported by this equipping health care providers with communication with the patient’s certification criterion. The finalized better tools to transition patient EHI to health care providers and other scope of data included in the criterion another health IT system. We noted that individuals (84 FR 7447). In addition, export is discussed in greater detail this criterion would create a baseline this criterion complements other under the ‘‘Scope of Data Export’’ capability for exporting EHI. We provisions that support patients’ access (IV.B.6.c) section below. While the data that must be exported requested comments regarding the to their EHI and health care providers proposed single patient EHI export and has been more specifically scoped, the use of EHI, such as the secure, standard- the proposed database export certification criterion does not require a based API certification criterion functionalities, as well as the proposed specific standard format be used for the (proposed in 84 FR 7427 and finalized scope of data export and other criterion purposes of representing the exported in § 170.315(g)(10)), and also supports elements throughout the Proposed Rule EHI. We also modified the certification longitudinal data record development. section at 84 FR 7447 through 7449. criterion’s documentation requirements Therefore, we have finalized the Comments. Commenters generally in § 170.315(b)(10)(iii) to be more criterion with revisions. Notably, in supported the intent of the proposed concise. As finalized, the ‘‘EHI export’’ criterion to advance the response to comments on this criterion documentation required for the export access, exchange, and use of EHI. and the proposed information blocking format(s) used to support (b)(10)(i) and Commenters in favor of the criterion policies, we have adopted a focused (ii) functionality must be kept up-to- and its proposed conformance definition of EHI in § 170.102 and date and made available via a publicly requirements stated that it would foster § 171.102. For context purposes, the EHI accessible hyperlink. Additional innovative export capabilities and definition is focused on ‘‘electronic information is included under ‘‘Export inform areas where additional standards protected health information as defined Format’’ below. development could be needed. We also in 45 CFR 160.103 to the extent that it We appreciate the comments received received a variety of comments asking would be included in a designated regarding the specific data sets and data for adjustments to proposed record set as defined in 45 CFR transmission standards for this requirements. A majority of commenters 164.501’’ with additional caveats not certification criterion. We reiterate that requested revisions to the criterion, repeated here for briefness. Put simply, the finalized certification criterion is including calling for a defined set of the EHI definition represents the same specific to EHI, as defined, that can be data elements for export and specific ePHI that a patient would have the right stored at the time of certification by the data transport standards. Many to request a copy of pursuant to the product, of which the Health IT Module commenters offered recommended HIPAA Privacy Rule. This is a is part, and is not limited to a standards or requested that we provide regulatory concept with which the predefined data set or to specific data specific standards to reduce variation. industry has nearly 20 years of transmission standards. Developers are These commenters indicated that no familiarity. Health IT developers’ required to ensure the health IT defined standard could lead to broad customer base includes health care products they present for certification interpretation and potential providers who are HIPAA covered are capable of exporting all of the EHI inadequacies of the data export. Some entities, and in many cases developers that can be stored at the time of commenters expressed a medical record serve as HIPAA business associates to certification by the product. We keeping concern that the proposed their covered-entity customers. Thus, acknowledge that the amount of EHI standards-agnostic approach for the health IT developers should be exported and format in which such EHI export functionality could be accustomed to identifying ePHI so that is represented will differ by developer problematic, stating that the export their products support appropriately and products of which certified Health could create a dissonance if the EHI securing it, the fulfillment of patient IT Modules are a part. Each product renders health record content in a form access requests, and the identification presented for certification, of which the or format that is different from what a and reporting on breaches. They should, Health IT Module is a part, will likely provider produces or utilizes as output. therefore, be well prepared to identify vary in the amount of EHI it can store. Other commenters opposed the what EHI their product(s) would need to As a result, the amount of EHI that will adoption of this proposed criterion. export in order to support a patient’s need to be able to be exported in order These commenters expressed concern HIPAA right of access. The finalized to demonstrate conformance with this that later implementation of standards, criterion requires a certified Health IT certification criterion will vary widely such as APIs, would make developers Module to include export capabilities because of the diversity of products invest time and funding into the for a single patient (§ 170.315(b)(10)(i)) presented for certification. For example, proposed requirements only for the and patient population small software components only capable work to be discarded in the future. (§ 170.315(b)(10)(ii)) related to EHI. of storing a certain scope of EHI (and Response. We thank commenters for More specifically, the export(s) will only certified to a few certification their feedback on the proposed ‘‘EHI need to include the EHI that can be criteria) will only need to be able to

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00051 Fmt 4701 Sfmt 4700 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 the adoption and implementation data protection responsibilities under this certification criterion. In contrast, a timeline of technology that could either applicable laws and regulations. more comprehensive product with an add more structure to or remove the Comments. Comments received EHI storage scope well beyond all of the need for this certification criterion in included concerns with the adopted certification criteria would by the future. However, we do not accept development and use of the certification its nature need to demonstrate it could the promise of this future state as a criterion. Some commenters expressed export a lot more EHI. But even in this reason to simply wait, nor do we believe support for the criterion’s overall latter case, it is important to note that that the potential of this future justifies flexibility but cautioned ONC to be while that scope of EHI may be delaying the incremental progress the realistic regarding the goals and comprehensive for that product, it may industry can make. In this case, had we expectations for the certification still not be all of the health information followed such commenters direction, criterion. These commenters also for which a health care provider is the we would be withholding from patients expressed concern that the proposed steward and that meets the EHI and health care providers the certainty certification criterion would result in definition within the health IT products that there would be technical development for an ambiguous scope of deployed within their organization. In capabilities within a defined time that data export and would divert from work other words, a health IT user may have could be used to enable the access, needed to achieve other interoperability other health IT systems with no exchange, and use of EHI. We note that goals. Other commenters stated connection to the Certification Program suggestions by commenters to structure concerns that development costs could that store EHI and such EHI would still the certification criterion to only move potentially be passed onto health IT be in scope from an information information within specific data sets or users, such as health care providers. blocking perspective. We note all of via specific standards-based export These commenters also anticipated use these distinctions to make clear for and functionality would delay the ability of and implementation challenges for users to dissuade readers from jumping to an patients and users of health IT to access, that work with multiple systems. improper conclusion that the EHI export exchange, and use the information they Response. We thank commenters for criterion in the Certification Program is need and would run counter to the sharing their concerns. In regards to the a substitute for or equivalent to the EHI underlying principles supporting this use of the capabilities required by this definition for the purposes of certification criterion—that the certification criterion, we interpreted information blocking. We direct readers electronic health information should be from comments some confusion related to the information blocking section accessible for access, exchange, and use. to potential ‘‘users’’ of the health IT. As (VIII) for additional information. Unless For this reason, we have not included previously defined under the Program, a health care provider (which is an specific data set or export requirements ‘‘user’’ is a health care professional or their office staff; or a software program ‘‘actor’’ regulated by the information in this certification criterion as some or service that would interact directly blocking provision) only used a single commenters suggested. with the certified health IT (80 FR health IT product to store EHI that was In consideration of comments, the finalized ‘‘EHI export’’ criterion in 62611, 77 FR 54168). also certified to this certification We also appreciate the comments and criterion, the EHI definition will always § 170.315(b)(10) is not included in the 2015 Edition Base EHR definition, concerns regarding the potential be larger. Regardless of the amount of development burden that could result to EHI each product has within its scope which is a modification from what we proposed. We revised the policy in meet the requirements of the proposed to export, the purpose of this recognition of comments received, criterion. In consideration of those certification criterion is to make the EHI including comments regarding the expressed concerns, we have narrowed already available in such health IT structure and scope of the criterion as the scope of data that must be exported. products more easily available for proposed and the development burden This more focused scope should access, exchange, and use by patients of the criterion. As finalized here, we measurably reduce the stated ambiguity and their providers, which is a believe that including this certification by commenters and development fundamental principle established by criterion in the Conditions and burden for health IT developers in the Cures Act. Maintenance of Certification is the best contrast to what was proposed (84 FR As technology continues to advance, place to include the requirement 7448). We appreciate the concerns and as stated in the Proposed Rule at 84 associated with the criterion. Thus, we expressed for the potential user(s) of FR 7447, this criterion may not be have finalized the § 170.315(b)(10) Health IT Modules, but note that the needed in the future. However, the certification criterion as a general certification criterion is designed to comments suggesting we not adopt this certification requirement for the ONC advance the electronic movement of certification criterion at all because it Health IT Certification Program, and data out of a product while factoring in will be outmoded at some point in the have not included it in the 2015 Edition the current variability in health IT. As future did not appear to acknowledge Base EHR Definition. always, we encourage developers to that all technology is eventually In general, we also note that those seek innovative and expedient replaced for a variety of reasons. We too who use Health IT Module(s) certified to capabilities that, at minimum, meet the look forward to a day where standards- the ‘‘EHI export’’ criterion remain requirements of the certification based APIs are the predominant method responsible for safeguarding the security criterion, as well as the developing for enabling electronic health and privacy of individuals’ EHI needs of their health IT users. information to be accessed, exchanged, consistent with applicable laws and Comments. Commenters provided and used. We strongly encourage regulations related to health information alternative ideas for the criterion industry partners to engage in their own privacy and security, including the specific to USCDI. Some recommended consortiums, with ONC and other HITECH Act, HIPAA Privacy and amending the criterion to require the Federal agencies, and other stakeholders Security Rules, 42 CFR part 2, and State specific structure and applicable in the health IT ecosystem to advance laws. The existence of a technical standards for USCDI elements, or standards development, prototypes, and capability to make EHI more accessible starting this criterion with a minimum pilot testing in order to ultimately build and useable by Health IT Module users of USCDI data elements. Several a body of evidence that could accelerate does not alter or change any of their commenters recommended expanding

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00052 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25693

the existing 2015 Edition ‘‘data export’’ product of which the certified Health IT finalized as proposed in criterion to include USCDI in lieu of the Module is a part. The scope of EHI § 170.315(b)(10)(i)(D) that the export proposed ‘‘EHI export’’ criterion. applies across the product as a whole as files must be electronic and in a Response. We thank commenters for a means to further promote the access, computable format, we modified in sharing these ideas. We have finalized exchange, and use of EHI for the use § 170.315(b)(10)(ii)(E) that the publicly the ‘‘EHI export’’ criterion as described cases required to be supported by this accessible hyperlink of the export’s above. Our intent under this finalized certification criterion. format must be included with the criterion is to advance export exported file(s). This modification a. Single Patient Export To Support functionality for single patient and clarifies that the user is able to access Patient Access patient population EHI exports, while the format, and that the developer will leaving flexibility in regard to format As part of this criterion, we proposed keep their hyperlink up-to-date. and without assigning specific data sets a functionality for single patient EHI We appreciate commenter’s due to the different scopes of data that export at 84 FR 7447 which would recommendations for specific data health IT may include. Toward those enable a user of certified health IT to transmission formats and data content ends, limiting the scope of this timely create an export file(s), with the standards, and considered the range of certification criterion to solely the data proposed scope of data export of all of recommendations when developing the represented by the USCDI would make the EHI the health IT product produces finalized scope of data export required it no different than other USCDI and electronically manages on a single for this criterion. We believe the bounded certification criteria already patient. The functionality would also definition of EHI as focused in adopted and would not advance the require a user to be able to execute this § 171.102, as well as the modifications policy interests we have expressed. In capability at any time the user chooses to the scope of data export, addresses regards to comments on the existing and without subsequent developer the data ambiguity concerns received by 2015 Edition ‘‘data export’’ criterion assistance to operate. In addition, we commenters. We direct readers to our (§ 170.315(b)(6)), we refer readers to our proposed that health IT certified to this detailed discussion of the scope of data discussion of the criterion below. criterion would be required to enable export below. As finalized, the Comments. Some comments the ability to limit the users who could certification criterion’s export, for both expressed confusion and asked for create such export file(s) in at least one single and patient population EHI guidance on how this certification of two ways: To a specific set of Export, remain standards-agnostic. We criterion would apply to health IT that identified users, and (2) as a system believe that the finalized certification is no longer certified. Commenters also administrative function. We also criterion will serve as an initial step asked for guidance on how this criterion proposed that the export file(s) created towards increased access, exchange, and applies to other systems that interact must be electronic and in a computable use of electronically available data. We with Health IT Modules certified to this format and that the export file(s) format, will continue working alongside criterion based on the proposed scope of including its structure and syntax, must industry stakeholders and will revisit data for export. be included with the exported file(s). export strategies as standards continue Response. We thank commenters for Comments. We received many to develop and mature. We appreciate requesting clarification. We first clarify comments in support of the proposal for confirmation that commenters support that the export functionality under this single patient export to support patient inclusion of the criterion in certification criterion applies to Health access under the certification criterion. § 170.315(b)(10) alongside the rest of the IT Modules presented for certification The majority of these commenters care coordination criteria in under the Program. More specifically, if provided recommended revisions, § 170.315(b), and have finalized that this a health IT developer presents for including suggested transmission certification criterion is part of the real certification a health IT product of formats and data export content world testing Condition of Certification which a Health IT Module is a part and standards. Some commenters requirement. the product electronically stores EHI, recommended the addition of this Comments. Some commenters asked certification to § 170.315(b)(10) is certification criterion to the list of ONC to clarify how health IT developers required. As noted in our response criteria subject to real world testing. may limit the users’ ability to access and above, this would include the EHI that Response. We thank commenters for initiate the export function in can be stored at the time of certification their feedback. We have finalized the § 170.315(b)(10)(i), and to include by the product, of which the Health IT single patient export functionality in examples of potential permissible and Module is a part. This includes all EHI § 170.315(b)(10)(i) with some non-permissible behaviors. stored by the product’s certified and modifications. We finalized a focused Response. We appreciate the ‘‘non-certified’’ capabilities. For data export scope, which applies to the comments received. We again clarify example, if a health IT product includes data expected to be available for export that ‘‘user’’ is a health care professional a component(s) that is presented for under the single patient export or their office staff; or a software certification and that component stores capability. We defined the scope of data program or service that would interact EHI, then that EHI must be made that needs to be exported to EHI that can directly with the certified health IT (80 available for export, in accordance with be stored at the time of certification by FR 62611, 77 FR 54168). In regards to § 170.315(b)(10). Importantly, the scope the product, of which the Health IT questions on permissible behaviors for of data required to be exported in Module is a part. Thus, we have developers, the ability to limit the accordance with § 170.315(b)(10) modified the title of § 170.315(b)(10)(i) health IT users’ access to the single includes only to the EHI that can be to ‘‘single patient electronic health patient EHI export functionality in stored at the time of certification by the information export’’ to reflect the scope § 170.315(b)(10)(i) is intended to be product. We emphasize that such of this data export. We finalized that the used by and at the discretion of the ‘‘stored’’ data applies to all EHI and is capability for a user to execute a single organization implementing the agnostic as to whether the EHI is stored patient export must be able to be limited technology. We reiterate that similar to in or by the certified Health IT Module at least one of two ways: To a specific the 2015 edition ‘‘data export’’ criterion or in or by any of the other ‘‘non- set of identified users, and as a system in § 170.315(b)(6), this cannot be used certified’’ capabilities of the health IT administrative function. While we by health IT developers as a way to

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00053 Fmt 4701 Sfmt 4700 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 user- members or from deciding to share this with the health IT developer, an ONC– driven aspect of this capability (80 FR information with family members or ACB, or ONC. 62646). We do not wish to limit this others, including their health care Comments. Some commenters functionality to specific permissible or providers. Thus, individuals are free to requested specific stakeholder non-permissible behaviors at this time, provide their doctors with a complete exemptions from this requirement, such but reaffirm in § 170.315(b)(10)(i)(B) that family medical history or communicate as health plans. a user must be able to execute the single with their doctors about conditions that Response. We thank commenters for patient EHI export capability at any time run in the family. To the degree that, for the recommendations. We note that the the user chooses and without example, Patient A’s medical record ‘‘EHI export’’ criterion is applicable subsequent developer assistance to include that their mother had breast only to health IT products presented by operate. To be clear, the user must be cancer, that information would be developers for certification under the able to execute the export without the accessible to Patient A because it was Program that meet the criterion and intervention of the developer. We also provided by Patient A and included as ‘‘Assurances’’ Condition of Certification finalize, as proposed, in part of their medical record. Under this requirements in § 170.402. In addition, § 170.315(b)(10)(i)(C) that this capability criterion, patients would not have a we note that the information subject to must limit the ability of user who create ‘‘right’’ to other patient’s records, the export requirements is EHI that can such export files(s) in at least one of two consistent with existing laws. In be stored at the time of certification by ways; (1) to a specific set of identified general, with respect to patient access to the product, of which the Health IT users, and (2) as a system administrative information, we note that Health IT Module is a part. function. Module users must ensure that any i. EHI Export for Patient-Initiated Comments. The majority of comments disclosures of data conform to all Requests received asked for further clarity on applicable laws and regulations, In the Proposed Rule, we reiterated ‘‘timely’’ regarding a health IT user’s including but not limited to alignment that the ‘‘user’’ of the single patient request to create an export file(s). between this rule and the HIPAA Response. We thank commenters for export functionality would typically be Privacy Rule, as discussed in IV.B.6 a provider or their office staff on behalf the questions. We specify that ‘‘timely’’ above. We also refer readers to the means near real-time, while being of the patient (80 FR 62611, 77 FR information blocking section at VIII in 54168). We also recognized that in reasonable and prudent given the this preamble, as well. circumstances. service to innovative and patient-centric Comments. Commenters also sought Comments. Commenters requested approaches, a health IT developer could clarity on data in electronic health clarity on how ONC will monitor a develop a method that allows a patient records that may be shared between developer’s compliance with exporting to execute the request for data export patients and possibly included in the in a timely manner and what penalties without needing a provider to do so on export. These commenters asked if ONC will impose if there is a delay in their behalf. Under this scenario, we under the proposed criterion, patients regards to a Health IT Module user’s sought comments on whether the single have a right to information about others request. Commenters requested ONC patient export functionality should be that may be contained in their medical release sub-regulatory guidance that made more prescriptive and require that record. describes how users may file complaints the developers design the health IT to Response. We thank commenters for and recommended ONC work with the allow only the patient and their submitting these questions. In regards to HHS Office for Civil Rights (OCR) on authorized representative to be the shared patient data concerns, we note patient education. requestor of their EHI (84 FR 7447). that the export functionality Response. Any noncompliance by Comments. In the scenario of patient- requirements apply to what a product developers with the finalized ‘‘EHI centric approaches created by with a Health IT Module certified to this export’’ certification criterion developers, the majority of commenters criterion must be able to do regardless (§ 170.315(b)(10)) or the associated were in favor of developers designing of whether the developer is operating Conditions and Maintenance of the export capability to make the patient the export for a health care provider or Certification requirements (e.g., and their authorized representative able a health care provider is maintaining § 170.402(a)(4) and (b)(2)) would be to be the direct requestors of their EHI and operating the technology in their subject to review, corrective action, and without needing a provider to execute own production environment. Under enforcement procedures under the this capability on their behalf. We also the HIPAA Privacy Rule, when a Program. We refer readers to the received recommended terms to further covered health care provider, in the enforcement (VII) and information define ‘‘authorized representative’’ course of treating an individual, collects blocking (VIII) sections of this preamble under this scenario. Several commenters or otherwise obtains an individual’s for further information. We do not advised against specifying or restricting family medical history, this information believe there is a general need to work the potential additional user roles able may become part of the medical record with OCR further on this particular to initiate a single patient export. Some for that individual and thus be included issue or to issue further sub-regulatory commenters recommended additional in the ‘‘designated record set’’ (defined guidance. The functionality of the ‘‘EHI requirements for developers, including at 45 CFR 164.501)). Thus, if the family export’’ criterion in § 170.315(b)(10) requiring developers to create this medical history becomes part of the provides a user (e.g., a health care capability to enable the patient or their designated record set, the individual/ provider) with the ability to export a file ‘‘proxy’’ to request their information patient may exercise the right of access for a single patient and multiple through and receive information from (45 CFR 164.524) under the HIPAA patients. If a user or other stakeholder the patient’s health portal or an Privacy Rule to this information in the has concerns about ongoing compliance application. Commenters asked for the same fashion as any other information of health IT certified to this criterion, final rule to include clarification on in the medical record. The HIPAA with the required functionality of the what the patient and their authorized Privacy Rule does not prevent criterion, or the associated Conditions representative can access. We did individuals, themselves, from gathering and Maintenance of Certification receive some comments that requested medical information about their family requirements, they may file a complaint clarification of this potential approach.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00054 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25695

We also received comments expressing transitions between health IT systems. to create an industry-wide approach. We confusion with the patient and Many commenters recommended format do acknowledge the comments received authorized representative requests and content specifications, such as the that data structured for one system may applying across the certification use of bulk FHIR®-based APIs for export not necessarily seamlessly align with criterion, as opposed to the proposed transmission. Some commenters another, and refer commenters to the and previously defined ‘‘users’’ of stressed that ONC should determine and export format requirements of this health IT that will typically perform the require standards, as well as clarify the certification criterion. As finalized in request on behalf of a patient. scope of data export specific to this use § 170.315(b)(10)(ii)(A), the export Response. We thank commenters for case. Some commenters expressed created must be electronic and in a their input and requests for clarification. concerns, including gathering patient computable format. In contrast with the In response to the concerns and consent and the developer burden that single patient EHI export capability, potential confusion, we clarify the may exist with gathering data from which must be available to a user following. This certification criterion disparate systems under the proposed without subsequent developer does not require ‘‘direct-to-patient’’ scope terminology. One commenter was assistance to operate, the patient functionality in order to demonstrate against the transitions between health IT population EHI export capability of this conformance. Providing such a systems capability, citing that data criterion could require action or support capability and demonstrating structured for one system will not on the part of the health IT developer. conformance to this certification necessarily work in another. criterion with such a capability would Response. We thank commenters for We acknowledged in the Proposed Rule be at the sole discretion of the health IT their feedback specific to the (84 FR 7448) that because of anticipated developer. In general, just like with the functionality of transitions between large volume of electronic health ‘‘data export’’ criterion in health IT systems under this criterion. information that could be exported § 170.315(b)(6), the capability to execute We finalized this export functionality under this specific proposed capability, this certification criterion can be health with modifications. First, this developer action or support could be care provider/health care organization functionality is now referred to as needed. Our thinking remains the same initiated (presumably upon that ‘‘patient population electronica health post-public comments even with the organization receiving a request by information export’’ in narrowed scope of data export. While patient for their EHI). In instances § 170.315(b)(10)(ii) to better reflect the exporting one patient’s data on an as- where the functionality certified to this policy intent of patient data transitions needed basis is a capability that should criterion is implemented in a ‘‘direct-to- in instances of providers switching be executable by a user on their own, patient’’ way such that the patient can health IT systems, and to reflect the orchestrating an entire export of EHI for request and accept EHI export without finalized scope of data that a product migration to another health IT system is assistance from a user, we recognize that with a certified Health IT Module must an entirely different task and dependent further configuration of the be capable of exporting. Similar to the on a variety of factors such as the functionality or product in which it is modifications in § 170.315(b)(10)(i), we organization’s overall infrastructure and implemented may be needed in order to finalized in § 170.315(b)(10)(ii)(A) that deployment footprint. Additionally, account for applicable laws related to the export files must be electronic and developers of health IT certified to this the patient’s information access rights in a computable format and we criterion are required to provide the and other privacy and information modified in § 170.315(b)(10)(ii)(B) that assurances in § 170.402, which include blocking policies that apply to the the publicly accessible hyperlink of the providing reasonable cooperation and configuration and use of the Health IT export’s format must be included with assistance to other persons (including Module. While this specific capability the exported file(s). This modification customers, users, and third-party within the certification criterion clarifies that the user is able to access developers) to enable the use of emphasizes health IT developer the format, and that the developer will interoperable products and services. assistance must not be needed to keep their hyperlink up-to-date. Thus, while developers have flexibility operate the export, we recognize that In response to comments on defining regarding how they implement the user assistance (e.g., a provider) may be a separate scope of data export specific export functionality for transitions necessary to initiate such capability in to the patient population export between systems, they are ultimately the user’s product. functionality, it is our final policy for responsible for ensuring that the this certification criterion to align both capability is deployed in a way that b. Patient Population EHI Export for the single patient and patient Transitions Between Health IT Systems enables a customer and their third-party population export data to EHI, as contractors to successfully migrate data. In addition to the single patient defined in this rule, that can be stored Such cooperation and assistance could export functionality in at the time of certification by the include, for example, assisting a § 170.315(b)(10)(i), we proposed in product, of which the Health IT Module customer’s third-party developer to § 170.315(b)(10)(ii) that health IT is a part. This narrower scope also automate the export of EHI to other certified to this criterion would also addressed concerns received regarding systems. We refer readers to the export facilitate the migration of EHI to another development burden expressed format section below for additional health IT system. We proposed that a regarding gathering data from disparate details. health IT developer or health IT systems under the proposed scope certified to this criterion must, at a terminology. We note that the narrowed scope of user’s request, provide a complete In regards to the comments on data that certified Health IT Modules export of all EHI that is produced or enforcing format and standards for data must be capable of exporting does not electronically managed (84 FR 7447 transmission, it is our intent under this reduce contractual obligations of health through 7448) by means of the certification criterion that health IT IT developers to continue to support developer’s certified health IT. developers have flexibility regarding providers if they do want to change Comments. We received many how the export outcome is achieved. We systems, and direct readers to the comments in support of the again encourage the industry to work information blocking section (VIII) for functionality under this criterion for together toward this common goal and additional information.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00055 Fmt 4701 Sfmt 4700 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 alignment with other regulations and export functionalities as well as the We proposed in 84 FR 7448 and in data standards, such as the USCDI. We Conditions and Maintenance of § 170.315(b)(10) that for both use cases also received a recommended Certification requirements tied to this supported by this criterion, the scope of requirement for health IT developers to criterion. data that the certified health IT product provide a plain language definition of First, we agree with comments received and acknowledge that a health must be capable of exporting would the EHI typically included in their IT developer is best positioned to know encompass all the EHI that the health IT Health IT Module’s export. Some (and would be solely responsible for system produces and electronically commenters expressed confusion on only) the EHI that can be stored by the manages for a patient or group of how the criterion’s proposed scope of health IT product at the time the Health patients. Our intention was that data export may apply to EHI ‘‘produced IT Module is presented for certification. ‘‘produces and electronically manages’’ or electronically managed’’ by both the In response to comments regarding the would include a health IT product’s product’s certified and ‘‘non-certified’’ capabilities as well as data from third applicability of the scope of export to entire database. In the Proposed Rule, parties. the product’s certified and ‘‘non- our use of the term EHI was deliberate. Response. We thank commenters for certified’’ capabilities, as well as data At the time of rulemaking, the proposed feedback on our proposed terms and for from third parties, we clarify and definition of the EHI term in § 171.102 specific recommendations. The reiterate the following from our prior was intended to support the consistency finalized criterion draws the upper responses. We emphasize that such and breadth of the types of data bound of its data scope from the focused ‘‘stored’’ data applies to all EHI and is envisioned by this proposed criterion. definition of EHI as finalized. The agnostic as to whether the EHI is stored We requested comment on the criterion export includes the EHI, as in or by the certified Health IT Module terminology used (‘‘produces and defined, that can be stored at the time or in or by any of the other ‘‘non- electronically manages’’) or whether of certification by the product, of which certified’’ capabilities of the health IT there were alternatives to the proposed the Health IT Module is a part. As product of which the certified Health IT language. defined in this rule, EHI means Module is a part. To be clear, Comments. Some commenters were electronic protected health information conformance ‘‘at the time of supportive of our proposed scope of as defined in 45 CFR 160.103 to the certification’’ means the combined data data export requirements, while a few extent that it would be included in a that can be stored by the product, of others offered alternative specific designated record set as defined in 45 which the Health IT Module is a part, terminology options. Those commenters CFR 164.501 (other than psychotherapy at the time the Health IT Module is suggested terminology such as all EHI notes as defined in 45 CFR 164.501 or presented for certification. As such, for the health IT system ‘‘collects and information compiled in reasonable the purposes of this certification retains,’’ or ‘‘produces or can anticipation of, or for use in, a civil, criterion, the EHI that must be exported electronically access, exchange, or use.’’ criminal, or administrative action or does not include any data generated A majority of commenters, however, proceeding), regardless of whether the from unique post-certification in stated that the proposed terminology, actor is a covered entity as defined in 45 response to a particular customer including the proposed EHI definition, CFR 160.103. In response to comments (though such data could meet the left broad interpretations of the scope of received, this revised scope of data for definition of EHI for the purposes of data a Health IT Module would have to export provides a more manageable and information blocking). Such be capable of exporting under this less administratively burdensome modifications could include custom criterion. These commenters expressed certification criterion for health IT interfaces and other data storage concerns that the ambiguity and developers for several reasons. systems that may be subsequently and potentially vast amounts of data would We agree with commenters that our uniquely connected to a certified Health create undue burden on health IT proposed terms of all EHI a health IT IT Module post-certification. developers for development and upkeep system ‘‘produces and electronically Additionally, to remain consistent with of export capabilities, as well as manages’’ (84 FR 7448) raised the ‘‘at the time of certification,’’ we clarify compliance issues with other applicable potential for broad variance in that any new EHI stored by the product laws. A majority of commenters interpretations and concerns about the due to ongoing enhancements would requested and highlighted a need for breadth of data intended for export need to be included within the scope of further specificity regarding the under this criterion and potential certification only when a new version of terminology used to define data development burden. We also the product with those new EHI storage exported under this criterion. Some considered the comments noting that a capabilities is presented for certification commenters expressed concerns that a developer presenting a Health IT and listing on the CHPL. In developer presenting a Health IT Module for certification may not, at the consideration of comments, we believe Module for certification may not know time of certification, know all systems a that this approach to define storage at all systems a user may later connect to user will later connect to the health IT the time the product is presented for the health IT capabilities. We also capabilities. Ultimately, we considered certification of a Health IT Module will received many comments reflecting several approaches to better reflect the make the certification requirements varied thoughts on what should or policy intent and to alleviate confusion more clear for health IT developers and should not be included in the criterion’s related to the proposed criterion. In more efficient to administer from a data export. Some commenters strongly consideration of the public comments Program oversight perspective. opposed any data limits, citing existing and the policy outcome we sought to In addition, the use of ‘‘can be stored regulations such as the HIPAA Privacy address, we revised the final criterion‘s by’’ refers to the EHI types stored in and Rule right of access, while others phrasing to describe what information by the health IT product, of which the proposed alternatives to constrain data health IT products with Health IT Health IT Module is a part. This is export requirements, citing Module(s) certified to the criterion must meant to be interpreted as the development infeasibility. be capable of exporting. The revised combination of EHI a heath IT product Recommendations to constrain the scope of data export applies to both the stores itself and in other data storage proposed criterion’s scope included single patient and patient population locations. Thus, the cumulative data

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00056 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25697

covered by these storage techniques which they asserted would assist health certification criterion applies are links would be in the scope of data export. care providers in delivering care. Other to images/imaging data (and not the Per our policy intent, by focusing the commenters expressed burden concerns images themselves, which may remain definition of EHI and defining the data with data image export, particularly in a PACS) then only such links must for export under this criterion, users of challenges around the movement and be part of what is exported. We certified Health IT, such as health care storage of large amounts of data and encourage developers to work with their providers, will have the ability to create accumulating data from disparate health customers to achieve innovative ways to ‘‘readily producible’’ exports of the IT systems. A few commenters share all relevant data, including information of a single patient upon requested specific exclusion of images situations outside of the scope of data request by the user, which increases or videos created as a byproduct of export under this criterion where patient access as reflected in the Cures procedures. As for minimum image data images could be made more accessible. Act. Lastly, in support of the second elements to share, recommendations ii. Attestation of Information a Health IT functionality we finalized for patient varied and included Digital Imaging and Developer Cannot Support for Export population export, the EHI exported Communications in Medicine (within the Health IT product’s scope of (DICOMTM) data elements or file type In the Proposed Rule (84 FR 7448), we data export) would likely be of recommendations. Comments included also solicited comment on whether we significant importance to health care additional policy recommendations, should require, to support transparency, providers for the purposes of such as making Picture Archiving and health IT developers to attest or publish transitioning health IT systems and Communication Systems (PACS) as part of the export format maintaining continuity of care for developers subject to certification rules documentation the types of EHI they patients, and also helps remove and requiring EHI export data to include cannot support for export. We did not potential barriers to users switching links for remote authorized access to have any specific proposals. systems to meet their needs or their externally hosted images. Comments. The majority of patient’s needs. Response. We thank commenters for commenters supported public In finalizing this policy, we their shared insight and attestation regarding the information a emphasize that health IT developers recommendations regarding the export Health IT Module is unable to export. may provide the export of data beyond of images, imaging information, and Some commenters requested that we the scope of EHI and for functionalities image elements. Health IT Modules add to the regulatory text to state that beyond those discussed under this certified to the finalized criterion must developers attest to information they criterion. In such cases, for additional electronically export all of the EHI, as cannot support for export ‘‘and/or export purposes, it is advised that defined, that can be stored at the time ingestion.’’ Some commenters health IT developers and users discuss of certification by the product, of which questioned if it is fair for EHI developers and agree to appropriate requirements the Health IT Module is a part. Thus, to delineate what is in their Health IT and functionalities. We again emphasize any images, imaging information, and Module’s scope of data for export under that health IT product users must ensure image elements that fall within this this criterion. Another felt that this that any disclosures of data conform to finalized scope of EHI that can be stored requirement should be extended to all applicable laws, including the at the time of certification in or by the health care delivery organizations and HIPAA Rules and 42 CFR part 2. product, of which the Health IT Module that the attestation should be included Stakeholders should review applicable is a part will need to be exported under within patient portals or other laws and regulations, including those this certification criterion. We communications. regarding patients’ right of access to appreciate the recommendations Response. We thank commenters for their data, in order to determine the received for image transfer methods and their feedback. We again note the appropriate means of disclosing patient encourage the stakeholder community revised scope of data export under this data. We also refer readers to the to continue exploring innovative image finalized criterion. Under the finalized information blocking section at VIII. transfer methods, including for image approach, which focuses on the export transfer that would fall outside of this of the EHI that can be stored at the time i. Image, Imaging Information, and certification criterion. We appreciate the of certification by the product, we have Image Element Export policy recommendations, such as determined that our final requirements In the Proposed Rule, we noted at 84 including PACS developers. The ‘‘EHI provide sufficient clarity and have not FR 7448 that clinical data would export’’ certification criterion only included any additional requirements encompass imaging information, both applies to developers of health IT such as those on which we sought images and narrative text about the seeking or maintaining certification comment. Additionally, we believe the image. However, we addressed that under the Program. To the extent such recommendation for ingestion would be EHRs may not be the standard storage providers are developers of health IT impracticable as part of this certification location for images. We solicited under the Program they would be criterion due to the flexibility we permit additional feedback and comments on included. If they are not developers for the output format(s). It would not be the feasibility, practicality, and under the Program, they would not be possible from a regulatory enforcement necessity of exporting images and/or included. perspective to administer a certification imaging information. We requested We also thank commenters for their criterion that included within its scope comment on what image elements, at a suggestions to require data export to a conformance requirement for a Health minimum, should be shared such as include links for remote authorized IT Module’s capability to import any image quality, type, and narrative text. access to externally hosted images. We proprietary format that may exist We did not make any proposals in 84 FR note that the export requirements of this without prior knowledge of such 7448. certification criterion refers to the EHI formats. Comments. Most commenters were that can be stored at the time of supportive of sharing images and/or certification by the product, of which iii. Export Exclusion Request for related data elements, expressing that the Health IT Module is a part. In the Comments interoperability should include context of imaging, if the only EHI In the Proposed Rule, we proposed electronic ordering of imaging studies, stored in or by the product to which this metadata categories at 84 FR 7448 for

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00057 Fmt 4701 Sfmt 4700 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 using the developer’s certified Health IT accessible hyperlink of the export’s requested feedback on what metadata Module(s). We also proposed in format must be included with the elements should remain included for § 170.315(b)(10)(iii) that the developer’s exported file(s). We clarify that the export or added to the list of excluded export format must be made available hyperlink must allow any person to data. Metadata proposed for exclusion via a publicly accessible hyperlink and directly access the information without from the criterion included metadata kept up-to date. any preconditions or additional steps. present in internal databases used for Comments. Comments received were We note that the export format need not physically storing the data, metadata in favor of this proposal in be the same format used internally by that may not be necessary to interpret § 170.315(b)(10)(iii). Several the certified health IT and the health IT the EHI export, and metadata that refers commenters were supportive of the developer does not need to make public to data that is not present in the EHI flexibility of export format for their proprietary data model. This export. Examples of these proposed developers, as long as export certification criterion also does not exclusions are provided at 84 FR 7448. documentation is provided as specified prescribe how (i.e., media/medium) the Comments. Commenters offered in the Proposed Rule, citing specifically exported information is to be made varied recommendations for metadata how this would support the export available to the user, as this may depend elements to remain excluded, or to be capability in § 170.315(b)(10)(ii). Some on the size and type of information to included under the scope of data export commenters recommended additional be exported. While file formats and for this criterion. We received several clarification for the publicly accessible related definitions are not finalized as comments strongly supporting the hyperlink, specifically to ensure that specific certification requirements, we inclusion of audit log metadata. information is available without login or encourage developers to continue to Commenters noted that the inclusion of other associated requirements. foster transparency and best practices audit log metadata had potential legal Commenters also provided export for data sharing, such as machine- utility and could aid in the patient’s format suggestions. readable format, when they create and ability to have all of their data and Response. We thank commenters for update their export format information. knowing who has accessed their data. their feedback regarding developers’ Commenters also requested increased export format. We have finalized e. Initial Step Towards Real-Time clarity on the definition of metadata, § 170.315(b)(10)(iii) with modifications Access audit log, and access log in regards to to clarify the regulatory text. We In the Proposed Rule at 84 FR 7449, this rulemaking, and requested the use finalized that the export format(s) used we offered a clarifying paragraph to of standards to further clarify policy to support § 170.315(b)(10)(i) and highlight that the criterion in intentions. We note, however, that other § 170.315(b)(10)(ii) of this section must § 170.315(b)(10) was intended to commenters were against the inclusion be kept up-to-date. provide a step in the direction of real- of audit log data as part of the EHI We clarify that the documentation for time access goals, as well as a means to, export. Those against inclusion stated the export format(s) in within the confines of other applicable that this information was not necessary § 170.315(b)(10)(iii) consists of laws, encourage mobility of electronic to interpret the EHI export, could be information on the structure and syntax health data while other data transfer burdensome for development of export for how the EHI will be exported by the methods were maturing. In that section, capabilities, and potentially contain product such as, for example, C–CDA we clarified that ‘‘persistent’’ or personally identifiable information of document(s) or data dictionary for ‘‘continuous’’ access to data is not the health care staff. comma separated values (csv) file(s), required to satisfy the proposed ‘‘EHI Response. We thank commenters for and not the actual EHI. The user will export’’ criterion’s requirements, and their input on potential metadata use the export format documentation to that the minimum requirement of exclusions. As noted above, we have process the EHI after it is exported by developers presenting Health IT finalized that EHI that can be stored at the product. We also require that health Module(s) for certification to this the time of certification by the product IT developers keep the export format(s) criterion is for a discrete data export is the scope of data that must be used to support § 170.315(b)(10)(i) and capability. In this clarification section, included in exports pursuant to § 170.315(b)(10)(ii) must be ‘‘up-to- we did not have specific proposals or § 170.315(b)(10). Under this revised and date.’’ For example, if the health IT requests for comments. specified scope of data export, it is no developer had previously specified the Comments. We received longer necessary to list specific C–CDA standard as the export format for recommendations to further specify the metadata exclusions or inclusions. We meeting the criterion, but subsequently use of ‘‘persistent’’ and ‘‘continuous’’ in direct readers to the discussion of scope updated their product to use the FHIR context of access to EHI. Additional of data export (IV.B.6.c) under this standard and stopped supporting commenters recommended specifying criterion for further details. C–CDA export format then the Representational state transfer (REST) or documentation for export format would ‘‘RESTful’’ transfer, or specifying data d. Export Format need to be updated so that users are able transport methods. We did not propose a content to continue to accurately process the Response. We thank commenters for standard for the export. However, we EHI exported by the product. We their input. We first clarify that this did propose to require documentation in appreciate suggestions received section was added to the Proposed Rule § 170.315(b)(10)(iii) that health IT regarding ensuring that such for additional clarification and to developers include the export file(s) information is available without login or provide prospective context on the format, including its structure and other associated requirements. In proposed certification criterion. syntax, such as a data dictionary or response to these comments, our policy However, we recognize from the export support file, for the exported intent to foster transparency, and in comments received that our reference to information to assist the user requesting alignment with other certification ‘‘persistent’’ or ‘‘continuous’’ access in the information in processing the EHI criterion requirements set forth in this the Proposed Rule may have created (84 FR 7448). This was to prevent loss rule, we note our modifications in confusion. We again note that of information or its meaning to the § 170.315(b)(10)(i)(E) and ‘‘persistent’’ or ‘‘continuous’’ access is extent reasonably practicable when § 170.315(b)(10)(ii)(B) that the publicly not required by health IT developers

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00058 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25699

presenting Health IT Module(s) to exported. In turn, when these the ‘‘data export’’ certification criterion, satisfy the requirements of this capabilities are deployed in production we have maintained the ‘‘data export’’ certification criterion. We have finalized they will need to be capable of certification criterion in § 170.315(b)(6) the ‘‘EHI export’’ criterion as described exporting all of the EHI that can be as available for certification until 36 above in response to comments received stored at the time of certification by the months after this final rule’s publication on proposals we have made. We product, of which the Health IT Module date. To implement this decision, we appreciate the responses to our future is a part. We also agree with the points have finalized in § 170.550(m) that looking points in the Proposed Rule but received regarding the HIPAA Privacy ONC–ACBs are permitted to issue have not made further revisions to the Rule right of access at 45 CFR 164.524 certificates to ‘‘data export’’ in final certification criterion in response. and emphasize the importance of § 170.315(b)(6) until, but not after, 36 HIPAA covered entities aligning with f. Timeframes months after the publication date of this applicable law regarding patient access final rule. However, we note the ‘‘data We requested input and comments on to health information. export’’ certification criterion has been the criterion and timeframes at 84 FR removed from the 2015 Edition Base 7449. In particular, beyond the proposal g. 2015 Edition ‘‘Data Export’’ Criterion in § 170.315(b)(6) EHR definition (in § 170.102) as of the to export all the EHI the health IT general effective date of this final rule system produces and electronically We proposed to remove the ‘‘data (60 days after its publication in the manages, we sought comment on export’’ criterion (defined in Federal Register). During the 36 months whether this criterion should include § 170.315(b)(6)) from the 2015 Edition immediately following publication of capabilities to permit health care Base EHR definition in § 170.102 and to this final rule, developers will be able providers to set timeframes for the EHI replace ‘‘data export’’ with the proposed to maintain the certification to export, such as only the ‘‘past two ‘‘EHI export’’ criterion (defined in § 170.315(b)(6) as a standardized means years’’ or ‘‘past month’’ of EHI (84 FR § 170.315(b)(10)) by amending the third of exporting the discrete data specified 7449). paragraph of the 2015 Edition Base EHR in the CCDS, but the criterion will not Comments. A majority of commenters definition in § 170.102. We did not be updated to the USCDI. Given that were against the concept of allowing propose a transition period for the ‘‘data certification to the § 170.315(b)(6) providers to set timeframes for the export’’ criterion. Rather, we proposed criterion will no longer be available export functionality. Commenters were to remove the criterion from the 2015 after 36 months, we do not believe an concerned that creating the capability to Edition Base EHR definition upon the update to the USCDI is the best path. limit timeframes would involve effective date of a final rule. We also Rather, § 170.315(b)(6) will remain an significant technical complexity for proposed to modify the 2015 Edition unchanged criterion in the Program for health IT developers. Commenters also Base EHR definition to include the new the 36 months immediately following expressed concern that allowing proposed export criterion (defined in publication of this final rule in the providers the capability to limit § 170.315(b)(10)), with an Federal Register. After that timeframe, timeframes would not align with the implementation date 24 months from the EHI export criterion in HIPAA Privacy Rule right of access at 45 the effective date of the final rule. We § 170.315(b)(10), including that CFR 164.524 and could potentially welcomed comments on this approach. implicate information blocking. Comments. Some commenters were in certification criterion’s scope of data Commenters provided alternative favor of immediate removal of this export, will remain an available data approaches and concepts to implement criterion (§ 170.315(b)(6)) from the 2015 export certification criterion for health timeframe capabilities for this criterion, Edition Base EHR definition, stating it IT developers that present for including use of APIs, granting would reduce burden. However, the certification a Health IT Module that is flexibility to developers, allowing majority of commenters were against a part of a heath IT product which intervals or dynamic timeframe potential gap in functionality due to the electronically stores EHI. This approach requirements, and considering compliance timeline for the new export will support prior investments in permitted fees. Commenters asked for criterion (§ 170.315(b)(10)) and § 170.315(b)(6) by developers and their clarification on how far back the data requested that we keep the ‘‘data customers, and also encourage request capabilities could go and export’’ criterion until the new criterion movement toward the interoperability requested clarification regarding how in § 170.315(b)(10) and other opportunities afforded by new criteria. this criterion aligns with other API- standardized data transmission methods Regarding commenter concerns that related criteria within this rule. were fully implemented. Some the ‘‘data export’’ criterion is Response. We thank commenters for commenters supported an indefinite inconsistent with CMS QPP their feedback. We will not require the retention of the ‘‘data export’’ criterion, requirements, such as View, Download Health IT Module support a specific or regardless of the proposed addition of and Transmit (VDT), we do not believe user-defined timeframe range or time § 170.315(b)(10). Several commenters that this criterion would be inconsistent limit capability for the purposes of also recommended to expand the with QPP program requirements. In the demonstrating conformance to this current § 170.315(b)(6) criterion through CY 2019 Physician Fee Schedule final certification criterion. We agree with USCDI as an alternative approach to the rule, CMS removed the VDT measure in commenters concerns regarding proposed ‘‘EHI export’’ criterion in § 170.315(e)(1) (83 FR 59814). However, potential development complexity for § 170.315(b)(10). In addition, some the Promoting Interoperability health IT developers if we included commenters expressed concern that that performance category of QPP currently such a requirement upfront. What this the ‘‘data export’’ criterion is includes the measure entitled Provide means, however, is that for the purposes inconsistent with CMS Quality Payment Patients Electronic Access to their of testing and certification, a health IT Program (QPP) requirements such as Health Information (83 FR 59812 developer will need to prove that the View, Download, and Transmit (VDT) at through 59813), and CMS has identified product, of which a Health IT Module 83 FR 59814 of the CY 2019 Physician technology certified to the ‘‘View, is part, can perform the capabilities Fee Schedule final rule. Download and Transmit to 3rd party’’ required by the certification criterion, Response. In consideration of public criterion at 45 CFR 170.315(e)(1) as inclusive of all EHI that could be comments in support of the retention of required to meet this measure (83 FR

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00059 Fmt 4701 Sfmt 4700 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 supports multi-factor authentication implement any of the approved § 170.315(b)(6) is not required for the (§ 170.315(d)(13)). We did not propose encryption methods in order to attest Provide Patients Electronic Access to to require that health IT have these ‘‘yes’’ to this criterion. We noted that their Health Information measure authentication and encryption-related health IT developers should keep included in the Promoting functions, but instead proposed that a apprised of these standards as they Interoperability performance category, health IT developer must indicate evolve and are updated to address nor have we proposed to change the whether or not their certified health IT vulnerabilities identified in the current ‘‘View, Download and Transmit to 3rd has those capabilities by attesting ‘‘yes’’ standard. party’’ criterion in § 170.315(e)(1) or ‘‘no.’’ We did, however, propose to We did not propose that a Health IT required for this measure, thus we do include the two criteria in the 2015 Module would be required to be tested not believe this final policy will conflict Edition privacy and security to the ‘‘encrypt authentication with CMS requirements for QPP. certification framework (§ 170.550(h)). credentials’’ certification criterion. For clarity, attesting ‘‘yes’’ to either of Rather, by attesting ‘‘yes,’’ the health IT 7. Standardized API for Patient and these criteria indicates that the Health developer is attesting that if Population Services Criterion IT Module can support either Approach authentication credentials are stored, We proposed to adopt a new API 1 or Approach 2 of the 2015 Edition then the authentication credentials are criterion in § 170.315(g)(10) at 84 FR privacy and security certification protected consistent with the encryption 7449. In response to comments, we are framework for these criteria. requirements above. We proposed in 84 adopting a Standardized API for Patient We note that we received many FR 7450 that the attestations ‘‘yes’’ or and Population Services criterion for comments on the proposed ‘‘encrypt ‘‘no’’ would be made publicly available Certification in § 170.315(g)(10) with authentication credentials’’ and ‘‘multi- on the Certified Health IT Product List modifications. The new criterion, will factor authentication’’ criteria, but the (CHPL). We proposed in 84 FR 7450 replace the old ‘‘application access— majority of comments conflated the two that, for health IT certified prior to the data category request’’ certification proposals and provided collective final rule’s effective date, the health IT criterion (§ 170.315(g)(8)). In doing so, responses. Therefore, we have would need to be certified to the we are also adding the Standardized API responded to them in kind to preserve ‘‘encrypt authentication credentials’’ for Patient and Population Services the integrity of the comments. certification criterion within six months criterion to the updated 2015 Edition after the final rule’s effective date. For a. Encrypt Authentication Credentials Base EHR definition and removing the health IT certified for the first time after application access—data category We proposed in 84 FR 7450 to adopt the final rule’s effective date, we request criterion (§ 170.315(g)(8)). This an ‘‘encrypt authentication credentials’’ proposed that the health IT must meet finalized Standardized API for patient certification criterion in § 170.315(d)(12) the proposed criterion at the time of and population services certification and include it in the P&S certification certification. criterion requires the use of the FHIR framework (§ 170.550(h)). We proposed We also noted that some Health IT Release 4 and several implementation to make the ‘‘encrypt authentication Modules presented for certification are specifications. The new criterion credentials’’ certification criterion not designed to store authentication focuses on supporting two types of API- applicable to any Health IT Module credentials. Therefore, we specifically enabled services: (1) Services for which currently certified to the 2015 Edition requested comment on whether we a single patient’s data is the focus and and any Health IT Module presented for should include an explicit provision in (2) services for which multiple patients’ certification that is required to meet the this criterion to accommodate such data are the focus. Please refer to the ‘‘authentication, access control, and health IT. We stated that this could be ‘‘Application Programming Interfaces’’ authorization’’ certification criterion similar to the approach we utilized for section (VII.B.4) in this preamble for a adopted in § 170.315(d)(1) as part of the 2015 Edition ‘‘end-user device more detailed discussion of the ‘‘API’’ Program requirements. encryption’’ criterion certification criterion and related Encrypting authentication credentials (§ 170.315(d)(7)(ii)), where we permit Conditions and Maintenance of could include password encryption or the criterion to be met if the health IT Certification requirements. cryptographic hashing, which is storing developer indicates that their health IT encrypted or cryptographically hashed is designed to prevent electronic health 8. Privacy and Security Transparency passwords, respectively. If a developer information from being locally stored on Attestations Criteria attests that its Health IT Module end-user devices. In 2015, the HIT Standards Committee encrypts authentication credentials, we (HITSC) recommended the adoption of proposed in 84 FR 7450 that the b. Multi-Factor Authentication two new ‘‘authentication’’ certification attestation would mean that the Health We proposed in 84 FR 7450 to adopt criteria for the Program (81 FR 10635). IT Module is capable of protecting a ‘‘multi-factor authentication’’ (MFA) The National Coordinator endorsed the stored authentication credentials in criterion in § 170.315(d)(13) and include HITSC recommendations for accordance with standards adopted in it in the P&S certification framework consideration by the Secretary, and the § 170.210(a)(2), Annex A: Federal (§ 170.550(h)). We proposed to make the Secretary determined that it was Information Processing Standards (FIPS) ‘‘multi-factor authentication’’ appropriate to propose adoption of the Publication 140–2, ‘‘Approved Security certification criterion applicable to any two new certification criteria through Functions for FIPS PUB 140–2, Security Health IT Module currently certified to rulemaking. To implement the Requirements for Cryptographic the 2015 Edition and any Health IT Secretary’s determination, we proposed Modules.’’ We posited that FIPS Module presented for certification that two new criteria to which health IT Publication 140–2 is the seminal, is required to meet the ‘‘authentication, would need to be certified (84 FR 7450). comprehensive, and most appropriate access control, and authorization’’ These would require the developer to standard. Moreover, in the specified certification criterion adopted in attest to whether the Health IT Module FIPS 140–2 standard, there is an § 170.315(d)(1) as part of Program for which they are seeking certification allowance for various approved requirements. To provide clarity as to to the criteria encrypts authentication encryption methods, and health IT what a ‘‘yes’’ attestation for ‘‘multi- credentials (§ 170.315(d)(12)) and/or developers would have the flexibility to factor authentication’’ attestation would

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00060 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25701

mean, we provided the following given the risks involved with single- provided by such transparency can aid explanation. MFA requires users to factor authentication and how easy it is health IT users in making informed authenticate using multiple means to today to implement MFA. We also decisions on how best to protect health confirm they are who they claim to be received a number of comments information and comply with applicable in order to prove one’s identity, under requesting that we clarify that the MFA security regulations (e.g., the HIPAA the assumption that it is unlikely that an proposal does not create a requirement Security Rule). unauthorized individual or entity will for health care providers to implement Comments. Some commenters who be able to succeed when more than one MFA or encryption of authentication supported the proposed criteria token is required. MFA includes using credentials. Similarly, we received requested clarification on the scope and two or more of the following: (i) several comments seeking clarification intent of the criteria, including what Something people know, such as a that a ‘‘yes’’ attestation would only level of authentication and which types password or a personal identification require support of MFA, not that MFA of users and user roles the criteria apply number (PIN); (ii) something people would have to be implemented. Along to, as well as on how to attest for have, such as a phone, badge, card, RSA these same lines, several commenters multiple sign-on paths. A number of token or access key; and (iii) something expressed concerns that the commenters noted the wide variation in people are, such as fingerprints, retina requirements could interfere with authentication needs and approaches scan, heartbeat, and other biometric clinical care and urged that the throughout the industry, and they information. Thus, we proposed in 84 requirements not contribute to provider recommended that we permit health IT FR 7451 that in order to be issued a burden. developers to describe how they support certification, a health IT developer must Response. We have adopted both authentication, rather than simply attest attest to whether or not its Health IT proposed privacy and security ‘‘yes’’ or ‘‘no.’’ The commenters stated Module presented for certification transparency attestation criteria and that such information would provide supports MFA consistent with industry- included both criteria (§ 170.315(d)(12) helpful clarity regarding what the recognized standards (e.g., NIST Special and § 170.315(d)(13)) in the P&S certified health IT supports. Publication 800–63B Digital certification framework (§ 170.550(h)), Additionally, several commenters stated Authentication Guidelines, ISO with minor modifications. While some that we should require that health IT 27001).52 commenters recommended that MFA developers explain how they support We proposed in 84 FR 7451 that, for should be a requirement for all certified MFA. A number of commenters stressed health IT certified prior to the final health IT, we did not propose such a that MFA may not be appropriate or rule’s effective date, the health IT would requirement nor could health IT applicable in all situations, and in need to be certified to the ‘‘multi-factor developers have foreseen such an particular, several commenters noted authentication’’ certification criterion outcome in this final rule based on our that automated transactions, including within six months after the final rule’s proposals, particularly considering the some that may occur in the public effective date. For health IT certified for clarity provided with our proposals (84 health reporting context, cannot support the first time after the final rule’s FR 7450) and the complexities of such MFA. effective date, we proposed that the a requirement. For example, as noted by Response. In response to requests for health IT must meet this criterion at the commenters below, MFA may not be modifications and clarifications, we time of certification. We solicited appropriate or applicable in all have modified the ‘‘encrypt comment on the method of attestation situations and there is wide variation in authentication credentials’’ criterion to and, if the health IT developer does authentication needs and approaches permit a health IT developer that attests attest to supporting MFA, whether we throughout the industry. These criteria ‘‘no’’ for its Health IT Module(s) to should require the health IT developer will, however, still provide increased indicate why the Health IT Module(s) to explain how they support MFA. In transparency, and if a developer attests does not support encrypting stored particular, we asked whether a health IT ‘‘yes’’ to these criteria regarding a authentication credentials. A health IT developer should be required to identify certified Health IT Module, that Health developer that attests ‘‘no’’ to the the MFA technique(s) used/supported IT Module will then be subject to ONC– ‘‘encrypt authentication credentials’’ by submitting specific information on ACB surveillance for any potential non- criterion may explain, for example, that how it is implemented, including conformity with the requirements of its Health IT Module is not designed to identifying the purpose(s)/use(s) to these criteria. Given the strong support store authentication credentials, which MFA is applied within their expressed in public comments for these therefore there is no need for the Health Health IT Module, and, as applicable, criteria as proposed, we believe this is IT Module to encrypt authentication whether the MFA solution complies the appropriate approach at this time. credentials because it does not store, or with industry standards. While we believe that encrypting have the capability to store, Comments. The vast majority of authentication credentials and MFA authentication credentials. commenters supported the adoption of represent best practices for privacy and For the ‘‘MFA’’ criterion, consistent the two proposed privacy and security security in health care settings, we with our solicitation of comments and transparency attestation certification emphasize again that these criteria do the comments received recommending criteria. A few commenters were not require certified health IT to have that health IT developers explain how opposed to the new criteria. Several these capabilities or for health IT they support MFA, we have modified supporters of the proposed criteria developers to implement these the criterion to require health IT recommended that we make the criteria capabilities for a specific use case or any developers that attest ‘‘yes’’ to describe operative functional requirements use case. Equally important, the criteria the use cases supported. For example, a (including testing), rather than yes/no place no requirements on health IT health IT developer could attest ‘‘yes’’ to attestations. Some of these commenters users, such as health care providers, to supporting MFA and state that the reasoned that MFA should be a implement these capabilities (if present Health IT Module supports MFA for requirement for all certified health IT, in their Health IT Modules) in their remote access by clinical users, thus health care settings. However, we note providing clarity on the user roles to 52 NIST Special Publication 800–63B: https:// that information regarding the security which MFA applies for that particular pages.nist.gov/800-63-3/sp800-63b/cover.html capabilities of certified health IT Health IT Module. To be clear, health IT

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00061 Fmt 4701 Sfmt 4700 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 Module seeking certification for the first applying security tags to HL7 CDA specific technical details about how time to the criteria specified in the 2015 documents to ensure that privacy they support MFA that could pose Edition privacy and security policies established at a record’s source security risks. Again, the purpose is to certification framework (§ 170.550(h)), can be understood and enforced by the enable health IT developers to give an after the effective date of this final rule, recipient of the record. indication of the types of uses for which will need to meet these privacy and The utility of the DS4P standard is not their Health IT Module(s) support MFA. security transparency attestation criteria limited to data subject to the Federal We note that health IT developers may at the time of certification. Similarly, a regulations governing the wish to add new MFA use cases for previously certified Health IT Module Confidentiality of Substance Use their certified health IT over a period of that has undergone revision, such as Disorder Patient Records, 42 CFR part 2 time. In such instances, to provide the removal of certain capabilities, and is (80 FR 62647). DS4P may be clarity sought in the Proposed Rule as presenting for revised certification to implemented to support other data to the MFA technique(s) used/supported the criteria specified in the 2015 Edition and how MFA is implemented, privacy and security certification exchange use cases in which including identifying the purpose(s)/ framework (§ 170.550(h)) after the compliance with State or Federal legal use(s) to which MFA is applied within effective date of this final rule, will need frameworks require special protections their Health IT Modules, any new MFA to meet these privacy and security for sensitive health information. use cases are required to comply with transparency attestation criteria at the Security tagging capabilities are an this criterion’s ‘‘yes’’ attestation time of certification. We believe that initial step towards enabling an provisions and be part of the quarterly this approach will still provide the interoperable health care system to use CHPL reporting by health IT developers intended transparency as health IT will technical standards to permit and ONC–ACBs under § 170.523(m). need to be issued new certifications as appropriate access, use, or disclosure of If a health IT developer attests ‘‘no,’’ Health IT Modules are updated or sensitive health information in then it would not be required to explain certified to other new or revised criteria accordance with applicable policies and why its Health IT Module does not adopted in this final rule. At the same patient preferences. We understand and support authentication, through time, this approach should reduce acknowledge additional challenges multiple elements, of the user’s identity burden for health IT developers and related the prevalence of unstructured with the use of industry-recognized allow them more time to plan and data, sensitive images, and potential standards. We did not propose to prepare to meet these new transparency issues around use of sensitive health require an explanation for ‘‘no’’ requirements. information by clinical decision support attestation nor did we request comment systems. The adoption of document on allowing health IT developers to 9. Security Tags and Consent level data tagging for structured provide an explanation for a ‘‘no’’ Management Criteria documents would not solve these attestation like we did for ‘‘yes’’ In the 2015 Edition final rule, we issues, but could help move technology attestations (84 FR 7450–7451). adopted two ‘‘data segmentation for in the direction where these issues However, in an effort to provide privacy’’ (DS4P) certification criteria. could be addressed (80 FR 16841). One criterion, ‘‘DS4P-send’’ transparency and consistency for these Adoption of the 2015 Edition final (§ 170.315(b)(7)), includes capabilities privacy and security attestation criteria, rule DS4P criteria was consistent with for applying security tags according to we will also permit developers to earlier HIT Policy Committee (HITPC) the DS4P standard in § 170.205(o) at the provide a reason for attesting ‘‘no’’ in recommendations for the use of security order to provide more context. Such a document-level of a summary care tagging to enable the electronic reason may be due to MFA being record formatted to the C–CDA 2.1 implementation and management of inapplicable or inappropriate. In those standard in § 170.205(a)(4). The other disclosure policies that originate from cases, a developer could state, for criterion, ‘‘DS4P-receive’’ the patient, the law, or an organization, example, that the Health IT Module (§ 170.315(b)(8)), includes capabilities does not support MFA because it is for receiving a summary care record in an interoperable manner, so that formatted to the C–CDA 2.1 standard in electronic sensitive health information engaged in system-to-system public 53 health reporting and MFA is not § 170.205(a)(4) with document-level may be appropriately shared. The applicable. security tags according to the DS4P HITPC recommendations consisted of a Comments. We received several standard in § 170.205(o). As noted in the glide path for the exchange of 42 CFR comments requesting adjustment to the 2015 Edition final rule (80 FR 62646), part 2-protected data starting with the deadline for compliance to meet these certification to these criteria is not inclusion of Level 1 (document level criteria. We also received a number of required to meet the CEHRT definition tagging) send and receive functionality. comments recommending that we only for PI Programs. The HITPC also recommended apply both of the proposed criteria to Security tagging enables computer advancing the exchange of 42 CFR part new certifications and new Health IT systems to recognize the existence of 2-protected data, by outlining additional Modules, and not to Health IT Modules sensitive elements in data and properly capabilities in sharing, viewing and already in widespread use. protect the privacy and security of the incorporating privacy restricted data at Response. Regarding the timeframe data by ensuring that only the a more granular level, as well as for compliance, and in response to appropriate individuals and entities can comments recommending that we only access it. Security tagging capabilities 53 See HIT Policy Committee (HITPC) apply the criteria to ‘‘new do not compromise the availability or Recommendation Letter to ONC, July 2 014, http:// www.healthit.gov/facas/sites/faca/files/PSTT_ certifications,’’ we have determined that comprehensiveness of health DS4P_Transmittal%20Letter_2014-07-03.pdf; see certification to these criteria as part of information available for treatment or also HITPC’s Privacy and Security Tiger Team the updated 2015 Edition privacy and research purposes; rather, they enable Public Meeting, Transcript, May 12, 2014, http:// security certification framework appropriate access controls in www.healthit.gov/facas/sites/faca/files/PSTT_ Transcript_Final_2014-05-12.pdf.; Public Meeting, (§ 170.550(h)) will only be necessary for accordance with existing policies, Transcript, May 27, 2014, http://www.healthit.gov/ Health IT Modules that are presented for governance, and applicable laws. The facas/sites/faca/files/PSTT_Transcript_Final_2014- certification. Thus, a new Health IT DS4P standard describes a method for 05-27.pdf.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00062 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25703

managing computable patient consent and OCR, such as the HHS Security Risk barriers and challenges near term, for the use of restricted data.54 Assessment Tool 55 and the Guide to including but not limited to the Since the 2015 Edition final rule, the Privacy and Security of Electronic perceived cost involved with successful health care industry has engaged in Health Information,56 as well as the segmentation in practice and indicated additional field testing and Office for Civil Rights’ security risk we should delay our finalization of the implementation of the DS4P standard. analysis guidance 57 that entities may proposal. Others felt immediate As of the beginning of the fourth quarter employ to make risk-based decisions adoption of our proposal in the final of the 2019 calendar year, 34 Health IT regarding their implementation of the rule was critical for patient care and the Modules were certified to one or both of proposed DS4P criteria. We also noted secure exchange of sensitive health the current 2015 Edition DS4P the availability of the Electronic information. Many commenters in favor certification criteria (Health IT Modules Consent Management Landscape of our proposal provided examples of with multiple certified versions were Assessment, Challenges, and use cases which it could support, such counted once). Stakeholders have Technology report.58 The report as helping to combat the opioid crisis by shared with ONC—through public includes suggestions for overcoming facilitating the secure exchange of forums, listening sessions, and barriers associated with implementing sensitive health information across correspondence—that document-level electronic consent management, which health care settings and including security tagging does not provide may be considered for further research substance use disorder (SUD) enough flexibility to address more and discussion. information covered by 42 CFR part 2. complex privacy and security use cases. We note that we received many We also received support of our Stakeholders noted that certain provider comments on the proposed DS4P proposal for the protection of women’s types, such as pediatrics and behavioral criteria and the proposed consent health—the commenter explained that health, often rely on burdensome management for the API criterion but segmenting at the element level would manual workflows to appropriately the majority of comments conflated the protect individuals who have segment and share sensitive health two proposals and provided a collective experienced intimate partner violence, information according to State and local response. We tried to separate where sexual assault, and other sensitive laws. Additionally, stakeholders possible, but in some instances, we kept experiences. Stakeholders shared with expressed interest in ONC adopting them combined in order to preserve the us that focusing certification on health IT standards that work with integrity of the comments. segmentation to only the document DS4P to support electronic consent for level does not permit providers the a. Implementation With the the exchange of security tagged data flexibility to address more granular Consolidated CDA Release 2.1 over an API. segmentation needs. We received many Therefore, in consideration of In place of the removed 2015 Edition comments on this proposal in the stakeholder feedback and HITPC DS4P criteria, we proposed (84 FR 7452) context of the following topics: provider recommendations to adopt DS4P to adopt new DS4P-send and developer burden; readiness of the certification criteria on a glide path, we (§ 170.315(b)(12)) and DS4P-receive standard and C–CDA exchange; proposed (84 FR 7452) to remove the (§ 170.315(b)(13)) criteria that would information blocking and EHI; future 2015 Edition DS4P-send remain based on the CDA 2.1 and the multidisciplinary activities (such as (§ 170.315(b)(7)) and DS4P-receive HL7 DS4P standard. These criteria workgroups) and creating a vision for (§ 170.315(b)(8)) certification criteria. would include capabilities for applying segmentation using health IT; safety; We proposed that the effective date of security tags according to the DS4P privacy policy conformity; suggested removal of these criteria would be the standard at the document, section, and use cases; cost; and requests for specific effective date of the final rule. We entry level. We believe this offers more clarifications. We describe these proposed to replace the removed DS4P valuable functionality to providers and comments further below. criteria with two new 2015 Edition patients, especially given the Response. We thank commenters for DS4P certification criteria in complexities of the landscape of privacy their input. To address the comments § 170.315(b)(12) and § 170.315(b)(13) laws for multiple care and specialty concerned about the cost and timing, at that would support security tagging settings. We stated in the Proposed Rule the current time, these criteria are according to the DS4P standard at the that we believe health IT certified to voluntary and not required under the document, section, and entry levels of these criteria would support multiple definition of CEHRT or to participate in C–CDA 2.1 formatted documents. Our practice settings and use cases. any HHS program. For more information primary purpose for proposing to Comments. We received many on the costs for the adoption of these remove and replace the criteria, in lieu comments both in support and against criteria, please see the Regulatory of proposing to revise them, was to this proposal. In certain instances, Impact Analysis in section XIII. For the provide clarity to stakeholders about the commenters were supportive of our reasons noted above, in this final rule, additional functionality enabled by aims but felt there were too many we have finalized our proposal to health IT certified to the new criteria. support a more granular approach to 55 HHS Security Risk Assessment Tool: http:// We also proposed a new 2015 Edition privacy tagging data consent certification criteria for sharing patient www.healthit.gov/providers-professionals/security- risk-assessment. management for health information consent information over an API using 56 ONC Guide to Privacy and Security of exchange supported by the C–CDA the Substance Abuse and Mental Health Electronic Health Information: http:// exchange standard. We do this not by Services Administration’s (SAMHSA) www.healthit.gov/sites/default/files/ pdf/privacy/ privacy-and-security-guide.pdf. removing and replacing the 2015 Consent2Share (C2S) IG a FHIR-based Edition DS4P criteria with new exchange standard, in § 170.315(g)(11). 57 HHS Office for Civil Rights: https:// www.hhs.gov/hipaa/for-professionals/security/ § 170.315(b)(12) and § 170.315(b)(13), We noted resources released by ONC guidance/index.html; and https://www.hhs.gov/ but by revising the 2015 Edition DS4P hipaa/for-professionals/security/guidance/ criteria, DS4P criteria DS4P-send 54 For more details on the two glide paths for part guidance-risk-analysis/index.html?language=es. 2-protected data, see http://www.healthit.gov/facas/ 58 https://www.healthit.gov/sites/default/files/ (§ 170.315(b)(7)) and DS4P-receive sites/faca/files/PSTT_DS4P_Transmittal%20Letter_ privacy-security/ecm_finalreport_ (§ 170.315(b)(8)), to include the full 2014-07-03.pdf. forrelease62415.pdf. scope of the HL7 DS4P standard for

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00063 Fmt 4701 Sfmt 4700 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, determine what they are going to do indicated that without this technical section and entry level with with that information. Policies and standard, it would be difficult for modifications as described below. procedures for what to do with the stakeholders to know whether Comments. We received many information once it is received are appropriate consent has been obtained comments regarding the perceived outside the scope of these criteria and prior to releasing health information. burden of segmentation on providers this final rule. However, we emphasize Further, the commenter indicated and developers including comments that health care providers already have concern that without such capabilities, focused on workflow challenges. One processes and workflows to address hospitals and health systems could be commenter indicated a lack of system their existing compliance obligations for accused of information blocking because and explained that tagging is State and Federal privacy laws, which they cannot verify that a patient has burdensome for implementers because it could be made more efficient and cost given consent for their EHI to be shared. does not describe how to determine effective through the use of health IT, They further commented that if ONC what information is sensitive and rather than relying on case-by-case does not finalize this criterion, then we should be tagged. Another indicated manual redaction and subsequent should provide an appropriate that DS4P creates a permanent added workarounds to transmit redacted exception in the information blocking burden of extensive and costly manual documents. We believe this tool may be provisions so that an entity is not data curation to redact each page to one part of innovative solutions to accused of information blocking because meet overlapping Federal and State support health IT enabled privacy they do not know if another regulations. Commenters indicated end segmentation in care coordination organization has obtained consent from users would be required to flag each workflows to significantly reduce the patients. One commenter stated ONC individual data element, a process that burden of these manual processes should propose a new information is time consuming and error prone. currently in practice. blocking exception that specifically They further explained that granular Comments. Several commenters clarifies that a health IT developer’s level privacy tagging has the risk of indicated that enhanced segmentation choice to not certify to an optional adding additional data entry burden to may unintentionally impact clinical standard cannot be a practice that provider workflows if users must tag care when providers are presented with implicates information blocking. each item individually. an incomplete picture of patient data. Response. We thank commenters for Response. We appreciate the Commenters stated there could be their support of the DS4P standard. thoughtful comments submitted on the patient care risks involved with not While we understand commenters’ proposed criteria. Notably, with respect sharing elements as users of concerns, we first reiterate the DS4P to the comments we received that downstream systems may not realize capability enables sensitive health expressed concern about the DS4P that a single element is filtered and act information to be exchanged standard due to the burden, our analysis improperly, such as by prescribing a electronically with security tags in a of the comments indicates that the contraindicated medication due to standardized format. It does not enable concerns the commenters express are missing information. the full segmentation of a patient’s more closely related to the complexity Response. DS4P is a technical record within an EHR, which may be of the privacy law landscape than to the standard for C–CDA that helps health necessary when responding to a request specific functionality and standard in care providers comply with existing, for EHI. Second, we have revised the our proposal. As noted above, at the applicable laws. As such, health care Infeasibility Exception in the current time, these criteria are voluntary providers should already have processes information blocking section of this and not required under the definition of and workflows in place to address their final rule to provide that an actor is not CEHRT or to participate in any HHS existing compliance obligations. The required to fulfill a request for access, program. The DS4P standard is a tool DS4P standard does not itself create exchange, or use of EHI if the actor and voluntary certification to these incomplete records. Under existing law, cannot unambiguously segment the criteria is an initial step towards patients already have the right to requested EHI from other EHI: (1) enabling an interoperable health care prevent re-disclosure of certain types of Because of a patient’s preference or system to use technical standards to data by withholding consent to its because the EHI cannot be made compute and persist security tags to disclosure or to place restrictions on its available by law; or (2) because the EHI permit access, use, or disclosure of re-disclosure. DS4P allows providers to is withheld in accordance with the sensitive health information. The electronically tag (mark) data as Harm Exception in § 171.201 criteria do not specify that a manual sensitive and express re-disclosure (§ 171.204(a)(2)). For instance, an actor workflow is required to implement restrictions and other obligations in an will be covered under this condition if security tagging, and we understand electronic form. DS4P does not the actor could not fulfill a request to from examples of DS4P use in practice determine whether a segmentation access, exchange, or use EHI because the that solutions may include the use of obligation exists legally or what that requested EHI could not be value sets to automate the tagging legal obligation means to the recipient. unambiguously segmented from patient process. We reiterate that these criteria Instead, DS4P allows for tagging and records created by federally assisted are intended to apply standards to the exchange of health information that has programs (i.e., Part 2 Programs) for the transmission of documents so that such already been determined to be sensitive treatment of substance use disorder (and security tags may be interoperable. and in need of special protections under covered by 42 CFR part 2) or from Though the updated criteria would existing law. records that the patient has expressed a support a more granular approach to Comments. We received comments in preference not to disclose. We refer tagging the sensitive information, we support of our proposal indicating that, readers to the Infeasibility Exception recognize that this will not solve the without data segmentation, other discussion in section VIII.D.1.d of this whole problem of how to manage data mandatory criteria, such as the final rule. segmentation for privacy and consent proposed ‘‘EHI export’’ criterion, would Comments. Many commenters noted a management. The recipient will still be difficult to implement without low level of adoption for these receive and can view the information risking disclosure of sensitive data or standards and concerns related to that is tagged—the recipient will need to information blocking. One commenter readiness expressing that the standard

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00064 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25705

utility is limited by lack of widespread solutions to replace burdensome manual recommendations for industry adoption developer implementation. Several privacy workflows. and implementation. One commenter in commenters encouraged ONC to defer Comments. Several commenters support of our proposal suggested such adoption of the DS4P criteria with a few called for the need to increase workgroup focus on including whether commenters recommending that the conformity among Federal and State additional standards are needed, as well optional 2015 Edition criterion should privacy provisions to achieve successful as data visualization of non-disclosed be maintained with document level implementation of granular tagging. data and its utilization in clinical tagging only until practical They noted the significant policy decision support algorithms. Several implementations at scale have been component involved with the successful commenters cited existing work to help demonstrated at this level. One implementation of the DS4P standard in support potential new multidisciplinary commenter suggested that organic practice, and in certain instances efforts indicating that one SDO has adoption by end-user providers will specifically noted support for HIPAA already undertaken early work toward help spark innovation in this emerging Privacy Rule and 42 CFR part 2 evolving DS4P implementation standard while expressing concern that harmonization. Several commenters guidance via the HL7 V2 to FHIR C–CDA level data tagging for privacy is identified specific areas for technical mapping project sponsored by the HL7 largely untested in real world scenarios. development of IT supporting data Orders Work Group. One commenter, Others encouraged ONC to provide segmentation for privacy based on called for an ONC led public-private additional guidance on the adoption of Federal and State privacy provisions. collaborative effort to reduce data entry the DS4P standards and certification One commenter indicated that ONC burden. One commenter recommended criteria and forgo the inclusion of this could map which clinical codes are that ONC stand up a multi-stakeholder requirement until additional real world associated with certain health workgroup to identify and define policy testing is available. They also indicated conditions that receive special privacy needs and functional requirements to ONC should first conduct use test cases protections in addition to the HIPAA address patient privacy and provider to demonstrate how this functionality Rules. Other commenters noted that needs. will be effectively used across a variety mapping of privacy policy to technical Response. We thank commenters for of environments. specifications is not a sufficient or their recommendations. ONC believes adequate approach given policy Response. We appreciate the that data segmentation is an integral complexities. One commenter indicated comments on the proposed criteria. In capability for exchanging sensitive a future approach should focus on health data. ONC first studied policy reference to the DS4P standard’s development of criteria that support a maturity, we note that it is considered considerations regarding data data provenance driven method of segmentation in electronic health a ‘‘normative’’ standard from the HL7 sensitive data management as applicable perspective—a status which indicates information exchange in 2010 and under privacy laws. informed ONC’s launch of the DS4P the content has been enhanced and Response. As we have stated, the Standards and Interoperability refined through trial use. While we DS4P standard enables sensitive health Framework (S&I Framework) Initiative recognize that to date the standard has information to be exchanged in 2011.59 The initiative focused on the not been widely adopted, the SAMHSA electronically with security tags in a development of a DS4P technical C2S application uses the standard to standardized format and we encourage specification that would allow highly segment Part 2 information. Likewise, health IT developers to include DS4P sensitive health information to flow the U.S. Department of Veterans Affairs functionality and pursue certification of more freely to authorized users while (VA) and private companies across the their health IT to these criteria in order country have used the DS4P standard to to help support their users’ compliance improving the ability of users of health support behavioral health and pediatric with relevant State and Federal privacy IT to meet their obligations under State care models. In addition, as of the fourth laws that protect sensitive health and Federal privacy rules. quarter of 2019, 34 individual Health IT information. We recognize that the Recommendations from the initiative Modules obtained certification to one of current privacy law landscape is called for the use of metadata security or both of the prior 2015 Edition complex. In light of the complexities of tags to demonstrate privacy and security certification criteria. Our intent for the privacy law landscape, we believe obligations associated with patient adopting the updates to these criteria is that supporting a standard that allows health information. It also advised that that in the absence of adoption of for increased granularity in security patients and providers be able to share consensus driven standards there is tagging of sensitive health information portions, or segments, of records in increased risk that single-use-case, would better allow for the interoperable order to maintain patient privacy. Pilot proprietary solutions will be developed, exchange of this information to support projects conducted under the DS4P S&I which may increase fragmentation, a wide range of privacy related use Framework Initiative demonstrated provider burden, and cost while cases. ways to enable the sharing of limiting interoperability. Further, the Comments. Many commenters offered information that is protected by Federal purpose of adopting these criteria is to an approach for next steps to advance and State laws, including the substance encourage the use of interoperable the standard. To advance adoption and use disorder treatment confidentiality standards, in this case to use technical implementation of the standard, several regulations, 42 CFR part 2. ONC’s prior standards to compute and persist commenters suggested that ONC work Federal Advisory Committee, the security tags upon exchange of a closely with clinicians, privacy subject HITPC, also focused on the health IT summary of care document in an matter experts and interoperability certification needed to enable exchange interoperable manner. In addition, the experts (notably the HL7 Privacy and of behavioral health data.60 certification criteria using the DS4P Security workgroups) to develop a clear Additionally, ONC led a project on standard are voluntary and therefore our vision for implementing enhanced data intent is, as commenters noted, to segmentation. Many commenters 59 https://archive.healthit.gov/providers- professionals/ds4p-initiative. support organic adoption of technology specifically called for ONC to sponsor or 60 https://www.healthit.gov/topic/Federal- certified to the criteria by providers lead a multidisciplinary workgroup of advisory-committees/health-it-policy-committee- seeking to implement health IT stakeholders to develop recommendations-national-coordinator.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00065 Fmt 4701 Sfmt 4700 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 a health record and data may be tagged for C–CDA-based data exchange and sensitive data was addressed.61 ONC at the document-level, the section-level, recommended ONC add FHIR-based also led a project on the Behavioral or individual data element-level. The standard for tagging of sensitive data. Health Data Exchange (BHDE) HL7 DS4P standard also provides a Several commenters expressed concern Consortium. The purpose of the project means to express obligations and over what they described as was to facilitate and address barriers to disclosure restrictions that may exist for misalignment of this proposal with the intra and interstate exchange of the data. We appreciate commenters other ONC policies explaining that behavioral health data.62 Currently, input on additional guidance beyond neither USCDI nor ARCH, nor HL7 FHIR ONC’s Leading Edge Acceleration these certification requirements that US Core includes the FHIR Composition Projects (LEAP) in Health Information may prove useful for developers. resource, which would be at the Technology (IT) program seeks to However, we reiterate that in this rule equivalent level of granularity as a C– address well-documented and fast we address only that guidance that is CDA document. emerging challenges inhibiting the required for those developers to Response. We thank commenters for development, use, and/or advancement voluntarily submit a Health IT Module their input and we appreciate the need of well-designed, interoperable health for certification to our criteria. for clarity requested by commenters. In IT. In 2019, one of the two LEAP awards Additional guidance on best practices the Proposed Rule (84 FR 7452), we issued by ONC focused on the would be outside the scope of this proposed both to adopt an update to the standardization and implementation of rulemaking. However, as noted above, HL7 DS4P standard for the existing 2015 the Fast Healthcare Interoperability we are committed to continuing to work Edition certification criteria to support ® Resources (FHIR ) Consent resource. with stakeholders, including health IT security tagging of a C–CDA upon send ® Under this project, a FHIR Consent developers and those involved in and receive by removing DS4P-send Implementation Guide (IG) and package implementing privacy policy in the (§ 170.315(b)(7)) and DS4P-receive of open-source prototypes and content health care industry, to work toward (§ 170.315(b)(8)) and replacing them ® to assist partners in using the FHIR interoperable solutions for privacy and with DS4P-send (§ 170.315(b)(12)) and Consent Resource will become consent management. DS4P-receive (§ 170.315(b)(13)) and to available.63 Comments. We received several also adopt a new criterion to support Also, ONC actively participates in ® comments seeking clarification on our API exchange via consent management HL7 International (HL7 ) Workgroups proposal to remove the current 2015 solutions using the FHIR standard. In and standards-development activities Edition ‘‘DS4P-send’’ (§ 170.315(b)(7)) other words, these were two separate related to data segmentation and and ‘‘DS4P-receive’’ (§ 170.315(b)(8)) proposals, the first to support security consent management. It is critical for certification criteria and to replace these tags in summary of care documents and sensitive health information to be two criteria with three new 2015 Edition another to support consent management included in health information DS4P certification criteria (two for C– for specific use cases that leverage a exchange and we are exploring CDA and one for a FHIR-based API). As FHIR-based API. As of this final rule, opportunities for additional examples, one commenter sought these criteria remain voluntary and not collaboration in the future. clarification on whether our proposal required under the definition of CEHRT Comments. One commenter was for DS4P send and receive to or to participate in any HHS program. recommended a companion guide be become mandatory for the revised 2015 We proposed these several criteria in a developed to assist implementers with Edition certification, or if they will single section of the Proposed Rule the standard. Another indicated ONC remain voluntary criteria. One because of the relationship between should provide guidance to facilitate commenter sought clarification on them as two potential health IT tools adoption of the DS4P standards and whether the data protections apply to that could be part of overarching certification criteria including FHIR transmissions. Another indicated solutions to manage privacy and dissemination of best practices to help that they believe the DS4P consent in health information exchange. ensure that providers can most implementation guide only focuses on However, as stated earlier, we note that effectively implement the standards and data segmentation for C–CDA neither of these tools addresses the associated workflows. Another referred documents and not for HL7 FHIR and entirety of the scope of data to a Query-Based Document Exchange sought ONC clarification regarding segmentation for privacy. To address the IG which has further guidance on the whether or not we intend to apply data comment on the DS4P implementation ability to assert access policies and segmentation labeling to the HL7 FHIR guide, we confirm that the HL7 DS4P DS4P implementation considerations. resources in support of the USCDI as standard in § 170.205(o)(1) describes the Response. The HL7 Version 3 well. Another commenter recommended technical means to apply security tags to Implementation Guide: Data that we require FHIR Release 4 version a health record and data may be tagged Segmentation for Privacy (DS4P), but commented that a consistent at the document-level, the section-level, Release 1, Part 1: CDA R2 and Privacy approach of USCDI across HL7 CDA, C– or individual data element-level in the Metadata Reusable Content Profile, May 64 CDA and HL7 FHIR is not attainable at C–CDA and not for FHIR. Currently, we 16, 2014 standard § 170.205(o)(1) this time. One commenter stated a do not intend to apply data (HL7 DS4P standard) describes the similar need for clarification indicating segmentation labeling to the HL7 FHIR technical means to apply security tags to that the standard for DS4P should be resources in support of the USCDI HL7 standards for CDA Version 2 and because all FHIR resources already 61 https://www.healthit.gov/topic/patient-consent- electronic-health-information-exchange. FHIR security tagging and not be the include the capability to apply security 62 https://www.healthit.gov/topic/health-it-health- SAMHSA C2S stating that ONC should tags to the resource as metadata. We care-settings/behavioral-health-data-exchange- clarify this misunderstanding. Another appreciate the recommendation to primary-care-and-behavioral. commenter sought clarification by ONC require FHIR Release 4 for consent 63 https://www.healthit.gov/topic/leading-edge- to indicate that the IG is for CCDS and management but as discussed below, we acceleration-projects-leap-health-information- technology-health-it. not FHIR, and also indicated confusion have decided not to finalize the 64 https://www.hl7.org/implement/standards/ regarding STU4. One commenter noted proposal for consent management for product_brief.cfm?product_id=354. that the DS4P criteria are only effective APIs in this final rule. For further

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00066 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25707

discussion of our FHIR-based consent • Revised criterion: ‘‘Security tags— provides instructions for using the FHIR management proposal, we direct readers Summary of Care (send)’’ Consent resource to capture a record of to subsection b below. (§ 170.315(b)(7)) includes capabilities a health care consumer’s privacy For the updates to the existing DS4P for creating a summary of care record preferences. criteria, to support greater clarity formatted to the C–CDA standard and In section VII.B.4 of this final rule, we requested by public comment, rather that is tagged as restricted and subject discuss policies related to the than removing the existing 2015 Edition to restrictions on re-disclosure implementation of a standardized API to criteria and replacing them with new according to the DS4P standard at the support the exchange of health criteria as proposed, we instead document, section, and entry (data information between providers and finalized a simple update to the existing element) level, or at the document-level patients and among members of a care criteria to note the use of the full HL7 for the period until May 2, 2022. team. In the Proposed Rule, we DS4P standard for tagging or applying • Prior criterion: ‘‘DS4P-receive’’ anticipated that the proposed 2015 security tags at the document, section, (§ 170.315(b)(8)) includes capabilities Edition ‘‘standardized API for patient and entry level. for receiving a summary care record and population services’’ certification We further note that these updated formatted to the C–CDA standard and criterion (§ 170.315(g)(10)) would result criteria remain voluntary, and that we document-level tagged as restricted (and in a proliferation of APIs that will have finalized modifications in subject to restrictions on re-disclosure) enable a more flexible and less § 170.315(b)(7)(ii) and according to the DS4P standard. burdensome approach to exchanging § 170.315(b)(8)(i)(B) to our proposed • Revised criterion: ‘‘Security tags— EHI. We stated our belief that the health effective date for this change to allow Summary of Care (receive)’’ care industry could leverage this API for a longer glide path for health IT (§ 170.315(b)(8)) includes capabilities infrastructure to share segmented data developers to update Health IT Modules for receiving a summary of care record in a secure and scalable manner. to the full standard to better support formatted to the C–CDA standard and Therefore, we proposed to adopt a 2015 clinical and administrative workflows. that is tagged as restricted and subject Edition certification criterion ‘‘consent While certification to the updated to restrictions on re-disclosure management for APIs’’ in standards will be available after the according to the DS4P standard at the § 170.315(g)(11) to support data effective date of this final rule upon document, section, and entry (data segmentation and consent management successful testing, we have finalized element) level, or at the document-level through an API in accordance with the that document-level tagging remains for the period until May 2, 2022. We Consent Implementation Guide. Comments. Overall, the majority of applicable for up to 24 months after the have finalized our proposal to include commenters were supportive of the publication date of this final rule. For in the voluntary ‘‘Security tags— concept of consent management for certification and compliance of Health Summary of Care (receive)’’ APIs but many had concerns with the IT Modules certified after 24 months (§ 170.315(b)(8)) criterion as a proposed criteria, specifically the after the publication date of this final requirement that the Health IT Module adoption of the Consent Implementation rule, only the full scope of the HL7 has the capability to preserve privacy Guide or the C2S platform as part of a markings to ensure fidelity to the DS4P standard is applicable. We have certification criterion. Many tagging based on consent and with finalized this 24 month period for the commenters raised concerns that the respect to sharing and re-disclosure update for these criteria under the real Consent Implementation Guide has not restrictions as proposed. world testing provisions in been balloted as an HL7 standard and § 170.405(b)(6) as follows: • b. Implementation With the Fast noted that C2S does not support a Security tags. A health IT developer Healthcare Interoperability Resources consenter’s signature or specification to with health IT certified to § 170.315 (FHIR®) Standard protect information content data (b)(7) and/or § 170.315 (b)(8) prior to requirements. A couple of commenters In collaboration with ONC, SAMHSA June 30, 2020, must: stated that the Consent Implementation Æ developed the C2Sapplication to Update their certified health IT to Guide is a new emerging standard in address the specific privacy protections be compliant with the revised versions pilot with feedback requested. for patients with substance use of the criteria adopted in § 170.315(b)(7) Commenters also raised concern that the disorders whose treatment records are and/or the revised versions of the IG has not gone through an SDO covered by the Federal confidentiality criteria adopted in § 170.315(b)(8); and process. Another commenter raised Æ regulation, 42 CFR part 2. C2S is an Provide its customers of the concern that SAMHSA no longer open source application for data previously certified health IT with supports the C2S platform and the segmentation and consent management. certified health IT that meets paragraph Consent Implementation Guide and it It is designed to integrate with existing (b)(6)(i) of this section by May 2, 2022, now lacks a steward. A couple of FHIR systems. SAMHSA created a FHIR In addition, we have finalized these commenters suggested ONC defer the implementation guide (the updated criteria with modifications to consent management criteria at least Consent2Share Consent Profile Design, the criteria names to better describe the until an API FHIR standard version is hereafter referred to as ‘‘Consent function the criteria support in finalized and the Consent Implementation Guide’’) that describes interoperable health IT systems. The Implementation Guide is revised to how the Consent2Share application and modifications to the criteria are as conform that to that version. One associated access control solution (C2S follows: commenter supported the adoption of • platform) uses the FHIR Consent Prior criterion: ‘‘DS4P-send’’ FHIR v3-based Consent resource, but resource to represent and persist patient (§ 170.315(b)(7)) includes capabilities urged ONC to also consider pediatric consent for treatment, research, or for creating a summary care record and geriatric use cases in its adoption. disclosure.65 The implementation guide formatted to the C–CDA standard and Other commenters stated that their document-level tagging as restricted 65 The draft FHIR IG titled ‘‘Consent2Share FHIR understanding was that tagging will be (and subject to restrictions on re- Profile Design.docx’’ can be accessed through the disclosure) according to the DS4P Community- Based Care and Privacy (CBCP) HL7 ‘‘BHITS_FHIR_Consent_IG,’’ at https:// standard. workgroup, within the Package Name titled gforge.hl7.org/gf/project/cbcc/frs/.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00067 Fmt 4701 Sfmt 4700 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 of FHIR releases and we appreciate requirements and note that there is no unclear how the proposal to move to comments received related to these substantial change to the standard. FHIR Release 2 would work. One questions. We direct readers to section We further note that health IT commenter questioned how if there are VII.B.4.c for further discussion of our developers must update Health IT no standards-based approaches for adoption in this rule the FHIR Release Modules to these updated standards identifying what in the record is 4 standard. We note that the Consent referenced in these criteria within 24 sensitive, how one could feasibly Implementation Guide is designed in months after the publication date of this implement privacy-tagging and consent FHIR Release 3 and that there is final rule. We have added as a management via FHIR at the Resource significant work to be done in standards Maintenance of Certification level and that tagging at a more granular development before the IG would be requirement for the real world testing level is too cumbersome and unrealistic. feasible with FHIR Release 4. At this Condition of Certification requirement, A number of commenters stated that the time, FHIR Release 4 version of FHIR that health IT developers are required to standards were premature and if consent resource is not normative and provide the updated certified health IT adopted could have unintended can change from version to version and to all their customers with health IT negative effects. Commenters were not therefore further development, review, previously certified to the identified supportive of having two versions of balloting, and testing would be required criteria no later than 24 months after the FHIR but instead recommended the use for a FHIR Release 4 based IG to be a publication date of the final rule. of FHIR Release 4. Commenters viable consensus standard for adoption Developers would also need to factor recommended ONC focus on driving in the Program. In consideration of these updates into their next real world real-world implementation experience comments, and the scope of the testing plan as discussed in section before adopting the standards. additional work required for readiness VII.B.5 of this final rule and in On the other hand, a few commenters of an IG that could be adopted in our § 170.405(b)(7). supported our proposal, and stated that regulations, we have not finalized the the C2S platform and the Consent proposed ‘‘consent management for C. Unchanged 2015 Edition Criteria— Implementation Guide is mature and APIs’’ certification criterion in Promoting Interoperability Programs already supports granular level security § 170.315(g)(11). We maintain, as stated Reference Alignment tagging and data segmentation and above, that the C2S platform and the In the FY 2019 IPPS/LTCH PPS supports several API standards listed in Consent Implementation Guide may still proposed rule (83 FR 20516), CMS the Proposed Rule. One commenter serve as a template for implementation proposed scoring and measurement expressed support broadly for the C2S of consent management workflows policies to move beyond the three stages platform indicating that, though it was leveraging APIs and that it may be a part of meaningful use to a new phase of originally designed to satisfy 42 CFR of health IT solutions to facilitate health EHR measurement with an increased part 2 consent for the substance use information exchange of sensitive focus on interoperability and improving disorder data, it supports the other information. We will continue to patient access to health information. To sensitive categories such as HIV and monitor the development of the Consent reflect this focus, CMS changed the mental health. Several commenters Implementation Guide and other FHIR name of the Medicare and Medicaid stated that the criteria should be resources to support consent EHR Incentive Programs, to the required in the Base EHR definition. management and may consider Many providers called for patient Medicare and Medicaid Promoting including in a future rulemaking. education and for ONC to work with Interoperability (PI) Programs. To align SAMHSA, OCR, and CMS. It was also 10. Auditable Events and Tamper- with the renaming of the EHR Incentive suggested that ONC coordinate with Resistance, Audit Reports, and Auditing Programs, we proposed to remove SAMHSA to establish a public-private Actions on Health Information references to the EHR Incentive project to advance the C2S platform and Programs and replace them with the Consent Implementation Guide Since adopting the Auditable events ‘‘Promoting Interoperability Programs’’ using an analogous process to that of the and tamper-resistance (§ 170.315(d)(2)), in the updated 2015 Edition ‘‘automated Da Vinci Project with transparency and Audit Reports (§ 170.315(d)(3)), and numerator recording’’ criterion in with no membership fees. Finally, Auditing Actions on health information § 170.315(g)(1) and the ‘‘automated several commenters raised issues that (§ 170.315(d)(10)) criteria in the 2015 measure calculation’’ criterion in are out of scope for this rule including Edition, there has been an update to § 170.315(g)(2). concerns specifically with the HIPAA ASTM E2147—1 standard and has been Comments. We did not receive any Rules or 42 CFR part 2 which are under replaced by a newer version. Given the comments on this proposal to remove the authority of OCR and SAMHSA older version has been deprecated and references to the EHR Incentive respectively. based on comments received, we have Programs and replace them with Response. We appreciate the updated these criteria with the most up ‘‘Promoting Interoperability Programs’’ comments received and the insights into to date standard, ASTM E1247—18 in in the updated 2015 Edition ‘‘automated real world implementing challenges of § 170.210(h). We have also updated the numerator recording’’ criterion in consent management. We agree that requirements to align with the new § 170.315(g)(1) and the ‘‘automated there is continued work to be done to numbering sequence of the updated measure calculation’’ criterion in ballot and field test the C2S platform standard. In order to meet the minimum § 170.315(g)(2). and the Consent Implementation Guide requirements for capturing and auditing Response. We have removed and also agree with commenters that electronic health information, we have references to the EHR Incentive identified this resource as having specified, in § 170.210(e)(1)(i), that the Programs and replaced them with significant potential to support consent data elements in sections 7.1.1 through ‘‘Promoting Interoperability Programs’’ management for specific use cases such 7.1.3 and 7.1.6, through 7.1.9 in ASTM in the 2015 Edition ‘‘automated as 42 CFR part 2, behavioral health, and E1247—18 are required. We believe that numerator recording’’ criterion in pediatric care. We also note that we had the updated standard reinforces what § 170.315(g)(1) and the ‘‘automated included a series of questions in our we have previously required and measure calculation’’ criterion in Proposed Rule related to the alignment maintained with previous certification § 170.315(g)(2).

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00068 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25709

V. Modifications to the ONC Health IT patient data for which a request for an tamper-resistance’’ certification Certification Program amendment would be relevant. criterion (§ 170.315(d)(2)). However, we Comments. One commenter expressed no longer require testing of activity A. Corrections support of the proposals under section history log when certifying for 1. Auditable Events and Tamper V (‘‘Modifications of the ONC Health IT § 170.315(d)(2). Therefore, this cross- Resistance Certification Program’’) of the Proposed reference is no longer applicable to meet We proposed to revise § 170.550(h)(3) Rule as a whole. However, we received certification requirements for the to require the End-User Device no comments specific to this proposal. updated 2015 Edition ‘‘view, download, Encryption criterion in § 170.315(d)(7) Response. We have finalized the and transmit to 3rd party’’ certification as appropriate, and exempt Health IT proposal with modifications. Health IT criterion (§ 170.315(e)(1)) activity Modules from having to meet Modules presented for certification to history log requirements. Consequently, § 170.315(d)(7) when the certificate these criteria do not have to we have finalized our proposal to scope does not require § 170.315(d)(7) demonstrate the capabilities required by remove § 170.315(e)(1)(ii)(B). the revised 2015 Edition ‘‘amendments’’ certification (see § 170.315(d)(2)(i)(C)) 4. Integrating Revised and New certification criterion (§ 170.315(d)(4)), (84 FR 7454). As noted in the Proposed Certification Criteria Into the 2015 unless the Health IT Module is Rule (84 FR 7454), paragraph Edition Privacy and Security presented for certification to another 170.315(d)(2)(i)(C) was not applicable to Certification Framework the privacy and security testing and criterion that requires certification to We proposed to require the new certification of a Health IT Module the 2015 Edition ‘‘amendments’’ certification criteria (§ 170.315(d)(12) required by § 170.550(h)(3)(iii), (v), (vii), criterion under the privacy and security and (d)(13)) to apply to all § 170.315 and (viii), but we intended for it to also (P&S) certification framework. We note certification criteria (84 FR 7454). be exempted from the aforementioned that, because we have not finalized our Therefore, given these and the other paragraphs. We, therefore, proposed to proposal to remove the ‘‘drug-formulary modifications discussed above, we revise § 170.550(h)(3)(iii), (v), (vii), and and preferred drug list checks’’ criterion proposed to revise the P&S Certification (viii) by removing references to in § 170.315(a)(10) and the ‘‘patient- Framework as shown in Table 1 of the paragraph 170.315(d)(2)(i)(C). specific education’’ criterion in Comments. One commenter expressed § 170.315(a)(13), but to only permit Proposed Rule (84 FR 7455), noting that support of the proposals under section ONC–ACBs to issue certificates for these the P&S Certification Framework when V (‘‘Modifications of the ONC Health IT criteria until January 1, 2022, we have finalized could differ depending on Certification Program’’) of the Proposed not removed references to these criteria finalization of proposals in section Rule as a whole. However, we received from the exemption in § 170.550(h) at III.B.4 of the Proposed Rule (84 FR 7436 no comments specific to this proposal. this time. This clarification has already and 7437) to remove certain 2015 Response. We have finalized the been incorporated into sub-regulatory Edition certification criteria. revision as proposed. Certification can guidance,67 and is now codified in Comments. One commenter expressed proceed for the audit log process regulation. support of the proposals under section without the Health IT Module V (‘‘Modifications of the ONC Health IT 3. View, Download, and Transmit to 3rd demonstrating that it can record an Certification Program’’) of the Proposed Party encryption status in accordance with Rule as a whole. However, we received § 170.315(d)(2)(i)(C). Paragraph We proposed to remove no comments specific to this proposal. Response. We thank the commenter § 170.315(d)(2)(i)(C) is not applicable for § 170.315(e)(1)(ii)(B), which includes a for their input regarding our proposals the privacy and security testing and cross-reference to § 170.315(d)(2) under section V (‘‘Modifications of the certification of a Health IT Module indicating that a Health IT Module may ONC Health IT Certification Program’’) required by § 170.550(h)(3)(iii), (v), (vii), demonstrate compliance with active of the Proposed Rule. We have adopted and (viii). We had previously identified history log requirements if it is also the revisions as proposed with this error in guidance,66 and have now certified to § 170.315(d)(2) (84 FR 7454). modifications. As noted in section codified the correction to Comments. One commenter expressed IV.B.8.a, we have also adopted both § 170.550(h)(3)(iii), (v), (vii), and (viii) support of the proposals under section proposed privacy and security in regulation. V (‘‘Modifications of the ONC Health IT Certification Program’’) of the Proposed transparency attestation criteria 2. Amendments Rule as a whole. However, we received (§ 170.315(d)(12) and (d)(13)) with We proposed to revise § 170.550(h) to no comments specific to this proposal. minor modifications. We have applied remove the ‘‘amendments’’ criterion’s Response. We thank commenters for § 170.315(d)(12) and (d)(13) to all application to certain non-applicable their support and have finalized the certification criteria across the P&S clinical criteria including: ‘‘Drug-drug, proposal to remove Certification Framework. Table 2 shows drug-allergy interaction checks for § 170.315(e)(1)(ii)(B), which includes a the final updated P&S Certification computerized provider order entry cross-reference to § 170.315(d)(2). As Framework, which includes all changes (CPOE)’’ in § 170.315(a)(4); ‘‘clinical noted in the Proposed Rule (84 FR including the removal of certain 2015 decision support (CDS)’’ in 7454), this cross-reference indicates that Edition certification criteria as finalized § 170.315(a)(9); ‘‘drug-formulary and a Health IT Module may demonstrate in section III.B.4 of this final rule. We preferred drug list checks’’ in compliance with activity history log updated the P&S Certification § 170.315(a)(10); and ‘‘patient-specific requirements if it is also certified to the Framework to reflect other changes education resources’’ in § 170.315(a)(13) 2015 Edition ‘‘auditable events and made throughout this final rule. The (84 FR 7454). The ‘‘amendments’’ privacy and security certification certification criterion § 170.315(d)(4) is 67 https://www.healthit.gov/test-method/drug- criteria applicable to a Health IT not necessarily indicated for health IT drug-drug-allergy-interaction-checks-cpoe; https:// Module presented for certification is www.healthit.gov/test-method/clinical-decision- based on the other capabilities included capabilities that may not have any support-cds; https://www.healthit.gov/test-method/ drug-formulary-and-preferred-drug-list-checks; and in the Health IT Module and for which 66 https://www.healthit.gov/test-method/ https://www.healthit.gov/test-method/patient- certification is sought (80 FR 62705). In auditable-events-and-tamper-resistance. specific-education-resources. this final rule, we have determined that

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00069 Fmt 4701 Sfmt 4700 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 We have revised § 170.550(h) of this regulatory text, were erroneously rationale provided in the 2015 Edition final rule to reflect these clarifications. deleted in the Proposed 2015 Edition final rule, (g)(1) through (6) are exempt We also corrected Table 2 to accurately Privacy and Security Certification from the P&S Certification Framework reflect the regulatory text at Framework table and we corrected it in due to the capabilities included in these § 170.315(a)(3), (a)(14), and (a)(15). Table 2. criteria, which do not implicate privacy Sections 170.315(a)(3), (a)(14), and and security concerns (80 FR 62707). (a)(15), though included in the

TABLE 2—2015 EDITION PRIVACY AND SECURITY CERTIFICATION FRAMEWORK

If the Health IT Module includes It will need to be certified to approach 1 or approach 2 for each of the P&S certification criteria listed in capabilities for certification listed the ‘‘approach 1’’ column under: Approach 1 Approach 2

§ 170.315(a)(1) through (3), (5), (12), § 170.315(d)(1) (authentication, access control, and For each applicable P&S certification criterion not (14), and (15). authorization), (d)(2) (auditable events and tam- certified using Approach 1, the health IT devel- per resistance), (d)(3) (audit reports), (d)(4) oper submits system documentation that is suffi- (amendments), (d)(5) (automatic log-off), (d)(6) ciently detailed to enable integration such that (emergency access), (d)(7) (end-user device the Health IT Module has implemented service encryption) (d)(12) (encrypt authentication cre- interfaces for each applicable P&S certification dentials) (d)(13) (multi-factor authentication). criterion that enable the Health IT Module to ac- cess external services necessary to meet the re- quirements 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(b)(1) through (3) and (6) § 170.315(d)(1) through (d)(3), (d)(5) through (d)(8) through (9). (integrity), (d)(12), and (d)(13). § 170.315(c) ...... § 170.315(d)(1) through (d)(3) and (d)(5), (d)(12), and (d)(13) *. § 170.315(e)(1) ...... § 170.315(d)(1) through (d)(3), (d)(5), (d)(7), (d)(9) (trusted connection), (d)(12), and (d)(13). § 170.315(e)(2) and (3)...... § 170.315(d)(1) through (d)(3), (d)(5), (d)(9), (d)(12), and (d)(13) *. § 170.315(f) ...... § 170.315(d)(1) through (d)(3), (d)(7), (d)(12), and (d)(13). § 170.315(g)(7) through (g)(10) ...... § 170.315(d)(1) and (d)(9); (d)(2) or (d)(10) (audit- ing actions on health information), (d)(12), and (d)(13). § 170.315(h) ...... § 170.315(d)(1) through (d)(3), (d)(12), and (d)(13) *. 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 dem- onstrate) 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 period after removal from the CFR (84 CFR, the start and end dates for the ‘‘life ONC–ACBs FR 7456). of the edition’’ are published in the Comments. Several commenters Federal Register in the rulemaking 1. Records Retention expressed support for ONC’s proposal to actions that finalize them. The period of We proposed to revise the records revise the records retention three years beyond the ‘‘life of the retention requirement in § 170.523(g) to requirement. Another commenter edition’’ begins on the effective date of include the ‘‘life of the edition’’ as well requested that ONC provide a separate the final rule that removes the as three years after the retirement of an posting or notice that lists the dates applicable edition from the CFR, thus edition related to the certification of specific to when the ‘‘life of the edition’’ the three-year period after removal from starts and dates specific to when the Complete EHRs and Health IT Modules the CFR continues through three full ‘‘life of the edition’’ and the minimum calendar years following that date. For (84 FR 7456). We also proposed to period of three years from the effective example, if the effective date of a clarify that HHS has the ability to access date that removes the applicable edition hypothetical final rule removing an certification records for the ‘‘life of the end. edition from the CFR were July 1, 2025, edition,’’ which begins with the Response. We thank commenters for then the three year period following the codification of an edition of certification their input and have finalized this end of the life of this hypothetical criteria in the Code of Federal revision as proposed. Because the ‘‘life edition would be June 30, 2028. We Regulations through a minimum of three of the edition’’ begins with the anticipate continuing to work with years from the effective date of the final codification of an edition of certification ONC–ACBs to provide guidance and rule that removes the applicable edition criteria in the CFR and ends on the information resources as necessary or from the Code of Federal Regulations effective date of the final rule that appropriate to promote successful (CFR), not solely during the three-year removes the applicable edition from the adherence to all Principles of Proper

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00070 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25711

Conduct (PoPC) applicable to their Another commenter expressed support the need for ONC–ATLs entirely. Two participation in the Program. for ONC’s proposal to revise the PoPC commenters sought clarity from ONC as to clarify that certifications can only be to what metrics the National 2. Conformance Methods for issued to Health IT Modules and not Coordinator will use to approve a Certification Criteria Complete EHRs. The commenter also conformance method. These The PoPC in § 170.523(h) specified expressed support for ONC’s proposal to commenters also sought clarification on that ONC–ACBs may only certify health remove the provision that permits the ONC’s plan to reduce the risk of IT that has been tested by ONC–ATLs certification of health IT previously developers seeking certification through using tools and test procedures certified to an edition if the certification fraudulent means. The commenters approved by the National Coordinator. criterion or criteria to which the Health cited the example of two developers We proposed to revise the PoPC in IT Module(s) was previously certified who are currently operating under § 170.523(h) in three ways (84 FR 7456). have not been revised and no new corporate integrity agreements with the First, we proposed to revise this PoPC certification criteria are applicable HHS Office of the Inspector General due to additionally permit ONC–ACBs to because the circumstances that this to court cases brought against them in certify Health IT Modules that the ONC– provision seeks to address are no longer relation to conduct including, but not ACB has evaluated for conformance feasible with certification to the 2015 limited to, the process of seeking with certification criteria without first Edition. certification. passing through an ONC–ATL. Response. We have finalized the Response. We thank commenters for However, we proposed that such proposal to revise the PoPC in their feedback. We have finalized the methods to determine conformity must § 170.523(h). As noted in the Proposed proposal to revise the PoPC in first be approved by the National Rule, the ability to maintain Complete § 170.523(h) to permit a certification Coordinator. EHR certification is only permitted with decision to be based on an evaluation Second, we proposed to revise the health IT certified to the 2014 Edition conducted by the ONC–ACB for Health PoPC to clarify that certifications can certification criteria (84 FR 7435). IT Modules’ compliance with only be issued to Health IT Modules and Because this concept was not continued certification criteria by use of not Complete EHRs. We proposed to in the 2015 Edition (84 FR 7456), we conformity methods approved by the remove the 2014 Edition from the CFR proposed revisions to clarify that National Coordinator. (see section III.B.2 of this preamble) and Complete EHR certifications are no We note that all certification criteria Complete EHR certifications are no longer available. We note that ONC– will continue to have some method of longer available for certification to the ACBs have discretion, and processes in holding developers responsible for 2015 Edition (80 FR 62608; 79 FR place, to evaluate updates made to demonstrating conformity whether 54443). We also proposed to remove the certified health IT and assess the need through ONC–ATL testing, developer provision that permits the use of test for additional testing. These ONC–ACB self-declaration, or some other method results from National Voluntary processes allow for efficient certification assessed and approved by the National Laboratory Accreditation Program of upgraded version releases of Coordinator. As noted in the Proposed (NVLAP)-accredited testing laboratories previously certified health IT while Rule (84 FR 7456), ONC acknowledges under the Program because the ensuring its continued conformity with that there is a broad spectrum of types regulatory transition period from certification criteria and standards to of evidence of conformance, from NVLAP-accredited testing laboratories which the prior version release of the laboratory testing with an ONC–ATL to to ONC–ATLs has expired (81 FR same Module(s) had been certified. We developer self-declaration. Some of 72447). have finalized this proposal. these types of evidence may be more Third, we proposed to remove the Comments. Multiple commenters appropriate than others in specific provision that permits the certification expressed support for the use of circumstances. Historically, it has been of health IT previously certified to an conformance methods approved by the proven that, in some circumstances, the edition if the certification criterion or National Coordinator. One commenter requirement for ONC–ATL testing has criteria to which the Health IT noted that the opportunity would enable presented more administrative burden Module(s) was previously certified have alternative testing methods and less on health IT developers than benefits for not been revised and no new costly testing. Another commenter assessing conformity. For example, certification criteria are applicable noted that this proposal would reduce under § 170.315(a)(5) demographics because the circumstances that this burden for EHR developers and for certification criteria require only provision seeks to address are no longer ONC–ATLs by leveraging certification documentation or a visual inspection, feasible with certification to the 2015 programs and alternative test methods and do not require testing by an ONC– Edition. and specifically requested that ONC ATL. We note that industry Comments. One commenter sought consider a specific proprietary advancements have presented clarification on whether the proposal to certification related to e-prescribing opportunities for improved efficiency remove references to § 170.545, which functionalities for potential approval. for demonstrating conformity and this includes the ability to maintain While expressing appreciation for the flexibility will allow the Program to Complete EHR certification, would flexibility offered by the proposed advance as the state of the art for impact § 170.550(k), which requires revision, one commenter expressed demonstrating conformance evolves. ONC–ACBs to accept requests for a concern about certifications based on This flexibility addresses the current newer version of a previously certified other ONC-approved conformance Program construct limitation of ONC– Health IT Module(s) to inherit the methods that are not specifically ACB certification only being permissible certified status of the previously designed to test against the ONC criteria for health IT that has been tested by an certified Health IT Module(s) without and stressed the importance of assessing ONC–ATL with ONC-approved test requiring the newer version to be conformance to technical standards procedures. In some instances, such as recertified. The commenter strongly before being deployed to end users. developer self-declaration, there is no urged ONC to allow ONC–ACBs to grant Another commenter questioned whether testing required and thus bypassing the inherited certification status to updated the ONC–ACB would be permitted to do ONC–ATL testing step reduces burden versions of certified technology. all evaluation directly, thus eliminating and enables a more streamlined and

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00071 Fmt 4701 Sfmt 4700 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 would have an opportunity to explain provisions of HHS programs requiring flexibility, we may approve the potential issues to ONC and NVLAP, the use of certified health IT or to conformance methods that rely solely and on a case-by-case basis, ONC could achieve any other use within the scope on ONC–ACB evaluation, and not ONC– consider the facts and make the final of the health IT’s certification. ATL testing, when appropriate. determination. We also proposed to remove the We will follow the same process used Comments. Multiple commenters provision in § 170.523(k)(3) that for alternative test methods (76 FR 1280) expressed support for the proposed requires a certification issued to a pre- for the submission of non-governmental requirement that ONC–ACBs must coordinated, integrated bundle of Health developed conformance methods to the accept test results from any ONC–ATL IT Modules to be treated the same as a National Coordinator for approval. A in good standing. One commenter certification issued to a Complete EHR person or entity may submit a expressed an opinion that this proposal for the purposes of § 170.523(k)(1), conformance method to the National has value in ensuring the credibility of except that the certification must also Coordinator to be considered for the Program. Another commenter agreed indicate each Health IT Module that is approval for use under the Program. The that this proposal would encourage included in the bundle (84 FR 7457). submission should identify the market competition and provide more We proposed to revise § 170.523(k)(4) developer of the conformance method; options to developers. One commenter to clarify that a certification issued to a specify the certification criterion or recommended that ONC–ATLs should Health IT Module based solely on the criteria that is/are addressed by the also be required to provide their results applicable certification criteria adopted conformance method; and explain how to any ONC–ACB to which the by the ONC Health IT Certification the conformance method would developer has chosen to present its Program must be separate and distinct evaluate a Health IT Module’s or, if health IT for certification, stating that from any other certification(s) based on applicable, other type of health IT’s, this consistency across ONC–ACBs and other criteria or requirements (84 FR compliance with the applicable ONC–ATLs would ensure market 7457). certification criterion or criteria. The competition. We also proposed changes related to submission should also provide Response. We thank commenters for transparency attestations and information describing the process used their input. We have finalized the PoPC disclosures of limitations in section to develop the conformance method, for ONC–ACBs in § 170.523(r) as III.B.5 of the Proposed Rule preamble including any opportunity for the public proposed. While an ONC–ATL (84 FR 7437 and 7438). Additionally, we to comment on the conformance method attempting to inappropriately restrict proposed other new PoPC for ONC– and the degree to which public developers’ choice of ONC–ACBs to ACBs as discussed in sections VII.B.5 comments were considered. In those favored by the ONC–ATL would (84 FR 7501) and VII.D (84 FR 7506 and determining whether to approve a not support appropriate competition, we 7507) of the Proposed Rule preamble. conformance method for purposes of the do not believe it would be practical to Comments. Multiple commenters Program, the National Coordinator will mandate direct transmission of ONC– expressed support for ONC’s proposal to consider whether it is clearly traceable ATL results to any ONC–ACB include a detailed description of all to a certification criterion or criteria designated by the developer, in part known material information concerning adopted by the Secretary; whether it is because developers often do not initiate additional types of costs or fees that a sufficiently comprehensive (i.e., engagement with an ONC–ACB until user may be required to pay to assesses all required capabilities) for the after they have received and had a implement or use the Health IT assessment of Health IT Modules’, or chance to review their ONC–ATL Module’s capabilities—whether to meet other type of health IT’s, conformance to results. To date, we are not aware of provisions of HHS programs requiring the certification criterion or criteria substantial evidence that the standard the use of certified health IT or to adopted by the Secretary; whether an practice of NVLAP-accredited testing achieve any other use within the scope appropriate public comment process laboratories providing test results to the of the health IT’s certification. One was used during the development of the client who engaged them to test their commenter endorsed the transparency conformance method; and any other Health IT Modules is not serving as a that this proposal would provide, noting relevant factors. When the National sufficient safeguard against anti- that it would help providers budget for Coordinator has approved a competitive behavior on the part of their health IT, but also expressed conformance method for purposes of the ONC–ATLs in relation to their client concern that requiring developers to Program, we will publish a notice of developers’ selection of ONC–ACBs. disclose how much they charge for a particular functionality may be availability in the Federal Register and 4. Mandatory Disclosures and identify the approved conformance impractical due to variations across Certifications method on the ONC website. contracts and over time, or potentially We proposed to revise the PoPC in have unintended consequences on 3. ONC–ACBs To Accept Test Results § 170.523(k) to remove market pricing. Multiple commenters From Any ONC–ATL in Good Standing § 170.523(k)(1)(ii)(B) because expressed support for our proposal to We proposed to add the PoPC for certifications can only be issued to remove subsection § 170.523(k)(1)(ii)(B). ONC–ACBs in § 170.523(r) in order to Health IT Modules and not Complete One commenter expressed support for address business relationships between EHRs (84 FR 7456). We also proposed to ONC’s proposed revisions to ONC–ACBs and ONC–ATLs (84 FR revise § 170.523(k)(1)(iii)(A) to broaden § 170.523(k)(4). Another commenter was 7456). To encourage market the section beyond the Promoting supportive of the proposal to remove the competition, we proposed to require Interoperability (PI) Programs. We provision in § 170.523(k)(3). ONC–ACBs to accept test results from proposed to revise the section to include Response. We thank commenters for any ONC–ATL that is in good standing a detailed description of all known their support. We have finalized the under the Program and is compliant material information concerning proposals, in their entirety, as proposed. with its ISO/IEC 17025 accreditation additional types of costs or fees that a To clarify, the finalized revision in requirements. However, if an ONC–ACB user may be required to pay to § 170.523(k) requires disclosure of a has concerns about accepting test results implement or use the Health IT detailed description of all known from a certain ONC–ATL, the ONC–ACB Module’s capabilities, whether to meet material information concerning

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00072 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25713

additional types of costs or fees a user related to clinical priorities beyond providers have the tools they need (such may be required to incur or pay to those specifically included in the EHR as access to essential health information implement or use the Health IT Incentive Programs (now called the across care settings) to support patients Module’s capabilities to achieve any use Promoting Interoperability Programs) at the point of care. within the scope of the health IT’s including efforts in public health, A. Health IT for Pediatric Setting certification. We emphasize that (unless behavioral health, and long-term and required elsewhere in CFR part 170) the post-acute care. We noted in the Section 4001(b)(iii) of the Cures Act— requirement is for a description of the Proposed Rule that these initiatives ‘‘Health information technology for types of costs or fees, not predicted often include the development of non- pediatrics’’ requires: • amounts of these costs or fees across the regulatory informational resources to First, that the Secretary, in full array of probable implementation support the specific implementation consultation with relevant stakeholders, circumstances or over time. Among goal and align with the technical shall make recommendations for the other considerations, we note that costs specifications already available in the voluntary certification of health IT for required to achieve some particular uses Program for certification. To advance use by pediatric health providers to within the scope of some certifications these efforts, we also explained in the support the health care of children, and • may be for third-party services outside Proposed Rule that we generally Second, that the Secretary shall the control of the developer required to consider a range of factors including: adopt certification criteria to support disclose the detailed description. Stakeholder input and identification of the voluntary certification of health IT clinical needs and clinical priorities, the for use by pediatric health providers to C. Principles of Proper Conduct for evolution and adoption of health IT support the health care of children. ONC–ATLs—Records Retention across the care continuum, the costs and In the Proposed Rule (84 FR 7458), we We proposed to revise the records benefits associated with any policy or described our approach to stakeholder retention requirement in § 170.524(f) to implementation strategy related to care engagement, the analysis used to include the ‘‘life of the edition’’ as well settings and sites of service, and develop the recommendations, the as 3 years after the retirement of an potential regulatory burden and specific 2015 Edition certification edition related to the testing of Health compliance timelines. Our goal was criteria that support each IT Module(s) to an edition of then and is now to support the recommendation, and the voluntary certification criteria (84 FR 7457). The advancement of interoperable health IT certification of health IT for use by circumstances are the same as in section and to promote health IT functionality pediatric health providers to support the V.B.1 of the Proposed Rule preamble, as in care and practice settings across the health care of children. summarized above. Therefore, we care continuum (see 80 FR 62604). As Comments. We received several proposed the same revisions for ONC– stated in the Proposed Rule (84 FR comments requesting further ATLs as we did for ONC–ACBs. We did 7458), generally, our approach can be clarification on whether the pediatric not receive any comments specific to summarized in three parts: health IT recommendations will be this proposed revision to the PoPC for • First, we analyze existing adopted as an independent certification ONC–ATLs. In light of the absence of certification criteria to identify how program and/or certification criteria comments, we have finalized the such criteria may be applicable for designated specifically for pediatric revisions as proposed. medical specialties and sites of service. care. One commenter recommended that • Second, we focus on the real-time pediatric provisions should be VI. Health IT for the Care Continuum evaluation of existing and emerging formalized over time within what they Health IT should help promote and standards to determine applicability to refer to as the current pediatric program support patient care when and where it medical specialties and sites of service and not as a separate program, and that is needed. This means health IT should as well as to the broader care this future aligns with the 2015 help support patient populations, continuum, including the evaluation of Children’s EHR Format. One commenter specialized care, transitions of care, and such standards for inclusion in the ONC also sought clarification as whether practice settings across the care Interoperability Standards Advisory ONC intends for other government continuum. In the Proposed Rule, we (ISA).68 agencies/programs such as CHIP, to provided a history of the many actions • Third, we may work in develop conditions of participation or we have taken since the inception of the collaboration with stakeholders to financial incentives around the ONC Health IT Certification Program support the development of adoption of certification criteria through the Proposed Rule (84 FR 7457). informational resources for medical identified in this rulemaking. We also As stated in the Proposed Rule, section specialties and sites of service for which received several comments stating that 4001(b)(i) of the Cures Act instructs the we identify a need to advance the since current EHRs have pediatric National Coordinator to encourage, effective implementation of certified capabilities, there is no need to specify keep, or recognize, through existing health IT. requirements in regulation, and that authorities, the voluntary certification of We continue to believe this approach there is no value in having EHRs health IT under the Program for use in is economical, flexible, and responsive certified as ‘‘pediatric-friendly,’’ only medical specialties and sites of service for both health care providers and the increased costs. We also received for which no such technology is health IT industry. It is also in several comments stating that our available or where more technological alignment with the provisions of section approach reflects an attempt to retrofit advancement or integration is needed. 4001(a) in the Cures Act related to the needs of pediatric patients by using This provision of the Cures Act closely burden reduction and promoting adult requirements. aligns with our ongoing collaborative interoperability. We are committed to Response. We thank commenters for efforts with both Federal partners and continuing to work with stakeholders to their feedback. The comments we stakeholders within the health care and promote the adoption of health IT to received suggests a need for greater health IT community to encourage and support medical specialties and sites of clarity on our approach. We therefore support the advancement of health IT service and to help ensure that reiterate that we did not propose to for a wide range of clinical settings. adopt care- or practice-specific These initiatives have included projects 68 https://www.healthit.gov/isa/. certification tracks, or additional

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00073 Fmt 4701 Sfmt 4700 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 certification pathway or a new ONC organizations, charitable foundations existing voluntary ONC Health IT certification designation called pediatric engaged in children’s health care Certification Program. In the Proposed certification. However, we recognize research, and health IT developers Rule, we reiterated our statements from that beyond certification and testing supporting pediatric care settings. For the 2015 Edition final rule, which there are certain implementation needs example, significant work has been explained that we did not intend to that are important for pediatric care and done by the Agency for Healthcare develop and issue separate regulatory services. We agree with the Research and Quality (AHRQ), CMS, the certification ‘‘paths’’ or ‘‘tracks’’ for overwhelming prior feedback from Health Resources and Services particular care or practice settings (e.g., stakeholders stating that they should not Administration (HRSA), and a ‘‘long-term and post-acute care have to purchase separate products that organizations around the Children’s (LTPAC) certification’’) because it contain universally applicable EHR Format (Children’s Format), which would be difficult to independently functionality, such as the ‘‘API is critical to any discussion of the construct such ‘‘paths’’ or ‘‘tracks’’ in a functionality’’ certification criteria. We pediatric health IT landscape.69 manner that would align with other are exploring options for non-regulatory The Children’s Format was authorized relevant programs and specific informational resources on effective by the 2009 Children’s Health Insurance stakeholder needs. We further stated implementation of health IT for use by Program Reauthorization Act that stakeholders had indicated that pediatric health providers to expand the (CHIPRA) 70 and developed by AHRQ in separate certification pathways could availability of health IT products close collaboration with CMS. It was have unintended consequences related supporting the care of children. developed to bridge the gap between the to increasing burden on health care Comments. We received comments functionality present in most EHRs providers and health IT developers. We regarding how the approach for currently available and the functionality also stated that we would welcome the voluntary certification of health IT for that could optimally support the care of opportunity to work with HHS agencies, use by pediatric health providers might children. Specifically, the Children’s other agencies, and provider be applicable to other medical Format provides information to EHR associations in identifying the specialties and use cases. One system developers and others about appropriate functionality and commenter noted that the pediatric critical functionality and other certification criteria in the Program to experience is scalable and should be requirements that are helpful to include support their stakeholders (80 FR extended to other disciplines. Another in an EHR system to address health care 62704). In response to the comments commenter sought clarification if this needs specific to the care of children. regarding our approach to implement model could be used for broad The final version of the Children’s section 4001(b) of the Cures Act, we applicability to multiple medical Format, released in 2015, consists of 47 clarify that the 2015 Edition specialties such as pathologists. high priority functional requirements in certification criteria identified for the Response. We thank these 19 topic areas that focus on voluntary certification of health IT for commenters for identifying the improvements that would better support use by pediatric health providers are applicability of our approach to the safety and quality of care delivered agnostic to the age of the patient (with pediatrics to other medical specialties. to children. The Children’s Format was the exception of the pediatric vital signs We confirm that our approach for intended as a starting point for in the USCDI). Therefore, we believe our advancing health IT can be used for developers, users, and purchasers for approach to fulfilling the Cures Act other use cases and medical specialties, informing an approach for pediatric requirement for pediatric health care and welcome the opportunity to engage voluntary certification. We refer to the providers and settings, which involves with stakeholders representing a wide Voluntary Edition proposed rule for a identifying existing, new, or revised range of medical specialties or sites of description of our prior discussion 2015 Edition criteria—as applicable to service to provide insight into this around the Children’s Format (79 FR an identified clinical or interoperability process and to inform stakeholder-led 10930). priority—is appropriate across patient efforts to improve clinically-relevant In the summer of 2017, the American populations. We also note that our health IT implementation across Academy of Pediatrics (AAP) reviewed authority is limited to implementing the specialties and settings of care. the 2015 Children’s Format using a described requirements of the Cures Act 1. Background and Stakeholder robust analytical process and related to pediatric settings. We cannot Convening engagement with their members. The speak for the actions of other Federal result was a prioritized list of eight Over the past ten years, a number of agencies, but would note once again that clinical priorities to support pediatric initiatives have focused on the we have taken a limited regulatory health care (‘‘Priority List’’). In October availability and use of effective health approach to implementing the pediatric 2017, we held a technical discussion IT tools and resources for pediatric care. provisions of the Cures Act. with stakeholders titled ‘‘Health IT for These have included a number of Comments. We received multiple Pediatrics’’ with the specific purpose of public-private partnerships including comments requesting clarification on obtaining input from an array of efforts between HHS, State agencies, the intended use and functionality of stakeholders in an effort to draw and health systems for innovative the Certified Health IT Products List correlations between the pediatric projects that range from care (CHPL) for pediatric certification, such providers’ clinical priorities identified coordination enterprise solutions to as guidance on navigating the CHPL to in the Priority List with the detailed identify relevant products based on immunization information systems and to point of care solutions for specialty pediatric care settings. 69 Agency for Health Care Information and Response. We thank stakeholders for needs. In order to learn from and build Technology. Health Information Technology. http:// their comments on the CHPL. We do not upon these efforts, ONC has engaged healthit.ahrq.gov/health-it-tools-and-resources/ intend to have a separate tag with stakeholders in both the public and childrens-electronic-health-record-ehr-format. functionality on the CHPL that private sector including other Federal, Accessed September, 2017. 70 Pub. L. 111–3, section 401 https:// identifies a product specifically for State and local government partners, healthit.ahrq.gov/sites/default/files/docs/citation/ pediatric care. We did not propose, and health care providers engaged in the children-ehr-format-enhancement-final- do not intend, for there to be a separate care of children, standards developing recommendation-report-abridged.pdf.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00074 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25715

technical requirements outlined in the proposed in the Proposed Rule that adding in developmental activity Children’s Format and the capabilities support the 10 recommendations for the milestones, including what versions of and standards that could be included in voluntary certification of health IT for growth charts should be supported, and certified health IT. Through this use by pediatric health providers to including listings to clearly identify collaborative approach, the meeting support the health care of children. In medical home providers. Several participants identified a set of priority the Proposed Rule (84 FR 7459), we commenters also referenced concerns needs for health IT to support pediatric directed readers to the appendix of the regarding the feasibility of care based upon those identified by the Proposed Rule for a set of technical implementing the content included as Priority List and the primary correlation worksheets, which include a crosswalk part of the pediatric health IT technical to the Children’s Format. of the various criteria specifically worksheet crosswalk analysis included associated with each recommendation. in the Proposed Rule appendix for 2. Recommendations for the Voluntary These worksheets outlined the Recommendation 5 ‘‘Synchronize Certification of Health IT for Use in following information: immunization histories with registries.’’ Pediatric Care • The alignment of each In this regard, several commenters noted To support the first part of section recommendation to the primary that FHIR is not currently consistent 4001(b) of the Cures Act, we considered Children’s Format 71 item identified by with CDC/AIRA standards or practices the historical efforts on the Children’s stakeholders for immunization data submission or Format, the input from stakeholders, • The alignment of each query/response, and that public health and our own technical analysis and recommendation to the 2015 Edition is not currently funded to provide this review of health IT capabilities and certification criteria and the new or capability from IIS. standards to develop a set of revised criteria described in the Response. We thank commenters for recommendations for voluntary Proposed Rule their useful input regarding the certification of health information • Supplemental items from the technical worksheets in the appendix technology for use by pediatric health Children’s Format for each we included for the Proposed Rule. As providers to support the health care of recommendation and the related 2015 we stated in the Proposed Rule, these children. These include eight Edition certification criteria comments, and the detailed insights recommendations related to the Priority We also sought comment on the received through stakeholder outreach, List: following: will inform the future development of a • Recommendation 1: Use biometric- 1. Relevant gaps, barriers, safety non-binding informational guide or specific norms for growth curves and concerns, and resources (including informational resource to provide useful support growth charts for children available best practices, activities, and • information for health IT developers Recommendation 2: Compute tools) that may impact or support and pediatric care providers seeking to weight-based drug dosage feasibility of the recommendation in • successfully implement these health IT Recommendation 3: Ability to practice. solutions in a clinical setting. To document all guardians and caregivers 2. Effective use of health IT itself in facilitate adoption of the ten • Recommendation 4: Segmented support of each recommendation as it recommendations, we are developing a access to information relates to provider training, establishing Pediatric Health IT Developer • Recommendation 5: Synchronize workflows, and other related safety and Informational Resource and a Pediatric immunization histories with registries usability considerations. • Health IT Provider Informational Recommendation 6: Age- and 3. If any of the 10 recommendations weight- specific single-dose range Resource to be available for respective should not be included in ONC’s final use in 2020. As such, we appreciate the checking recommendations for voluntary • Recommendation 7: Transferrable comments we received specific to certification of health IT for use by implementation recommendations and access authority pediatric health providers to support the • Recommendation 8: Associate will take them into account in the health care of children. support of the creation of non-regulatory maternal health information and 4. Any certification criteria from the demographics with newborn informational resources for health IT Program that is identified for the 10 developers and other stakeholders. We We also developed two additional recommendations that should not be recommendations beyond the Priority plan to continue working with included to support the specific stakeholders as we further develop and List, which relate to other items within recommendation. the Children’s Format that are consider technical and implementation Comments. We received many recommendations we have received considered important to pediatric comments asking for detailed guidance stakeholders. These additional through solicited public comments, the and/or implementation specifications Health Information Technology recommendations, which may be post final rulemaking, with one supported by certified health IT, are as Advisory Committee (HITAC), and other commenter noting that the majority of engagements. We also direct readers to follows: recommendations require additional • Recommendation 9: Track our ‘‘pediatrics health IT’’ web page capabilities beyond the scope of any (www.healthIT.gov/pediatrics) for incomplete preventative care aligned existing or proposed opportunities information on future work pertaining • certification criteria. We also received to health IT for pediatric care. Recommendation 10: Flag special many comments providing Comments. We received several health care needs implementation recommendations In order to implement the second part comments suggesting the use of specific to the 10 ONC of section 4001(b) of the Cures Act for pediatric-focused clinicians and settings recommendations for the voluntary the adoption of certification criteria to to test EHR systems as part of these certification of health IT for use by support the voluntary certification of provisions, specifically recommending pediatric health providers such as health IT for use by pediatric health care that we should require EHR developers providers, we identified both the 2015 71 http://healthit.ahrq.gov/health-it-tools-and- to use pediatric-focused scenarios and Edition certification criteria and the resources/childrens-electronic-health-record-ehr- mock pediatric patients when testing new or revised certification criteria format. functionality, as well as requiring the

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00075 Fmt 4701 Sfmt 4700 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 to re-disclosure; receive a summary evaluated immunization history and of end-user testing. record that is document-level tagged as forecast from an immunization registry Response. We thank commenters for restricted; separate the document-level for a patient. Immunization forecasting their input. We agree that it would be tagged document from other documents recommendations allow for providers to beneficial for health IT developers to received; and view the restricted access the most complete and up-to-date include pediatric-focused testing of document without having to incorporate information on a patient’s immunization their health IT especially with regards to any of the data from the document. history to inform discussions about ensuring patient safety. We note that we • ‘‘Demographics’’ criterion what vaccines a patient may need based have established requirements for real (§ 170.315(a)(5)) which supports on nationally recommended world testing that requires health IT pediatric care through the capture of immunization recommendations (80 FR developers to real world test their health values and value sets relevant for the 62662 through 62664). IT for the types of setting(s) in which it pediatric health care setting as well as • ‘‘View, download, and transmit to is intended for use (we refer readers to allowing for improved patient matching 3rd party’’ (VDT) criterion section VII.B.5 for more information on which is a key challenge for pediatric (§ 170.315(e)(1)) which supports real world testing Condition and care. transferrable access authority for the • Maintenance of Certification ‘‘Electronic Prescribing’’ criterion pediatric health care setting and requirements). (§ 170.315(b)(3)) which includes an provides the ability for patients (and optional Structured and Codified Sig a. 2015 Edition Certification Criteria their authorized representatives) 72 to Format, which has the capability to view, download, and transmit their In order to implement the second part exchange weight-based dosing health information to a 3rd party. of section 4001(b) of the Cures Act to calculations within the NCPDP SCRIPT We noted in the Proposed Rule (84 FR adopt certification criteria to support 10.6 standard and limits the ability to 7460) that some of these criteria may be the voluntary certification of health IT prescribe all oral, liquid medications in updated based on proposals contained for use by pediatric health providers to only metric standard units of mL (i.e., in the Proposed Rule (see further support the health care of children, we not cc) important for enabling safe discussion below on new or revised identified the following already adopted prescribing practices for children. certification criteria); and stated that we • ‘‘Family health history’’ criterion 2015 Edition certification criteria in the continue to believe that prior to any (§ 170.315(a)(12)) which supports Proposed Rule that support the such updates, technology that is pediatric care because it leverages recommendations. The already adopted currently available and certified to these concepts or expressions for familial 2015 Edition criteria are as follows: 2015 Edition criteria can make a • ‘‘API functionality’’ criteria conditions, which are especially significant impact in supporting (§ 170.315(g)(7)–(g)(9)) which address clinically relevant when caring for providers engaged in the health care of many of the challenges currently faced children. children. We invited readers to use the by patients and by caregivers such as • ‘‘Patient health information technical worksheets in the appendix of parents or guardians accessing child’s capture’’ criterion (§ 170.315(e)(3)) the Proposed Rule to inform their public health information, including the which supports providers’ ability to comment on the recommendations, the ‘‘multiple portal’’ problem, by accept health information from a patient inclusion of specific items from the potentially allowing individuals to or authorized representative. This Children’s Format, and the identified aggregate health information from criterion could support pediatric care 2015 Edition certification criteria as multiple sources in a web or mobile through documentation of decision- they relate specifically to use cases for application of their choice. making authority of a patient • ‘‘Care plan’’ criterion representative. pediatric care and sites of service. (§ 170.315(b)(9)) which supports • ‘‘Social, psychological, and b. New or Revised Certification Criteria pediatric care by facilitating the behavioral data’’ criterion In order to implement the second part documentation of electronic health (§ 170.315(a)(15)) which supports of section 4001(b)(iii) of the Cures Act information in a structured format to integration of behavioral health data to adopt certification criteria to support improve care coordination (80 FR 62648 into a child’s record across the care the voluntary certification of health and 62649). continuum by enabling a user to record, information technology for use by • ‘‘Clinical decision support’’ (CDS) change, and access a patient’s social, pediatric health providers to support the criterion (§ 170.315(a)(9)) which psychological, and behavioral data health care of children, we also supports pediatric care by enabling based using SNOMED CT® and LOINC® identified new or revised 2015 Edition interventions based on the capture of codes. certification criteria (and standards) in biometric data. • ‘‘Transitions of care’’ criterion • ‘‘Common Clinical Data Set’’ (§ 170.315(b)(1)) which supports the Proposed Rule (84 FR 7460) that (§ 170.315(b)(4) and § 170.315(b)(5)) structured transition of care summaries support the recommendations. These proposed criteria and standards include: which includes optional pediatric vital and referral summaries that help ensure • sign data elements including as optional the coordination and continuity of New API criterion (§ 170.315(g)(10)) the reference range/growth curve for health care as children transfer between which would serve to implement the three pediatric vital signs—BMI percent different clinicians at different health Cures Act requirement to permit health per LOINC identifiers for age per sex, care organizations or different levels of information to be accessed, exchanged, weight per length/sex, and head care within the same health care occipital-frontal circumference for organization. 72 The VDT criterion includes a ‘‘patient- children less than three years of age. • ‘‘Transmission to immunization authorized representative’’ concept that aligns with • the use of the term under the EHR Incentive ‘‘Data segmentation for privacy’’ registries’’ criterion (§ 170.315(f)(1)) Program. A ‘‘patient-authorized representative’’ is send criterion and receive criterion which supports the safe and effective defined as any individual to whom the patient has (§ 170.315(b)(7) and § 170.315(b)(8)) provision of child health care through granted access to their health information (see also 77 FR 13720). However, consent is not needed for which provides the ability to: Create a immunizations and registry linkages. minors, for whom existing local, state, or Federal summary record that is tagged at the This criterion also provides the ability law grants their parents or guardians access (see document level as restricted and subject to request, access, and display the also 77 FR 13720).

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00076 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25717

and used from APIs without special finalize our proposal for the criterion in B. Health IT and Opioid Use Disorder effort. this final rule. The functionality of the Prevention and Treatment—Request for • New ‘‘DS4P’’ criteria (two for C– proposed new ‘‘DS4P’’ criteria have Information CDA ((§ 170.315(b)(12)) and been incorporated into the already We identified a need to explore ways (§ 170.315(b)(13)) and one for FHIR adopted 2015 Edition DS4P criteria to advance health IT across the care (§ 170.315(g)(11))) that would support a DS4P-send (§ 170.315(b)(7)) and DS4P- continuum to support efforts to fight the more granular approach to privacy receive (§ 170.315(b)(8)) now referred to opioid epidemic. For that purpose, in tagging data for health information as ‘‘Security tags—Summary of Care- the Proposed Rule, we included a exchange supported by either the C– send’’ and ‘‘Security tags—Summary of request for information (RFI) related to CDA or FHIR-based exchange standards. Care—receive,’’ respectively. The • New electronic prescribing health IT and opioid use disorder functionality of the proposed new e-Rx certification criterion (§ 170.315(b)(11)), prevention and treatment (84 FR 7461 which would support improved patient criterion was also incorporated in the through 7465). We received over 100 safety and prescription accuracy, already adopted e-Rx criterion comments in responses to this RFI, workflow efficiencies, and increased (§ 170.315(b)(3)). Last, we have removed which included recommendations from configurability of systems including the ‘‘Common Clinical Data Set’’ the HITAC. We appreciate the feedback functionality that could support (§ 170.315(b)(4) and § 170.315(b)(5)) and recommendations provided by pediatric medication management. from the 2015 Edition in this final rule. commenters and the HITAC taskforce, • USCDI (§ 170.213) and USCDI- We note that we are aware that the respectively. We plan to share this based criteria which enables the NCPDP SCRIPT Standard Version feedback with appropriate Department partners. inclusion of pediatric vital sign data 2017071 Implementation Guide elements, including the reference range/ contains a number of requirements VII. Conditions and Maintenance of scale or growth curve for BMI percentile intended to improve accurate dosing Certification Requirements for Health per age and sex, weight for age per and pediatric patient safety. One such IT Developers length and sex, and head occipital- requirement is the inclusion of the most frontal circumference. Each of the new Section 4002 of the Cures Act recent patient height and weight in the or revised certification criteria and modifies section 3001(c)(5) of the Public Observation Segment on all new and standards are further described in other Health Service Act (PHSA) to require renewal prescriptions sent from the sections of this final rule, including all the Secretary of HHS, through notice final actions related to the criteria (some prescriber to the pharmacy, along with and comment rulemaking, to establish of which are described below in the the date associated with these measures, Conditions and Maintenance of response to comments). for all patients 18 years old and Certification requirements for the Comments. A majority of comments younger. We are also aware of the Program. Specifically, health IT received supported our challenges that such a requirement may developers or entities must adhere to recommendations for the voluntary pose on specific providers and under certain Conditions and Maintenance of certification of health IT for use by certain circumstances where height and/ Certification requirements concerning pediatric health providers to support the or weight is not required or applicable information blocking; appropriate health care of children along with the for dosing of the product. We believe exchange, access, and use of electronic alignment with the Children’s Format additional work must be done on health information; communications and 2015 Edition certification criteria. refining this requirement, and will regarding health IT; application Several commenters suggested that the continue to monitor standards and programming interfaces (APIs); real 10 recommendations should only be the industry advancements before world testing; attestations regarding first step and encouraged future proposing such a requirement. At this certain Conditions and Maintenance of development of additional time, we recommend vital signs to be Certification requirements; and recommendations using the Children’s included in all electronic prescriptions submission of reporting criteria under Format. Commenters were also pleased for all patient populations when the EHR Reporting Program under with the 10 recommendations selected available and where applicable. section 3009A(b) of the PHSA. by ONC from the Children’s Format The 10 recommendations and the A. Implementation stating that they represent a strong, aligned 2015 Edition certification positive step forward for improving To implement section 4002 of the criteria support the health IT needs of EHRs used in the care of children. Many Cures Act, we proposed an approach commenters stated that they support the pediatric care providers. We believe whereby the Conditions and continued alignment with the 2015 further support can be provided through Maintenance of Certification Edition recommendations. non-regulatory informational resources. requirements express initial certification Response. We thank commenters for These resources can help inform requirements for health IT developers their support and feedback. As such, we technical and implementation and their certified Health IT Module(s) have maintained the 10 specifications for health IT developers as well as ongoing maintenance recommendations for the voluntary and products for use by pediatric health requirements that must be met by both certification of health IT for use by providers to support the health care of health IT developers and their certified pediatric health providers to support the children. We also agree with Health IT Module(s) under the ONC health care of children. We have commenters that the 10 Health IT Certification Program finalized in this final rule the majority recommendations are a first step and (Program). If these requirements are not of the aligned proposed new 2015 welcome input and collaboration from met, the health IT developer may no Edition certification criteria that support the health IT industry and health care longer be able to participate in the the voluntary certification of health IT providers to continue efforts to develop Program and/or its certified health IT for use by pediatric health providers, and build a health IT infrastructure may have its certification terminated. with the exception of the proposed supporting pediatric care and other We proposed to implement each criterion for ‘‘consent management’’ in specialty care and sites of service across Condition of Certification requirement § 170.315(g)(11) since we did not the continuum. with further specificity as it applies to

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00077 Fmt 4701 Sfmt 4700 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 requirement under the Program, not take it does not take any action that may establish Maintenance of Certification any action that constitutes ‘‘information inhibit the appropriate exchange, requirements for certain Conditions of blocking’’ as defined in section 3022(a) access, and use of EHI. These proposed Certification requirements as standalone of the PHSA (see 3001(c)(5)(D)(i) of the requirements serve to provide further requirements. As we stated in the PHSA). We proposed to establish this clarity under the Program as to how Proposed Rule, this approach would Information Blocking Condition of health IT developers can provide such establish clear baseline technical and Certification in § 170.401. We proposed broad assurances with more specific behavior Conditions of Certification that the Condition of Certification actions. requirements with evidence that the would prohibit any health IT developer Comments. Most commenters agreed Conditions of Certification requirements who has at least one health IT product with the central premise of our proposal are continually being met through the certified under the Program from taking to adopt the ‘‘assurances’’ Condition Maintenance of Certification any action that constitutes information and Maintenance of Certification requirements. blocking as defined by section 3022(a) requirement, requiring that a health IT Comments. We received comments of the PHSA and proposed in § 171.103. developer provide certain assurances to expressing general support for the We clarified in the Proposed Rule that the Secretary, including that, unless concept of requiring Conditions and this proposed ‘‘information blocking’’ done for one of the ‘‘legitimate Maintenance of Certification Condition of Certification and its purposes’’ specified by the Secretary, it requirements. Commenters stated that requirements would be substantive will not take any actions that constitutes these requirements are a step forward requirements of the Program and would information blocking as defined in toward promoting transparency, rely on the definition of ‘‘information section 3022(a) of the PHSA, or any improving usability, and achieving blocking’’ established by section 3022(a) other action that may inhibit the interoperability of health IT. We also of the PHSA and proposed in § 171.103 appropriate exchange, access, and use of received comments asserting that the (84 FR 7465). electronic health information (EHI). Conditions and Maintenance of We received no comments specifically Commenters stated that they support Certification requirements should only about the Information Blocking ONC’s efforts to eliminate barriers that apply to developers of certified health Condition of Certification and have result in information blocking. One IT. adopted the Condition of Certification commenter stated that it is not clear Response. We thank commenters for as proposed. We received many what constitutes ‘‘satisfactory to the their support. We provide further details comments regarding the information Secretary’’ as interpretations may on each of the Conditions and blocking provision, and have responded change from Secretary to Secretary, and Maintenance of Certification to those comments in the information suggested removing the term requirements within their respective blocking discussion in section VIII of ‘‘Secretary.’’ subsections in this section of the final this preamble. We also refer readers to Response. We thank commenters for rule. However, to clarify our approach section VII.D of this final rule for their support. We have finalized our to the Conditions and Maintenance of additional discussion of ONC’s proposal to adopt the ‘‘assurances’’ Certification requirements in response enforcement of this and other Condition and Maintenance of to comments, the Conditions and Conditions and Maintenance of Certification requirement subject to the Maintenance of Certification Certification requirements. clarifications and revisions discussed below. In response to the comment requirements, except for the 2. Assurances ‘‘information blocking’’ and recommending we remove the term The Cures Act requires that a health ‘‘assurances’’ Conditions and ‘‘Secretary’’ as Secretaries may change IT developer, as a Condition and Maintenance of Certification over time, it will not be removed as it Maintenance of Certification requirements, apply only to actions and is in the authorizing Cures Act statutory requirement under the Program, provide behaviors of health IT developers language. For clarification, future assurances to the Secretary, unless for related to their certified health IT as Secretaries may establish changes to the legitimate purposes specified by the implementation of the Cures Act well as to the certified health IT itself. Secretary, that it will not take any action ‘‘assurances’’ Condition and For the ‘‘information blocking’’ and that constitutes information blocking as Maintenance of Certification ‘‘assurances’’ Conditions and defined in section 3022(a) of the PHSA, requirements through notice and Maintenance of Certification or any other action that may inhibit the comment rulemaking, as has been done requirements, consistent with the Cures appropriate exchange, access, and use of with this rulemaking. Act provisions and our implementation electronic health information (EHI). We of section 3022(a) (information proposed to implement this Condition a. Full Compliance and Unrestricted blocking) of the PHSA, a health IT of Certification and accompanying Implementation of Certification Criteria developer is also responsible to ensure Maintenance of Certification Capabilities that all of its health IT and related requirements in § 170.402. As a We proposed, as a Condition of actions and behaviors do not constitute Condition of Certification requirement, Certification requirement, that a health information blocking or inhibit the a health IT developer must comply with IT developer must ensure that its health appropriate access, exchange, and use of the Condition of Certification as recited IT certified under the Program conforms electronic health information (EHI). We here and in the Cures Act. We discussed to the full scope of the certification refer readers to section VIII of this in section VIII of the Proposed Rule the criteria to which its health IT is preamble for further discussion of the proposed reasonable and necessary certified. This has always been an information blocking regulations. activities specified by the Secretary, expectation of ONC and users of B. Provisions which constitute the exceptions to the certified health IT and, importantly, a information blocking definition. requirement of the Program. As stated in 1. Information Blocking We also proposed to establish more the Proposed Rule, we believe that by The Cures Act requires that a health specific Conditions and Maintenance of incorporating this expectation as an IT developer, as a Condition and Certification requirements for a health explicit Condition of Certification Maintenance of Certification IT developer to provide assurances that requirement under the Program, there

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00078 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25719

would be assurances, and necessary to enable the use of certified considered noncompliance with the documentation via the ‘‘Attestations’’ capabilities for their intended purposes. Condition of Certification requirement, Condition and Maintenance of More generally, any action that would such as managed services, hosting, Certification requirements proposed in be likely to substantially impair the connecting with exchange networks, or § 170.406, that all health IT developers ability of one or more users (or outsourced arrangements under fully understand their responsibilities prospective users) to implement or use agreement. under the Program, including not to take certified capabilities for any purpose Response. We clarify that the purpose any action with their certified health IT within the scope of applicable of this Condition of Certification that may inhibit the appropriate certification criteria would be requirement is to make certified exchange, access, and use of EHI. To prohibited by this Condition of capabilities available in ways that this point, certification criteria are Certification requirement. Such actions enable them to be implemented and designed and issued so that certified may include imposing limitations or used in production environments for health IT can support interoperability additional types of costs, especially if their intended purposes. As stated and the appropriate exchange, access, these were not disclosed when a above, the Condition of Certification and use of EHI. customer purchased or licensed the requirement would be violated were a We also proposed that, as a certified health IT. developer to refuse to provide complementary Condition of Comments. We received a comment documentation, support, or other Certification requirement, health IT recommending additional language to assistance reasonably necessary to developers of certified health IT must allow health IT developers to be able to enable the use of certified capabilities provide an assurance that they have provide an explanation of how their for their intended purposes (see 84 FR made certified capabilities available in software conforms to the certification 7466). We do not believe that actions by ways that enable them to be criteria requirements and how they health IT developers to provide their implemented and used in production enable the appropriate exchange, access, customers with education, environments for their intended and use of EHI. implementation, and connection purposes. More specifically, developers Response. We thank the commenter assistance to integrate certified would be prohibited from taking any for their input, but do not accept the capabilities for their customers would action that could interfere with a user’s recommendation. Health IT must typically constitute actions that interfere ability to access or use certified comply with certification criteria as with a customer’s ability to use certified capabilities for any purpose within the specified in regulation. We also refer capabilities for their intended purposes, scope of the technology’s certification. readers to the ‘‘Attestations’’ Condition but in the absence of specific facts, we Such actions may inhibit the of Certification requirement in this cannot say that whether there are appropriate access, exchange, or use of section of the preamble for more scenarios that would result in the EHI and are therefore contrary to this information regarding how we proposed assistance interfering with a user’s proposed Condition of Certification to provide flexibilities, including a ability to access or use certified requirement. While such actions are method for health IT developers to capabilities for any purpose within the already prohibited under the Program indicate their compliance, scope of the health IT’s certification. As (80 FR 62711), making these existing noncompliance, or the inapplicability of such, education and other assistance requirements that prohibit developers each Condition and Maintenance of may be offered, but care should be taken from taking any action that could Certification requirement as it applies to to do so in a manner that minds the interfere with a user’s ability to access all of their health IT certified under the Condition of Certification requirement or use certified capabilities for any Program, as well as the flexibility to standards. purpose within the scope of the specify noncompliance per certified Comments. We received a comment technology’s certification explicit in this Health IT Module, if necessary. As such, asking that health IT developers be Condition of Certification requirement we have finalized the Full Compliance required to provide honest will ensure that health IT developers are and Unrestricted Implementation of communication and expert advice as required to attest to them pursuant to Certification Criteria Capabilities required by a user. the Attestations Condition of Condition of Certification requirement Response. We appreciate the Certification requirement in § 170.406, as proposed that a health IT developer commenter’s suggestion regarding which will in turn provide additional must ensure that its health IT certified honest communication and expert assurances to the Secretary that under the Program conforms to the full advice. However, such a requirement developers of certified health IT support scope of the certification criteria to would not be consistent with this and do not inhibit appropriate access, which its health IT is certified, and that Condition of Certification requirement, exchange, or use of EHI. health IT developers would be which focuses on assurances that Health As discussed at 84 FR 7466 in our prohibited from taking any action that IT developers did not take actions that Proposed Rule, actions that would could interfere with a user’s ability to may inhibit the appropriate exchange, violate this Condition of Certification access or use certified capabilities for access, and use of electronic health requirement include failing to fully any purpose within the scope of the information (EHI). We also believe it deploy or enable certified capabilities; technology’s certification. We note that would be difficult to enforce such a imposing limitations (including because compliance with the requirement in terms of determining restrictions) on the use of certified information blocking section of this what constitutes an ‘‘honest’’ capabilities once deployed; or requiring final rule (Part 171) is not required until communication and ‘‘expert advice.’’ subsequent developer assistance to six months after the publication date of enable the use of certified capabilities, the final rule, § 170.402(a)(1) also has a b. Certification to the ‘‘Electronic Health contrary to the intended uses and six-month delayed compliance date. Information Export’’ Criterion outcomes of those capabilities). The Comments. A couple of commenters We proposed that a health IT Condition of Certification requirement requested clarification on whether developer that produces and would also be violated were a developer requiring subsequent developer electronically manages EHI must certify to refuse to provide documentation, assistance to enable the use of certain their health IT to the 2015 Edition ‘‘EHI support, or other assistance reasonably certified capabilities would be export’’ criterion in § 170.315(b)(10). As

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00079 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25720 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

a Maintenance of Certification months or less. Another commenter when this final rule is published. We requirement, we proposed that a health suggested that we narrow the type of also acknowledge the concerns IT developer that produces and health IT developer that must certify expressed regarding the 24-month electronically manages EHI must health IT to § 170.315(b)(10), noting that timeframe and have extended the provide all of its customers of certified some Health IT Modules may manage compliance timeline to within 36 health IT Modules with health IT data produced by other Health IT months of the final rule’s publication certified to the functionality included in Modules, or received and incorporated date, as finalized in § 170.402(b)(2)(i). § 170.315(b)(10) within 24 months of a from other sources. We did not receive With the narrowed scope of data export subsequent final rule’s effective date or any comments specific to our proposal for the criterion, we believe health IT within 12 months of certification for a to amend § 170.550 to require that developers should be able to provide all health IT developer that never ONC–ACBs certify health IT to the of their customers of Health IT Modules previously certified health IT to the proposed 2015 Edition ‘‘EHI export’’ certified to § 170.315(b)(10) with the 2015 Edition, whichever is longer. criterion when the health IT developer export functionality included in Consistent with these proposals, we also of the health IT Module presented for § 170.315(b)(10) within 36 months. We proposed to amend § 170.550 to require certification produces and electronically have also finalized in § 170.402(b)(2)(ii) that ONC–ACBs certify health IT to the manages EHI. that on and after 36 months from the proposed 2015 Edition ‘‘EHI export’’ Response. We thank the commenters publication of this final rule, health IT certification criterion when the health for their support. In response to developers that must comply with the IT developer of the health IT Module comments regarding scope of data requirements of § 170.402(a)(4) must presented for certification produces and export under this criterion, we have provide all of their customers of electronically manages EHI. As modified the proposed ‘‘EHI export’’ certified health IT with health IT discussed in section IV.C.1 of the certification criterion and scope of data certified to § 170.315(b)(10). From this Proposed Rule, the availability of the export. In doing so, we have also revised milestone forward, a health IT capabilities in the ‘‘EHI export’’ our Condition of Certification developer’s participation in the certification criterion promote access, requirement, which we have finalized in Certification Program obligates them to exchange, and use of health information § 170.402(a)(4), that a health IT provide the technical capabilities to facilitate electronic access to single developer of a certified Health IT expressed in § 170.315(b)(10) when they patient and patient population health Module that is part of a health IT provide such certified health IT to their information in cases such as a patient product which electronically stores EHI customers. We will monitor ongoing requesting their information, or a health must certify to the certification criterion compliance with this Condition and care provider switching health IT in § 170.315(b)(10). Additionally, we Maintenance of Certification through a systems. As such, health IT developers clarify that in attesting to § 170.406, a variety of means including, but not with health IT products that have health health IT developer must attest limited to, developer attestations IT Modules certified to the finalized accurately in accordance with pursuant to § 170.406, health IT ‘‘EHI export’’ certification requirement § 170.402(a)(4) and (b)(2) if the health IT developers real world testing plans, must make this functionality available developer certified a Health IT response to user complaints, and ONC– to customers and provide assurances Module(s) that is part of a health IT ACB surveillance activities. that the developer is not taking actions product which can store EHI. The finalized criterion focuses on the Health Consistent with the above revisions that constitute information blocking or IT Module’s ability to export EHI for the and in alignment with our proposal to any other action that may inhibit the health IT product’s single and patient amend § 170.550, we have also amended appropriate exchange, access, and use of population, which encompasses the EHI § 170.550(g)(5) regarding Health IT health information. We discussed the that can be stored at the time of Module dependent criteria for EHI export functionality in section certification by the product, of which consistency with the requirements of IV.B.4 of the Proposed Rule. the Health IT Module is a part. To note, § 170.402(a)(4) and (b)(2) when a Health Comments. A couple of commenters we do not require developers to disclose IT Module presented for certification is expressed their support for the proprietary information about their part of a health IT product which can Condition of Certification requirement, products. Also, as clarified above and in store electronic health information. In noting that certifying health IT to § 170.315(b)(10)(iii), we do not require addition, we have amended § 170.315(b)(10) would provide greater any specific standards for the export § 170.550(m)(2) to only allow ONC– EHI access to end users. Several format(s) used to support the export ACBs to issue certifications to commenters requested extending the functionality. § 170.315(b)(6) until 36 months after the implementation timeframe to 36 months In regards to when health IT publication date of this final rule. Thus, stating that more time is needed for developers must provide all of their ONC–ACBs may issue certificates for analysis, product development, and users of certified health IT with health either § 170.315(b)(6) or (b)(10) up until testing, with an additional 12 months IT certified to the functionality included 36 months after the publication date of for client adoption, testing, and training. in § 170.315(b)(10), we have removed this final rule, but on and after 36 A couple of commenters supported the the proposed language ‘‘within 12 months they may only issue certificates 24-month timeframe, but stated that months of certification for a health IT for Health IT Modules in accordance they did not support ONC dictating the developer that never previously with § 170.315(b)(10). We note that adoption schedule for providers, and certified health IT to the 2015 Edition, ONC–ACBs are required by their ISO/ that the proposal does not consider the whichever is longer.’’ Our intention was IEC 17065 accreditation to have efforts required from providers to plan to provide equity between existing and processes in place to meet the and execute effective implementation new health IT developers. However, we expectations and minimum and adoption. One commenter stated have concluded that new health IT requirements of the Program. Thus, that 24 months is not aggressive enough developers will not be at a disadvantage ONC–ACBs are expected to have and that the rule should prioritize to meet the same timeline considering processes in place in order to effectively certain aspects of patient-directed all health IT developers will be aware of monitor these timeline requirements on exchange and make these available in 12 requirements necessary for certification and after 36 months after the

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00080 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25721

publication of this rule, and to period also aligns with the records health IT developers that no longer additionally ensure that the health IT retention requirements for ONC–ACBs maintain a certified Health IT Module or developer attests accurately to and ONC–ATLs under the Program. have their certification suspended, a § 170.402(a)(4) and (b)(2). Should a We encouraged comment on these health IT developer who does not have developer fail to comply, the ONC–ACB proposals and whether the proposed any certified Health IT Modules within will follow its processes to institute requirements can provide adequate the Program would no longer have any corrective action and report to ONC in assurances that certified health IT obligation to retain records and accordance with Program reporting developers are demonstrating initial and information for the purposes of the requirements in 45 CFR ongoing compliance with the Program. However, we note that it may 170.523(f)(1)(xxii). In the event the requirements of the Program; and be in the health IT developer’s best developer does not follow through with thereby ensuring that certified health IT interest to retain their records and the corrective action plan established can support interoperability, and information. For example, records may and approved with the ONC–ACB, the appropriate exchange, access, and use of be useful for health IT developers in any ONC–ACB must alert ONC of the health EHI. potential investigation or enforcement IT developer’s failure to comply with Comments. Some commenters action taken outside of the ONC Health the Conditions and Maintenance of requested clarification on what records IT Certification Program such as by the Certification requirements. and information are expected to be HHS Office of the Inspector General Comments. A commenter requested maintained and how this is different (e.g., information blocking) or the U.S. ONC add functionality to the CHPL (or from the records ONC–ACBs and ONC– Department of Justice (e.g., False Claims in another format) that provides a list of ATLs retain. A couple commenters Act). the start and end dates of each requested clarification on when the previously certified Health IT Module. records and information retention d. Trusted Exchange Framework and the Response. We appreciate this requirement would take effect. One Common Agreement—Request for suggestion and note that the CHPL commenter requested clarification Information already lists certification dates for regarding the role of health IT In the Proposed Rule, we included a certified Health IT Modules, including developers that no longer maintain a Request for Information (RFI) as to the dates the Health IT Module was last certified Health IT Module or have their whether certain health IT developers modified, decertified, or made inactive. certification suspended. One commenter should be required to participate in the recommended setting a retention period c. Records and Information Retention Trusted Exchange Framework and for record keeping in the event that a Common Agreement (TEFCA) as a We proposed that, as a Maintenance health IT developer removes a Health IT means of providing assurances to their of Certification requirement in Module from market to ensure that customers and ONC that they are not § 170.402(b)(1), a health IT developer potentially short lived Health IT taking actions that constitute must, for a period of 10 years beginning Modules would inadvertently not have information blocking or any other action from the date of certification, retain all their documentation maintained. that may inhibit the appropriate records and information necessary to Response. We have adopted our exchange, access, and use of EHI. We demonstrate initial and ongoing proposal in § 170.402(b)(1) without received 40 comments on this RFI. We compliance with the requirements of the revisions. We continue to believe that appreciate the input provided by Program. In other words, records and 10 years is an appropriate period of time commenters and may consider them to information should be retained starting given that many users of certified health inform a future rulemaking. from the date a developer first certifies IT participate in various CMS programs, health IT under the Program and applies as well as other programs, that require 3. Communications separately to each unique Health IT similar periods of records retention. We The Cures Act requires that a health Module (or Complete EHR, as also finalized that in situations where IT developer, as a Condition and applicable) certified under the Program. applicable certification criteria are Maintenance of Certification This retention of records is necessary to removed from the Code of Federal requirement under the Program, does verify health IT developer compliance Regulations, records must only be kept not prohibit or restrict communication with Program requirements, including for 3 years from the date of removal for regarding the following subjects: certification criteria and Conditions and those certification criteria and related • The usability of the health Maintenance of Certification Program provisions unless that information technology; requirements. As stated in the Proposed timeframe would exceed the overall 10- • The interoperability of the health Rule, 10 years is an appropriate period year retention period. We clarify that information technology; of time given that many users of health IT developers are best situated to • The security of the health certified health IT participate in various determine what records and information information technology; CMS programs, as well as other in their possession would demonstrate • Relevant information regarding programs, that require similar periods of their compliance with all of the relevant users’ experiences when using the records retention. Program requirements. We note that it is health information technology; In an effort to reduce administrative our understanding that health IT • The business practices of burden, we also proposed, that in developers are already retaining the developers of health information situations where applicable certification majority of their records and technology related to exchanging criteria are removed from the Code of information for the purposes of ONC– electronic health information; and Federal Regulations before the 10 years ACB surveillance and ONC direct • The manner in which a user of the have expired, records must only be kept review under the Program. We also refer health information technology has used for 3 years from the date of removal for readers to section VII.D of this final rule such technology. those certification criteria and related preamble for additional discussion of The Cures Act established the broad Program provisions unless that records necessary for the enforcement of communications protections delineated timeframe would exceed the overall 10- the Conditions and Maintenance of above (referred to hereafter as year retention period. This ‘‘3-year from Certification requirements. In regard to ‘‘protected communications’’) and we the date of removal’’ records retention the requested clarification for the role of proposed in 84 FR 7467 to implement

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00081 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25722 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

this general prohibition against proposed requirements, primarily based the changes we have made to our developers imposing prohibitions and on concerns regarding intellectual proposals, in more detail below. restrictions on protected property (IP). a. Background and Purpose communications in § 170.403. Response. We appreciate the overall We also recognized that there are strong support for the Communications The Communications Condition of circumstances where it is both Condition of Certification requirements Certification requirements address legitimate and reasonable for developers as proposed and have finalized with industry practices of certified health IT to limit the sharing of information about modifications in § 170.403. We also developers that can severely limit the their health IT. As such, we proposed to recognize the need to provide ability and willingness of health IT allow developers to impose prohibitions clarification regarding some aspects of customers, users, researchers, and other or restrictions on protected the requirements, including regarding stakeholders to openly discuss and communications in certain narrowly the protections available for IP that are share their experiences and other defined circumstances. In order for a included in the Communications relevant information about health IT prohibition or restriction on a protected Condition and Maintenance of performance, including about the ability communication to be permitted, we Certification requirements. of health IT to exchange health proposed in 84 FR 7467 that it must We emphasize that, under section information electronically. These pass a two-part test. First, the 3001(c)(5) of the PHSA, participation in practices result in a lack of transparency communication that is being prohibited the ONC Health IT Certification Program that can contribute to and exacerbate or restricted must not fall within a class (Program) is voluntary. In other words, patient safety risks, system security of communications (hereafter referred to ONC cannot compel health IT vulnerabilities, and health IT as ‘‘communications with unqualified developers to participate in the Program performance issues. protection’’) that is considered to always nor can ONC impose consequences (e.g., We explained in the Proposed Rule be legitimate or reasonable—such as enforcement actions or penalties) on that the challenges presented by health communications required by law, made health IT developers who choose not to IT developer actions that prohibit or to a government agency, or made to a participate in the Program. The restrict communications have been defined category of safety organizations. requirements of the Program are much examined for some time. The problem Second, to be permitted, a developer’s like requirements for any other was identified in a 2012 report by the prohibition or restriction on voluntary contract or agreement an Institute of Medicine of the National communications must also fall within a entity would enter into with the Federal Academies (IOM) entitled ‘‘Health IT category of communications (hereafter Government. Through the Conditions and Patient Safety: Building Safer referred to as ‘‘permitted prohibitions and Maintenance of Certification Systems for Better Care’’ 73 (IOM and restrictions’’) for which it is both requirements, we have essentially Report). The IOM Report stated that legitimate and reasonable for a offered developers terms for health care providers, researchers, developer to limit the sharing of participation in the Program that we consumer groups, and other health IT information about its health IT. This believe are appropriate based on: Our users lack information regarding the would be because of the nature of the statutory instruction and interpretation functionality of health IT.74 The IOM relationship between the developer and of the Cures Act; the utility and Report observed, relatedly, that many the communicator or because of the necessity of using intellectual property, developers restrict the information that nature of the information that is, or including screenshots, to communicate users can communicate about could be, the subject of the issues with usability, user experience, developers’ health IT through communication. We proposed that a interoperability, security, or the way the nondisclosure clauses, confidentiality developer’s restriction or prohibition technology is used (and relatedly, the clauses, IP protections, hold-harmless that does not satisfy this two-part test real and substantial threat to public clauses, and other boilerplate contract would contravene the Communications health and safety resulting from language.75 The report stressed the need Condition of Certification requirement. prohibitions and/or restrictions on the for health IT developers to enable the We note that this two-part test strikes a communication of screenshots); and the free exchange of information regarding reasonable balance between the need to measured approach we have taken the experience of using their health IT, promote open communication about throughout the Communications including the sharing of screenshots health IT and related business practices, Condition and Maintenance of relating to patient safety.76 and the need to protect the legitimate Certification requirements (which is Concerns have also been raised by interests of health IT developers and discussed in detail in this section). researchers studying health IT,77 who other entities. Because the Program is voluntary, emphasize that confidentiality and IP Comments. The majority of public developers have the option to agree to provisions in contracts often place comments we received supported the the terms we have offered or to choose broad and unclear limits on authorized proposed Communications Condition of not to participate in the Program. As uses of information related to health IT, Certification requirements, with many such, we believe our policies commenters expressing strong support. concerning intellectual property, 73 IOM (Institute of Medicine), Health IT and Commenters stated that the proposed including the use of screenshots, are Patient Safety: Building Safer Systems for Better requirements would enable better consistent with other laws and Care (2012). Available at http:// communication that would improve regulations that govern terms for www.nationalacademies.org/hmd/Reports/2011/ Health-IT-and-Patient-Safety-Building-Safer- health IT and patient care. Some voluntary contracts and agreements Systems-for-Better-Care.aspx. commenters who supported the with the Federal Government. Further, 74 Id. at 37. proposed requirements sought we believe that the final provisions of 75 Id. at 36, 128. clarification or had specific concerns, this Condition of Certification include 76 Id. including regarding the proposed appropriate consideration of health IT 77 See Hardeep Singh, David C. Classen, and Dean deadlines for contract modification. developers’ intellectual property rights. F. Sittig, Creating an Oversight Infrastructure for Electronic Health Record-Related Patient Safety These matters are discussed in more We further discuss the various aspects Hazards, 7(4) Journal of Patient Safety 169 (2011). detail below. Additionally, a handful of of the Communications Condition of Available at https://www.ncbi.nlm.nih.gov/pmc/ public comments strongly opposed the Certification requirements, as well as articles/PMC3677059/.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00082 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25723

which in turn seriously impact the when making communications that are interoperability, and other critical issues ability of researchers to conduct and not afforded unqualified protection with health IT, and a consent publish their research.78 under § 170.403(a)(2)(i). For example, requirement would chill the ability of The issue of health IT developers we proposed that this Condition of users of health IT to engage in that prohibiting or restricting Certification’s requirements are not communication as well as be contrary to communications about health IT has limited to communications by health IT section 4002 of the Cures Act. been the subject of a series of hearings customers (e.g., providers) who have Comments. One commenter stated by the Senate Committee on Health, contracts with health IT developers. that the Communications Condition of Education, Labor and Pensions (HELP Comments. Many commenters Certification requirements should apply Committee), starting in the spring of addressed the scope of protected only to certified health IT, 2015. Senators on the HELP Committee communications in their comments. recommending that ONC clarify that the expressed serious concern regarding the Several commenters suggested that the use of ‘‘the health IT’’ refers only to the reported efforts of health IT developers proposed scope of protected developer’s health IT that is certified to restrict, by contract and other means, communications was too broad. Other under the ONC Health IT Certification communications regarding user commenters stated that the scope Program. The commenter stated that the experience, including information should be clarified. One commenter use of ‘‘the health IT’’ in the Cures Act relevant to safety and interoperability.79 suggested that the scope of private can only be reasonably interpreted as Developer actions that prohibit or communications that can be shared referring to the health IT for which a restrict communications about health IT should be limited and that ONC should developer is seeking certification, not all have also been the subject of require mutual consent for such of the developer’s health IT. Another investigative reporting.80 A September communications to be made public. commenter stated that other health IT, 2015 report examined eleven contracts Response. We appreciate these such as billing systems, should be out between health systems and major comments. The Cures Act identifies a of scope of this requirement and noted health IT developers and found that, list of subject areas about which health that to do otherwise would create a with one exception, all of the contracts IT developers cannot prohibit or restrict regulatory imbalance between protected large amounts of information communications to meet the conditions developers of such health IT who also from being disclosed, including for certification. The terms we proposed offer certified health IT and those who information related to safety and for the protected subject areas are taken do not. performance issues.81 from the language in section 4002 of the Response. We appreciate these comments regarding restricting the b. Condition of Certification Cures Act and include: • applicability of the Communications Requirements The usability of the health information technology; Condition of Certification requirements i. Protected Communications and • The interoperability of the health to certified health IT. We clarify that, as Communicators information technology; with all of the Conditions of We proposed in 84 FR 7468 that the • The security of the health Certification requirements, the protection afforded to communicators information technology; Communications Condition of under the requirements of the • Relevant information regarding Certification requirements apply to Communications Condition of users’ experiences when using the developers of health IT certified under Certification in § 170.403(a) would health information technology; the Program and to the conduct of such • apply irrespective of the form or The business practices of developers with respect to health IT medium in which the communication is developers of health information certified under the Program. By way of made. We proposed in 84 FR 7468 that technology related to exchanging example, if a developer had health IT developers must not prohibit or restrict electronic health information; and certified under the Program and also • communications whether written, oral, The manner in which a user of the had health IT that was not certified electronic, or by any other method if health information technology has used under the Program, then only those they are protected, unless such such technology. communications about the certified prohibition or restriction is otherwise We continue to interpret the above health IT would be covered by the permitted by the requirements of this statutory terms broadly, but within the Communications Condition of Condition of Certification. Similarly, we limiting framework we proposed, which Certification requirements. proposed that these Condition of includes a distinction between Comments. We received one comment Certification requirements do not communications entitled to unqualified requesting more specificity on the impose any limit on the identity of the protections and those communications definition of communicators covered by communicators that are able to benefit not entitled to such protection. We the Communications Condition of from the protection afforded, except that have, however, finalized some Certification requirements. The employees and contractors of a health IT provisions with further limiting and commenter expressed concern that the developer may be treated differently clarifying language as well as provided broad scope could impact the ability to examples to improve understanding of maintain confidentiality in traditional 78 Kathy Kenyon, Overcoming Contractual the provisions. business-to-business relationships. Barriers to EHR Research, Health Affairs Blog We decline to create a consent Response. We appreciate this (October 14, 2015). Available at http://healthaffairs. requirement as part of the requirements comment and understand the concern org/blog/2015/10/14/overcoming-contractual- of this Condition of Certification noted by the commenter. As stated in barriers-to-ehr-research/. the Proposed Rule and finalized in 79 Senate HELP Committee Hearing at 13 and 27 because such a requirement could (July 23, 2015), available at https:// unnecessarily encumber vital § 170.403, the Communications www.help.senate.gov/hearings/achieving-the- communications protected by the Cures Condition and Maintenance of promise-of-health-information-technology- Act. As highlighted above, the Certification requirements generally do information-blocking-and-potential-solutions. Communications Condition of not impose any limit on the identity of 80 D. Tahir, POLITICO Investigation: EHR gag clauses exist—and, critics say, threaten safety, Certification requirements are intended communicators that are able to benefit Politico, August 27, 2015. to enable unencumbered from the protection afforded. We also 81 Id. communication about usability, note that there are limited exceptions

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00083 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25724 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

where communications by certain these comments emphasized that false Comments. Several commenters communicators can be restricted. communications such as libel should requested that ‘‘safety’’ be added as a Specifically, as finalized in not be protected, nor should protected category or that ONC should § 170.403(a)(2)(ii)(A), health IT communications sent by someone who include in the final rule a specific ban developers can place limited restrictions obtained them illegally, such as a that prohibits any restrictions on on communications by employees and hacker. Some of the commenters communications about health IT-related contractors. We believe this will enable recommended adding a category of patient safety. Additionally, several traditional business-to-business communications that would never be commenters noted that ONC should relationships to continue without undue protected under the proposed include specific reporting methods or disruption, including allowing framework, and such communications standards in the final rule to improve implementation of non-disclosure would not receive unqualified safety reporting or add examples to help agreements or other contracts as protection or necessitate permitted encourage reporting of safety and necessary to maintain confidentiality. restrictions. This would allow a security issues. Several commenters also requested that ONC develop protocols ii. Protected Subject Areas developer to—for example—prohibit or restrict communications that are false or for reporting safety issues, and one Comments. We received several deceptive, would violate a law or court commenter recommended ONC develop comments requesting that we clarify order, or would result in a breach of a patient safety reporting system. how the Communications Condition of contract. Response. In implementing the Cures Certification requirements would apply Response. We appreciate the concerns Act requirement that a health IT to communications regarding public expressed by commenters regarding developer, as a Condition of health reporting, including statements that may be false or Certification requirement under the communications made by public health misleading. However, developers Program, not restrict communications authorities. about health IT, we adhered to the list Response. We emphasize that the already have legal means and remedies available to them to address such of protected subject areas identified by Cures Act identified a list of subject Congress in the Cures Act. Those subject areas about which we were required to statements, and this rule does not change that. For example, each State has areas include communications about forbid developers from prohibiting or ‘‘usability,’’ ‘‘relevant information restricting communications. Though libel laws that address libelous or defamatory statements and provide regarding users’ experiences when using public health reporting was not the health information technology,’’ and remedies in situations where the specifically covered by the Cures Act or the ‘‘manner in which a user of the specific facts in a damaging statement our proposed regulations, it may be that health information technology has used can be proven to be untrue. We believe certain public health communications such technology.’’ We clarify that that such statements are best addressed will fall within the categories patient safety issues related to an through those laws and that it is neither established by the statute. We also note interaction with the health IT could be prudent nor practical for ONC to use the that one of the ‘‘communications with covered in one or more of those Program and the Communications unqualified protection’’ discussed later categories. Additionally, we agree with Condition of Certification requirements in this section is for communicating commenters that safety-related to attempt to assess such statements and information about adverse events, communications should receive specific hazards, and other unsafe conditions to make determinations as to their protections, and we emphasize that the government agencies, health care veracity. communication of safety concerns is accreditation organizations, and patient Further, we note that the also addressed as a protected safety organizations. Depending on the Communications Condition of communication receiving ‘‘unqualified specific communication in question, a Certification requirements only provide protection.’’ In the section of this final communication about public health that such protected communications rule on ‘‘Communications with reporting or a communication made to cannot be restricted or prohibited. It is Unqualified Protection,’’ and in public health authorities could be a up to the health IT developer whether § 170.403(a)(2)(i)(B), we state that communication that could not be and how they choose to respond to the communicating information about restricted in any way. We also protected communication once made. adverse events, hazards, and other emphasize that, subject to limited Therefore, we clarify that it is not a unsafe conditions to government circumstances already discussed above, violation of the Communications agencies, health care accreditation we do not impose any limit on the Condition of Certification requirements organizations, and patient safety identity of the communicators that are for developers to respond to false or organizations is a communication about able to benefit from protections afforded unlawful comments under applicable which a developer would be prohibited under the Communications Condition of law, as they do now, and to pursue from imposing any prohibition or Certification requirements. litigation or any other available legal restriction. Communicators are broadly defined and remedy in response to any protected could include public health agencies communications that are covered by the (A) Usability of Health Information and authorities. Communications Condition of Technology Comments. Several commenters had Certification. For example, it would not The term ‘‘usability’’ is not defined in concerns regarding how a developer be a violation of the Communications the Cures Act, nor in any other relevant may address communications that Condition of Certification for a health IT statutory provisions. We proposed in 84 contain false claims or libelous developer who restricts the FR 7469 that the ‘‘usability’’ of health IT statements. Commenters discussed the communication of screenshots as be construed broadly to include both an need to enable health IT developers to— permitted under § 170.403(a)(2)(ii)(D) to overall judgment on the ‘‘usability’’ of a for example—refute false claims, deal pursue litigation for Copyright particular certified health IT product by with anonymous claims, and restrict infringement or violation of contract if the user, as well as any factor that certain communications (such as false a ‘‘protected communication’’ disclosed contributes or may contribute to statements or communications protected more screenshots than the developer’s usability. We proposed that the factors by attorney-client privilege). Some of restriction allowed. of usability that could be the subject of

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00084 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25725

protected communications include, but IT’’ would include communications required by the HIPAA Security Rule, are not limited to, the following: The about whether certified health IT and that may be implemented (or not user interface (e.g., what a user sees on associated developer business practices implemented) by a developer to ensure the screen, such as layout, controls, meet the interoperability definition the confidentiality, integrity, and graphics and navigational elements); described in section 3000(9) of the availability of EHI (information that ease of use (e.g., how many clicks); how PHSA, including communications about includes ePHI), together with the the technology supports users’ aspects of the technology or developer certified health IT’s performance workflows; the organization of that fall short of the expectations found regarding security. information; cognitive burden; cognitive in that definition. We stated that this Comments. One commenter noted support; error tolerance; clinical would include communications about that it is important that developers are decision support; alerts; error handling; the interoperability capabilities of able to remove posts on a website or customizability; use of templates; health IT and the practices of a health forum that could compromise the mandatory data elements; the use of text IT developer that may inhibit the access, security of health IT and recommended fields; and customer support. exchange, or use of EHI, including that ONC explicitly allow developers to Comments. One commenter stated information blocking. As previously do so in the final rule. that ‘‘usability’’ is too broadly defined noted, Congress did not define the terms Response. We recognize the and should relate more specifically to used in the Communications Conditions importance of protecting the security of judgments on the ease of use of the of Certification requirements in section EHI and health IT. We also recognize health IT, rather than factors related to 4002(a) of the Cures Act and codified in that our engagement with stakeholders, usability. section 3001(c)(5)(D)(iii) of the PHSA. as well as the language in section 4002 Response. We do not believe that We believe that ‘‘interoperability’’ was of the Cures Act, emphasize the strong ‘‘usability’’ is inaccurately defined nor appropriately defined in the Proposed public interest in allowing too broadly defined. To define usability Rule by using the interoperability unencumbered communications in the Proposed Rule, we referenced the definition that is located elsewhere in regarding the protected subject areas 82 NIST standard as well as principles section 4003(a)(2) of the Cures Act and and communications with unqualified recognized by the Healthcare codified in section 3000(9) of the PHSA. protection, which are discussed in more Information and Management Systems We did not receive comments about detail below and in § 170.403(a)(2)(i). Society (HIMSS). We also emphasized this aspect of the Proposed Rule, and we We emphasize that developers may that there are a multitude of factors that have finalized the scope of the protected respond to communications as allowed contribute to any judgment about subject area ‘‘interoperability of its under applicable law and may pursue ‘‘usability,’’ including factors health IT’’ in § 170.403(a)(1)(ii) as any appropriate legal remedy. Taking contributing to the effectiveness, proposed above. these factors into consideration, we efficiency, and performance of the decline at this time to explicitly allow health IT. We have finalized the scope (C) Security of Health IT developers to restrict communications of the protected subject area ‘‘usability The security of health IT is addressed regarding security as suggested by the of its health IT’’ in § 170.403(a)(1)(i) as by the HIPAA Security Rule,83 which commenter. Comments. One commenter requested proposed, providing that the ‘‘usability’’ establishes national standards to protect that ONC consider narrowing the of health IT be construed broadly to individuals’ electronic protected health permitted communication of security include both an overall judgment on the information (ePHI) that is created, elements in § 170.403(a)(1)(iii) that ‘‘usability’’ of a particular certified received, maintained, or transmitted by might be used to compromise a health IT product, as well as any of the a covered entity or business associate particular certified health IT’s security, many factors that could contribute to (as defined at 45 CFR 160.103). Covered for example restricting the sharing of usability as described in the Proposed entities and business associates must authentication credentials issued to a Rule. We also note that communications ensure the confidentiality, integrity, and customer or user to access a system about the usability of health IT may availability of all ePHI; protect against containing sensitive information such as include communications about features any reasonably anticipated threats or that are part of the certified health IT as PHI. hazards to the security or integrity of Response. We do not believe it is well as communications about what is such information; and protect against not in the certified health IT (e.g., the necessary in this final rule to narrow or any reasonably anticipated uses or restrict the information that can be absence of alerts or features that a user disclosures of such information that are believes would aid in usability or are communicated where security elements not permitted or required under the are included in the communication. As related to the other subject areas HIPAA Privacy Rule.84 The HIPAA identified by the Cures Act). stated above, we believe there is a strong Security Rule requires health IT public interest in allowing (B) Interoperability of Health developers, to the extent that they are unencumbered communications Information Technology business associates of covered entities, regarding the protected subject areas to implement appropriate The Cures Act, as codified in section and communications with unqualified administrative, physical, and technical 3000(9) of the PHSA, provides a protection. Further, assurances that safeguards to ensure the confidentiality, definition of ‘‘interoperability’’ that access credentials and PHI integrity, and availability of ePHI.85 We describes a type of health IT that communicated under these proposed in 84 FR 7469 that the matters demonstrates the necessary capabilities circumstances will not be shared that fall within the topic of health IT to be interoperable. For the purposes of inappropriately are addressed in the security should be broadly construed to the Communications Condition of HIPAA Security Rule and relevant State include any safeguards, whether or not Certification requirements, we proposed laws, and this rule does not change those protections. that protected communications 83 45 CFR part 160 and subparts A and C of part regarding the ‘‘interoperability of health 164. Comments. One comment 84 45 CFR part 160 and subparts A and C of part recommended that the Communications 82 See https://www.nist.gov/programs-projects/ 164. Condition of Certification requirements health-it-usability. 85 Id. should protect communication

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00085 Fmt 4701 Sfmt 4700 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 experience that could positively or information related to how the health IT that the health IT developer takes or negatively impact the effectiveness or has been used. We also proposed that makes the user take, including performance of the health IT. the terms used to describe the protected communications regarding a system Comments. One commenter stated subject areas should be construed with known and longstanding issues or that the most relevant aspect of a user’s broadly. We noted in the Proposed Rule bugs. experience of a health IT system is that this subject area largely overlaps Response. We appreciate this whether that experience resulted in with the matters covered under the comment and clarify that patient safety events and requested that ‘‘user experience’’ subject area but may communications related to the overall ONC specify patient safety events that include additional perspectives or security posture taken by a health IT arise from the use, misuse, or failure of details beyond those experienced by a developer would be within the subject health IT systems as ‘‘user experiences’’ user of health IT. We proposed that the area of ‘‘security of its health IT,’’ and that cannot be covered by gag orders. types of information that would fall thus would be protected Response. As previously noted in our within this subject area include but are communications covered by the response to patient safety comments not limited to: Communications Condition of above, we reiterate that a user • Information about a work-around Certification requirements. We have experience resulting in a patient safety implemented to overcome an issue in finalized the scope of the protected event would be covered under the the health IT; subject area ‘‘security of its health IT’’ Communications Condition of • customizations built on top of core in § 170.403(a)(1)(iii) as proposed. Certification requirements and that a health IT functionality; communication about such an • the specific conditions under which (D) User Experiences experience would be protected, subject a user used the health IT, such as The phrases ‘‘relevant information to other applicable laws. Further, information about constraints imposed regarding users’ experiences when using communications about ‘‘adverse events, on health IT functionality due to the health IT’’ and ‘‘user experience’’ hazards, and other unsafe conditions to implementation decisions; and are not defined in the Cures Act nor any government agencies, health care • information about the ways in other relevant statutory provisions. We accreditation organizations, and patient which health IT could not be used or proposed in 84 FR 7470 to afford the safety organizations’’ receive did not function as was represented by term ‘‘user experience’’ its ordinary unqualified protection as described in the developer. meaning. To qualify as a ‘‘user § 170.403(a)(2)(i). We noted in the We did not receive comments on this experience,’’ we proposed that the Proposed Rule that the Patient Safety specific aspect of the Proposed Rule, experience would have to have been one and Quality Improvement Act of 2005 and we believe the Proposed Rule that is had by a user of health IT. (PSQIA) provides for privilege and appropriately outlined what would fall However, beyond this, we did not confidentiality protections for within the subject matter of the manner propose to qualify the types of information that meets the definition of in which a user has used health IT. We experiences that would receive patient safety work product (PSWP). have finalized the scope of the protected protection under the Communications This means that PSWP may only be subject area ‘‘manner in which a user of Condition of Certification requirements disclosed as permitted by the PSQIA the health IT has used such technology’’ based on the ‘‘user experience’’ subject and its implementing regulations. We in § 170.403(a)(1)(vi) as proposed, with area. To illustrate the breadth of clarified that to the extent activities are the clarification that ‘‘used’’ refers to potential user experiences that would be conducted in accordance with the any uses of the certified health IT by the protected by the proposed PSQIA, its implementing regulation, user and is not limited to uses that Communications Condition of and section 4005(c) of the Cures Act, no involve direct patient care. Certification requirements, we proposed such activities shall be construed as that communications about ‘‘relevant constituting restrictions or prohibitions (F) Business Practices Related to information regarding users’ that contravene this Condition of Exchange experiences when using the health IT’’ Certification. We proposed in 84 FR 7470 that the would encompass, for example, We believe that ‘‘user experience’’ subject matter of ‘‘business practices of communications and information about was appropriately defined in the developers of health IT related to a person or organization’s experience Proposed Rule and have finalized the exchanging electronic health acquiring, implementing, using, or scope of the protected subject area information’’ should be broadly otherwise interacting with the health IT. ‘‘relevant information regarding users’ construed to include developer policies We also proposed that this would experiences when using its health IT’’ in and practices that facilitate the include experiences associated with the § 170.403(a)(1)(iv) as proposed, with the exchange of EHI and developer policies use of the health IT in the delivery of clarification provided above regarding and practices that impact the ability of health care, together with administrative patient safety events and to clarify that health IT to exchange health functions performed using the health IT. any communications regarding information. We further proposed that We proposed that user experiences consumer-facing technologies would the exchange of EHI would encompass would also include the experiences need to be about certified consumer- the appropriate and timely sharing of associated with configuring and using facing technologies per our earlier EHI. the technology throughout clarification about the scope of this We proposed that protected implementation, training, and in Condition of Certification being limited communications would include, but practice. Further, we proposed that user to certified health IT. would not be limited to: experiences would include patients’ and • The costs charged by a developer consumers’ user experiences with (E) Manner in Which a User Has Used for products or services that support the consumer apps, patient portals, and Health IT exchange of EHI (e.g., interface costs, other consumer-facing technologies of We proposed in 84 FR 7470 that API licensing fees and royalties, the health IT developer. We clarified protected communications regarding the maintenance and subscription fees, that a ‘‘relevant user experience’’ would ‘‘manner in which a user has used transaction or usage-based costs for include any aspect of the health IT user health IT’’ would encompass any exchanging information);

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00086 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25727

• the timeframes and terms on which and terms on which developers health IT can be used to achieve greater developers would or would not enable facilitate exchange; the developer’s interoperability, and is a protected connections and facilitate exchange approach to participating in health communication. with other technologies, individuals, or information exchanges and/or networks; In response to the comments entities, including other health IT the developer’s licensing practices and recommending that we seek guidance developers, exchanges, and networks; terms as related to APIs and other from the FTC, we note that we are not • the developer’s approach to interoperable services; and the regulating health IT developer terms, participation in health information developer’s approach to creating prices, and timeframes under this exchanges and/or networks; interfaces with third-party services. As Communications Condition of • the developer’s licensing practices proposed in 84 FR 7473, this Certification requirements, and and terms as it relates to making Communications Condition of therefore do not need to seek further available APIs and other aspects of its Certification requirement will also guidance. Rather, the Communications technology that enable the development apply to any communication concerning Condition of Certification requirements and deployment of interoperable a Program requirement (e.g., a Condition would protect communications about products and services; and or Maintenance of Certification health IT developer costs, terms, and • the developer’s approach to creating requirement) related to the exchange of timeframes as described above and interfaces with third-party products or EHI or the information blocking ensure that such information could be services, including whether connections provision. shared. We have finalized the scope of are treated as ‘‘one off’’ customizations, Comments. Several commenters had the protected subject area ‘‘business or whether similar types of connections concerns regarding communications practices of developers of health IT can be implemented at a reduced cost. about prices and costs, with some related to exchanging electronic health Importantly, we further proposed in commenters asserting that such information’’ in § 170.403(a)(1)(v) as 84 FR 7470 that information regarding communications should be protected proposed. ‘‘business practices of developers of and some others asserting that iii. Meaning of ‘‘Prohibit or Restrict’’ health IT related to exchanging developers should be able to restrict electronic health information’’ would communications about prices and costs, The terms ‘‘prohibit’’ and ‘‘restrict’’ include information about switching including switching costs. Additionally, are not defined in the Cures Act, nor in costs imposed by a developer, as we are one commenter had concerns about any other relevant statutory provisions. aware that the cost of switching health protecting communications regarding We discussed in the Proposed Rule that IT is a significant factor impacting timeframes and terms as well as communications can be prohibited or health care providers adopting the most workarounds and customizations. One restricted through contractual terms or exchange-friendly health IT available. commenter also recommended that ONC agreements (e.g., non-disclosure Comments. One commenter stated seek guidance from the Antitrust agreements or non-disparagement that our proposed ‘‘business practices’’ Division of the FTC regarding economic clauses) as well as through conduct, is too broadly defined and should relate impacts of regulating health IT including punitive or retaliatory exclusively to interoperability elements developer terms, prices, and timeframes. business practices that are designed to of certified health IT, rather than to Response. We continue to interpret create powerful disincentives to products and services that support costs, information regarding timeframes engaging in communications about exchange. and terms, and information about health developers or their health IT. Therefore, Response. As discussed in the IT workarounds and customizations as we proposed in 84 FR 7470 that the Proposed Rule, we believe the term protected communications under the Communications Condition of ‘‘business practices of developers of ‘‘Business Practices Related to Certification requirements would not be health IT related to exchanging Exchange’’ provision of this condition. limited to only formal prohibitions or electronic health information’’ should We believe that this type of information restrictions (such as by means of be broadly construed consistent with is frequently relied upon and necessary contracts or agreements) and would our interpretation of the Cures Act in order to optimize health IT for the encompass any conduct by a developer language regarding the Communications exchange of EHI. We emphasize that the that would be likely to restrict a Condition of Certification requirements, costs charged by a developer for communication or class of but limited to those business practices certified health IT or related services communications protected by the that relate to the certified health IT as that support the exchange of EHI are Communications Condition of clarified previously in this Condition significant factors that can impact the Certification requirements. We and Maintenance of Certification adoption of interoperable certified explained that the conduct in question section. A wide variety of business health IT and should be protected must have some nexus to the making of practices could impact the exchange of communications. For example, pricing a protected communication or an EHI, including developer business could include prohibitive costs that attempted or contemplated protected strategies, pricing, and even fraudulent prevent or discourage customers from communication. behavior. As such, we have finalized in using certified health IT to interact with § 170.403(a)(1)(v) our proposal that such competing technologies. Likewise, (A) Prohibitions or Restrictions Arising business practices include developer information regarding timeframes and by Way of Contract policies and practices that impact or terms is the type of information We explained in the Proposed Rule facilitate the exchange of EHI. They considered and relied upon in the that the principal way that health IT could also include costs charged by a adoption of interoperable certified developers can control the disclosure of developer not only specifically for health IT and is a protected information about their health IT is interoperability elements of the certified communication. We have also finalized through contractual prohibitions or health IT, but also for any products or in § 170.403(a)(1)(vi) that information restrictions. We noted that there are services that support the exchange of about certified health IT workarounds different ways that contractual EHI through the certified health IT. We and customizations relates to important prohibitions or restrictions arise. In reiterate that business practices related aspects of how a user has used certified some instances, a contractual to exchange could include timeframes health IT, including how the certified prohibition or restriction will be

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00087 Fmt 4701 Sfmt 4700 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 was some nexus between the conduct or prohibit developers from imposing any scope of the prohibition or restriction performance issue and the making of (or prohibition or restriction on will be explicit in the contract or attempting or threatening to make) a communications that fall into a narrow agreement. However, we also noted that protected communication. class of communications—consisting of a contract may also impose prohibitions We did not receive comments on this the five specific types of or restrictions in less precise terms. We specific aspect of the Proposed Rule and communications described below—that stated that a contract does not need to have finalized our interpretation would receive unqualified protection. expressly prohibit or restrict a protected proposed in 84 FR 7471 regarding (A) Disclosures Required by Law communication in order to have the prohibitions or restrictions arising by effect of prohibiting or restricting that way of conduct as stated above. We proposed in 84 FR 7472 that protected communication. The use of where a communication relates to iv. Communications With Unqualified subject areas enumerated in proposed broad or vague language that obfuscates Protection the types of communications that can § 170.403(a)(1) and there are Federal, and cannot be made may be treated as We proposed in 84 FR 7472 a narrow State, or local laws that would require a prohibition or restriction if it has the class of communications—consisting of the disclosure of information related to effect of restricting legitimate five specific types of communications— health IT, developers must not prohibit communications about health IT. that would receive unqualified or restrict in any way protected We stated that restrictions and protection from developer prohibitions communications made in compliance prohibitions found in contracts used by or restrictions. With respect to with those laws. We noted that we developers to sell or license their health communications with unqualified expect most health IT contracts would IT can apply to customers directly and protection, a developer would be allow for, or not prohibit or restrict, any can require that the customer ‘‘flow- prohibited from imposing any communication or disclosure that is down’’ obligations to the customer’s prohibition or restriction. We proposed required by law, such as responding to employees, contractors, and other that this narrow class of a court or Congressional subpoena, or a individuals or entities that use or work communications warrants unqualified valid warrant presented by law with the developer’s health IT. We protection because of the strength of the enforcement. We further proposed that proposed that such contract provisions public policy interest being advanced by if required by law, a potential would not comply with the the class of the communication and/or communicator should not have to delay Communications Condition of the sensitivity with which the identified any protected communication under the Certification requirements and would be recipient treats, and implements Communications Condition of treated as prohibiting or restricting safeguards to protect the confidentiality Certification requirements. protected communications. We noted and security of, the information We did not receive comments on this that prohibitions or restrictions on received. We stated that a developer that aspect of the Proposed Rule and have communications can also be found in imposes a prohibition or restriction on finalized in § 170.403(a)(2)(i)(A) our separate nondisclosure agreements a communication with unqualified approach regarding disclosures required (NDAs) that developers require their protection would fail the first part of the by law as proposed. two-part test for allowable prohibitions customers—and in some instances the (B) Communicating Information About or restrictions, and as such would users of the health IT or third-party Adverse Events, Hazards, and Other contravene the Communications contractors—to enter into in order to Unsafe Conditions to Government Condition of Certification requirements. receive or access the health IT. We Agencies, Health Care Accreditation proposed that such agreements are Comments. One commenter recommended adding language Organizations, and Patient Safety covered by the Communications Organizations Condition of Certification requirements. specifying the types of entities that can We did not receive comments on this receive communications with We proposed in 84 FR 7472 that there specific aspect of the Proposed Rule and unqualified protection, noting that such is an overwhelming interest in ensuring have finalized our interpretation specificity would help ensure that these that all communications about health IT proposed in FR 7471 regarding communications go to the appropriate that are necessary to identify patient prohibitions or restrictions arising by entities so that they can be addressed safety risks, and to make health IT safer, way of contract as stated above. quickly. The commenter recommended not be encumbered by prohibitions or that provisions around reporting to restrictions imposed by health IT (B) Prohibitions or Restrictions That government entities should be limited to developers that may affect the extent or Arise by Way of Conduct United States government entities. timeliness of communications. In We proposed in 84 FR 7471 that Response. We do not believe it is addition to the public policy interest in conduct that has the effect of necessary to further specify the types of promoting uninhibited communications prohibiting or restricting a protected entities that can receive about health IT safety, we proposed that communication would be subject to the communications with unqualified the recognized communication channels Communications Condition of protection. We intend for this protection for adverse events, hazards, and unsafe Certification requirements. We to cover a wide variety of organizations, conditions provide protections that help emphasized that the conduct in and further specifying the types of ensure that any disclosures made are question must have some nexus to the entities that can receive such appropriately handled and kept making of a protected communication or communications, such as limiting confidential and secure. We proposed an attempted or contemplated protected communication to only United States that the class of recipients to which the communication. As such, developer government entities, would information can be communicated conduct that was alleged to be unnecessarily limit the scope of this under this specific category of intimidating, or health IT performance protection and could be counter to the communications given unqualified that was perceived to be substandard, public policy interest to advance the protection should provide health IT would not, in and of itself, implicate the ability of these communications to developers with comfort that there is Communications Condition of occur unencumbered. We have finalized little risk of such communications Certification requirements unless there in § 170.403(a)(2)(i) our proposal to prejudicing the developer’s IP rights.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00088 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25729

We sought comment on whether the users to notify them simultaneously or which developers are permitted to unqualified protection afforded to prior to reporting such incidents, with restrict communications (see communications made to a patient one comment noting that this would § 170.403(a)(2)(ii)(B) as finalized). Last, safety organization about adverse enable developers to better address and we note that we will continue to work events, hazards, and other unsafe respond to security threats prior to the with our Federal partners to mitigate conditions should be limited. knowledge of a threat becoming and address cybersecurity threats and Specifically, we sought comment on widespread. Some commenters incidents. whether the unqualified protection recommended that ONC make it a (D) Communicating Information About should be limited by the nature of the violation for developers to not share Information Blocking and Other patient safety organization to which a cybersecurity vulnerabilities with Unlawful Practices to a Government communication can be made, or the providers, and that ONC work with DHS Agency nature of the communication that can to mitigate issues around sharing such made. vulnerabilities. One commenter We proposed in 84 FR 7473 that the Comments. Several commenters recommended changing the wording public benefit associated with the stated that ONC should not place any regarding communicating cybersecurity communication of information to limits on the unqualified protection and security risks to include known government agencies on information afforded to communications made to vulnerabilities and health IT defects. blocking, or any other unlawful patient safety organizations about practice, outweighs any concerns Response. We strongly encourage developers might have about the adverse events, hazards, and other users of health IT to notify developers unsafe conditions. disclosure of information about their as soon as possible when reporting Response. We have finalized in health IT. We noted that reporting security incidents and issues. However, § 170.403(a)(2)(i)(B) as proposed information blocking, as well as other regarding the unqualified protection it would not be appropriate to require unlawful practices, to a government afforded to communications about this practice, which would impose an agency would not cause an undue threat adverse events, hazards, and other obligation on users of health IT that is to a health IT developer’s IP. unsafe conditions that are made to outside the scope of this rule. It would Comments. We received several government agencies, health care also be outside the scope of this comments regarding the lack of accreditation organizations, and patient condition to implement additional whistleblower protections in the safety organizations. Additionally, we requirements for developers regarding Proposed Rule for individuals who placed no limits or qualifiers on such the sharing of cybersecurity report information blocking or other communications, including those vulnerabilities with health care issues regarding certified health IT. communications made to patient safety providers. To be clear, we expect These comments discussed the need to organizations. developers with Health IT Modules provide for whistleblower type certified under the Program to share protections for individuals who (C) Communicating Information About information about cybersecurity highlight information blocking Cybersecurity Threats and Incidents to vulnerabilities with health care practices, as well as to identify them to Government Agencies providers and other affected users as the appropriate authorities so that the We proposed in 84 FR 7472 that if soon as feasible, so that these affected individual is not subject to retaliatory health IT developers were to impose users can take appropriate steps to action by the actor identified by the prohibitions or restrictions on the mitigate the impact of these whistleblower. ability of any person or entity to vulnerabilities on the security of EHI Response. We appreciate these communicate information about and other PII in the users’ systems. comments and agree that it is extremely cybersecurity threats and incidents to Thus, we have finalized the important for individuals to be able to government agencies, such conduct Communications Condition of report information blocking and would not comply with the Certification requirements in violations of other Conditions of Communications Condition of § 170.403(a)(2)(i)(C) as proposed. Certification without fear of retaliation. Certification requirements. Developers must not place restrictions We note that the Communications We sought comment on whether it on communications receiving Condition of Certification requirements would be reasonable to permit health IT unqualified protections. We also clarify provide protections against retaliation developers to impose limited that known vulnerabilities and health IT and intimidation by developers with restrictions on communications about defects would likely be considered respect to protected communications. security issues to safeguard the types of ‘‘adverse events, hazards, and We discussed in the Proposed Rule that confidentiality, integrity, and security of other unsafe conditions’’ that would the Communications Condition of EHI. In the Proposed Rule, we asked if, receive ‘‘unqualified protection,’’ and Certification requirements cover for example, health IT developers thus a developer would not be able to communications that are prohibited or should be permitted to require that restrict a health IT user from restricted through contractual terms or health IT users notify the developer communicating about such issues in agreements (e.g., non-disclosure about the existence of a security communications receiving unqualified agreements, non-disparagement clauses) vulnerability prior to, or simultaneously protections under the Communications between the health IT developer, or with, any communication about the Condition of Certification requirements offeror of health IT, and the issue to a government agency. (see § 170.403(a)(2)(i) as finalized). communicator, as well as through Comments. Some commenters stated However, we note that in conduct, including punitive or that users should never be required to communications not receiving retaliatory business practices that are notify the developer when reporting unqualified protection under the designed to create powerful cybersecurity issues, as this would Communications Condition of disincentives to engaging in impose a burden on the user and a Certification requirements, a security communications about developers or potential barrier to reporting. Other vulnerability that is not already public their health IT. We clarify, however, commenters recommended that knowledge would be considered a non- that merely filing a lawsuit against the developers should be allowed to require user-facing aspect of health IT, about communicator regarding the making of

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00089 Fmt 4701 Sfmt 4700 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 or other Program requirement is vital to permitted would violate the considered intimidating conduct in the effective performance and integrity Communications Condition of violation of this Condition. Any such of the Program. Moreover, the failure of Certification requirements. determination would necessarily be a certified health IT to meet such Additionally, we proposed that it would fact-specific, and the health IT requirements could impact the be the developer’s burden to developer’s lawsuit would have to be performance of the certified health IT demonstrate to the satisfaction of ONC designed to intimidate a communicator with respect to usability, safety, and that the developer met all associated in order to prevent or discourage that interoperability. We stated that it is requirements. Further, as an additional communicator from making a protected important to enable unencumbered safeguard, we proposed that where a communication, rather than be designed reporting of such information and that developer sought to avail itself of one of to pursue a legitimate legal interest. We such reporting is essential to the the permitted types of prohibitions or believe that the proposed broad transparency that section 4002 of the restrictions, the developer must ensure interpretation of ‘‘prohibit’’ and Cures Act seeks to ensure. While the that potential communicators are clearly ‘‘restrict’’ is appropriate given the current procedures for reporting issues and explicitly notified about the intention of the Cures Act, which placed with certified health IT encourage information and material that can be no limitations on the protection of providers to contact developers in the communicated, and that which cannot. communications about the protected first instance to address certification We proposed this would mean that the subject areas. We finalized this issues, we noted that users of health IT language of health IT contracts must be interpretation of ‘‘prohibit’’ and should not hesitate to contact ONC- precise and specific. We stressed that ‘‘restrict’’ proposed in 84 FR 7470 and Authorized Certification Bodies (ONC– contractual provisions or public believe that the interpretation would ACBs), or ONC itself, if the developer statements that support a permitted provide significant protections for does not provide an appropriate prohibition or restriction on whistleblowers from retaliatory actions. response, or the matter is of a nature communication should be specific about Thus, retaliatory actions by a developer that should be immediately reported to the rights and obligations of the against a whistleblower would be in an ONC–ACB or to ONC. potential communicator. We explained violation of this provision. We also We did not receive any comments on that contract terms that are vague and emphasize that conduct by a developer this aspect of the Proposed Rule. In cannot be readily understood by a that may be perceived as intimidating or consideration of the above, we have reasonable health IT customer would punitive would not implicate the finalized this provision in not benefit from the qualifications to Communications Condition of § 170.403(a)(2)(i)(E) as proposed. this Condition of Certification Certification requirements unless that requirement as outlined in the Proposed conduct was specifically designed to v. Permitted Prohibitions and Rule and below. influence the making of a protected Restrictions (A) Developer Employees and communication. In other words, We proposed in 84 FR 7473 that, Contractors punitive actions must have a nexus to except for communications with the making of a protected unqualified protection We recognized in the Proposed Rule communication, such as retaliation for (§ 170.403(a)(2)(i)), health IT developers in 84 FR 7473 that health IT developer reporting of information blocking, in would be permitted to impose certain employees, together with the entities order to violate the Communications narrow prohibitions and restrictions on and individuals who are contracted by Condition of Certification requirements communications. Specifically, we health IT developers to deliver products in § 170.403(a)(1). Last, we refer readers proposed that, with the exception of and/or services (such as consultants), to the discussion of ‘‘complaints’’ under communications with unqualified may be exposed to highly sensitive, the information blocking section of this protection, developers would be proprietary, and valuable information in final rule, which details the permitted to prohibit or restrict the the course of performing their duties. confidentiality provided to information following communications, subject to We also stated that we recognize that an blocking complaints and complainants. certain conditions: employer should have the ability to We have finalized the • Communications of their own determine how and when the Communications Condition of employees; organization communicates information Certification requirements in • Disclosure of non-user-facing to the public, and that employees owe § 170.403(a)(2)(i)(D) as proposed. aspects of the software; confidentiality obligations to their • Certain communications that would employers. We noted that this would (E) Communicating Information About a infringe the developer’s or another similarly apply to contractors of a Health IT Developer’s Failure To person’s IP rights; developer. We proposed in 84 FR 7473 Comply With a Condition of • Publication of screenshots in that on this basis, developers would be Certification or Other Program narrow circumstances; and permitted to impose prohibitions or Requirement • Communications of information restrictions on the communications of We proposed in 84 FR 7473 that the that a person or entity knows only employees and contractors to the extent benefits to the public and to users of because of their participation in that those communications fall outside health IT of communicating information developer-led health IT development of the class of communications with about a health IT developer’s failure to and testing. unqualified protection as discussed comply with a Condition of Certification The proposed Communications above. requirement or other Program Condition of Certification requirements Comments. One commenter stated requirement (45 CFR part 170) justify delineated the circumstances under that this provision should be clarified prohibiting developers of health IT from which these types of prohibitions and and expanded to cover other third placing any restrictions on such restrictions would be permitted, parties with whom the health IT protected communications. We including certain associated conditions developer shares its confidential explained that information regarding the that developers would be required to information, including subcontractors, failure of certified health IT to meet any meet. We emphasized that any agents, auditors, suppliers, partners, co- Condition of Certification requirement prohibition or restriction not expressly sellers, and re-sellers, as well as

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00090 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25731

potential relationships for which a (B) Non-User-Facing Aspects of Health users, thus the non-user-facing contract has not yet been signed in case IT provision should apply only to ‘‘non- information is shared during a pre- We proposed in 84 FR 7474 that the end-user-facing’’ aspects of health IT. contract evaluation stage. Communications Condition of Some commenters emphasized that administrative portions of health IT Response. We reiterate that Certification requirements would permit health IT developers to impose contain more insight into health IT ‘‘developer employees and contractors’’ systems and that administrative include health IT developer employees, prohibitions and restrictions on communications to the extent necessary functions affect a limited number of together with the entities and users and are not the types of individuals who are contracted by to ensure that communications do not disclose ‘‘non-user-facing aspects of communications or subject matters health IT developers to deliver health IT contemplated by the Cures Act. One and/or services who may be exposed to health IT.’’ We noted that, like all permitted prohibitions, such commenter stated that algorithms highly sensitive, proprietary, and should be considered non-user-facing. prohibitions and restrictions could only valuable information in the course of Another commenter stated that ONC be put in place by developers if there is performing their duties. This functional should clarify the status of diagrams and not an unqualified protection that description of employees and flowcharts. applies. We proposed in 84 FR 7474 that contractors could include Response. We do not see a necessary a ‘‘non-user-facing aspect of health IT,’’ or appreciable distinction between subcontractors, agents, auditors, for the purpose of this Condition of suppliers, partners, co-sellers, and re- ‘‘users’’ and ‘‘end users,’’ as we have Certification, was an aspect of health IT focused on the aspects of the health IT sellers, depending on the specific that is not a ‘‘user-facing aspect of relationship and circumstances. We that are and are not subject to protected health IT.’’ We stated that ‘‘user-facing communications under this Condition have finalized the proposed approach to aspects of health IT’’ would include the describing employees and contractors in of Certification. We also believe that design concepts and functionality that is there could be unintended § 170.403(a)(2)(ii)(A). We note that we readily ascertainable from the health consequences with the term ‘‘end user,’’ did not expand this description to IT’s user interface and screen display. such as limiting certain users not include ‘‘potential relationships’’ We stated that they did not include specified under the ‘‘permitted because such an addition would make those parts of the health IT that are not prohibitions and restrictions’’ (e.g., the description overly broad, and it is exposed to persons running, using, or developer employees and contractors) unlikely that individuals who are not observing the operation of the health IT from making protected communications. yet under contract would be exposed to and that are not readily ascertainable Therefore, we believe ‘‘non-user-facing’’ highly sensitive, proprietary, and from the health IT’s user interface and best reflects the scope of the valuable information. screen display, all of which would be communications about health IT we considered ‘‘non-user-facing’’ concepts. Comments. We received one comment seek to capture with these terms. We proposed in 84 FR 7474 that ‘‘non- that self-developers should not be We reiterate that ‘‘non-user-facing user-facing aspects of health IT’’ would aspects of health IT’’ comprise those permitted to place restrictions on the include source and object code, software communications of their employees aspects of the health IT that are not documentation, design specifications, readily apparent to someone interacting who are using their certified health IT. flowcharts, and file and data formats. with the health IT as a user of the health Response. We agree that self- We welcomed comments on whether IT, including source and object code, developers should not be allowed to these and other aspects of health IT certain software documentation, design restrict the communications of users of should or should not be treated as user- specifications, flowcharts, and file and their certified health IT who are also facing. data formats. We clarify that ‘‘non-user- employees or contractors. We have In the Proposed Rule, we noted that facing aspects of health IT’’ would also revised § 170.403(a)(2)(ii)(A) to clarify the terminology of ‘‘non-user-facing include underlying software that is that the limited prohibitions developers aspects of health IT’’ is not intended to utilized by the health IT in the may place on their employees or afford only health IT users with specific background and not directly by a user contractors under the Communications protections against developer of the health IT. For example, the Condition of Certification requirements prohibitions or restrictions on programming instructions for cannot be placed on users of a self- communications and is agnostic as to proprietary APIs would be considered developer’s certified health IT who are the identity of the communicator. non-user-facing because they are not Comments. Some commenters also employees or contractors of the readily apparent to the individual users expressed concern regarding the broad self-developer. For example, a large of the health IT. In addition, underlying scope of ‘‘user-facing’’ and, by database software that connects to health system with a self-developed extension, the scope of ‘‘non-user- health IT and is used to store data EHR cannot restrict a health care facing.’’ One commenter asked for would be considered a non-user-facing provider, who is employed by that clarification regarding the definition of aspect of health IT because it serves data health system and using that EHR to ‘‘software documentation’’ with regards to the health IT, not directly to a user. provide services, from communicating to non-user-facing aspects of health IT We further clarify that algorithms about the EHR as a user based on the and suggested that it applies to would be considered ‘‘non-user-facing fact that the health care provider is also documentation that is for back-end aspects of health IT’’ as they are not an employee of the health system. We components, not documents for normal- readily apparent to persons using health note that the concept of ‘‘self- end use. Additionally, a couple of IT for the purpose for which it was developed’’ refers to a Complete EHR or comments stated that administrative purchased or obtained. Thus, Health IT Module designed, created, or functions should not be considered communications regarding algorithms modified by an entity that assumed the user-facing, including one comment that (e.g., mathematical methods and logic) total costs for testing and certification the relevant users for the purpose of the could be restricted or prohibited, while and that will be the primary user of the Communications Condition of communications regarding the output of health IT (76 FR 1300). Certification requirements are ‘‘end’’ the algorithm and how it is displayed in

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00091 Fmt 4701 Sfmt 4700 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 that any prohibition or restriction Condition of Certification requirements. restricted as ‘‘non-user-facing aspects of imposed by a developer must be no Also, as discussed earlier regarding health IT.’’ Similarly, we also clarify broader than legally permissible and developer employees and contractors in that certain ‘‘software documentation’’ reasonably necessary to protect the § 170.403(a)(2)(ii)(A), developers may that would be considered to be a non- developer’s legitimate IP interests. We restrict communications by their user-facing aspect of health IT would also proposed in 84 FR 7474 that health employees, contractors, and consultants include documentation for back-end IT developers are not permitted to without implicating the components, again because it is not prohibit or restrict, or purport to Communications Condition of readily apparent to persons using health prohibit or restrict, communications Certification requirements, provided IT. that would be a ‘‘fair use’’ of any they do not restrict communications Whether or not a communication copyright work comprised in the with unqualified protections. Further, as would be considered a ‘‘non-user-facing developer’s health IT.86 ‘‘Fair use’’ is a described earlier regarding non-user- aspects of health IT’’ would be based on legal doctrine that allows for the facing aspects of certified health IT in whether the communication involved unlicensed use of copyright material in § 170.403(a)(2)(ii)(B), developers may aspects of health IT that would be certain circumstances, which could restrict communications that disclose evident to anyone running, using, or include circumstances involving non-user-facing aspects of the observing the operation of the health IT criticism, commentary, news reporting, developer’s certified health IT, provided for the purpose for which it was and research.87 they do not restrict communications purchased or obtained. With respect to Comments. One commenter stated with unqualified protections. We administrative functions, where the that fair use should not override other clarified in that section that screenshots communication at issue relates to IP protections and stressed that relying or videos depicting source code would aspects of the health IT that are not on fair use could lead to uncertainty be considered communications of non- observable by users of the health IT, it because it is determined on a case-by- user-facing aspects of health IT and would be considered ‘‘non-user-facing’’ case basis. Another commenter stated could be restricted under the for the purpose of this Condition of that because the fair use doctrine can be Communications Condition of Certification requirement. For example, difficult to implement and can lead to Certification requirements as long as a communication regarding an input uncertain results, ONC should expand they did not receive unqualified process delay experienced by an the list of communications that would protection. We also clarify that this administrator of health IT that was be explicitly protected as fair use to Condition does not prohibit health IT caused by the underlying database include news reporting, criticism, developers from enforcing their IP rights software could be restricted if the parody, and communications for and that a lawsuit filed by a health IT communication discussed the educational purposes. developer in response to a protected underlying database software, which Response. We disagree with communication regarding infringement would be considered a non-user-facing commenters and believe that relying on of IP rights would not automatically be aspect of the health IT. However, if the the ‘‘fair use’’ doctrine for determining considered intimidation or retaliation in communication discussed the user when a screenshot or other violation of this Condition. screens and the delay experienced by communication cannot be restricted As discussed later in the pre-market the administrator, which would be should be allowed under the testing and development section in § 170.403(a)(2)(ii)(E), developers can considered user-facing aspects of health Communications Condition of IT, it could not be restricted. Similarly, place restrictions on communications Certification requirements. This as long as diagrams or flowcharts do not related to pre-market health IT doctrine presents a framework of include aspects of the health IT that are development and testing activities, analysis that is well-developed in case observable by users of the health IT, as which could include IP protections, law and thus can be interpreted and described above, they would be provided they do not restrict applied consistently, even when considered communications about non- communications with unqualified materials are not formally copyrighted. user-facing aspects of health IT. protections. Combined, these avenues Accordingly, we are retaining the We have finalized in allow for protecting IP in ways that concept of ‘‘fair use’’ in the final § 170.403(a)(2)(ii)(B) our proposed would not implicate the approach to the scope of ‘‘non-user- provision in § 170.403(a)(2)(ii)(C). Communications Condition of facing aspects of health IT’’ with the Developers and ONC will apply a fair Certification requirements, thereby clarification provided above regarding use test to copyrighted materials and, by allowing developers to take a number of scope. analogy, to materials that could be actions to protect and safeguard IP in copyrighted, to determine whether their certified health IT. (C) Intellectual Property developers may prohibit a Comments. Several commenters We proposed in 84 FR 7474 that the communication that would infringe on requested clarity regarding how the Communications Condition of IP rights. proposed protections for IP would work. Certification requirements are not The Communication Condition of One commenter stated that the rule intended to operate as a de facto license Certification requirements relate only to must allow developers to protect for health IT users and others to act in protected communications, thus legitimate IP interests and asked for a way that might infringe the legitimate developers can place restrictions on clarity on how ONC would determine IP rights of health IT developers or other communications about subject matters whether a developer’s restriction on the persons. Indeed, we proposed in 84 FR outside of the protected communication of a screenshot was an 7474 that health IT developers are communications categories without allowable protection of trade secrets or permitted to prohibit or restrict certain implicating the Communications an impermissible restriction of communications that would infringe protected communications. Several their IP rights so long as the 86 See 17 U.S.C. 107 (setting forth the four factors other commenters, who generally required to evaluate a question of fair use under the communication in question is not a statutory framework). supported the Communications communication with unqualified 87 See https://www.copyright.gov/fair-use/more- Condition of Certification requirements, protection. We proposed in 84 FR 7474 info.html for more information on fair use. requested clarification regarding how a

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00092 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25733

prohibition on communications that is enabling protected communications and Comments. A large number of designed to protect IP can be applied. do not believe that an ‘‘intent’’ element commenters, particularly health care Some commenters requested examples would be necessary. We have finalized providers, supported our proposals of the types of communications that can the proposals regarding IP in regarding the communication of be restricted on the basis of IP and § 170.403(a)(2)(ii)(C), as amended above. screenshots, with several stressing how clarification of the standard ONC will helpful screenshots are when (D) Faithful Reproductions of Health IT use to determine what prohibitions are communicating usability and safety Screenshots permissible. issues with health IT. One commenter Response. We have finalized an We proposed in 84 FR 7475 that noted that communication of approach in § 170.403(a)(2)(ii)(C) that health IT developers generally would screenshots can help different health allows developers to prohibit or restrict not be permitted to prohibit or restrict care systems understand whether a communications that involve the use or communications that disclose proposed implementation of an EHR has disclosure of intellectual property screenshots of the developer’s health IT. introduced safety-related challenges at existing in the developer’s health IT We proposed that the reproduction of other locations, or help identify (including third-party intellectual screenshots in connection with the solutions to common problems, such as property), provided that any prohibition making of a communication protected usability challenges. One other or restriction imposed by a developer by this Condition of Certification would commenter stated that there is nothing must be no broader than necessary to ordinarily represent a ‘‘fair use’’ of any novel displayed in health IT screenshots protect the developer’s legitimate copyright subsisting in the screen that would need to be protected. intellectual property interests and display, and developers should not Response. We appreciate the many consistent with all other requirements impose prohibitions or restrictions that positive comments on our proposals under the ‘‘permitted prohibitions and would limit that fair use. regarding screenshots. restrictions’’ (§ 170.403(a)(2)(ii)) of this Notwithstanding this, we proposed that Comments. Commenters stated that section. As discussed above, a health IT developers would be allowed the scope of protected communications restriction or prohibition would be to place certain restrictions of the as proposed should exclude disclosure deemed broader than necessary and disclosure of screenshots as specified in of the health IT itself, such as through inconsistent with the ‘‘permitted proposed § 170.403(a)(2)(ii)(D). screenshots. The commenter stressed prohibitions and restrictions’’ With respect to the limited allowable that the Cures Act required that health (§ 170.403(a)(2)(ii)) if it would restrict or restrictions on screenshots, we proposed IT developers not restrict preclude a public display of a portion of in 84 FR 7475 that developers would be communications about the certified a work subject to copyright protection permitted to prevent communicators health IT with respect to specific topic (without regard to whether the from altering screenshots, other than to areas, while the Proposed Rule expands copyright is registered) that would annotate the screenshot or to resize it for that restriction to include reasonably constitute a ‘‘fair use’’ of that the purpose of publication. We also communication of the health IT itself. work. proposed that health IT developers One commenter noted that the Cures Examples of the types of could impose restrictions on the Act does not mention screenshots and communications that could be restricted disclosure of a screenshot on the basis they should not be included in the under the Communications Condition of that it would infringe third-party IP Communications Condition of Certification requirements might rights (on their behalf or as required by Certification requirements. include a blog post describing a license). However, to take advantage of Response. The Cures Act amended customization of a developer’s health IT this exception, we proposed in 84 FR title XXX of the PHSA to establish this that includes the source code of the 7475 that the developer would need to condition of certification, which applies developer’s health IT or a written first put all potential communicators on to ‘‘health information technology.’’ review of an analytical feature of the sufficient written notice of those parts of Title XXX of the PHSA was previously developer’s health IT that reveals the the screen display that contain IP and added by the HITECH Act, which algorithms used. However, as cannot be communicated, and would included the definition of ‘‘health mentioned above, the restriction must still need to allow communicators to information technology.’’ Section be no broader than necessary to protect communicate redacted versions of 3000(5) of the PHSA defines health the developer’s legitimate IP interests, screenshots that do not reproduce those information technology to mean thus only the infringing portions of the parts. Finally, we proposed in 84 FR hardware, software, integrated communications could be restricted. 7475 that it would be reasonable for technologies or related licenses, IP, Comments. One commenter developers to impose restrictions on the upgrades, or packaged solutions sold as recommended that a health IT developer communication of screenshots that services that are designed for or support must demonstrate that a communication contain PHI, provided that developers the use by health care entities or was specifically designed to copy or permit the communication of patients for the electronic creation, steal a developer’s IP in order for the screenshots that have been redacted to maintenance, access, or exchange of developer to be allowed to prohibit the conceal PHI, or where the relevant health information. We emphasize both communication as an infringement on individual’s consent or authorization that this definition includes IP their IP rights. had been obtained. associated with the health information Response. We appreciate this We welcomed comments on whether technology and that it applies to this comment, but decline to require that a an appropriate balance had been struck condition of certification as this developer demonstrate that a between protecting legitimate IP rights condition references communications communication was designed to copy or of developers and ensuring that health regarding health information steal IP in order for the developer to IT customers, users, researchers, and technology. We have also adopted this restrict the communication as one that other stakeholders who use and work definition in § 170.102. would infringe on IP rights. We believe with health IT can openly discuss and We disagree with the commenters’ that the revised approach discussed share their experiences and other interpretation of the statutory provision. above provides appropriate balance relevant information about the The statutory provision focuses on between protecting IP rights and performance of health IT. ‘‘communications’’ regarding

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00093 Fmt 4701 Sfmt 4700 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. Response. We agree with the Response. We appreciate the Communications are not defined nor recommendation that protections comments regarding how a developer’s limited in the Cures Act, and we afforded to screenshots should extend to IP may be impacted by the proposed to broadly define them. video. We clarify that, like screenshots, Communications Condition of Verbal, written, and visual, as well other video is considered a form of visual Certification requirements. As discussed types of communications, are all communication. A video of a computer earlier in this section, participation in covered under the Cures Act. A screen while a software program is in the Program is voluntary; and screenshot is a copy/picture of the user operation would capture the user developers have the option to agree to interface of the health IT, or a ‘‘visual experience of interacting with that the terms we have offered or to choose communication’’ that is protected under program and essentially would show a not to participate in the Program. this condition of certification. We have number of screenshots from that However, we recognize the need to specifically defined ‘‘communication’’ program in rapid succession. We properly balance the protection of a for this section in § 170.403(c) to mean emphasize that video, similarly to developer’s IP with the need to advance any communication, irrespective of the individual screenshots, is a critical form visual communications (e.g., screenshot form or medium. The term includes of communication of issues with the and video communications) under the visual communications, such as health IT, including issues related to Communications Condition and screenshots and video. usability, user experience, Maintenance of Certification As we emphasized in the Proposed interoperability, security, or the way the requirements, which we believe is Rule in 84 FR 7475, the sharing of technology is used. critical to addressing—among other screenshots (with accompanying As with screenshots, video is things—the usability, interoperability, annotation and/or explanatory prose) is particularly useful in communicating a and security of health IT. As discussed often a critical form of communication user’s experience with health IT and the throughout this section and in section of issues with health IT related to—for manner in which the user has used (C) above, we believe that we have example—usability, user experience, health IT. This is especially the case properly considered and addressed interoperability, security, or the way the when issues of a temporal nature are health IT developers’ IP rights in this technology is used. We believe involved. For example, video would be final rule in § 170.403(a)(2)(ii)(C) by screenshots are uniquely helpful as a essential for illustrating a latency issue amending the proposed regulation as form of visual communication that can experienced during drug ordering that described above. We emphasize that the non-verbally illustrate the ‘‘user’s could not be communicated through experiences when using the health communication of screenshots is screenshots or other forms of information technology’’ and the essential to protect public health and communication. Video also could be ‘‘manner in which a user of the health safety and that our final policies take a critical to demonstrating an issue with information technology has used such measured approach to responding to a clinical decision support alert that is technology’’ as they relate intrinsically and addressing a real and substantial designed to appropriately and timely to both subject areas and capture those threat to public health and safety. The notify the provider of a patient matter user experiences immediately and communication of screenshots enables but fails to do so. directly. Further, enabling screenshot providers, researchers, and others to sharing can allow for clearer, more Comments. Several commenters identify safety concerns, share their immediate, and more precise expressed concern regarding how a experiences with the health IT, learn communication on these pertinent developer’s IP may be impacted by the from the problems, and then repair issues, potentially helping a health proposed Communications Condition of dangers that could otherwise cause system avoid costly, or even deadly, Certification requirements. Several serious harm to patients. Our position is complications when implementing commenters stated that the Proposed informed both by years of experience health IT. It is also our understanding Rule goes beyond protecting regulating health IT and overwhelming that screenshots are often the only communications for the purposes of research and academia, which is recourse a user in a network enterprise patient safety and system improvement discussed below. system has for capturing, documenting, and would enable or require For instance, a study published in and explaining their concerns. We inappropriate sharing and disclosure of 2018 was performed to better clarify, however, that the sharing of a IP, potentially creating security risks, characterize accessibility to EHRs screenshot alone would not be increased IP theft, and harming among informatics professionals in considered a protected communication innovation and the marketplace for various roles, settings, and organizations as it would need to be accompanied by health IT. Several commenters stated across the United States and an explanation of the issues or aspects that trade secrets, patent protections, internationally.88 To quantify the of the health IT that the screenshot is and protections for confidential and limitations on EHR access and meant to communicate or illustrate. proprietary information were not publication rights, the researchers Considering the value of addressed or considered appropriately conducted a survey of informatics communicating significant issues in the Proposed Rule, and that as a professionals from a broad spectrum of regarding health IT through screenshots, result it would be possible for bad actors roles including practicing clinicians, we have finalized our proposal to to create pirated health IT based on the researchers, administrators, and include screenshots as a protected disclosure of screenshots and similar members of industry. The results were communications under the Cures Act. communications. Commenters stated analyzed and levels of EHR access were However, as discussed in responses to that developers of health IT have stratified by role, organizational other comments below, we have revised successfully used licensing and affiliation, geographic region, EHR type, our final policy in multiple ways. nondisclosure agreements that apply to and restrictions with regard to Comments. One commenter user-facing aspects of the technology to recommended that screenshots should maintain the trade secret status of their 88 Khairat, S, et al. 2018 Assessing the Status Quo be defined broadly to include video and health IT and that the Proposed Rule of EHR Accessibility, Usability, and Knowledge Dissemination. eGEMs (Generating Evidence & other media that can be helpful in would impact their ability to do so and Methods to improve patient outcomes), pp. 1–11, demonstrating challenges with EHRs. remain competitive in the market. https://doi.org/10.5334/egems.228.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00094 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25735

publishing results of usability testing, Committee on Patient Safety and Health prescribing safety should be a priority including screenshots. Among faculty Information Technology (Committee) and should take precedence over members and researchers, 72 percent explained that a significant impediment commercial considerations (and to the could access the EHR for usability and/ to gathering safety data is contractual extent correctable problems can be or research purposes, but, of those, barriers (e.g., nondisclosure, identified, likely would result in an fewer than 1 in 3 could freely publish confidentiality clauses) that can prevent improved commercial CPOE product). screenshots with results of usability users from sharing information about In cases where the FDA sought to testing and half could not publish such health IT–related adverse events. They illustrate problems in the system, they data at all. Across users from all roles, further explained that such barriers drew generic screenshots to illustrate only 21 percent reported the ability to limit users’ abilities to share knowledge the issue in question.97 of risk-prone user interfaces, for publish screenshots freely without Among their recommendations, the 89 instance through screenshots and restrictions. FDA recommended that vendors be The study explained that the patient descriptions of potentially unsafe required to share screenshots and error safety implications of EHR publication processes. In addition, some vendors reports. The FDA emphasized that censorship and restricted EHR access include language in their sales contracts vendors should be required to permit are multiple. First, limiting institutions and escape responsibility for errors or the sharing of screenshots and from sharing usability research findings defects in their software (i.e., ‘‘hold- information with the FDA and other can prevent the correction of known harmless clauses’’). The Committee institutions regarding other CPOE problems. Second, without public concluded that these types of system issues of concern or that pose dissemination, poor design practices contractual restrictions limit risk for errors. They stressed that the will propagate to future iterations of transparency, which significantly practice of prohibiting such sharing via existing vendor systems. Finally, contributes to the gaps in knowledge of research efforts are directed away from health IT–related patient safety risks. copyright must be eliminated. Further, real-world usability problems at a time Further, these barriers to generating the FDA recommended that vendors when EHR systems have become widely evidence pose unacceptable risks to should be required to disclose errors deployed and when an urgency exists to safety.94 Based on these findings, the reported to them or errors identified in accelerate usability testing. The study committee recommended that the their products, analogous to the referenced the 2011 Institute of Secretary of HHS should ensure insofar requirement that drug manufacturers 98 Medicine report (as discussed in the as possible that health IT vendors report significant adverse drug effects. Proposed Rule and in additional detail support the free exchange of One of the co-authors of the FDA below), which identified contractual information about health IT experiences study recently wrote a law review restrictions as a barrier to knowledge and issues and not prohibit sharing of article that discussed the significance of regarding patient safety risks related to such information, including details (e.g., screenshots.99 The author noted that the health IT.90 screenshots) relating to patient safety.95 results of the FDA study were The study emphasized that the result Recently, the U.S. Food and Drug remarkable and remarkably distressing, of this level of censorship is that a vast Administration (FDA) funded Brigham as they identified and took screenshots majority of scientists researching EHR and Women’s Hospital Center for of over fifty different dangers in the usability are either prevented from Patient Safety Research and Practice to health IT. He expressed frustration that publishing screenshots altogether or conduct an exploration of computerized it took up to two years of additional must first obtain vendor permission, prescriber order entry (CPOE)-related discussions with the vendors to get thus impeding the free dialogue potential for errors in prescribing, permission to share the screenshots necessary in communities of particularly as these relate to drug name publicly, and that even after these investigation.91 The study argued that: displays, and ordering and workflow extended discussions, one vendor— (1) Lack of EHR access makes many design issues. The project investigated ‘‘with more than a lion’s share of the critical EHR usability research activities ways to better identify, understand, and market’’—prevented the study from impossible to conduct, and (2) prevent electronic ordering errors in the displaying the screenshots, some of 96 publication censorship, especially future. However, the researchers noted which were clearly dangerous or deadly. regarding screenshots, means that even that one large vendor would not grant He explained that they had worked those usability studies which can be permissions to share requested around that limitation by substituting conducted may not have the impact screenshots necessary for the study. the one vendor’s screens with parallel they otherwise would. As a This refusal ran counter to both the screens taken from Harvard’s consequence, innovation can be stifled. FDA’s task order initial precondition as homegrown, but by then superannuated, As such, one of the recommendations well as multiple high-level panels’ EHR. The author emphasized that those made by the researchers was that there health IT safety recommendations. The images and screenshots illustrated over should be a mandate that screenshots FDA emphasized that it is hard to justify fifty EHR risks caused by dangerous and and images from EHR systems be freely from a safety viewpoint why such confusing EHR interfaces. The author publishable without restrictions from permission was withheld, despite the also emphasized that the study could copyright or trade secret constraints.92 vendors’ proprietary concerns. FDA have been even more helpful in In the report by the Institute of explained that identifying, preventing, identifying these risks if the FDA had Medicine that was noted above, entitled and learning from errors and improving been able to present the findings when Health IT and Patient Safety: Building first available, rather than haggle for a 93 Care. Washington, DC: The National Academies Safer Systems for Better Care, the Press, https://doi.org/10.17226/13269. year or two, and if the study was able 94 Id. at 3. 89 Id. at 1. 95 Id. at 7. 97 Id. at 44. 90 Id. at 2. 96 U.S. Food & Drug Admin., UCM477419, 98 Id. at 52. 91 Id. at 7. Computerized Prescriber Order Entry Medication 99 Ross Koppel, Uses of the Legal System That 92 Id. at 8. Safety: Uncovering and Learning from Issues and Attenuate Patient Safety, 68 DePaul L. Rev. (2019) 93 Institute of Medicine 2012. Health IT and Errors, https://www.fda.gov/downloads/Drugs/ Available at: https://via.library.depaul.edu/law- Patient Safety: Building Safer Systems for Better DrugSafety/MedicationErrors/UCM477419.pdf. review/vol68/iss2/6.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00095 Fmt 4701 Sfmt 4700 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 could be shared and the potential that need to be communicated to each system they studied.100 negative consequences of allowing demonstrate or display the issue. Comments. A commenter screenshots to be shared. In the We have finalized provisions in recommended that ONC draw a Proposed Rule in 84 FR 7475, we § 170.403(a)(2)(ii)(D)(2) and (3) that distinction around purpose of use in proposed to allow developers to place allow health IT developers to require relation to the fair use of screenshots limited restrictions on the sharing of persons who communicate screenshots and require that the discloser of a screenshots. We stressed in the to limit the sharing of screenshots to screenshot be responsible for ensuring Proposed Rule that our goal with our only the relevant number of screenshots the appropriateness of that purpose. proposals concerning screenshots was to and amount of video that are needed to Response. As discussed under section enable communications that will communicate about the health IT (C) above we have retained the concept address matters such as patient safety, regarding one or more of the six subject of ‘‘fair use’’ as it applies to all health system security vulnerabilities, health areas identified in the Cures Act and IT developer intellectual property IT performance, and usability. Our detailed in § 170.403(a)(1). Allowing covered under ‘‘permitted prohibitions developers to limit the sharing of intent was not to prevent developers and restrictions’’ (§ 170.403(a)(2)(ii)). As screenshots to only the relevant number from restricting the communication of discussed throughout this section, we needed to communicate about the screenshots for purposes outside the have placed certain restrictions on the health IT—regarding one or more of sharing of screenshots responsive to the scope of the protected communications those six subject areas—places a commenter. detailed in the Cures Act. Additionally, limitation on the number of screenshots Comments. One commenter urged we believe that modern software design allowed to be shared under the ONC to revise the proposed approach to best practices uncouple screen design Communications Condition of screenshots by adopting a process that from underlying algorithms, and that Certification requirements and requires would allow developers to review and limited use of screenshots for safety that the screenshots are related to, and approve screenshots for publication for would not allow reverse engineering of thus necessary in illustrating, the specific purposes, such as large parts of the underlying code. protected communication being made. communications about safety and However, we further emphasize that it In practice, this would mean that if a usability. was never our intention that screenshots particular safety issue in the health IT Response. A pre-approval process (or other visual communications such as could be communicated using three could create potential or perceived video) depicting source or object codes screenshots, the communicator should barriers to communications and thus would be protected communications not share additional screenshots that are could discourage or delay the making of (see the non-user-facing aspects irrelevant or only potentially relevant to protected communications that are vital provision of this Condition of communicate the safety issue with the to patient safety or other important Certification), so long as such health IT. If the communication issues regarding certified health IT. For communications are not included additional screenshots that example, a user might be less willing to communications with unqualified were not necessary to visually go through the process, the time the protection. communicate about the particular safety process takes could undermine the We reviewed comments that issue with the health IT that falls within conveyance of the communications, and suggested establishing a set numerical the usability category, the health IT the objections raised during the process limit for the sharing of screenshots. developer would have grounds to seek may not be valid or amenable to all However, we have not finalized a redress. parties. As with screenshots, we wish to be requirement in § 170.403(a)(2)(ii)(D) Comments. Several commenters had sensitive to concerns regarding with a fixed numerical limit because concerns regarding the volume of protecting IP in health IT and allow there is no non-arbitrary way to screenshots that could be shared under developers to appropriately limit video determine what the ‘‘right’’ or our proposal and potential harms that communication in order to protect could occur. One commenter ‘‘appropriate’’ number is in a one-size- against harms that could occur due to emphasized that sharing of screenshots fits-all way. That is because the number unlimited sharing. Similar to could disclose information about how of screenshots or amount of video that screenshots, the amount of video that health IT works, including algorithms would be needed to communicate about may be necessary to make a protected and workflows, and enable creation of the health IT could vary, from one communication about health IT could duplicate software and theft of valuable situation to the next, based on the vary, depending on the nature of the IP. One commenter suggested that if a specific issue and circumstances. For issue or aspect of the health IT being user of health IT published hundreds of instance, an issue with health IT addressed. For example, a video meant screenshots of the health IT, a bad actor functionality regarding a particular to communicate a delay in order entry could theoretically deduce trade secrets process that involves the user viewing would need to be long enough to based on the screenshots. Several and making selections on several communicate the significance of the additional commenters were also different screens may necessitate images delay, but would not need to include concerned that the Proposed Rule could of all of the screens involved in order video of the log-in process or other allow communication of an unlimited to communicate the issue. However, an unrelated functionality of the health IT. number of screenshots of certified issue regarding how one value is being We have finalized a provision in health IT, and one commenter suggested displayed in a particular context (e.g., a § 170.403(a)(2)(ii)(D)(3) that allows revising the proposed approach to medication name being truncated) may health IT developers to place certain include limiting sharing of screenshots only necessitate one screenshot in order limitations on the communication of to a reasonable number, such as seven. to communicate the issue. Thus, we video. Under this provision, a health IT Response. We appreciate those believe the best approach is to adopt a developer may require persons who comments expressing concerns qualitative standard that is designed to communicate video to limit the sharing regarding the volume of screenshots that be sufficiently flexible for the wide of video to: (1) The relevant amount of range of health IT issues that may arise video needed to communicate about the 100 Id. at 280–81. and the varying visual communications health IT regarding one or more of the

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00096 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25737

subject areas identified in the Cures Act stated that the proposal should be We requested comment on whether and detailed in § 170.403(a)(1); and (2) removed. One commenter we should limit the time this protection only videos that address temporal recommended ONC consider not would apply for testing purposes. We matters that the user reasonably believes making developers accountable for also requested comment on whether we cannot be communicated through actions by health IT users regarding the should set specific parameters for screenshots or other forms of disclosure of screenshots with third- covered testing. communications. party information. One commenter Comments. A couple of commenters In sum, any disclosure must be requested additional guidance from stated that there should be no limit on limited to the relevant number of ONC for dealing with third-party, non- how long testing and development screenshots or amount of video that is health IT content in health IT. could last for the purpose of the necessary to convey the matter that falls Response. Where a health IT restrictions that developers would be within one of the six subject areas, with developer is prohibited by this rule from allowed to place on communications video only being used to convey restricting the communication of a regarding products in development. temporal matters that cannot be screenshot and allows a screenshot These commenters stressed that any communicated through screenshots or containing third-party content to be limit would be arbitrary and that until other forms of communication. We communicated, the health IT developer certified health IT is in live commercial believe these additional limitations on is acting as required by this final rule use, health IT developers should be the communication of screenshots and and enabling important communication permitted to restrict communications video will further bolster protections for regarding critical health IT issues to about it. developer IP, while still allowing occur. Thus, we believe developers Response. We agree with the necessary and effective communication acting in accordance with this final rule commenters and did not propose to add about health IT issues within the six should not be responsible for third-party a time limit on testing and development subject areas. content in screenshots that are phases for the purpose of this Condition Comments. Several commenters communicated as required by the of Certification requirement. stated that there should be a way to Communications Condition of Comments. A couple of commenters protect against doctored screenshots. Certification requirements. As such, in requested clarification that providers Response. As proposed, § 170.403(a)(2)(ii)(D) we have removed testing products in real-world communicators of screenshots must not from the requirements related to third- environments would not be considered alter the screenshots (or video), except party IP rights proposed in 84 FR 7475. ‘‘contractors’’ of developers for the to annotate the screenshots or resize the purpose of the Communications screenshots (§ 170.403(a)(2)(ii)(D)(1)). (E) Testing and Development Condition of Certification requirements These restrictions similarly apply to We discussed in the Proposed Rule in because such treatment could result in video as well (§ 170.403(a)(2)(ii)(D)(1)). 84 FR 7475 that some health IT developers being allowed to place We further note that, despite a lack of developers expose aspects of their additional communication restrictions comments, on further reflection, we health IT to health care providers and on employees and contractors under the have elected to not finalize proposed others for the purpose of testing and Communication Condition of limitations to allow developers to development prior to a product’s Certification requirements. One impose restrictions on the ‘‘general availability’’ release. We stated comment also stated that restrictions on communication of screenshots that that such disclosures may relate to beta communications by employees and contain PHI. We have made this releases that are shared with certain contractors should not extend to their determination because we believe that customers for testing prior to the communications regarding product most of the individuals or entities software being made generally available features and functionality that the communicating the screenshots would to the market, or may be made as part employees and contractors were not be bound by other laws, including the of a joint-venture or cooperative involved in developing or testing. HIPAA Rules and State privacy laws, development process. In these Response. The applicability of this which would be applicable to the PHI circumstances, we proposed in 84 FR allowable restriction to providers testing at issue. Therefore, we do not believe it 7475 that a health IT developer would products would be determined by the is necessary to provide for developers be justified in keeping information particular facts at issue and whether or policing the release of such data in the about its health IT confidential. We not the provider was an actual form of screenshots in this Condition of explained that this permitted contractor, employee, or consultant for Certification. prohibition or restriction would allow the developer. We also clarify that this Comments. A number of commenters developers to seek appropriate IP final rule does not limit the restrictions discussed the infeasibility of the protection and discuss novel, a developer may place on an employee, proposed requirements regarding ‘‘unreleased’’ product features with contractor, or consultant with regard to restricting communication of their customer base, which has protected communications, except to screenshots, and in particular, the significant public policy benefits for the extent that the communication is requirement that health IT developers research and innovation in the health IT one with unqualified protection, in put all potential communicators on industry. which case no such restrictions would sufficient written notice of each aspect We proposed in 84 FR 7475 that this be allowed. of its screen display that contains third- permitted restriction would be limited Comments. One commenter party content that cannot be and would not apply to recommended that a health IT user must communicated because it would communications that are subject to have used health IT in a real-world infringe IP rights. Some commenters unqualified protection as specified in context before a communication by the stated that the proposed language proposed § 170.403(a)(2)(i). We user about the health IT can be should be amended to require a list of proposed that this permitted restriction protected. third-party content that might appear in would also not apply to Response. We have finalized our a screen or that the developer communications about the released proposal in § 170.403(a)(2)(ii)(E) that a sublicenses, or to require a notice on the version of the health IT once the health health IT developer would be justified developer’s website. Other commenters IT has been released. in keeping information about its health

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00097 Fmt 4701 Sfmt 4700 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 the Communications Condition of 84 FR 7476 for amending contracts/ ‘‘general availability’’ release. We note Certification requirements, we proposed agreements to be in compliance with that a health IT developer would also be in 84 FR 7476 that the developer would this condition. While we considered justified in keeping information about a not be in contravention of the extending the deadline to five years to product update confidential because the Communications Condition of allow developers to have additional update is not yet generally available. We Certification requirements so long as it time for compliance, we determined do not place any limits on who the takes no step to enforce the prohibition that a more flexible solution is communicator has to be in order to be or restriction. We did not propose that appropriate. As such, we have modified covered by the Communications health IT developers be required to the requirement in § 170.405(b)(2)(ii) to Condition of Certification requirements, furnish to ONC or their ONC–ACB state that any contracts/agreements in particularly since the protections in the copies of notices made to customers, or place as of the effective date of the final Communications Condition of copies of contracts or agreements rule and containing language in Certification requirements extend revised, in satisfaction of this contravention of the Communications beyond users of certified health IT to Maintenance of Certification Condition of Certification requirements cover researchers and other stakeholders requirement, although we noted that must be revised to remove or void the who may experience certified health IT those communications could be contractual provision that contravenes in a variety of settings and scenarios. As requested by ONC or an ONC–ACB in the Communications Condition of such, we have decided not to limit the the usual course of business or to Certification requirements whenever the communication protection to only those demonstrate compliance. contract is next modified for any reason. communications that are made by users Comments. A number of commenters We clarify that where a contract of certified health IT in the real-world expressed concerns regarding the automatically renews, the developer context. proposed deadlines for complying with would still be prohibited under the the requirements. Several commenters Program from enforcing any agreement c. Maintenance of Certification stated that the requirement to notify Requirements or contract provisions that contravene customers and others with whom the the Communications Condition of We proposed in 84 FR 7476 that to developer has contracts or agreements Certification requirements in maintain compliance with the within six months was too long and § 170.403(a) and the developer would Communications Condition of recommended that the deadline be also be responsible for sending an Certification requirements, a health IT shortened. Regarding the deadline for annual notice as described above until developer must not establish or enforce amending contracts/agreements that such provisions have been modified. To any contract or agreement provision that contravene the Communications note, we decline to absolve a developer contravenes the Communications Condition of Certification requirements, of the requirement to modify the Condition of Certification requirements. most commenters stated that the contract solely because the developer We also proposed in 84 FR 7476 that a deadline was too short, with several has made a reasonable effort to do so. health IT developer must notify all requesting that it be extended to five entities or individuals with which it has years. Some other commenters We finalized the notification a contract/agreement related to certified recommended that modification of any requirements proposed in 84 FR 7476. A health IT that any communication or contracts/agreements to comply with health IT developer must notify all contract/agreement provision that the Communications Condition of entities and individuals with which it contravenes the Communications Certification requirements should occur has a contract/agreement related to Condition of Certification requirements whenever such contracts/agreements are certified health IT that any will not be enforced by the health IT renewed, or at the earliest available communication or contract/agreement developer. We proposed in 84 FR 7476 time, without the need for a specific provision that contravenes the that such notification must occur within deadline. A couple of commenters Communications Condition of six months of the effective date of the recommended that a health IT developer Certification requirements will not be final rule. Further, we proposed in 84 not be held responsible for amending enforced by the health IT developer. FR 7476 that this notice would need to contracts within two years of the However, we no longer require that such be provided annually up to and until effective date of the final rule if it has notification must occur within six the health IT developer amends the made reasonable efforts to do so. Several months of the effective date of the final contract or agreement to remove or comments recommended that ONC rule and annually thereafter until make void any contractual provision should allow alternative means of contravening provisions are amended. that contravenes the Communications completing this requirement, such as Instead, notification must only occur Condition of Certification requirements. posting relevant language on the annually, beginning in calendar year We further proposed as a Maintenance developer’s website. One commenter 2020, and continue until all of Certification requirement in proposed stated that it would be helpful to have contravening provisions are amended. § 170.403(b)(2) that health IT developers a ‘‘standard exception clause’’ that Given the timing of the publication of must amend their contracts/agreements developers could use in their contracts the final rule, health IT developers to remove or make void any provisions and agreements. could have potentially been required to that contravene the Communications Response. We appreciate the provide both initial notification and an Condition of Certification requirements comments we received on this annual notification in the same calendar within a reasonable period of time, but provision. We clarify in year. We believe the removal of the six not later than two years from the § 170.403(b)(2)(i) that a developer may months notification deadline and effective date of a final rule. not include provisions that contravene retention of an annual requirement only, In the event that a health IT developer the Communications Condition of beginning with notification in calendar cannot, despite all reasonable efforts, Certification requirements in any new year 2020, will simplify compliance for locate an entity or individual that contract as of the effective date of the health IT developers while still previously entered into an agreement final rule. In consideration of providing adequate notice and ensuring with the developer that prohibits or comments, we have decided to modify that initial notification is provided in a restricts communications protected by the timeframe requirement proposed in reasonable amount of time. Therefore

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00098 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25739

we have finalized the deadline for the third-party services, could all be agreement is modified for other notice requirement in § 170.403(b)(1) to considered protected communications purposes. be annually, beginning in calendar year to the extent they relate to facilitating 4. Application Programming Interfaces 2020. the exchange of health information. Comments. Several commenters Thus, we reiterate that where a contract The API Condition of Certification requested clarification that once the entered into by the developer would requirement in Section 4002 of the final rule goes into effect, contravening restrict a communication protected by Cures Act requires health IT developers provisions in developer contracts the Communications Condition of to publish APIs that allow ‘‘health prohibiting communications cannot be Certification requirements, the information from such technology to be enforced. One of these commenters developer may not enforce such a accessed, exchanged, and used without stated that developers would often contract and may not restrict a protected special effort through the use of APIs or include language in their contracts communication in violation of the successor technology or standards, as prohibiting communication on the part Communications Condition of provided for under applicable law.’’ The of end users and entities, thus Certification requirements after the requirement also states that a developer preventing communication about issues effective date of the final rule without must, through an API, ‘‘provide access with EHRs. Several commenters risking loss of certification. It is also to all data elements of a patient’s requested that ONC explicitly state that important to note that not all electronic health record to the extent any permitted communication made contractual provisions related to permissible under applicable privacy following the effective date of the final communications would create a risk of laws.’’ Additionally, the API Condition rule be inadmissible as a violation of a de-certification. As noted above, the of Certification requirement of the Cures contract/agreement regardless of Communications Condition of Act includes several key phrases and whether the customer has been notified. Certification requirements in requirements for health IT developers One commenter requested that ONC § 170.403(a)(2)(ii) do allow for that go beyond the technical clarify that, with respect to protecting developers to place restrictions on functionality of the Health IT Modules communications regarding developer certain communications as discussed they present for certification. In this business practices, where the disclosure above. Therefore, contractual provisions section of the preamble, we outline the of certain information is prohibited by that appropriately address those proposals we have adopted to contract, the developer would not be allowances would not create a risk of implement the API Condition of liable for its inability to communicate de-certification under the Program. Certification requirement of the Cures Act to provide compliance clarity for such information. Comments. One commenter suggested Response. We emphasize that as of health IT developers. that ‘‘renew’’ should be added to the the effective date of the final rule, We have adopted new standards, new maintenance requirement to not contravening provisions in contracts or implementation specifications, a new establish or enforce any contract or agreements cannot be enforced without certification criterion, Condition and agreement that contravenes the the risk of losing certification for the Maintenance of Certification Communications Condition of developer’s health IT or a certification requirements, and modified the Base Certification requirements in ban for the developer under the EHR definition. Health IT developers Program, regardless of whether the § 170.403(a). should consider these final customer was notified as required by the Response. We appreciate this requirements in the context of Communications Condition of comment and amended the proposed information blocking provisions Certification requirements. We clarify regulatory text in § 170.403(b)(2)(i) to described in section VIII of this that provisions of contracts requiring include ‘‘renew.’’ We clarify that where preamble. that the health IT customer ‘‘flow- a contract auto-renews, the developer a. Statutory Interpretation and API down’’ obligations onto the customer’s would still be prohibited under the Policy Principles employees, contractors, and other users Program from enforcing any agreement of the health IT that would restrict or contract provisions that contravene Section 4002 of the Cures Act requires protected communications would be in the Communications Condition of health IT developers certified to the contravention of this Condition of Certification requirements without Program to publish APIs that allow Certification. Such provisions could not risking loss of certification and would ‘‘health information from such be enforced after the effective date of the also be responsible for sending an technology to be accessed, exchanged, final rule without risking loss of annual notice as described above until and used without special effort through certification as noted above for the such provisions have been modified. the use of APIs or successor technology developer under the Program. Comments. A couple of commenters or standards, as provided for under We appreciate commenters’ concern expressed concern about developer applicable law.’’ To implement the regarding disclosing information that efforts to re-negotiate other terms of a Cures Act API requirements, we may be otherwise prohibited by contract that are unrelated to protected proposed a new 2015 Edition Cures contract. However, we clarify that the communications as part of the contract Update ‘‘API’’ certification criterion at purpose of the Communications modification process. 84 FR 7476 that included requirements Condition of Certification requirements Response. We stress that the contract for an API to have ‘‘read’’ capabilities is to prevent developers from modifications required as part of the that support two types of services: (1) improperly restricting protected Communications Condition of Services for which a single patient’s communications, including Certification requirements are strictly data is the focus; and (2) services for communications about a developer’s limited to removing any provisions of which multiple patients’ data are the practices and policies related to the relevant contract/agreement that focus. facilitating the exchange of health would restrict protected We conveyed in the Proposed Rule information. As discussed earlier in this communications in contravention of the our belief that ‘‘without special effort’’ section, costs, timeframes, licensing Communications Condition of requires APIs and the health care practices and terms, as well as the Certification requirements and are not ecosystem in which they are deployed developer’s approach to working with required to be done until the contract/ to be standardized, transparent, and pro-

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00099 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25740 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

competitive. Therefore, we noted that § 170.215(a)(1) and finalized its use in consistently approach how we reference any Health IT Module certified to the § 170.315(g)(10). the United States Core Data for new 2015 Edition Cures Update API Interoperability (USCDI) with various ii. United States Core Data for criterion and a health IT developer’s content standards (e.g., C–CDA), we Interoperability business practices would have to have determined that having an these attributes. We proposed in § 170.215(a)(2) at 84 implementation specification to map FR 7479 to adopt the API Resource USCDI to HL7 FHIR could create more b. API Standards and Implementation Collection in Health (ARCH) Version 1 restrictions than we intended. We Specifications implementation specification, which appreciate the concerns raised by ® ® i. Base Standard listed a set of base HL7 FHIR stakeholders, and as we evaluated the resources that Health IT Modules ARCH in context of our other proposals, We proposed in § 170.215(a)(1) at 84 certified to the proposed criterion in ® ® we determined that we could achieve FR 7477 to adopt HL7 FHIR Draft § 170.315(g)(10) would need to support. our desired policy outcome to link the Standard for Trial Use (DSTU) 2 for Comments. Most commenters were USCDI Data Elements to FHIR Resources reference in the criterion proposed in opposed to the adoption of the ARCH in without the ARCH. We refer § 170.315(g)(10). Additionally, we the final rule. Commenters argued for commenters to the sections that follow requested comment in 84 FR 7478 and the use of American National Standards for further clarity regarding the 7479 on four options to determine the Institute accredited standards, and implementation of Data Elements best version of HL7 FHIR to reference suggested ONC work with standards included in the USCDI implementation for use in § 170.315(g)(10): Option 1: developing organizations for standards specification (IV.B.1). FHIR DSTU 2, Option 2: FHIR DSTU 2 development and maintenance. and FHIR Release 3, Option 3: FHIR Several commenters noted that the iii. US Core IG and Bulk IG DSTU 2 and FHIR Release 4, and Option ARCH has not gone through a formal We proposed in 84 FR 7480 in 4: FHIR Release 4 only. We requested balloting process, did not support § 170.215(a)(3) to adopt the Argonaut commenters review the proposed ONC’s proposal to rely upon the Data Query Implementation Guide certification criterion in § 170.315(g)(10) National Technology Transfer and version 1 (Argonaut IG) implementation and the accompanying Condition of Advancement Act’s exception to adopt specification, which specifies Certification requirements attributed to the ARCH in the final rule, and constraints for 13 of the HL7® FHIR® the API certification criteria. Notably, encouraged the use of technical resources proposed in § 170.215(a)(2). we stated in the Proposed Rule at 84 FR standards developed or adopted by Additionally, we proposed in 7479 that if we adopted another FHIR voluntary consensus standards bodies. § 170.215(a)(4) to adopt the Argonaut Release in a final rule as an alternative Several commenters noted that Data Query Implementation Guide to FHIR Release 2 for the proposed API requiring the ARCH in addition to the Server implementation specification. criterion in § 170.315(g)(10), then we other adopted standards could create Comments. Several commenters would also adopt the applicable confusion. Commenters further advocated for the adoption of the FHIR implementation specifications emphasized the importance of US Core Implementation Guide STU 3 associated with the FHIR Release. maintaining ongoing consistency Release 3.0.0 implementation between the ARCH and the other specification instead of the Argonaut Comments. We received adopted standards, and noted this Implementation Guides. Commenters overwhelming support for Option 4: would be challenging to achieve. noted that the US Core Implementation Adopt solely FHIR Release 4 in the final Additional comments against the Guide was built from the Argonaut rule for reference in § 170.315(g)(10). ARCH expressed concern with the Implementation Guides and has been We received support for the adoption of proposed updates through the Standards balloted by the standards community. FHIR Release 4 across a broad array of Version Advancement Process, and with Response. We thank commenters for stakeholders, including health IT ONC over-regulating API functionality. their feedback. We note that in the developers, medical trade associations, Commenters also noted that ONC could Proposed Rule at 84 FR 7479 we stated software application developers, and encourage API access to specific data that if we were to adopt another FHIR payers. Commenters noted that FHIR elements without creating a new Release in the final rule as an alternative Release 4 is the first FHIR release with implementation specification. to FHIR Release 2, then we would also normative FHIR resources and support Some commenters in favor of the adopt the applicable implementation for enhanced capabilities. Most ARCH implementation specification specifications and FHIR profiles commenters emphasized that Option 4 asked for data element revisions. associated with the FHIR Release. will allow the industry to unify and Commenters also asked for clarity that Considering this and commenters’ focus on a single baseline standard, EHRs will not need to provide the full recommendations, we have adopted the rather than accommodating multiple set of data to modular applications, and HL7 FHIR US Core Implementation releases proposed in Options 2 and 3. A asked for specificity on how much of Guide STU 3.1.0 (US Core IG) minority of commenters suggested this data would need to be mapped by implementation specification in alternative or multiple versions, noting the API Technology Supplier. § 170.215(a)(2). We note that we this would allow for flexibility, but the Additionally, commenters asked for adopted the latest version of the US vast majority of commenters supported guidance on lab results, including Core IG at the time of the final rule the adoption of FHIR Release 4 only. application creation implementation publication. The US Core IG defines the Response. We appreciate the feedback guides that would ensure accuracy and minimum conformance requirements for and agree with commenters that compliance when incorporating lab accessing patient data using FHIR adoption of a single standard is the best data. Release 4 (adopted in § 170.215(a)(1)), option to align industry and enable Response. In response to commenters, including profiled resources, operations, widespread interoperability. We have we did not adopt the ARCH as an and search parameters for the Data adopted the latest version of the implementation specification in the Elements required in the USCDI standard at the time of this final rule final rule. Upon consideration of public implementation specification (adopted publication (FHIR Release 4.0.1) in comments and in an effort to in § 170.213).

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00100 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25741

We note that in the Proposed Rule at iv. HL7 SMART IG and Backend in scope for Program testing and 84 FR 7479 we proposed to require that Services Authorization certification. Additionally, we clarify the ‘‘Patient.address’’ and We proposed in 84 FR 7481 in that by requiring the ‘‘permission- ‘‘Patient.telecom’’ elements of the § 170.215(a)(5) to adopt the HL7® patient’’ ‘‘SMART on FHIR Core ‘‘Patient’’ resource must be supported. SMART Application Launch Framework Capability’’ in § 170.215(a)(3), Health IT We note these requirements have since Implementation Guide Release 1.0.0 Modules presented for testing and been subsumed by the US Core IG, given implementation specification, a profile certification must include the ability for that ‘‘Patient.address’’ and of the OAuth 2.0 specification. patients to authorize an application to ‘‘Patient.telecom’’ elements are both Comments. Most commenters receive their EHI based on FHIR flagged ‘‘must support’’ for the ‘‘Patient’’ expressed support for the HL7 SMART resource-level scopes. Specifically, this profile in the US Core IG. We also Application Launch Framework means patients would need to have the proposed to require that the Implementation Guide Release 1.0.0 ability to authorize access to their EHI ‘‘Device.udi’’ element follow the human (SMART IG) implementation at the individual FHIR resource level, readable representation of the unique specification. Multiple commenters from one specific FHIR resource (e.g., device identifier found in the suggested that in addition to requiring ‘‘Immunization’’) up to all FHIR resources necessary to implement the recommendation, guidance, and support for ‘‘refresh tokens,’’ standard adopted in § 170.213 and conformance requirements section of ‘‘Standalone Launch,’’ and ‘‘EHR implementation specification adopted the ‘‘HL7 Version 3 Cross Paradigm Launch’’ capabilities from the SMART IG, ONC also require support for ‘‘sso- in § 170.215(a)(2). This capability will Implementation Guide: Medical Devices give patients increased control over how openid-connect,’’ ‘‘launch-standalone,’’ and Unique Device Identification much EHI they authorize applications of ‘‘launch-ehr,’’ ‘‘client-public,’’ ‘‘client- Pattern, Release 1.’’ These requirements their choice to receive. For example, if confidentialsymmetric,’’ ‘‘context-ehr- have also been subsumed by the US a patient downloaded a medication patient,’’ ‘‘context-standalone-patient,’’ Core IG. Additional information can be management application, they would be ‘‘permission-patient,’’ ‘‘permission- found in the ‘‘Device’’ profile of the US able to use these authorization scopes to user,’’ and ‘‘permission-offline’’ Core IG adopted in § 170.215(a)(2). limit the EHI accessible by the capabilities. application to only information We note that in the Proposed Rule we Response. We thank stakeholders for contained in FHIR ‘‘MedicationRequest’’ proposed in 84 FR 7480 that the clinical their comments. The ten optional note text included in the and ‘‘Medication’’ profile. capabilities commenters suggested are Comments. Some commenters noted ‘‘DocumentReference’’ resource would included in the ‘‘SMART on FHIR Core need to be represented in its ‘‘raw’’ text concerns for privacy and security of Capabilities’’ section of the SMART IG. APIs. Specifically, one commenter form, and further proposed in 84 FR The ‘‘SMART on FHIR Core 7480 that it would be unacceptable for explained the threat of cross-site request Capabilities’’ suggested by commenters forgery (CSRF), and suggested we take the note text to be converted to another include ‘‘sso-openid-connect,’’ which file or format (e.g., .docx, PDF) when it action to mitigate that risk, including by allows for support of the OpenID requiring the use of both OAuth 2.0 and is provided as part of an API response. Connect profile in the SMART IG; We clarify that the clinical note text OpenID Connect Core 1.0. ‘‘client-public’’ and ‘‘client-confidential- Response. We appreciate the concerns included in any of the notes described symmetric,’’ which allow for client expressed by commenters regarding the in the ‘‘Clinical Notes Guidance’’ authentication; ‘‘context-ehr-patient’’ privacy and security of APIs. The section of the US Core IG adopted in and ‘‘context-standalone-patient,’’ OAuth 2.0 standard defined at Request § 170.215(a)(2) must be represented in a which provide context to apps at launch For Comment (RFC) 6749 101 describes ‘‘plain text’’ form, and would be time; and ‘‘permission-patient,’’ that ‘‘[The OAuth 2.0 authorization] unacceptable for the note text to be ‘‘permission-user,’’ and ‘‘permission- framework was designed with the clear converted to another file or format (e.g., offline,’’ which allow support for expectation that future work will define .docx, PDF) when it is provided as part patient-level scopes, user-level scopes, prescriptive profiles and extensions of an API response. and refresh tokens, respectively. Other necessary to achieve full web-scale We note that in the Proposed Rule we ‘‘SMART on FHIR Core Capabilities’’ interoperability.’’ The SMART IG serves proposed in 84 FR 7480 to require that that were not suggested by commenters as a ‘‘prescriptive profile’’ as described the ‘‘Provenance.recorded’’ and include ‘‘context-banner’’ and ‘‘context- in RFC 6749. Thus, consistent with ‘‘Provenance.agent.actor’’ elements of style,’’ which provide basic context to commenters’ recommendations, we the ‘‘Provenance’’ resource must be apps at launch time, and ’’context-ehr- have adopted a profile of the OAuth 2.0 supported. We note these requirements encounter’’ and ‘‘context-standalone- standard (SMART IG) in § 170.215(a)(3). have been subsumed by the US Core IG, encounter,’’ which provide encounter- Additionally, we have adopted OpenID given that ‘‘Provenance.recorded’’ and level granularity to apps at launch time. Connect Core 1.0 incorporating errata Given the importance of these ‘‘SMART ‘‘Provenance.agent.who’’ elements are set 1 in § 170.215(b), and require on FHIR Core Capabilities,’’ and in both flagged ‘‘must support’’ for the conformance with the relevant parts of consideration of public comments and ‘‘Provenance’’ profile in the US Core IG. this standard as part of testing and our own research, we have adopted the certification. CSRF is a well- As addressed under the header SMART IG, including mandatory documented security threat in OAuth ‘‘Standardized API for Patient and support for the ‘‘SMART on FHIR Core 2.0, which can be prevented with Population Services’’ in the section Capabilities’’ in § 170.215(a)(3). We adequate security practices. We V.B.4.c, we have finalized the adoption explicitly require mandatory support of encourage implementers to adhere to of the HL7 FHIR Bulk Data Access (Flat the ‘‘SMART on FHIR Core industry best practices to mitigate CSRF FHIR) (v1.0.0: STU 1) implementation Capabilities’’ in § 170.215(a)(3) because and other known security threats. specification (Bulk IG), including these capabilities are indicated as Relatedly, we note that the HL7 mandatory support for the ‘‘group- optional in the implementation community has developed an export’’ ‘‘OperationDefinition’’ in specification. We further clarify these § 170.215(a)(4). ‘‘SMART on FHIR Core Capabilities’’ are 101 https://tools.ietf.org/html/rfc6749.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00101 Fmt 4701 Sfmt 4700 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 Response. We appreciate the support envisioned for API-enabled ‘‘read’’ guide of security best practices for from commenters. As a result, we have services for multiple patients. The implementing FHIR-based APIs. We adopted a new certification criterion in ‘‘group-export’’ ‘‘OperationDefinition’’ encourage stakeholders to consult this § 170.315(g)(10), to replace will allow application developers guide during development and § 170.315(g)(8) and made several interacting with § 170.315(g)(10)- implementation of § 170.315(g)(10)- revisions to address public comment as certified Health IT Modules to export certified Health IT Modules to minimize discussed further below. Although the the complete set of FHIR resources as security risks. certification criteria finalized at constrained by the US Core IG adopted For backend services authorization, as § 170.315(g)(10) will replace in § 170.215(a)(2) and USCDI adopted in addressed under the header § 170.315(g)(8), we note that § 170.213 for a pre-defined cohort of ‘‘Standardized API for Patient and § 170.315(g)(8) is not removed from patients. We appreciate commenters’ Population Services’’ in the section regulation. We maintain § 170.315(g)(8) recommendations, and agree that V.B.4.c, we have finalized the adoption and have finalized in § 170.550(m) that coalescing around a common of the HL7 FHIR Bulk Data Access (Flat ONC–ACBs can issue certificates for implementation specification will FHIR) (v1.0.0: STU 1) implementation § 170.315(g)(8) during the transition advance interoperability of API-enabled specification (Bulk IG), which includes period to § 170.315(g)(10) for 24 months ‘‘read’’ services for multiple patients. the ‘‘Backend Services Authorization after the publication date of the final We provide further discussion of the Guide’’ in § 170.215(a)(4). rule. supported search operations, data Comments. Commenters suggested response, and authentication and v. OpenID Connect dividing the § 170.315(g)(10) criterion authorization requirements for API- We proposed in 84 FR 7480 through into two separate criteria for single and enabled ‘‘read’’ services for multiple 7481 in § 170.215(b) to adopt OpenID multiple patients. patients in the sections below. Connect Core 1.0 including errata set 1. Response. We appreciate the Comments. Commenters requested Comments. We received few feedback. We decline to split the clarification that API-enabled ‘‘read’’ comments regarding the adoption of certification criterion into two criteria. services for multiple patients are not OpenID Connect Core 1.0 including In consideration of comments and for intended for patient end users and that errata set 1, however, commenters clarity, we have improved the health IT developers and health care generally supported the adoption of this organization of the final certification providers are therefore not expected to standard. requirements for API-enabled ‘‘read’’ supply a patient-facing mechanism for Response. We thank commenters for services for single and multiple patients these requests. their feedback. Given their support, we by separating the criterion into distinct Response. We appreciate the feedback have finalized the adoption of OpenID sections in the regulation text. from commenters. API-enabled ‘‘read’’ Connect Core 1.0 including errata set 1 Comments. Several commenters services for multiple patients are not as proposed in § 170.215(b). We clarify supported referencing a standard for intended for patient end users because that only the relevant parts of the API-enabled ‘‘read’’ services for API-enabled ‘‘read’’ services for OpenID Connect Core 1.0 including multiple patients, including the HL7® multiple patients allow for the errata set 1 adopted in § 170.215(b) that FHIR® Bulk Data Access disclosure of multiple patients’ records, are also included in the implementation Implementation Guide Release 1.0.0. and individual patients only have the specification adopted in § 170.215(a)(3) Commenters felt that omitting a right to access their own records or will be in-scope for testing and standard in the criterion would records of patients to whom they are the certification. undermine interoperability for API- personal representative (45 CFR enabled ‘‘read’’ services for multiple 164.502(f)(1)). Health IT Modules are c. Standardized API for Patient and patients. not required to support patient-facing Population Services Response. We thank commenters for API-enabled ‘‘read’’ services for We proposed in 84 FR 7481 to adopt their feedback. To enable consistent multiple patients for the purposes of a new certification criterion, health IT implementation of API- this certification criterion. § 170.315(g)(10), to replace enabled ‘‘read’’ services for multiple Comments. One commenter suggested § 170.315(g)(8), and we proposed in 84 patients, we have finalized the adoption we modify the language that defines the FR 7495 to update the 2015 Edition Base of the Bulk IG, including mandatory purpose of this section to provide more EHR definition, as referenced in support for the ‘‘group-export’’ clarity, specifically the term ‘‘services.’’ § 170.102. The proposed certification ‘‘OperationDefinition’’ in The commenter also requested we criterion would require Health IT § 170.215(a)(4). As part of the Program, include the scope of cohorts we Modules to support API-enabled ‘‘read’’ we require Health IT Modules presented intended to address in ‘‘population services for single and multiple patients. for testing and certification to conform services.’’ ‘‘Read’’ services include those that to the Bulk IG implementation Response. We appreciate the feedback allow authenticated and authorized specification finalized in from commenters. The term ‘‘services’’ third-party applications to view EHI § 170.215(a)(4). The adoption of an includes all § 170.315(g)(10)-related through a secure API. These services implementation specification for API- technical capabilities included in a specifically exclude ‘‘write’’ enabled ‘‘read’’ services for multiple Health IT Module presented for testing capabilities, where authenticated and patients in § 170.215(a)(4) is responsive and certification. The API-enabled authorized third-party applications to stakeholder concerns and further ‘‘read’’ services for single patients is would be able to create or modify EHI supports our intent to prevent ‘‘special intended to support EHI requests and through a secure API. effort’’ for the use of APIs as mandated responses for individual patient records Comments. Commenters supported in section 4002 of the Cures Act. and the API-enabled ‘‘read’’ services for the proposed adoption of a new Furthermore, based on our analysis, we multiple patients is intended to support certification criterion, § 170.315(g)(10), believe the ‘‘group-export’’ EHI requests and responses for multiple to replace § 170.315(g)(8). ‘‘OperationDefinition,’’ as defined in the patients’ records. The scope of patient Bulk IG implementation specification is cohorts for ‘‘population services’’ can 102 https://www.hl7.org/FHIR/safety.html. essential to fulfill the use cases include various groups defined at the

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00102 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25743

discretion of the user of the API-enabled implementation specifications, whereas ‘‘PUT,’’ and FHIR messaging, we have ‘‘read’’ services for multiple patients, the criterion finalized in not adopted such requirements for the including, for example, a group of § 170.315(g)(10) requires conformance to Program. We encourage industry patients that meet certain disease several standards and implementation stakeholders to further consider all the criteria or fall under a certain insurance specifications, as described further requirements and implications for the plan. We have adopted the Bulk IG in below. We refer to the finalized ‘‘EHI ‘‘push’’ operations of the FHIR standard, § 170.215(a)(4) to support this function export’’ criterion in § 170.315(b)(10) for develop use cases, perform additional as discussed further below. The additional information. API-enabled ‘‘push’’ pilot technical capabilities expected of API- Comments. Several commenters implementations, create or expand related Health IT Modules presented for supported requiring Health IT Modules implementation profiles to support testing and certification are included in to support API-enabled ‘‘write’’ services ‘‘push’’ services, and demonstrate the § 170.315(g)(10). for single patients, either in this rule or utility of the ‘‘push’’ operations of the Comments. Commenters requested in a future rulemaking. One commenter FHIR standard for future potential clarification for information blocking suggested including a subset of data inclusion in the Program. policies and health care provider classes for ‘‘write’’ services for single obligations for API-enabled ‘‘read’’ patients, including ‘‘patient goals,’’ i. Data Response services for multiple patients. ‘‘patient-generated health data’’ We proposed in 84 FR 7482 in Response. We appreciate the request (including patient-reported outcomes, § 170.315(g)(10)(i) that Health IT for clarification from commenters. We patient generated device data, and Modules presented for testing and clarify that the criteria finalized in questionnaires), and ‘‘care plans.’’ certification must be capable of § 170.315(g)(10) includes the technical Another commenter suggested adding a responding to requests for data on single capabilities that must be met by API- list of required operations (‘‘read’’ and and multiple patients in accordance related Health IT Modules presented for ‘‘write’’) to USCDI elements, limited to with proposed standards and testing and certification. The ‘‘read’’ for this rulemaking. implementation specifications adopted information blocking policies in this Response. We appreciate the feedback in § 170.215(a)(1) (HL7® FHIR® DSTU 2 rule do not compel health care from commenters. While we support the (v1.0.2–7202)), specified in the providers to implement Health IT interest in API-enabled ‘‘write’’ services, proposed § 170.215(a)(2) (API Resource Modules certified to requirements in we have not adopted such requirements. Collection in Health (ARCH) Version 1), 170.315(g)(10). We note that other We do not believe API-enabled ‘‘write’’ and consistent with the proposed programs, like CMS value-based services have reached a level of a specifications in § 170.215(a)(3) programs, may require the use of this maturity to warrant the addition of (Argonaut Data Query Implementation technology. We refer commenters to the regulatory conformance requirements Guide Version 1.0.0). We clarified that information blocking section (VIII) for within the Program. We encourage all data elements indicated as additional clarification. industry to consider all the implications ‘‘mandatory’’ and ‘‘must support’’ by the Comments. Commenters asked us to and implementation requirements for proposed standards and implementation clarify the relationship between the API- API-enabled ‘‘write’’ services, and specifications must be supported and enabled ‘‘read’’ services for single and perform additional API-enabled ‘‘write’’ would be in scope for testing. multiple patients in § 170.315(g)(10) and pilot implementations to demonstrate Comments. Commenters expressed the ‘‘EHI export’’ criterion in the readiness for API-enabled ‘‘write’’ concern with fully enforcing § 170.315(b)(10). services in the testing and certification ‘‘mandatory’’ and ‘‘must’’ support Response. We thank commenters for of Health IT Modules. Additionally, we requirements of the referenced this request. The API criterion in encourage industry to expand existing specifications and implementation § 170.315(g)(10) is separate from the profiles like the US Core IG to support guides, explaining that developers may ‘‘EHI export’’ criterion in ‘‘write’’ services. be required to support requirements that § 170.315(b)(10). While both criteria aim Comments. Commenters are not applicable to the stated intended to advance health IT in alignment with recommended including a requirement use of the Health IT Module(s). the Cures Act’s goal of ‘‘complete for event logging for ‘‘read’’ services for Response. We appreciate the concerns access, exchange, and use of all single and multiple patients. expressed by commenters. We clarify electronically accessible health Response. We appreciate the that the standards and implementation information’’ for both single and recommendation from commenters. The specifications adopted and required for multiple patients, the criteria 2015 Edition Privacy and Security this certification criterion were created specifications and Condition and Certification Framework requires that if by standards developing organizations Maintenance of Certification a Health IT Module includes to support a wide range of health care requirements are distinct. capabilities for certification under use cases. The ‘‘EHI export’’ criterion focuses on § 170.315(g)(10) it needs to be certified We have finalized in a Health IT Module’s ability to to several privacy and security § 170.315(g)(10)(i)(A) that Health IT electronically export EHI, as defined in certification criteria including auditable Modules presented for testing and § 171.102, that can be stored at the time events in § 170.315(d)(2) or auditing certification must be capable of of certification by the product, of which actions on health information in responding to requests for a single the Health IT Module is a part. In § 170.315(d)(10). patient’s data according to the standard contrast, the finalized API criterion in Comments. Commenters noted that adopted in § 170.215(a)(1) and § 170.315(g)(10) focuses on ‘‘read’’ references to APIs focus exclusively on implementation specification adopted services for single and multiple patients RESTful query and ignore ‘‘push’’ in § 170.215(a)(2), including the for the USCDI (adopted in § 170.213) elements of the FHIR API, such as mandatory capabilities described in ‘‘US Data Elements and US Core IG (adopted ‘‘POST,’’ ‘‘PUT,’’ and FHIR messaging. Core Server CapabilityStatement,’’ for in § 170.215(a)(2)) FHIR profiles. Response. We appreciate the feedback each of the Data Elements included in Additionally, the ‘‘EHI export’’ criterion from commenters. While we support the the standard adopted in § 170.213. This finalized in § 170.315(b)(10) does not interest in the ‘‘push’’ operations of the requirement will enable Health IT mandate conformance to standards or FHIR standard, including ‘‘POST,’’ Modules to support US Core IG

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00103 Fmt 4701 Sfmt 4700 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 certification requirement until a API Data Provider’s clinical included in the USCDI. standard is published by HL7. environment. Additionally, we have finalized in Response. We appreciate the feedback Comments. Commenters generally § 170.315(g)(10)(i)(B) that Health IT from commenters. Since we have not supported that Health IT Modules Modules presented for testing and finalized the adoption of the ARCH as presented for testing and certification certification must be capable of proposed in § 170.215(a)(2), and instead must enable apps to register with an responding to requests for data on rely on the search parameters specified authorization server. Some commenters multiple patients as a group according in the US Core IG finalized in supported excluding application to the standard adopted in § 170.215(a)(2) and Bulk IG finalized in registration from the testing and § 170.215(a)(1) and implementation § 170.215(a)(4), the comments related to certification of apps executed within an specifications adopted in § 170.215(a)(2) the specific ‘‘Provenance’’ and API Data Provider’s clinical and § 170.215(a)(4), for each of the Data ‘‘DocumentReference’’ FHIR resources environment. Elements included in the standard are no longer applicable. We have Response. We appreciate the feedback adopted in § 170.213. Finally, we clarify finalized in § 170.315(g)(10)(ii)(A) that from commenters. Given the that the use of the ‘‘SMART Backend Health IT Modules presented for testing overwhelming support, we have Services: Authorization Guide’’ section and certification must support all search finalized in § 170.315(g)(10)(iii) that of the implementation specification capabilities for single patients according Health IT Modules presented for testing adopted in § 170.215(a)(4) is required to the implementation specification and certification must enable apps to for API ‘‘read’’ services for multiple adopted in § 170.215(a)(2), including register with an authorization server. patients as finalized in support for all mandatory capabilities We clarify that Health IT Modules § 170.315(g)(10)(i)(B) and described included in the ‘‘US Core Server presented for testing and certification above. CapabilityStatement.’’ Additionally, we must support application registration regardless of the scope of patient search For requests for data on multiple have finalized in § 170.315(g)(10)(ii)(B) that Health IT Modules presented for utilized by the application (e.g., single patients, we note that the testing and certification must respond to or multiple). This certification criterion implementation specification adopted search requests for multiple patients’ requires a health IT developer, as in § 170.215(a)(4) has optional data consistent with the search criteria finalized in the Condition of parameters which can be used to filter included in the implementation Certification requirements section results to a period of time, or one or specification adopted in § 170.215(a)(4). below, to demonstrate its registration several specified FHIR resources. While We clarify that the scope of data process, but does not require these parameters are not required for available in the data responses defined conformance to a standard. testing and certification, we encourage in § 170.315(g)(10)(i) must be supported Additionally, we expect that apps health IT developers to adopt these for single and multiple patient searches executed within an implementer’s parameters and other via the supported search operations clinical environment will be registered ‘‘OperationDefinitions’’ to enhance the finalized in § 170.315(g)(10)(ii). with an authorization server, but we do utility of requests for data on multiple Additionally, we clarify for the not require a health IT developer to patients. requirements finalized in demonstrate its registration process for ii. Search Support § 170.315(g)(10)(i) and (ii) that all data these ‘‘provider-facing’’ apps. We elements indicated as ‘‘mandatory,’’ reiterate that we believe implementers We proposed in 84 FR 7482 in ‘‘must support,’’ by the standards and of § 170.315(g)(10)-certified Health IT § 170.315(g)(10)(ii) that Health IT implementation specifications must be Modules should have the discretion to Modules presented for testing and supported and are in scope for testing. innovate and execute various methods certification must be capable of for application registration within a responding to all of the ‘‘supported iii. Application Registration clinical environment. searches’’ specified in the proposed We proposed in 84 FR 7483 in Comments. Commenters provided a implementation specification in § 170.315(g)(10)(iii) that Health IT mix of support and opposition for § 170.215(a)(4) (Argonaut Data Query Modules presented for testing and requiring the OAuth 2.0 Dynamic Client Implementation Guide Server). We certification must be capable of enabling Registration Protocol (RFC 7591) reiterated that Health IT Modules apps to register with an ‘‘authorization standard as the sole method of presented for testing and certification server.’’ As proposed, this would have application registration. Some and as implemented must support all required an API Technology Supplier to commenters felt that the Program search capabilities for single and demonstrate its registration process, but should require dynamic client multiple patients in accordance with the would not have required conformance registration in the context of patient- proposed implementation specification to a standard. We requested comment at access scenarios only, and others felt the in § 170.215(a)(4). We also requested 84 FR 7483 on whether to require the standard is not ready for mandated comments on the minimum ‘‘search’’ OAuth 2.0 Dynamic Client Registration adoption in the Program. Commenters parameters that would need to be Protocol (RFC 7591) 103 standard as the opposed to requiring the OAuth 2.0 supported for the ’’DocumentReference’’ sole method to support registration for Dynamic Client Registration Protocol and ‘‘Provenance’’ HL7® FHIR® the proposed certification criterion in (RFC 7591) felt that not specifying a resources. § 170.315(g)(10), and requested standard would allow flexibility for Comments. Most commenters comment on whether we should require different innovative registration supported this proposal. One its support as part of the final rule’s approaches to be used and developed. commenter recommended only certification criterion. Additionally, we Other commenters suggested there requiring the ‘‘target’’ query parameter requested comment at 84 FR 7483 on should be an option for data holders to for the ‘‘Provenance’’ FHIR resource, whether to include application support dynamic client application and ‘‘patient’’ and ‘‘date’’ query registration in the testing and registration if the data holder prefers parameters for the certification of apps executed within an that approach, including support for ‘‘DocumentReference’’ FHIR resource. dynamic application registration via One commenter suggested deferring this 103 https://tools.ietf.org/html/rfc7591. trusted networks.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00104 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25745

Response. We appreciate the feedback criterion is not a form of review or Response. We appreciate the feedback from commenters. We have not adopted ‘‘vetting’’ for purposes of this criterion. from commenters. The SMART IG a requirement for Health IT Modules Comments. Commenters requested ‘‘Standalone Launch’’ and ‘‘EHR presented for testing and certification to clarity on whether the ‘‘EHR Launch’’ Launch’’ modes can be used by both support the OAuth 2.0 Dynamic Client scenario was out of scope for testing provider- and patient-facing Registration Protocol (RFC 7591) during registration with an applications. We refer to the adopted standard. We agree with commenters authorization server. implementation specification in and believe that requiring registration Response. Commenters referred to the § 170.215(a)(3) for clarification of without a mandated standard will allow ‘‘EHR Launch’’ scenario, which is the certification requirements for the registration models to develop further. ‘‘launch-ehr’’ ‘‘SMART on FHIR Core SMART IG. We have finalized in We encourage health IT developers to Capability’’ included in the § 170.315(g)(10)(iv)(A) that Health IT coalesce around the development and implementation specification adopted Modules presented for testing and implementation of a common standard in § 170.215(a)(3). Health IT Modules certification must demonstrate the for application registration with an presented for testing and certification ability to establish a secure and trusted API’s authorization server. must enable all apps that utilize the connection with an application Comments. Commenters suggested SMART IG ‘‘launch-standalone’’ requesting data for a single patient in permitting implementers of ‘‘SMART on FHIR Core Capability’’ to accordance with the implementation § 170.315(g)(10)-certified Health IT register with an authorization server. specifications adopted in § 170.215(a)(2) Modules to undertake a review of third- We reiterate that the application and (a)(3). We amended this text from party applications prior to permitting registration requirement finalized in the Proposed Rule by adding the US them to connect to the implementers’ § 170.315(g)(10)(iii) does not require Core IG implementation specification deployed APIs. conformance to a standard or adopted in § 170.215(a)(2) because the Response. We appreciate the implementation specification. We US Core IG specifically requires suggestion from commenters. The envision that apps using only the Transport Layer Security 1.2 (RFC 5246) 104 requirement that health IT developers SMART IG ‘‘launch-ehr’’ ‘‘SMART on or higher for all transmissions must enable an application to register FHIR Core Capability’’ will be tightly not taking place over a secure network connection. Pursuant to this adopted with the § 170.315(g)(10)-certified integrated with § 170.315(g)(10)- implementation specification, we will Health IT Module’s authorization server certified Health IT Modules deployed by test Health IT Modules for support for only applies for the purposes of implementers, and will be able to all ‘‘SMART on FHIR Core Capabilities’’ demonstrating technical conformance to accommodate registration processes that including both ‘‘launch-ehr’’ and the finalized certification criterion and best suit the needs of those ‘‘launch-standalone.’’ implementers. Additionally, while we Condition and Maintenance of Additionally, we have finalized in do not require conformance to a Certification requirements. The § 170.315(g)(10)(iv)(B) that Health IT practices by all parties (including standard or implementation Modules presented for testing and implementers of Health IT Modules) specification for application certification must demonstrate the other than developers of certified Health registration, we clarify that Health IT ability to establish a secure and trusted IT Modules are not in scope for this Modules presented for testing and connection with an application certification criterion nor the associated certification are required to support requesting data for multiple patients in Condition and Maintenance of application registration functions to accordance with the implementation Certification requirements. All other enable authentication and authorization specification adopted in § 170.215(a)(4). practices associated with third-party as finalized in § 170.315(g)(10)(v). The implementation specification application review or ‘‘vetting’’ by iv. Secure Connection adopted in § 170.215(a)(4) has several implementers must not violate the sections, but for testing and certification information blocking provision We proposed in 84 FR 7483 in to this criterion, we specifically require described in section VIII of this § 170.315(g)(10)(iv) that Health IT conformance to, but not limited to, the preamble and applicable laws and Modules presented for testing and ‘‘SMART Backend Services: regulations. In general, an implementer certification must be capable of Authorization Guide.’’ of § 170.315(g)(10)-certified Health IT establishing a secure and trusted Modules (e.g., health care providers) connection with an application v. Authentication and Authorization would be allowed to review third-party requesting patient data in accordance We proposed in 84 FR 7483 in applications the implementer intends to with the proposed § 170.215(a)(5) (HL7 § 170.315(g)(10)(v) that Health IT use for its own business use (e.g., a SMART Application Launch Framework Modules presented for testing and third-party decision-support application Implementation Guide Release 1.0.0), certification must demonstrate the used by the health care provider in the including mandatory support for ability to perform user authentication, course of furnishing care) prior to ‘‘Standalone Launch’’ and ‘‘EHR user authorization, and issue a refresh permitting the third-party applications Launch’’ modes. token valid for a period of at least 3 to connect to the implementer’s Comments. Commenters asked for months during its initial connection deployed APIs within its enterprise and clarification around where ‘‘Standalone with an application to access data for a clinical users’ workflow. However, Launch’’ and ‘‘EHR Launch’’ single patient in accordance with the implementers of § 170.315(g)(10)- capabilities are required, suggesting that proposed standard in § 170.215(b) certified Health IT Modules (e.g., health ‘‘Standalone Launch’’ support be used (OpenID Connect Core 1.0 incorporating care providers) are not permitted to exclusively for patient access and ‘‘EHR errata set 1) and the proposed review or ‘‘vet’’ third-party applications Launch’’ support be used exclusively for implementation specification in intended for patient access and use (see provider/clinician access. They also § 170.215(a)(5) (HL7® SMART section VII.C.6 of this preamble). We noted that testing and certification of Application Launch Framework clarify that the third-party application ‘‘Standalone Launch’’ would not be a Implementation Guide Release 1.0.0). registration process that a health IT valid use case and should be excluded developer must meet under this from the certification criterion. 104 https://tools.ietf.org/html/rfc5246.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00105 Fmt 4701 Sfmt 4700 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)(v)(A)(1)(ii) that an Additionally, we clarify that Health IT § 170.315(g)(10)(vi) that Health IT application capable of storing a client Modules will be explicitly tested for US Modules presented for testing and secret must be issued a refresh token Core IG operations using authentication certification must demonstrate the valid for a period of no less than three and authorization tokens acquired via ability of an application to access data months. Additionally, we have finalized the process described in the for a single patient and multiple authentication and authorization implementation specification adopted patients during subsequent connections requirements for subsequent in § 170.215(a)(3), and Health IT of applications capable of storing a connections for patient and user scopes Modules will be explicitly tested for client secret, in accordance with the in § 170.315(g)(10)(v)(A)(2). This Bulk IG operations using authentication proposed implementation specification includes the requirements finalized in and authorization tokens acquired via in § 170.215(a)(5) (HL7 SMART § 170.315(g)(10)(v)(A)(2)(i) that Health the process described in the Application Launch Framework IT Modules presented for testing and implementation specification adopted Implementation Guide Release 1.0.0), certification must demonstrate that in § 170.215(a)(4). without requiring the user to re- access is granted to patient data in Comments. One commenter authorize and re-authenticate when a accordance with the implementation recommended that ONC introduce a valid refresh token is supplied. specification adopted in § 170.215(a)(3) Condition of Certification requirement Additionally, we proposed in 84 FR without requiring re-authorization and to ensure that implementers of 7483 that Health IT Modules presented re-authentication when a valid refresh § 170.315(g)(10)-certified Health IT for testing and certification must token is supplied by the application. It Modules can obtain automated system- demonstrate it can issue a new refresh also includes the requirements finalized level access to all API calls from the API token to an application, valid for a in § 170.315(g)(10)(v)(A)(2)(ii) that an servers offered by the Certified Health period of at least 3 months. application capable of storing a client IT Developers (e.g., via the SMART Comments. A majority of commenters secret must be issued a new refresh Backend Services authorization guide), supported that Health IT Modules token valid for a new period of no less with ‘‘system/*.*’’ scopes. presented for testing and certification than three months. Response. We decline to accept the recommendation to require ‘‘system/ must demonstrate the ability to perform Additionally, we have finalized *.*’’ scopes as a certification user authentication, user authorization, requirements for authentication and requirement in § 170.315(g)(10). Insofar and issue a refresh token valid for a authorization for system scopes in as the commenter requested that Health period of at least 3 months. Some § 170.315(g)(10)(v)(B), which require commenters noted that the OAuth 2.0 IT Modules make available automated that Health IT Modules presented for implementation guide does not system-level scopes for the purposes of testing and certification must recommend servers provide refresh an ‘‘all information export,’’ we have demonstrate that authentication and tokens to public/non-confidential finalized a similar requirement in authorization occurs during the process applications. § 170.315(b)(10), and refer the Response. We thank commenters for of granting an application access to commenter to that section for additional their feedback. Given the general patient data in accordance with the detail. Additionally, we have finalized support and in response to these ‘‘SMART Backend Services: in § 170.315(g)(10)(v)(B) that Health IT comments, we have consolidated the Authorization Guide’’ section of the Modules must perform authentication proposed requirements in implementation specification adopted and authorization during the process of § 170.315(g)(10)(v) and in § 170.215(a)(4) and the application granting an application access to patient § 170.315(g)(10)(vi) as a revised set of must be issued a valid access token. We data using system scopes in accordance requirements finalized in note that for system scopes, applications with the ‘‘SMART Backend Services: § 170.315(g)(10)(v). Specifically, we will likely be authorized via a prior Authorization Guide’’ section of the have finalized requirements for authorization negotiation and agreement implementation specification adopted authentication and authorization for between applications and Health IT in § 170.215(a)(4). We recognize that the patient and user scopes in Modules. capabilities supported by ‘‘SMART § 170.315(g)(10)(v)(A) and requirements For clarity, we use the term ‘‘an Backend Services: Authorization Guide’’ for authentication and authorization for application capable of storing a client could be used for many other use cases system scopes in § 170.315(g)(10)(v)(B). secret’’ to refer to ‘‘confidential clients.’’ that are currently not required by the We have focused the revised In the definition at RFC 6749, criterion. We clarify that implementers requirements around authentication and ‘‘confidential’’ clients are ‘‘clients of Health IT Modules are not prohibited authorization scopes to remove any capable of maintaining the from configuring Health IT Modules to confusion associated with requirements confidentiality of their credentials (e.g., support the backend ‘‘system’’ scope for single and multiple patients. We client implemented on a secure server described in the ‘‘SMART Backend have finalized authentication and with restricted access to the client Services: Authorization Guide’’ section authorization requirements for first time credentials), or capable of secure client of the Bulk IG adopted in § 170.215(a)(4) connections for patient and user scopes authentication using other means.’’ RFC for API-enabled ‘‘read’’ services defined in § 170.315(g)(10)(v)(A)(1). This 6749 also defines ‘‘public’’ clients as in the US Core IG. Indeed, we strongly include the requirement finalized in ‘‘clients incapable of maintaining the encourage health IT developers to § 170.315(g)(10)(v)(A)(1)(i) that Health confidentiality of their credentials (e.g., support these use cases as they develop IT Modules presented for testing and clients executing on the device used by in order to make full use of the certified certification must demonstrate that the resource owner, such as an installed functions of Health IT Modules and authentication and authorization occurs native application or a web browser- advance the state of the industry. during the process of granting access to based application), and incapable of Comments. Commenters suggested patient data in accordance with the secure client authentication via any specifying that refresh tokens apply implementation specification adopted other means.’’ We clarify that the term exclusively to patient access scenarios, in § 170.215(a)(3) and standard adopted ‘‘an application capable of storing a noting that there are too many security in § 170.215(b). It also includes the client secret’’ specifically excludes risks to allow persistent tokens for requirement finalized in ‘‘public’’ clients. provider-facing applications.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00106 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25747

Additionally, commenters suggested refresh tokens for users of the API, and security capabilities are present in permitting Health IT Modules to including patients and providers, to § 170.315(g)(10)-certified Health IT support the revocation of refresh tokens align with their institutional policies. Modules. Regarding the request for in appropriate scenarios to address Further, implementers of certification requirements to ensure that legitimate security concerns. § 170.315(g)(10)-certified Health IT software developers do not act in a way Response. We appreciate the feedback Modules are not prohibited from that could inhibit patient control of from commenters. We do not agree that implementing their § 170.315(g)(10)- their data, we refer to the requirement there are too many security risks to certified Health IT Modules in finalized in § 170.315(g)(10)(A), which allow refresh tokens to be used for accordance with their organizational requires that patients have the ability to provider-facing applications. Refresh security policies and posture, including grant applications authorization to tokens are commonly used in health by instituting policies for re- access their EHI using granular FHIR care and other industries to provide authentication and re-authorization Resources of their choice to comply seamless integration of systems with (e.g., providers and/or patients could with the adopted implementation other applications while reducing the always be required to re-authenticate specification in § 170.215(a)(3), and need for the burdensome process of re- and re-authorize after a set number of requirement in § 170.315(g)(10)(vi), authentication and re-authorization. We refresh tokens have been issued). We which requires that a Health IT expect implementers of § 170.315(g)(10)- also note that we have finalized a Module’s authorization server must be certified Health IT Modules to have the requirement in § 170.315(g)(10)(vi) that able to revoke an authorized capability of revoking refresh tokens a Health IT Module’s authorization application’s access at a patient’s where appropriate. Additionally, we server must be able to revoke an direction. clarify that implementers of authorized application’s access at a Comments. Several commenters § 170.315(g)(10)-certified Health IT patient’s direction. This required suggested that patients be able to specify Modules are not prohibited from capability will enable patients to refresh token length, if desired, and changing the length of refresh tokens for definitively revoke an application’s revoke a third-party application’s access users of the API including patients and authorization to receive their EHI until at any time. Commenters suggested that providers to align with their reauthorized, if ever, by the patient. clear information be provided to institutional policies. However, Comments. Commenters suggested patients whether authorized access is implementers of § 170.315(g)(10)- creating a more robust assessment one-time or ongoing. certified Health IT Modules should be process for identity management, Response. We appreciate the feedback mindful of information blocking including adding additional criteria for from commenters. Refresh tokens are an provisions applicable to them and that identity proofing, authentication, and OAuth 2.0 concept, and are largely requiring patients to re-authenticate and authorization, and ensuring software opaque to the end user. However, we re-authorize at a high frequency could developers do not act in a way that clarify that patients are not prohibited inhibit patient access and implicate could inhibit patient control of their from changing the length of refresh information blocking. data. tokens to the degree this option is Comments. Commenters suggested Response. We appreciate the feedback available to them. Additionally, amending the time from three months to and suggestions. Although we agree that pursuant to these comments, and to 12 months. One commenter agreed that identity proofing is an important ensure patients have the ability to the patient token should be valid for practice, we did not include revoke an application’s access to their three months, but suggested the requirements for identity proofing in the EHI at any time, we have finalized an provider token be limited to 24 hours. Proposed Rule, and have not finalized additional certification requirement in One commenter suggested requiring re- requirements for identity proofing in § 170.315(g)(10)(vi) which requires that authentication every time information is response to this comment. We note that a Health IT Module’s authorization sought via APIs. the certification criterion finalized in server must be able to revoke an Response. We appreciate the feedback § 170.315(g)(10) only applies to health authorized application’s access at a from commenters. We believe a refresh IT developers. Given the scope of the patient’s direction. We have finalized token valid for a period of three months Program, we believe that mandating this as a functional requirement to allow is sufficient to balance persistent access identity proofing, which are generally health IT developers the ability to and security concerns. Moreover, for business practices performed by implement it in a way that best suits subsequent connections of applications organizations and other entities, is not their existing infrastructure and allows capable of storing a client secret, Health something appropriate to require of for innovative models for authorization IT Modules are required to issue a new health IT developers. We note that per revocation to develop. Additionally, per refresh token valid for a new period of the requirements of the 2015 Edition the requirement finalized in no shorter than three months per the Privacy and Security Certification § 170.315(g)(10)(v)(A), Health IT API certification criterion requirement Framework, health IT developers with Modules must perform authorization finalized in § 170.315(g)(10)(v)(A)(2)(ii). Health IT Modules certified to conformant with the implementation Given this requirement, we anticipate § 170.315(g)(7) through (g)(10) are specification adopted in § 170.215(a)(3), that the user’s application will renew its required to certify to § 170.315(d)(1), including all ‘‘SMART on FHIR Core refresh token (valid for a new period of which includes requirements for Capabilities.’’ The ‘‘permission-offline’’ three months) every time the user authentication, access control, and ‘‘SMART on FHIR Core Capability’’ actively engages with the application. authorization. Additionally, includes support for the ‘‘offline_ We believe this justifies a refresh token authentication and authorization for use access’’ scope. Importantly, the length for a moderate period of no of § 170.315(g)(10)-certified Health IT implementation specification adopted shorter than three months rather than a Modules are included in the in § 170.215(a)(3) requires that patients long period of 12 months suggested by requirements finalized in have the ability to explicitly enable the commenters. Additionally, as stated § 170.315(g)(10)(v). We appreciate the ‘‘offline_access’’ scope during above, implementers of § 170.315(g)(10)- sentiment expressed by commenters, authorization. If the ‘‘offline_access’’ certified Health IT Modules are not and have created thorough and rigorous scope is not enabled by patients, prohibited from changing the length of requirements to ensure adequate privacy patients will be required to re-

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00107 Fmt 4701 Sfmt 4700 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 and password) they created and use to substantive changes to the requirements application’s access to their EHI after access their EHI through a patient portal proposed in § 170.315(g)(10)(vii). We the application’s access token expires. as they do when authorizing an have finalized these requirements Comments. Commenters suggested application to access their data. Since § 170.315(g)(10)(viii). We recognize that providing the ability for implementers patients complete the authentication our formal adoption of the HL7 FHIR of § 170.315(g)(10)-certified Health IT process directly with their health care standard and the associated Modules to perform token introspection provider, no application will have implementation specifications using services enabled by health IT access to their credentials. There is little referenced in § 170.315(g)(10) would be developers to ensure that additional protection software can provide to consistent across all Health IT Modules resource servers can work with the same protect against nefarious actors posing presented for certification. As a result, access tokens and authorization policies as legitimate health facilities, however, there may be minimal additional as the resource servers provided by API we believe that implementing the documentation needed for these Technology Suppliers. security controls and safeguards capabilities beyond what is already Response. We appreciate the feedback described above, along with the privacy documented in adopted standards and from commenters. Based on feedback, and security requirements required implementation specifications. We we have finalized in under the 2015 Edition Privacy and expect health IT developers to disclose § 170.315(g)(10)(vii) that Health IT Security Certification Framework, will any additional data their Modules presented for testing and help to protect Health IT Modules § 170.315(g)(10)-certified Health IT certification must demonstrate the against nefarious actors. Additionally, Module supports in the context of the ability to receive and validate a token the protections required for ePHI in adopted standards and implementation issued by its authorization server, but Health IT Modules offered by health IT specifications. The content of technical we did not specify a standard for this developers acting as business associates documentation required to meet this requirement. Token introspection will of health care providers remain certification criteria are described in allow implementers of § 170.315(g)(10)- unchanged. requirements finalized in certified Health IT Modules to use API vi. Technical Documentation § 170.315(g)(10)(viii)(A). We expect authorization servers and authorization these and any additional documentation tokens with various resource servers. We proposed in 84 FR 7484 in relevant to the use of a health IT This functionality has the potential to § 170.315(g)(10)(vii) that an API developer’s § 170.315(g)(10)-certified reduce complexity for implementers of Technology Supplier needed to provide Health IT Module to be made available complete documentation via a publicly § 170.315(g)(10)-certified Health IT via a publicly accessible hyperlink accessible hyperlink, without additional Modules authorizing access to several without preconditions or additional access requirements, for all aspects of its resource servers and reduces the overall steps to meet the requirement as effort and subsequent use of § 170.315(g)(10)-certified API, especially finalized in § 170.315(g)(10)(viii)(B). § 170.315(g)(10)-certified Health IT for any unique technical requirements Modules consistent with the goals of and configurations, including API d. API Condition of Certification section 4002 of the Cures Act to enable syntax, function names, required and Requirements the use of APIs without ‘‘special effort.’’ optional parameters supported and their i. Key Terms Although we do not specify a standard data types, return variables and their for token introspection, we encourage types/structures, exceptions and We proposed in 84 FR 7477 to adopt industry to coalesce around using a exception handling methods and their new definitions for ‘‘API Technology common standard, like OAuth 2.0 returns, the software components and Supplier,’’ ‘‘API Data Provider,’’ and Token Introspection (RFC 7662).105 configurations necessary for an ‘‘API User’’ in § 170.102 to describe the Comments. One commenter expressed application to successfully interact with stakeholders relevant to our proposals. concerns with the privacy and security the API and process its response(s), and Comments. The majority of of APIs, and nefarious actors posing as all applicable technical requirements commenters recommended updating legitimate health facilities. and attributes necessary for an definitions and providing examples for Response. Regarding the privacy and application to be registered with an the key terms, including API User. Most security of APIs, the Standardized API authorization server. Additionally, we commenters recommended dividing for Patient and Population Services proposed in 84 FR 7484 to remove the ‘‘API User’’ into two categories: ‘‘First- certification criterion finalized in ‘‘terms of use’’ documentation Order Users,’’ to include patients, health § 170.315(g)(10) requires Health IT provisions in the API certification care providers, and payers that use Modules presented for testing and criteria adopted in § 170.315(g)(7) apps/services that connect to API certification to implement the through (g)(9) in order to reflect the technology, and ‘‘Third-Party Users,’’ to implementation specification adopted Condition of Certification requirements include third-party software developers, in § 170.215(a)(3), which is based on the and not be duplicative of the terms and and developers of software applications OAuth 2.0 security standard that is conditions transparency Condition of used by API Data Providers. widely used in industry. The Certification requirements proposed in Response. We thank commenters for implementation of OpenID Connect 84 FR 7485. their feedback. We note that in this paired with OAuth 2.0 allows health Comments. Commenters generally section we use the terms proposed in care providers to securely deploy and supported the requirements for this § 170.102 that we finalized in manage APIs consistent with their criterion as proposed. Some § 170.404(c) with added quotation organizational practices. Health care commenters suggested technical marks for emphasis and clarity. We providers retain control over how their documentation should be limited to considered separating the term ‘‘API workforce and patients authenticate descriptions of how the API differs from User’’ into distinct terms for developers when interacting with the API. For the utilized standards and of software applications and other users, example, a patient may be required to implementation specifications, like such as patients and health care use the same credentials (e.g., username HL7® FHIR® and the SMART IG. providers. However, we determined that Response. We appreciate the feedback this distinction was unnecessary from a 105 https://tools.ietf.org/html/rfc7662. from commenters. We did not make regulatory perspective. Narrowing our

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00108 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25749

definitions to distinct subgroups could Certification requirements, we have ii. Scope and Compliance exclude unforeseen stakeholders that finalized these revised definitions in We proposed in 84 FR 7485 that the emerge in a future API ecosystem. The § 170.404(c). In this and other sections Condition and Maintenance of term ‘‘API User’’ was intended to of the rule, we use the original proposed Certification requirements proposed in describe stakeholders that interact with terms in the proposal and comment § 170.404 apply to API Technology the certified API technology either summaries, and the finalized terms in Suppliers with Health IT Modules directly (e.g., to develop third-party our responses. certified to any API-focused certification Comments. Some commenters apps/services) or indirectly (e.g., as a criteria adopted in the proposed suggested ONC allow flexibility for user of a third-party app/service). § 170.315(g)(7) through (11). instances where stakeholders may meet Based on suggestions to revise the Comments. Commenters agreed that the definition of more than one key proposed key terms, we have renamed the proposed applicability for the term, and others recommended the term ‘‘API Data Provider’’ to ‘‘API Condition of Certification requirements restricting stakeholders from meeting Information Source’’ finalized in proposed in § 170.404 should be limited the definition of more than one key § 170.404(c) to make clear which party to health IT developers certified to any term. Commenters expressed concern is the source and responsible for the EHI API-focused criteria adopted in the (as in ‘‘the source of the information is with the complexity of key terms in the Proposed Rule, and confusion with the proposed § 170.315(g)(7) through (11). the health care provider’’), and ‘‘API One commenter requested clarification Technology Supplier’’ to ‘‘Certified API interaction of these terms with other criteria within the rule. whether non-certified internally Developer’’ finalized in § 170.404(c) to Response. We thank commenters for developed laboratory systems would be more clearly refer to health IT expressing their concern about subject to this requirement. developers with Health IT Modules stakeholders being able to serve more Response. We thank stakeholders for certified to any of the API criteria under than one role under the definitions their comments. We have generally the Program. Rather than keeping ‘‘API proposed in § 170.102 that we have finalized the scope and compliance for technology’’ an undefined term, we finalized in § 170.404(c). We do not the Condition and Maintenance of renamed it to ‘‘certified API technology’’ believe it is practical to restrict persons Certification requirements as proposed and finalized a definition in or entities to just one definition. We in § 170.404 with one modification. § 170.404(c). Additionally, we amended anticipate situations where a person or Given that we have not adopted the the definition of ‘‘API User’’ for clarity entity can serve more than one role. For certification criterion proposed for in § 170.404(c) to ‘‘API User means a example, a large health care system adoption in § 170.315(g)(11), the scope person or entity that creates or uses could purchase and deploy ‘‘certified of the Condition and Maintenance of software applications that interact with API technology’’ as an ‘‘API Information Certification requirements apply only to the ‘certified API technology’ developed Source’’ and have ‘‘API Users’’ on staff health IT developers with Health IT by a ‘Certified API Developer’ and that create or use software applications Modules certified to any of the API- deployed by an ‘API Information that interact with the ‘‘certified API focused criteria finalized in Source.’’’ Additionally, we did not technology.’’ Additionally, a health IT § 170.315(g)(7) through (10). The include the non-exhaustive list of developer could serve as a ‘‘Certified Condition and Maintenance of examples of ‘‘API User’’ in the API Developer’’ that creates ‘‘certified Certification requirements finalized in definition finalized in § 170.404(c). API technology’’ for testing and § 170.404 do not apply to health IT Instead, we rely on preamble to provide certification and as an ‘‘API User’’ when developers not seeking certification, nor guidance for examples of ‘‘API Users’’ it creates software applications that do they apply to health IT developers rather than appearing to limit the connect to ‘‘certified API technology.’’ certified to solely non-API-focused regulatory definition to these examples. We clarify that a stakeholder will meet criteria. Additionally, we clarify that the We interpret that ‘‘API Users’’ can a role defined in § 170.404(c) based on Condition and Maintenance of include, but are not limited to, software the context in which they are acting. For Certification requirements only apply to developers, patients, health care example, only health IT developers practices of Certified API Developers providers, and payers. We simplified (when acting in the context of a with respect to the capabilities included the definition of ‘‘API Information ‘‘Certified API Developer’’) are required in § 170.315(g)(7) through (10). In other Source’’ in § 170.404(c) to ‘‘API to comply with these API Condition and words, the Condition and Maintenance Information Source means an Maintenance of Certification of Certification requirements would not organization that deploys ‘certified API requirements. apply to practices of Certified API technology’ created by a ‘Certified API Comments. Commenters expressed Developers with respect to non-certified Developer.’’’ We revised the definition concern that ONC exceeded its capabilities or practices associated with, of ‘‘Certified API Developer’’ in regulatory authority by implicating for example, the immunization § 170.404(c) to ‘‘Certified API Developer physicians in the definition of ‘‘API reporting certification criterion in means a health IT developer that creates Data Providers.’’ § 170.315(f)(1), because that criterion is the ‘certified API technology’ that is Response. We remind commenters not one of the API-focused criteria certified to any of the certification that these definitions were created to finalized in § 170.315(g)(7) through (10). criteria adopted in § 170.315(g)(7) describe relationships between key API However, health IT developers should through (10).’’ We added the definition stakeholders and to help describe the understand that other requirements in of ‘‘certified API technology’’ in Condition and Maintenance of this final rule, especially those related § 170.404(c) as ‘‘certified API Certification requirements. We clarify to information blocking, could still technology means the capabilities of that health care providers are not apply to its business practices Health IT Modules that are certified to covered by the Condition and associated with non-API-focused any of the API-focused certification Maintenance of Certification certification criteria. criteria adopted in § 170.315(g)(7) requirements to which the definitions through (10).’’ For ease of reference and apply in § 170.404(c) unless they are iii. General to clarify that these terms only apply to serving the role of a ‘‘Certified API We proposed in 84 FR 7485 in the Condition and Maintenance of Developer. § 170.404(a)(1) to adopt the Cures Act’s

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00109 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25750 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

API Condition of Certification the scope of ‘‘all data elements’’ include or additional steps. We made small requirement stating that an API the Data Elements of the standard adjustments to § 170.404(a)(2)(i) to Technology Supplier must, through an adopted in § 170.213 and FHIR reflect the changes in API definitions API, ‘‘provide access to all data resources referenced by the finalized in § 170.404(c). elements of a patient’s electronic health implementation specification adopted Given that we did not receive public record to the extent permissible under in § 170.215(a)(2), we note that both the comment on whether we should applicable privacy laws.’’ We then standard and implementation formally include public disclosure subsequently proposed in 84 FR 7485 to specification are included in the requirements for regular updates to interpret ‘‘all data of a patient’s interpretation of ‘‘all data elements of a business and technical documentation electronic health record’’ for the patient’s electronic health record to the in regulatory text, so we have finalized purposes of the scope of this API extent permissible under applicable in 170.404(a)(4)(iii)(B) that a Certified Condition of Certification requirement privacy laws’’ above. We note that this API Developer must provide notice and to include the proposed ARCH standard, specific interpretation does not extend a reasonable opportunity for API its associated implementation beyond the API Condition and Information Sources and API Users to specifications, and the policy expressed Maintenance of Certification update their applications to preserve around the data elements that must be requirements finalized in § 170.404 and compatibility with certified API supported by § 170.315(g)(10)-certified cannot be inferred to reduce the scope technology and to comply with APIs. or applicability of other Cures Act applicable terms and conditions. We Comments. Commenters supported Conditions of Certification or the note that notice could include a public our adoption of the Cures Act’s API information blocking policies, which notice made available on a website, but Condition of Certification requirement. include a larger scope of data. also encourage Certified API Developers For the purposes of the scope of data to contact API Information Source covered under this API Condition of iv. Transparency Conditions customers and registered API Users Certification requirement, most We proposed in 85 FR 7485 and 7486 (application developers) directly prior commenters recommended defining ‘‘all in § 170.404(a)(2)(i) to require API to updating business and technical data elements’’ as the Data Elements Technology Suppliers make available documentation. referenced by the USCDI and the FHIR complete business and technical (A) Terms and Conditions resources in the FHIR US Core documentation via a publicly accessible Implementation Guide STU 3 (US Core hyperlink, including all terms and We proposed in 84 FR 7485 in IG) for FHIR Release 4. We received conditions for use of its API technology. § 170.404(a)(2)(ii)(A) that API comments recommending additional Additionally, we proposed that API Technology Suppliers must publish all data elements to be included that we Technology Suppliers must make clear terms and conditions for its API discuss in our comment summary for to the public the timing information technology, including any restrictions, the ARCH in the ‘‘API Standards, applicable to their disclosures in order limitations, obligations, registration Implementation Specifications, and to prevent discrepancies between an process requirements, or other similar Certification Criterion’’ section of this API Technology Supplier’s public requirements that would be needed to: final rule. documentation and its direct Develop software applications to Response. We appreciate stakeholder communication to customers. interact with the API technology; feedback. The § 170.315(g)(10) Additionally, we requested comment at distribute, deploy, and enable the use of certification criterion requirement and 84 FR 7486 on whether the expectation software applications in production associated standards and for API Technology Suppliers to make environments that use the API implementation specifications will necessary changes to transparency technology; use software applications, enable secure, standards-based API documentation should be finalized in including to access, exchange, and use access to a specific set of information. regulation text, or whether this would EHI by means of the API technology; use We have finalized that a Certified API be standard practice as part of making any EHI obtained by means of the API Developer must publish APIs, and must this documentation available. technology; and register software allow EHI from such technology to be Comments. We received overall applications. Additionally, we proposed accessed, exchanged, and used without support from commenters for the need in § 170.404(a)(2)(ii)(B) that any and all special effort through the use of APIs or to make complete business and fees charged by an API Technology successor technology or standards, as technical documentation available via a Supplier for the use of its API provided for under applicable law, publicly accessible hyperlink. We did technology must be described in including providing access to all data not receive public comment on whether detailed, plain language, including the elements of a patient’s electronic health we should formally include public persons or classes of persons to whom record to the extent permissible under disclosure requirements for regular the fee applies; the circumstances in applicable privacy laws, in updates to business and technical which the fee applies; and the amount § 170.404(a)(1). Additionally, for the documentation in regulatory text. of the fee, which for variable fees must purposes of meeting this portion of the Response. We thank commenters for include the specific variable(s) and Cures Act’s API Condition of their support to make complete business methodology(ies) that will be used to Certification requirement, we clarify the and technical documentation available calculate the fee. data required and that must be via a publicly accessible hyperlink. We Comments. We received support from supported to demonstrate conformance have finalized in § 170.404(a)(2)(i) that a stakeholders regarding the transparency to the final § 170.315(g)(10) certification Certified API Developer must publish of ‘‘all terms and conditions’’ associated criterion (including all of its associated complete business and technical with the use of API technology. standards and implementation documentation, including the Response. We thank commenters for specifications) constitutes ‘‘all data documentation described in their support. We believe this terms and elements of a patient’s electronic health § 170.404(a)(2)(ii), via a publicly conditions transparency requirement record to the extent permissible under accessible hyperlink that allows any would ensure that API Information applicable privacy laws.’’ Regarding the person to directly access the Sources and API Users do not recommendation by commenters that information without any preconditions experience ‘‘special effort’’ in the form

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00110 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25751

of unnecessary costs or delays in shop for certified API technology and permitted to impose fees on any person obtaining the terms and conditions for related services that meet their needs. in connection with an API Technology certified API technology. Furthermore, We have finalized in Supplier’s work to support the use of we believe full transparency is § 170.404(a)(2)(ii)(B) that any and all API technology to facilitate a patient’s necessary to ensure that API Users have fees charged by a Certified API ability to access, exchange, or use their a thorough understanding in advance of Developer for the use of its certified API EHI. We also clarified that while the any terms or conditions that might technology must be described in proposed permitted fees set the apply to them once they have detailed, plain language, including all boundaries for the fees API Technology committed to developing software that material information described in Suppliers would be permitted to charge interacts with certified API technology. § 170.404(a)(2)(ii)(B)(1) through (3). and to whom those permitted fees could We have finalized in Additionally, we made small be charged, the proposed regulations § 170.404(a)(2)(ii)(A) that Certified API adjustments to § 170.404(a)(2)(ii)(B) to did not specify who could pay the API Developers must publish all terms and reflect the changes in API definitions Technology Supplier’s permitted fee. conditions for its certified API finalized in § 170.404(c). Rather, we proposed general conditions technology, including any fees, Comments. Multiple stakeholders that an API Technology Supplier’s restrictions, limitations, obligations, expressed the need to include consumer permitted fees must satisfy in registration process requirements or protections in the terms and conditions § 170.404(a)(3)(i)(B)(1) through (4), and other similar requirements as documentation with an explanation requested comment in 84 FR 7488 on enumerated in § 170.404(a)(2)(ii)(A)(1) about how EHI will be used. these conditions and whether they through (6). We made small adjustments Response. This provision of the sufficiently restrict fees from being used to § 170.404(a)(2)(ii)(A) to reflect the Condition of Certification requirements to prevent access, exchange, and use of changes in API definitions finalized in does not prohibit additional content or EHI through APIs without special effort. § 170.404(c). Additionally, we moved limit the type of content a Certified API We include detailed discussions of ‘‘App developer verification’’ from its Developer may include in its terms and permitted fees and related conditions proposed location in conditions. A Certified API Developer below. § 170.404(a)(2)(ii)(C) and finalized it in would be permitted to include Comments. Some commenters § 170.404(b)(1) to improve organization. consumer protections in their terms and supported the clear prohibition on API We added the phrase ‘‘Used to verify the conditions documentation. fees outside those fees permitted in authenticity of API Users’’ to the Additionally, we clarify these API § 170.404(a)(3)(ii) through (iv), regulation text finalized in Conditions of Certification requirements expressing that the language in the rule § 170.404(a)(2)(ii)(A)(5) for consistency only apply to Certified API Developers. would prevent confusion regarding with our proposed policy. We also As such, API Information Sources and allowable and restricted fees. Some moved the phrase ‘‘Register software API Users are not required by the API commenters noted that prohibiting fees applications’’ from its proposed location Condition of Certification requirements would enable patients to exercise their in § 170.404(a)(2)(ii)(A)(5) to the to publish any terms and conditions, HIPAA right of access without finalized location in including those that apply to consumer experiencing cost barriers, and remove § 170.404(a)(2)(ii)(A)(6) and revised the protections. cost barriers to hospitals and health care phrase for consistency. Additionally, we facilities using APIs for interoperability. made small changes to the regulation v. Fees Conditions Commenters noted that the proposals text finalized in § 170.404(a)(2)(ii)(A)(1) (A) General Fees Prohibition addressed many of the access and through § 170.404(a)(2)(ii)(A)(6) for pricing practices that API Technology clarity. We proposed in § 170.404(a)(3)(i)(A) Suppliers engaged in to limit data Comments. We received both support that API Technology Suppliers would exchange and gain a competitive and disagreement for the requirement to be prohibited from imposing fees advantage. Commenters noted that API publish transparency documentation on associated with API technology as a Technology Supplier pricing practices API fees. Some commenters felt Condition of Certification requirement. often create barriers to entry and transparency documentation of API fees In establishing this general prohibition, competition for apps that health care should be limited to value-added ONC was mindful of the need for API providers seek to use. Some commenters services, because those are the only Technology Suppliers to recover their supported the proposal that prohibits permitted fees applicable to API Users, costs and to earn a reasonable return on API Technology Suppliers from and the other permitted fees applicable their investments in providing API charging fees to API Users. to API Data Providers (usage-based fees technology that has been certified under Response. We thank stakeholders for and fees to recover costs for the Program. Accordingly, we identified their support of and feedback on our development, deployment, and categories of ‘‘permitted fees’’ in 84 FR proposal. We have finalized in upgrades) would be included in 7487 that API Technology Suppliers § 170.404(a)(3)(i)(A) that all fees related contractual documentation with their would be permitted to charge and still to certified API technology not customers. be compliant with the Condition of otherwise permitted by § 170.404(a)(3) Response. We recognize that some Certification and Program requirements. are prohibited from being imposed by a commenters had concern with making These include the proposed Certified API Developer. Additionally, documentation on permitted fees § 170.404(a)(3)(ii) (permitted fee for we have modified and reorganized these publicly available. We believe that developing, deploying, and upgrading Condition of Certification requirements transparent documentation of all API technology), proposed for clarity. We have renamed the title for permitted fees is necessary to maintain § 170.404(a)(3)(iii) (permitted fee to the section from the Proposed Rule to a competitive marketplace and ensure recover costs of supporting API usage ‘‘Fees conditions’’ because the that fees are reasonably related to the for purposes other than patient access), requirements include both permitted development, deployment, upgrade, and and proposed § 170.404(a)(3)(iv) and prohibited fees. We have updated use of certified API technology. Fee (permitted fee for value-added services). the terminology used in this section to transparency will also enable API We also proposed in 84 FR 7487 that reflect changes made to the terminology Information Sources and API Users to API Technology Suppliers would not be used throughout the API Condition of

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00111 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25752 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

Certification requirements and finalized ‘‘general conditions,’’ as finalized in from which a Certified API Developer in § 170.404(c). We finalized a § 170.404(a)(3)(i) and discussed above, may require payment, but they do not requirement in § 170.404(a)(3)(i)(A) that will facilitate API-based access, speak to who may pay the fee. For permitted fees in paragraphs exchange, and use of EHI by patients example, a permitted practice under § 170.404(a)(3)(ii) and § 170.404(a)(3)(iv) and other stakeholders without special these conditions could include a may include fees that result in a effort. We disagree with commenters relationship or agreement where an API reasonable profit margin in accordance that the permitted fee policies will stifle User or other party offered to pay the fee with the information blocking Costs relationships between Certified API owed by the API Information Source to Exception provision finalized in Developers and API Users. a Certified API Developer. This is an § 170.302. We clarify that any fee that is Cumulatively, these final policies create acceptable practice because the fee is not covered by those exceptions would guardrails to protect against anti- first agreed upon between the Certified be suspect under the information competitive practices and reinforce the API Developer and API Information blocking provision, and would equally independence that we believe API Source and subsequently paid by the not be permitted by this API Condition Information Sources should have to API Information Source directly or by a of Certification requirement. establish relationships with API Users. third party on behalf of the API This general prohibition on fees as Furthermore, we believe these fee Information Source. We note that fees finalized in § 170.404(a)(3)(i)(A) is policies are necessary in light of the charged for ‘‘value-added services’’ can meant to ensure that Certified API potential for Certified API Developers to arise between an API Information Developers do not engage in pricing use their market position and control Source and Certified API Developer or practices that create barriers to entry over certified API technology to engage API User. As a general matter, we note and competition for apps and API-based in discriminatory practices that create that stakeholders should be mindful of services that health care providers seek special effort and barriers to the use of other Federal and State laws and to use. Such activities are inconsistent certified API technology. We continue regulations that could prohibit or limit with the goal of enabling API-based to receive evidence that some Certified certain types of relationships involving access, exchange, and use of EHI by API Developers are engaging in remuneration. patients and other stakeholders without practices that create special effort for the We provide additional clarity and special effort. As finalized, this general use of certified API technology. These guidance regarding the API fees that can prohibition allows for three categories of practices include fees that create be charged under the Condition of permitted fees (§ 170.404(a)(3)(ii) barriers to entry or competition as well Certification requirements in the through (iv)) to allow Certified API as rent-seeking and other opportunistic sections that follow. Additionally, we Developers to recover their costs and to behaviors. For example, we have appreciate commenters’ requests for earn a reasonable return on their received feedback that some Certified clarification, including a chart of actors investments in providing certified API API Developers are conditioning access and costs. We will take this comment technology while being compliant with to technical documentation on revenue into consideration as we develop the Condition of Certification and sharing or royalty agreements that bear educational materials to help explain Program requirements. no plausible relation to the costs Comments. Some commenters were the permitted fees conditions finalized incurred by the Certified API Developer critical of our proposals, expressing in § 170.404(a)(3). to provide or enable the use of certified concerns that the proposed policies may Comments. Commenters suggested API technology. We are also aware of stifle relationships between API that one way to clarify the limits on API discriminatory pricing policies that Technology Suppliers and application fees would be to require API have the purpose or effect of excluding developers. Others expressed concern Technology Suppliers provide fee that the proposed fee structure would competitors from the use of APIs and information to ONC and for ONC to place undue burden on API Data other interoperability elements despite make this information publicly Providers, and that ONC should instead the fact that the API Information Source available, including information on consider regulations that allow fee would like to partner with and use these individual pricing transactions. sharing across stakeholders. Some competitive, best-of-breed services. Response. We appreciate the commenters stated that ONC should These practices from Certified API recommendation from commenters to remove all prohibitions, and allow for Developers close off the market to require Certified API Developers to market pricing and revenue sharing. innovative applications and services provide fee information to ONC. We Several commenters, many of whom that could empower patients and enable view fee transparency as a responsibility were providers and provider providers to deliver greater value and that a Certified API Developer can fulfill organizations, requested additional choice to health care consumers and without having to send a listing of its clarity and guidance regarding the API other service providers. API fees to ONC. We have finalized the fees that can be charged under the We note that Certified API Developers provision in § 170.404(a)(2)(ii) that a Condition of Certification requirements. and API Users have the ability to Certified API Developer must publish Some commenters requested collaborate and form relationships, so all terms and conditions for its certified clarification regarding whether an API long as these relationships do not API technology, including any fees. Data Provider can transfer costs to API conflict with any of the provisions of Specifically, we have finalized in Users. Other commenters requested this final rule or other applicable § 170.404(a)(2)(ii)(B) that any and all clarification regarding when it is (and is Federal and State laws and regulations. fees charged by a Certified API not) appropriate for an API User to be Further, we clarify that while the Developer for the use of its certified API charged a fee in connection with use of permitted fees set the boundaries for the technology must be described in API technology. A few commenters fees Certified API Developers are detailed plain language, including the requested that ONC provide a chart that permitted to charge and to whom those persons or classes of persons to whom lists all actors, all types of costs, and permitted fees can be charged, they do the fee applies; the circumstances in who can charge whom. not prohibit who may pay the Certified which the fee applies; and the amount Response. We appreciate this API Developer’s permitted fee. In other of the fee, which for variable fees must feedback from commenters. These words, these conditions limit the party include the specific variable(s) and

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00112 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25753

methodology(ies) that will be used to certified API technology for, API Developer’s subjective judgment or calculate the fee. Information Sources; (3) Ensure that discretion. such fees for supplying, and if Comments. A few commenters (B) Certified API Developer Permitted suggested that ONC allow API Data Fees Conditions applicable, supporting certified API technology are reasonably allocated Providers the ability to recoup the costs We proposed general conditions in among all similarly situated API for upgrading technology. § 170.404(a)(3)(i)(B)(1) through (4) that Information Sources; and (4) Ensure that Response. This comment appears to an API Technology Supplier’s permitted such fees are not based on whether API misunderstand the scope and fees must satisfy in order for such fees Information Sources or API Users are applicability of ONC’s authority with to be expressly permitted. competitors, potential competitors, or respect to these Condition of Comments. We received support for Certification requirements. We clarify will be using the certified API the general conditions for permitted fees that these Condition of Certification technology in a way that facilitates from commenters. Some commenters requirements apply only to Certified competition with the Certified API expressed appreciation for the API Developers. We note that similar to guardrails and transparency of the Developer. We have revised the term any IT investment, API Information permitted fees. Under the first ‘‘substantially similar’’ to ‘‘similarly Sources (as ‘‘health care providers’’) condition, commenters sought clarity on situated’’ in § 170.404(a)(3)(i)(B)(1) for would generally be expected to recover the nature and extent of some of the clarity and to align with changes made these costs through fees administered permissible fees an API Technology in § 171.302. Additionally, in response while delivering health care services. Supplier can charge and how to model to comments and to align with changes Additionally, if an API Information such fees, specifically regarding the made in § 171.302 and Source were to recoup such costs they ‘‘objective and verifiable’’ criteria. § 170.404(a)(3)(i)(B)(1), we have revised would need to do so consistent with the Another commenter supported the the term ‘‘substantially similar’’ to information blocking exceptions and second condition that fees must be ‘‘similarly situated’’ in other applicable laws and regulations. reasonably related to API Technology § 170.404(a)(3)(i)(B)(3). We emphasize Comments. Some commenters Supplier’s costs of supplying and, if that this provision is meant to prevent requested that ONC conduct evaluations applicable, supporting the API one customer or a specific group of after the implementation of the rule and technology to the API Data Provider, customers to whom the certified API use the results to drive future policy. especially in situations where technology is supplied or for whom it is Some commenters recommended a physicians may also develop APIs or supported from bearing an unreasonably study to evaluate the real-world cost of support apps. high cost compared to other customers, APIs used by health systems in areas However, some commenters which could lead to ‘‘special effort’’ for such as clinical decision support, expressed concern with the third accessing and using APIs. We believe payments, machine learning, and condition to reasonably allocate fees the final policy achieves the same goal precision medicine. Commenters also across all customers of the API. as proposed and provides clearer suggested ONC conduct a study on Commenters explained that fees could guidelines for the regulated community whether these regulations improve not be reasonably allocated across all to follow. Additionally, we have revised patient access to their EHI. customers of the API, because the the phrase ‘‘classes of persons and Response. We appreciate the number of customers will change over requests’’ to ‘‘API Information Sources evaluation recommendations. We will time. We received no comments on the and API Users’’ in consider these suggestions as we fourth condition that API Technology § 170.404(a)(3)(i)(B)(1) to clearly express implement and administer the Program. Suppliers must ensure that fees are not the actors being charged fees by based on whether the requestor or other (C) Certified API Developer Prohibited Certified API Developers. Additionally, Fees person is a competitor who will be we have revised the sentence structure using the API technology in a way that and grammar in § 170.404(a)(3)(i)(B)(2) We proposed in 84 FR 7595 in facilitates competition. In addition to through (4) for simplification. § 170.404(a)(3)(iii)(B) that permitted the general permitted fees proposed, fees would not include costs associated some commenters recommended clear In response to comments requesting with intangible assets (including fee exemption for any health clarity on the nature and extent of depreciation or loss of value), except the information provided or reported by a permissible fees a Certified API actual development or acquisition costs practice for the purpose of meeting Developer can charge and how a of such assets. Additionally, we reporting requirements. Certified API Developer should model proposed in § 170.404(a)(3)(iii)(C) that Response. We appreciate feedback such fees, specifically regarding the permitted fees would not include from commenters. We have finalized ‘‘objective and verifiable’’ requirement opportunity costs, except for the these general conditions for permitted finalized in § 170.404(a)(3)(i)(B)(1), we reasonable forward-looking cost of fees in § 170.404(a)(3)(i)(B) with some emphasize that there will be significant capital. modifications as described further variability in the fee models and Comments. We did not receive any below. We have finalized that for all specific fees charged by each Certified comments specific to the proposal for permitted fees, a Certified API API Developer. Our goal with the costs associated with intangible assets Developer must: (1) Ensure that such requirement that fees be ‘‘objective and other than actual development or fees are based on objective and verifiable’’ is to require Certified API acquisition costs of such assets. verifiable criteria that are uniformly Developers to apply fee criteria that, Response. We moved the proposed applied to all similarly situated API among other things, will lead the § 170.404(a)(3)(iii)(B) and (C) to the Information Sources and API Users; (2) Certified API Developer to come to the general conditions for permitted fees Ensure that such fees imposed on API same conclusion with respect to the finalized in § 170.404(a)(3)(i)(C)(1) and Information Sources are reasonably permitted fee’s amount each time it (2), respectively, because they are related to the Certified API Developer’s administers a fee to an API Information general conditions on permitted fees costs of supplying certified API Source or API User. Accordingly, the fee rather than conditions for ‘‘Recovering technology to, and if applicable, support cannot be based on the Certified API API usage costs.’’ We did not make

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00113 Fmt 4701 Sfmt 4700 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 could include, for example, access to API Developer considers necessary to regulation text in these two sections ‘‘test environments’’ and other resources successfully deploy applications in other than updating terms to the that an application developer would production are considered supplemental finalized definitions in § 170.404(c). need to efficiently design and develop to the development, testing, and Additionally, in the discussion of the apps. The services could also include deployment of software applications Fees Exception in this final rule access to distribution channels if they that interact with certified API (VIII.D.2.b), we discussed that one are necessary to deploy production- technology, and are permitted fees for commenter expressed concern that the ready software and to production value added services as finalized in overlap between the Fees Exception and resources, such as the information § 170.404(a)(3)(iv). the Licensing Exception creates the needed to connect to certified API (D) Record-Keeping Requirements potential for actors to recover the same technology (e.g., service base URLs) or costs twice. The commenter explained the ability to dynamically register with We proposed in § 170.404(a)(3)(v) that that licensing of IP is intended to recoup an authorization server. API Technology Suppliers must keep for the costs of development of that IP, so Comments. At least one commenter inspection detailed records of all API where the IP is an interoperability expressed concern about the open- technology fees charged, all costs element, the costs reasonably incurred ended nature of the examples of incurred to provide API technology to for its development should be prohibited fees we provided in the API Data Providers, methodologies used incorporated into the royalty rate. The Proposed Rule. In particular, that any to calculate such fees, and the specific commenter recommended that we be fee in connection with any services that costs to which such fees are attributed. clearer that, in these circumstances, would be essential to a developer or We requested comment in 84 FR 7492 only a single recovery is permitted. In other person’s ability to develop and on whether these requirements provide order to address this comment and align commercially distribute production- adequate traceability and accountability the API permitted fees with related ready applications that use API for costs permitted under this API provisions finalized in the Fees technology would be prohibited. They Condition of Certification and whether Exception (§ 170.302(a)(2)(vi)) and stated that if the example were not more to require more detailed accounting Licensing Exception clearly defined and scoped, it could be records or prescribe specific accounting (§ 170.303(b)(2)(iv)), we have added and used by API Users to create standards. finalized § 170.404(a)(3)(i)(C)(3), which requirements for API Technology Comments. A majority of commenters states that the permitted fees in this Suppliers beyond what would normally expressed concerns with the level of section cannot include any costs that be considered necessary to successfully granularity proposed for record keeping that led to the creation of IP if the actor deploy apps in production. They in § 170.404(a)(3)(v). These commenters charged a royalty for that IP pursuant to requested ONC more clearly define stated that the required recordkeeping § 170.303 and that royalty included the ‘‘essential services’’ in final rulemaking would exceed documentation performed development costs for the creation of or withdraw the reference. for any other purpose. Some the IP. We refer readers to the ‘‘Basis for Response. We appreciate the feedback commenters stated that the requirement Fees Condition’’ sub-section within from commenters. We disagree with for health IT developers to track who section VIII.D.2.b for a more detailed commenters that the examples are too pays fees and how fees enter the system discussion of the rationale for this broad. We believe that in some cases will cause significant administrative addition. they need to be general because of the burden, especially on smaller vendors diverse and varied practices that could or vendors with business models that (i) General Examples of Prohibited Fees be used by Certified API Developers to require less operational overhead. As discussed in the Proposed Rule in create special effort to use certified API Additionally, they stated that the 84 FR 7481 and finalized in technology. While we understand that requirement for clients to maintain and § 170.404(a)(3)(i)(A), any API-related fee the generality of the example regarding potentially publicly disclose records of imposed by a Certified API Developer ‘‘essential services’’ may at first appear fees for inspection would place a that is not expressly permitted is difficult for Certified API Developers to burden on IT providers, and could prohibited. In the Proposed Rule, we follow and, per the commenter, could be potentially allow bigger companies to provided the following non-exhaustive creatively used by an API User to engage in practices such as predatory examples of fees for services that request more support than necessary, pricing. Commenters suggested ONC Certified API Developers would be we offer the following as additional have a more scaled-back method, and prohibited from charging, and reiterate guidance: A Certified API Developer is simply allow patients the ability to them here in the final rule for clarity: best positioned to know what an API access their EHI without charge. These (1) Any fee for access to the User, for example, needs to have access commenters recommended focusing on documentation that a Certified API to and do programmatically in order for a good conduct approach rather than Developer is required to publish or the API User’s application to be prescriptive requirements. make available under this Condition of developed and commercially distributed Response. We thank commenters for Certification requirement. as production-ready for use with their feedback and perspective. We (2) Any fee for access to other types certified API technology. From a moved § 170.404(a)(3)(v) to of documentation or information that a Certified API Developer’s perspective, if 170.404(a)(3)(i)(D) for better software developer may reasonably that requires any number of mandatory organization because this provision require to make effective use of certified steps (e.g., passing tests in sandbox/test applies to the permitted fee Condition of API technology for any legally environment, conducting a demo, Certification requirements finalized in permissible purpose. submitting documentation or § 170.404(a)(3)(ii) through (iii). We have (3) Any fee in connection with any paperwork) in order for the application finalized in § 170.404(a)(3)(i)(D) that services that would be essential to a to be production-ready for use with Certified API Developers must keep developer or other person’s ability to certified API technology, then fees detailed records for inspection of all develop and commercially distribute associated with those mandatory steps fees charged, all costs incurred to production-ready applications that use are prohibited. Conversely, fees for provide certified API technology to API certified API technology. These services requirements beyond what a Certified Information Sources, methodologies

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00114 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25755

used to calculate such fees, and the that this blanket prohibition apply to all conditions in § 170.404(a)(4) will ensure specific costs to which fees are new and updated API technology. A few that fees permitted for upgrade costs attributed. Considering the feedback on commenters noted that it is possible that will not be used as a barrier to providing perceived burden, we believe API Technology Suppliers will bundle interoperability between systems or transparency and documentation of API or upcharge service fees to recoup API other applications, or as a means to fees is necessary to mitigate unfair technology development costs and API eliminate competitive threats. pricing practices that may stifle Technology Suppliers should not be Additionally, the transparency innovation or otherwise create barriers allowed to charge costs for development requirements regarding the publication to the goals of enabling API-based or impose surcharges for product feature of fees finalized in § 170.404(a)(2)(ii)(B) access, exchange, and use of EHI development. They noted that product will help prevent hidden integration without special effort. Further, we feature development should be fees cited by commenters. believe that the accounting practices considered a cost of doing business and We thank commenters for already used by health IT developers can be amortized as a one-time capital recommending and noting that will largely support the health IT expense across the vendor’s entire development of the APIs themselves developer to meet this requirement. customer base without the need for should be regarded as part of a license Examples of these practices by health IT recovering costs from API Users. They fee and that Certified API Developers developers include the methods used to emphasized that API access and use should not be permitted to charge an track their own investments, determine prices need to be transparent as the additional license fee for what is an how to bill and issue invoices to their intent of Congress was to have APIs be inherent part of the software. In customers, document receipt of made easily available and at no or low response to this recommendation, we payment, and to maintain overall cost, not to be a source of revenue for have added a provision in accurate financial records of business profit. Other commenters noted that the § 170.404(a)(3)(i)(C)(3) that states that transactions. We find it difficult to development of the APIs themselves permitted fees in § 170.404(a)(3)(ii) believe, as some commenters appeared should be regarded as part of the license through (iv) may not include any costs to indicate, that health IT developers are fee and the API Technology Suppliers that led to the creation of IP, if the actor not already keeping such financial should not be permitted to charge an charged a royalty for that IP pursuant to records and that this requirement would additional license fee to either the API the information blocking Licensing create substantial new documentation Data Provider or API User for what is an Exception (§ 171.303). This provision burden for Certified API Developers. inherent part of the software. Another aligns with similar provisions included The record-keeping requirements commenter requested that consideration in the information blocking section and finalized in 170.404(a)(3)(i)(D) foster be applied toward potential additional will ensure that Certified API transparency and promote hidden integration fees. Developers cannot earn a double Response. We appreciate the support, accountability in the Program. In recovery in instances described by the concerns, and recommendations from response to the comments received, we commenter. have not added additional requirements commenters. We finalized this proposal We will continue to work with for accounting records or standards. in § 170.404(a)(3)(ii) as proposed with updated terms based on the revised stakeholders to advance policies that (E) Permitted Fee for Development, finalized definitions in § 170.404(c). We promote interoperability and deter Deployment, and Upgrades refer to the discussions below and 84 FR practices that may stifle innovation or We proposed in § 170.404(a)(3)(ii) to 7488 for additional details on what present barriers to the access, exchange, permit an API Technology Supplier to Certified API Developer fees for and use of EHI through APIs. Subject to charge API Data Providers reasonable ‘‘developing,’’ ‘‘deploying,’’ and the general conditions in fees for developing, deploying, and ‘‘upgrading’’ certified API technology § 170.404(a)(3)(i), our final policies upgrading Health IT Modules certified comprise. We also note that the nature support the ability of Certified API to § 170.315(g)(7) through (g)(11). of the costs charged under this category Developers to recover the full range of Comments. Many commenters of permitted fees depends on the scope reasonable costs associated with applauded the permitted fee related to of the work to be undertaken by a developing, deploying, and upgrading development, deployment, and Certified API Developer (i.e., how much API technology over time. It is upgrading API technology. The majority or how little labor an API Information important that Certified API Developers supported the proposal that fees would Source requires of the Certified API be able to recover these costs and earn not be permitted if they interfere with Developer to deploy and upgrade the a reasonable return on their investments an API User’s ability to efficiently and certified API technology). so that they have adequate incentives to effectively develop and deploy We sincerely thank commenters for make continued investments in these production-ready software. A few the various recommendations to technologies. In particular, we commenters expressed concern that our prohibit or restrict fees regarding anticipate Certified API Developers will proposals regarding development, certified API technology. In order to need to continually expand the data deployment, and upgrade fees were not reconcile the recommendations specific elements and upgrade the capabilities restrictive enough. Commenters noted to § 170.404(a)(3)(ii) and other associated with certified APIs as the that API Technology Suppliers will use conditions in this final rule, we have USCDI and HL7® FHIR® standard and the allowable fees, such as for program aligned related conditions to address associated implementation upgrades, as a barrier to providing concerns and mitigate potential fee specifications mature. We refer readers interoperability between systems or practices that could limit API-based to the information blocking section of other applications and a means to access, exchange, and use of EHI by this preamble (VIII) for additional eliminate competitive threats. Some of patients and other stakeholders without information on activities that may these commenters recommended that special effort. As finalized, we believe constitute information blocking and for ONC explicitly prohibit API Technology the fees permitted in § 170.404(a)(3)(ii) discussion about how the fees Suppliers from charging any fees for and § 170.404(a)(3)(i)(B), transparency provisions in this Condition of implementing APIs and for facilitating requirements in § 170.404(a)(2), and Certification and within the information the interoperable exchange of EHI and openness and pro-competitive blocking section support innovation.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00115 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25756 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

Comments. Some developers an API Information Source’s certified developed in order to be considered expressed concern regarding balancing API technology. production-ready by the Certified API and distributing costs with regard to the While the development, deployment, Developer for use with its certified API permitted fee for developing, deploying, and upgrade permitted fee is limited technology, then fees associated with and upgrading technology. The between the Certified API Developer that kind of test environment would be commenters noted ONC proposed that and API Information Source as a way to prohibited as they would impose special the cost for development be distributed recoup a Certified API Developer’s costs effort. However, we note that this among those who will use it, which they to supply certified API technology to a prohibition is not globally applicable. If felt was problematic in many ways, but particular API Information Source, we instead, the purpose of the testing most fundamentally because it suggests again reiterate that the value added environment was to provide specific a serious misconception about how services permitted fee providers testing above-and-beyond production- software development is funded, priced, Certified API Developers a wide range of readiness for use with certified API and sold. The commenters emphasized options to make additional revenue technology, then fees could be charged related to their certified API technology. for such testing as part of the value- that requiring development costs to be Should API Users stand to generate divided among clients purchasing the added services permitted fee. revenue from the use of their apps, any Comments. A few commenters API necessitates new and complex fee an API Information Source may requested guidance on how ONC business processes and creates impose would not be in scope for this expects API Technology Suppliers to unsolvable scenarios that could easily Condition of Certification but would be account for the costs incurred to create business conflicts between API likely be covered by information develop, deploy, and upgrade the API Technology Suppliers and their clients. blocking. Accordingly, we emphasize technology, which is part of, and not At least one commenter suggested that that such stakeholders should take care necessarily separable from, the broader ONC should consider balancing the to ensure they are compliant with other EHR product. Several commenters costs associated with API development Federal and State laws and regulations opposed the prohibition against and deployment across both API Data that may prohibit or limit certain types charging for work to upgrade the Providers and certain API Users to of relationships involving remuneration. broader EHR product, expressing that ensure that third-party software In response to comments suggesting this is essential work needed to application developers also bear some of that costs for updating information modernize their solutions as broader the financial burden, since they stand to systems and Health IT Modules to the technologies evolve. One commenter generate revenue from the use of their new standards and requirements would noted that the Proposed Rule does not apps. Commenters asked ONC clarify be passed on to physicians and patients, set specific guidelines on what why it believes it is inappropriate to we disagree. We emphasize that most of constitutes an upgrade or how much the pass development, deployment, and the information contained in a patient’s fee could be, and it is the commenter’s upgrade costs on to API Users. Other electronic record has been documented experience that EHR systems often commenters noted that the costs for during the practice of medicine or has charge fees for such services as updating information systems and otherwise been captured in the course of integrating with a clinical data registry Health IT Modules to the new standards providing health care services to or using outside or non-preferred and requirements should not be passed patients. In our view, patients have software. on to physicians and patients. effectively paid for this information, Response. We thank stakeholders for either directly or through their their comments. While we understand Response. We appreciate the feedback employers, health plans, and other that there is overlap between features of from commenters. We proposed and entities that negotiate and purchase the certified API technology and the finalized this permitted fee for health care items and services on their ‘‘broader EHR product,’’ we refer development, deployment, and upgrade behalf, and should be able to access the specifically to development, costs because we believe that these costs information via certified API technology deployment, and upgrades made to should be negotiated solely between the without fees. ‘‘certified API technology’’ as defined in Certified API Developer that supplies Comments. Some developers § 170.404(c). Namely, development, the capabilities and the API Information suggested that API Technology deployment, and upgrades made to the Source that implements them in their Suppliers should be able to charge fees capabilities of certified Health IT production environment. In our view, it for access to a test environment and Modules that fulfill the API-focused is inappropriate for Certified API requested clarification as to whether an certification criteria adopted at Developers to go around the API API Technology Supplier can charge for § 170.315(g)(7) through (10). In response Information Source to directly impose the use of sandboxes by API Users. to commenters concerned that EHR financial cost burdens on API Users for Response. We appreciate the feedback developers often charge fees for services the benefit of working with or from commenters. As detailed in the such as integrating with a clinical data connecting to the API Information ‘‘General Examples of Prohibited Fees’’ registry or using outside or non- Source. Based on our experience, the section of the preamble text and preferred software, we note that, as practice of a Certified API Developer included in the general prohibition described in § 170.404(a)(3)(i)(A), going around its customer (the API finalized in § 170.404(a)(3)(i)(A), Certified API Developers are prohibited Information Source) to also charge API Certified API Developers are prohibited from imposing fees associated with Users erodes an API Information from charging fees in connection with certified API technology unless Source’s choice and the independence any services essential to a developer or included as a permitted fee in of their relationship with API Users. As other person’s ability to develop and § 170.404(a)(3)(ii) through (iv). We do such, that kind of business practice commercially distribute production- not include specific price information would be something that we would ready applications for use with certified for permitted fees to develop, deploy, or consider creating special effort on the API technology. In general, if a test upgrade API technology, because these part of the API Users if they had to environment or sandbox is required to costs are subject to change over time continue to face additional fees just for be used by a Certified API Developer with new technology and varying permission to work with or connect to and is essential for an application to be development, deployment, and upgrade

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00116 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25757

efforts. Instead, we allow Certified API used to access the certified API EHI. Finally, we proposed in Developers to recover their costs technology, which a Certified API § 170.404(a)(3)(iii)(B)–(C) restrictions for (including costs that result in a Developer can only recover under the permitted fees that were moved to the reasonable profit margin for permitted permitted fee for usage support costs general permitted fees section finalized fees in § 170.404(a)(3)(ii) and (§ 170.404(a)(3)(iii)). We emphasize that in § 170.404(a)(3)(i)(C). § 170.404(a)(3)(iv)) in providing for the purpose of this Condition of Comments. Commenters generally certified API technology while being Certification, we consider that certified supported our proposal to permit an API compliant with the Condition and API technology is ‘‘deployed’’ by the Technology Suppliers to charge usage- Maintenance of Certification and customer—the API Information based fees to API Data Providers to the Program requirements. We include Source—that purchased or licensed it. extent that the API technology is used descriptions of fees for developing, for purposes other than facilitating the (iii) Fees for Upgrading Certified API deploying, and upgrading API access, exchange, or use of EHI by Technology technology in the sections that follow, patients or their applications, in which we offer additional clarity, as The Certified API Developer’s fees for technologies, or services. discussed in the Proposed Rule at 84 FR ‘‘upgrading’’ certified API technology Response. We appreciate support 7488, on the fees for developing, comprise the Certified API Developer’s from commenters and have finalized deploying, and updating API costs of supplying an API Information this proposal in § 170.404(a)(3)(iii) with technology. Source with an updated version of some modification. We amended the certified API technology. Such costs title of the regulation text for clarity in (i) Fees for Developing Certified API would include the costs required to § 170.404(a)(3)(iii) to ‘‘Permitted fee— Technology bring certified API technology into Recovering API usage costs.’’ Fees for ‘‘developing’’ certified API conformity with new requirements of Additionally, we amended the technology comprise the Certified API the Program, upgrades to implement regulation text to focus on usage-based Developer’s costs of designing, general software updates (not otherwise fees and Certified API Developer’s developing, and testing certified API covered by development fees or under reasonable incremental costs. We did technology. In keeping with our warranty), or developing and releasing not finalize the specific prohibition on discussion at 84 FR 7488, fees for newer versions of the certified API permitted fees proposed in developing certified API technology technology at the request of an API § 170.404(a)(3)(iii)(A) that the must not include the Certified API Information Source. The nature of the ‘‘permitted fee does not include costs Developer’s costs of updating the non- costs that can be charged under this incurred by the API Technology API related capabilities of the Certified category of permitted fees depends on Supplier to support uses of the API API Developer’s existing Health IT the scope of the work undertaken by a technology that facilitate a patient’s Modules, including its databases, as part Certified API Developer (i.e., how much ability to access, exchange, or use of its development of the certified API or how little labor an API Information electronic health information.’’ We did technology. As we further discussed in Source requires of the Certified API not finalize this aspect of the provision 84 FR 7488 in our Proposed Rule, these Developer to upgrade the certified API because upon further consideration of costs are connected to past business technology being supplied from one this cost and the fee prohibition decisions made by the Certified API version or set of functions to the next). included in information blocking Developer and typically arise due to related to patient access, we determined (F) Permitted Fee to Recover Costs of Health IT Modules being designed or that these fees remain necessary in order Supporting API Usage implemented in nonstandard ways that to allow Certified API Developers to unnecessarily increase the complexity, We proposed in 84 FR 7489 in recover incremental costs reasonably difficulty or burden of accessing, § 170.404(a)(3)(iii) to permit an API incurred during the process of hosting exchanging, or using EHI. The recovery Technology Supplier to charge API certified API technology on behalf of the of costs associated with updating a usage-based fees to API Data Providers API Information Source. We reiterate Certified API Developer’s non-API to recover the API Technology that a Certified API Developer’s related Health IT Modules capabilities Supplier’s reasonable incremental costs ‘‘incremental costs’’ comprise the would be inconsistent with the Cures for purposes other than facilitating the Certified API Developer’s costs that are Act requirement that API technology be access, exchange, or use of EHI by directly attributable to supporting API deployed ‘‘without special effort.’’ patients or their applications, interactions at increasing volumes and technologies, or services. We considered scale within established service levels. (ii) Fees for Deploying Certified API ‘‘usage-based’’ fees to be the fees A Certified API Developer should Technology imposed by an API Technology Supplier ‘‘price’’ its costs of supporting access to Certified API Developer’s fees for to recover the costs that would typically the certified API technology by ‘‘deploying’’ certified API technology be incurred supporting API interactions reference to the additional costs that the comprise the Certified API Developer’s at increasing volumes and scale within Certified API Developer would incur in costs of operationalizing certified API established service levels. Additionally, supporting certain volumes of API use. technology in a production in 84 FR 7489 under § 170.404(a)(3)(iii), For comments and responses related to environment. Such fees include, but are we proposed that any usage-based fees the proposed provisions in not limited to, standing up hosting associated with API technology be § 170.404(a)(3)(iii)(B) and (C), we refer infrastructure, software installation and limited to the recovery of the API readers to the header ‘‘Certified API configuration, and the creation and Technology Supplier’s ‘‘incremental Developer Prohibited Fees.’’ maintenance of API Information Source costs.’’ Additionally, we proposed in Comments. We received a few administrative functions. We discussed § 170.404(a)(3)(iii)(A) that the permitted comments focused on volume in our Proposed Rule that a Certified fee would not include any costs thresholds and incremental costs. A few API Developer’s fees for ‘‘deploying’’ incurred by the API Technology commenters supported a reasonable cap certified API technology does not Supplier to support uses of the API for API call fees. Several recommended include the costs associated with technology that facilitate a patient’s changing the parameters around API managing the traffic of API calls that are ability to access, exchange, or use their usage-based fees to focus on volume

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00117 Fmt 4701 Sfmt 4700 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 establish a reasonable cap for API usage- patients with access to data via those contractual language related to these based fees, but the focus of our policy APIs, responsible for a variety of fees, to ensure that any incremental is to identify usage fees as a type of unwarranted costs with little recourse to costs attributable to supporting API permitted fee and not to dictate a recover those costs. interactions at increasing volumes and singular fee model, which we believe Response. While we understand the scale are addressed appropriately. could limit Certified API Developers perspective from which these concerns Commenters noted that if an API ability to create innovative fee models arise, especially regarding unpredictable Technology Supplier is receiving fees to that serve to benefit themselves and API overuse of certified API technology, an develop, deploy, and upgrade API Information Sources. We decline to API Information Source has financial technology, it is unlikely that they include a price cap for API usage-based responsibility for its overall technology would also need to charge for usage of fees or a range of prices for API fees infrastructure. This accountability is no the APIs, as long as their usage remains based on examples from the current different for certified API technology under a pre-determined volume marketplace because we anticipate the than it is for non-certified APIs and threshold. A few commenters noted that cost of technology will change over time other interfaces that may also create the volume of requests that will be and so too will the way in which usage costs for the API Information Source pinging APIs may compromise the costs are calculated. Additionally, while (i.e., health care provider). Given that performance of data retrieval and we understand and expect that Certified API Users can also include an API effective user experience. In order to API Developers and API Information Information Source’s own employees/ protect against denial of service attacks Sources will deploy particular security internal tools and 3rd party partners’ whether intentional or inadvertent, they methods to mitigate the risk of denial of tools, an API Information Source is best stated ONC should consider an service attacks and other impacts on API positioned and generally accountable additional throttling or rate-limiting availability, these types of technology for its financial commitments. Again, as layer or capability onto the API in order layers are separate from the focus of our noted above, we do not limit who may for the API to accept and digest the data policy on permitted API usage fees. pay for the charges an API Information being entered or extracted. A few Comments. Several commenters Source incurs. An API Information commenters noted that our proposal requested that ONC further clarify that Source should have full knowledge and could create loopholes that would API Technology Suppliers should not ability to assess what employees, enable certain organizations to charge attempt to charge different fees for internal applications, and 3rd party highly burdensome, excessive fees to different API transactions as they services it has granted access to use and clinical registries to access their data. frequently do today. interact with its certified API A few commenters expressed concern Response. We appreciate this technology. With respect to potential that this proposal is not restrictive information and feedback from overages as a result of patient access, as enough. Some commenters requested commenters. We clarify that Certified we have stated before, we believe that ONC provide more definitive API Developers are permitted to charge patients have effectively paid for this guidance, including a range of prices ‘‘usage-based’’ fees to recover the costs information, either directly or through based on examples from the current that would typically be incurred their employers, health plans, and other marketplace, to ensure providers are not supporting API transactions at entities that negotiate and purchase charged unreasonable fees by API increasing volumes and scale within health care items and services on their Technology Suppliers and can established service levels. To clarify, behalf, and believe they should not be reasonably charge API Users for the cost usage-based fees recover costs incurred charged. of accessing their API technology. by a Certified API Developer related to Additionally, as stated in the Response. We appreciate the feedback the actual use of certified API Proposed Rule (84 FR 7489) and from commenters. This Condition of technology once it has been deployed finalized here, usage fees for certified Certification requirement offers the (e.g., costs to support a higher volume API technology will only apply when flexibility necessary to accommodate of traffic, data, or number of apps via the Certified API Developer acts on reasonable pricing methodologies and the API Technology). We acknowledge behalf of the API Information Source to will allow Certified API Developers to that Certified API Developers could deploy its certified API technology. In explore innovative approaches to adopt a range of pricing methodologies scenarios where the API Information recovering the costs associated with when charging for the support of API Source, such as a large hospital system, supporting the use of certified API usage, including potentially charging assumes full responsibility for the technology with a permitted fee. As higher prices for some API transactions technical infrastructure necessary to described in the Proposed Rule (84 FR that incur relatively higher costs than deploy and host the certified API 7489), ‘‘usage-based’’ fees are fees others. However, in combination with technology it has acquired, the volume imposed by a Certified API Developer to this flexibility, Certified API Developers and scale of its usage would be the API recover costs typically incurred for will still need to be mindful of not Information Source’s sole responsibility, supporting API interactions at violating any overarching information and a Certified API Developer would increasing volumes and scale within blocking policies. We refer readers to a not be permitted to charge usage-based established service levels. That is, discussion in the Proposed Rule in 84 fees. Instead, the Certified API ‘‘usage-based’’ fees recover costs FR 7489 for additional discussions on Developer would be limited to charge incurred by a Certified API Developer usage-based fees. fees under the ‘‘development, due to the actual use of the certified API Comments. Some commenters deployment, upgrade’’ permitted fee in technology once it has been deployed emphasized that it is unreasonable to § 170.404(a)(3)(ii). Additionally, the (e.g., costs to support a higher volume presume that API User-driven data costs recovered under ‘‘usage-based’’ of traffic, data, or number of apps via overages should be the responsibility of fees can only reflect ‘‘post-deployment’’ the certified API technology). Certified the API Data Provider. While other costs. As such, ‘‘usage-based’’ fees API Developers can adopt a range of commenters expressed concern that our cannot include any costs necessary to pricing methodologies when charging proposal will leave providers, who are prepare and ‘‘get the certified API for the support of API usage. We mandated to use certified EHRs that technology up, running, and ready for appreciate commenters’ request to include API technology and provide use,’’ which are costs that must be

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00118 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25759

recovered as part of the deployment section of this final rule in VII.D.2.b, appropriate. They stated that, in the services delivered by the Certified API which applies to health IT developers case of TEFCA, HIEs and providers must Developer if permitted under and a broader set of actors than these be responsive to inbound requests to § 170.404(a)(3)(ii). Condition and Maintenance of broadcast data and should not be Comments. Several commenters Certification requirements, for a charged a fee for responding to such supported ONC’s efforts to bolster discussion of the restrictions on requests. They explained that such an patient access, noting that the capacity charging patients for access to their EHI. arrangement could be used maliciously to offer a patient’s access to all elements Comments. Several commenters between market participants seeking to of their electronic medical record, requested that ONC provide further increase the operational expenses of through an API, without cost, is well- guidance on the types of costs that a their competitors. supported in the Proposed Rule. One developer could charge to permit API Response. We appreciate this commenter noted that the proposed Data Suppliers to offer population-level comment, but we continue to believe provisions regarding fees supports uses queries to API Users. They requested that that usage-based fees should be of the API technology that facilitate a ONC clarify that such usages fees must permitted subject to the conditions patient’s ability to access, exchange, or relate to the costs associated with actual described in § 170.404(a)(3)(iii). We use their EHI. The commenters noted hardware (e.g., server space) needed to have addressed commenter’s concern that the clear language in the Proposed support the increased volume of queries regarding potential anticompetitive Rule will prevent any potential for non-patients and not the cost of behavior through the final provisions in confusion or friction in the future. implementing the population-level § 170.404(a)(3)(i)(B). Specifically, in A few commenters expressed concern query functionality itself. § 170.404(a)(3)(i)(B)(1), a Certified API that application developers will attempt Response. We clarify that API usage Developer must ensure that fees are to leverage the patient access fee fees related to API ‘‘read’’ services for based on objective and verifiable criteria limitations by claiming to be patient multiple patients would be calculated that are uniformly applied for all facing. One commenter suggested that using a similar methodology to calculate similarly situated classes of persons and the proposed fee limitations regarding API usage fees related to API ‘‘read’’ requests. In addition, under patient access applied only with respect services for single patients. These § 170.404(a)(3)(i)(B)(4), a Certified API to fees API Technology Providers ‘‘usage-based’’ fees are fees imposed by Developer must ensure that fees are not impose on API Data Providers, should a Certified API Developer to recover the based in any part on whether the also apply to fees charged to consumer- costs typically incurred to support API requestor or other person is a facing application developers who in interactions for API ‘‘read’’ services for competitor, potential competitor, or will the past have been charged high fees by multiple patients once these services be using the certified API technology in CEHRT developers. One commenter have been deployed. This could a way that facilitates competition with recommended making it clear that include, but not be limited to, costs to the Certified API Developer. provider organizations and health IT support a higher volume of traffic, data, Comments. Several commenters developers cannot charge patients, or or number of apps via the certified API expressed concern about incremental the apps that they use, for using patient- technology (which could include higher costs that can be recovered by actors facing APIs. At least one commenter costs for hardware, including server supporting the use of APIs for purposes requested that ONC clarify that space). We appreciate the other than patient access. They permitted usage-based fees do not apply recommendation from commenters; requested ONC clarify that recovery of to patients or patient designees. however, we have not prescribed the incremental costs for these other Response. We thank commenters for centralization of all of this content. purposes should not be allowed, their support for restricting API-related Comments. Some commenters because they believed the incremental fees. As noted above, we have suggested that API Technology costs do not add any efficiency to the reconfigured the permitted fee for usage Suppliers publish their fees on the same health care system, do not benefit costs in response to public comments website as their API documentation so patients, and do not serve any other and our assessment of the intersection there is full transparency and an API procompetitive purpose. of API permitted fees policies and Data Supplier and API User can easily Response. We appreciate these information blocking policies. We have understand costs before embarking upon comments, but continue to believe that finalized an approach that permits development. ‘‘incremental costs’’ should be allowed. Certified API Developers to recover Response. We appreciate the A Certified API Developer’s incremental usage costs reasonably recommendation and support from ‘‘incremental costs’’ comprise the incurred during the process of hosting commenters. As finalized under Certified API Developer’s costs that are certified API technology on behalf of an § 170.404(a)(2)(ii)(B), a Certified API directly attributable to supporting API API Information Source, which could Developer must publish all terms and interactions at increasing volumes and include fees to the API Information conditions for its certified API scale within established service levels. Source for providing and supporting technology, including any fees. Any and We believe a Certified API Developer patient access. However, the Certified all fees charged by a Certified API should ‘‘price’’ its costs of supporting API Developers and API Information Developer for the use of its certified API access to the certified API technology by Sources cannot recover these costs from technology must be described in reference to the additional costs that the patients or the developers of detailed, plain language, including the Certified API Developer would incur in applications that facilitate access to and persons or classes of persons to whom supporting certain volumes of API use. receipt of patients’ EHI. Patients have the fee applies; the circumstances in In practice, we expect that this means already effectively paid for their EHI, which the fee applies; and the amount that a Certified API Developer will offer either directly or through their of the fee, which for variable fees must a certain number of ‘‘free’’ API calls employers, health plans, and other include the specific variable(s) and based on the fact that, up to a certain entities that negotiate and purchase methodology(ies) that will be used to threshold, the Certified API Developer health care items and services on their calculate the fee. will not incur any material costs in behalf. We refer readers to the Fees Comments. Some commenters stated supporting certified API technology in Exception in the information blocking that usage-based fees may not be addition to the costs recovered for

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00119 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25760 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

deployment services. However, after service,’’ and are not meant to convey a certified API technology, the Condition this threshold is exceeded, we expect requirement or expectation that API of Certification covers its practices that the Certified API Developer will Technology Suppliers provide an app related to certified API technology only. impose usage-based costs commensurate store with application listing free of Conversely, this Condition of to the additional costs that the Certified charge. A few commenters requested Certification would not apply to any API Developer must incur to support that ONC clarify that EHR developers practices that do not involve certified certified API technology use at can charge value-add fees without API technology. However, health IT increasing volumes and scale. triggering the information blocking developers would need to be mindful of We expect that Certified API provision. A couple other commenters any applicable information blocking Developers will charge fees that are requested additional examples of what rules that may apply to their app store correlated to the incremental rising of constitutes a ‘‘value-added’’ service for practices given applicable facts and costs required to meet increased which an API Technology Supplier can circumstances. Regarding the request for demand. For example, if, at a certain charge fees to an API User. specific value-added fees that would not volume of API calls, the Certified API Response. We thank commenters for constitute information blocking, we Developer needed to deploy additional the feedback. We have finalized refer readers to the information blocking server capacity, the associated § 170.404(a)(3)(iv) as proposed, with the section (VIII) of this preamble. incremental cost of bringing an exception of updating terms based on additional server online could be passed the definitions finalized in § 170.404(c). (H) Request for Comment on on to the API Information Source Our final policy permits Certified API § 170.404(a)(3) because the certified API technology Developers to charge fees, including a We requested comment at 84 FR 7491 deployed on behalf of the API reasonable profit margin, to API Users on any additional specific ‘‘permitted Information Source was the subject of for value-added services related to fees’’ not addressed in our Proposed the higher usage. In this example, up certified API technology, so long as such Rule (84 FR 7491) that commenters felt until the point that the threshold is services are not necessary to efficiently API Technology Suppliers should be reached, the additional server capacity and effectively develop and deploy able to recover in order to assure a is not required, so the Certified API production-ready software that interacts reasonable return on investment. Developer would not be permitted to with certified API technology. We Furthermore, we requested comment on recover the costs associated with it. clarify that the value-added services whether it would be prudent to adopt Moreover, the additional server capacity need to be provided in connection with specific, or more granular, cost would support ongoing demand up to a and supplemental to the development, methodologies for the calculation of the certain additional volume, so the testing, and deployment of production- permitted fees. We encouraged Certified API Developer would not be ready software applications that interact commenters to consider, in particular, permitted to recover the costs of further with certified API technology. A fee is whether the approach we described additional server capacity until the permitted if it relates to a service that a would be administrable and existing capacity was exhausted. software developer can elect to purchase appropriately balance the need to from a Certified API Developer, but is ensure that stakeholders do not (G) Permitted Fee for Value-Added not required to purchase in order to encounter unnecessary costs and other Services develop and deploy production-ready special effort with the need to provide We proposed in 84 FR 7490 and 7491 apps for certified API technology. adequate assurance to API Technology in § 170.404(a)(3)(iv) to permit an API In response to comments for clarity, Suppliers, investors, and innovators that Technology Supplier to charge fees to we note that examples used to illustrate they will earn a reasonable return on API Users for value-added services when a fee would or would not qualify their investments in API technology. We supplied in connection with software as a ‘‘value-added service,’’ such as app welcomed comments on whether the that can interact with the API store listing, are demonstrative, but not approach adequately balances these technology. We also clarified in 84 FR required unless otherwise noted in the concerns and achieves our stated policy 7491 that a fee will only be permitted regulation text. Under this condition, goals. We also welcomed comments on if it relates to a service that an API User, we permit fees for services associated potential revisions or alternative such as a software developer, can elect with the listing and promotion of apps approaches. We encouraged detailed to purchase, but is not required to beyond basic application placement so comments that included, where purchase in order to develop and deploy long as the Certified API Developer possible, economic justifications for production-ready apps for API ensures that basic access and listing in suggested revisions or alternative technology. the app store is provided free of charge approaches. Comments. Several commenters (if an application developer depended Comments. Commenters suggested we supported our proposal to permit an API on such listing to efficiently and alter our approach to APIs so that it is Technology Supplier to charge fees to effectively develop and deploy tiered fee structure. They suggested that API Users for value-added services production-ready apps for use with ONC could establish categories where supplied in connection with software certified API technology). Fees charged the technology requirements designate that can interact with certified API for additional/specialized technical the fees: (1) A ‘‘no fee’’ category would technology. Some commenters support or promotion of the API User’s limit API Technology Suppliers from requested certain clarifications application beyond basic access and charging API Data Providers or API regarding our proposal. One commenter listing services would be examples of Users any fees for exchanging data in requested that we clarify within the permitted value-added services. We compliance with Federal requirements; discussion of value-added services, that caution health IT developers not to (2) an ‘‘at cost’’ category would allow references to ‘‘app stores’’ and ‘‘listing over-interpret the scope of this API Technology Suppliers to charge API processes’’ for software applications that Condition of Certification, which is Data Providers or API Users the cost of register to connect with the API focused on certified API technology. To interfacing APIs with a non-API technology are solely intended as the degree that a health IT developer Technology Supplier’s commercial examples to illustrate when a fee would administers an ‘‘app store’’ and offers technology; and (3) a ‘‘cost plus or would not qualify as a ‘‘value-added value-added services associated with reasonable profit’’ category would allow

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00120 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25761

API Technology Suppliers to charge API should view revenue sharing practices noted by the commenters Data Providers or API Users a arrangements as a type of market-based while enabling and supporting reasonable profit when conducting compensation that will ultimately innovation. legitimate custom API development or benefit innovation and competition. We also emphasize that a majority of creating custom apps. Conversely, one commenter stated that the EHI has been generated and Response. We appreciate the it is essential that API Technology recorded in the course of furnishing recommendation from commenters, but Suppliers be expressly prohibited from health care services paid with public we have not adopted a tiered fee conditioning access to API technology dollars through Federal programs, structure in the final rule because it on charging revenue-sharing or royalty including Medicare and Medicaid, or would require unnecessary specificity agreements to API Data Providers or API directly subsidized through the tax and prescribe a particular method that Users outside of actual usage costs preferences for employer-based could have unintended effects of incurred. The commenter noted this insurance. Yet, this EHI is not readily limiting the market’s evolution over rent-seeking behavior is anti- available where and when it is needed. time. We believe the current structure competitive in nature and can have a We believe the overwhelming benefits for prohibited and permitted fees allows significant impact on squelching any of publishing certified APIs that allow for the adequate cost recovery and new market entrants and allow existing EHI from such technology to be reasonable profit by Certified API health IT actors to prevent all the accessed, exchanged, and used without Developers while also establishing the positive outcomes that could arise from special effort far outweigh the potential guardrails around which API access can the ONC’s proposed rules. Some burden on Certified API Developers and be enabled without special effort. developers stated that the prohibition API Information Sources. Comments. Many commenters against health IT developers charging Comments. A few commenters expressed concerns related to the effect for work to update their code structure requested that ONC clarify whether API our proposals regarding API fees would is unreasonable, emphasizing that this is Data Suppliers would be allowed to have on innovation and business. important work that is necessary for recoup costs from API Users in light of Several commenters noted that the companies to be able to modernize their the information blocking provisions. A structure of permitted fees could have solutions as broader technologies few commenters expressed confusion unintended consequences that will evolve. that fees are addressed under the API ultimately work to impede innovation, Response. We appreciate these Condition and Maintenance of increase administrative burden, and comments, but disagree with Certification and information blocking. focus on cost recovery rather than commenters regarding the potential The commenters suggested that ONC creation of novel ways to improve data negative effect of the final permitted fee address fees in one consolidated access. structure on innovation. We also note section. Several developers stated that the that the value-added services permitted Response. We appreciate this proposed fee structure specifically fee does permit a direct relationship comment and refer readers to the works to sever business relationships between Certified API Developers and information blocking section of this between API Technology Providers and API Users. What is generally prohibited rule. We do not believe that a discussion API Users for anything other than and what we noted presented ‘‘special of fees should be consolidated in one ‘‘value added services’’ and effectively effort’’ in the Proposed Rule were section for a couple of reasons. First, the eliminates the ability for API Users to Certified API Developer practices that information blocking provision has a work directly with API Technology required an API Information Source to much broader reach than the Condition Suppliers to innovate and accelerate seek permission to use its own certified and Maintenance of Certification API development, and to achieve truly API technology from the Certified API requirements and regulates conduct of integrated and supported products Developer. health IT developers of certified Health throughout the product lifecycle. They We reiterate that complying with the IT Modules, health care providers, suggested that a better model would be requirements of this permitted fee and health information networks, and health one that gives API Data Providers rights the information blocking exception will information exchanges. The Condition to leverage APIs ‘‘without special generally not prevent an actor from and Maintenance of Certification effort,’’ while supporting the ability for making a reasonable profit in requirements only relate to conduct by API Technology Suppliers and API connection with the access, exchange, health IT developers of certified Health Users to voluntarily engage in direct or use of EHI. To be responsive to IT Modules. Second, the API Condition business relationships under mutually comments, we have added a provision of Certification covers a much narrower agreeable terms that are fair and in § 171.404(a)(3)(i)(A) to clarify this scope of potential fees, as the fees in equitable. Some developers stated that point. This final provision states that this section are specific to certified API the market should determine permitted certain permitted API fees technology only while fees in the fees. They stated that in order to (§ 170.404(a)(3)(ii) and information blocking section generally maintain a vigorously competitive § 170.404(a)(3)(iv)) may include fees relate to the access, exchange, or use of market, API Technology Suppliers must that result in a reasonable profit margin EHI regardless of the particular be adequately compensated for their in accordance with the Costs Exception technology used. work to create and deploy non-standard (§ 171.302). We believe that the We emphasize that we have finalized APIs and support expanding standards. allowance of reasonable profits is a provision in § 171.302(c) that if the They explained that without this necessary to incentivize innovation and actor is a health IT developer subject to compensation, there will be far fewer allow innovators to earn returns on the the Condition of Certification entrants into the certified health IT investments they have made to develop, requirements in § 170.402(a)(4) space and current participants will maintain, and update innovations that (Assurances), § 170.404 (API), or both, depart. ultimately improve health care delivery the actor must comply with all A couple of developers recommended and benefit patients. Our finalized requirements of such conditions for all that ONC allow revenue-sharing models approach to API fees strikes the practices and at all relevant times. for certain components of certified APIs. appropriate balance of addressing the Under this provision, health IT The commenters suggested that ONC rent-seeking and exclusionary pricing developers of certified Health IT

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00121 Fmt 4701 Sfmt 4700 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 covered functions of the covered entity. Response. We appreciate the feedback Certification requirements may not HIPAA does not require a covered entity from commenters. Based on the general charge certain types of fees and are (e.g., API Information Source) or its support, we have finalized in subject to more specific cost business associate (e.g., API Technology § 170.404(a)(4)(i)(A) that a Certified API accountability provisions than apply Supplier) to enter into a business Developer must provide certified API generally under the Costs Exception. We associate agreement with an app technology to API Information Sources explain in the Costs Exception that a developer that does not create, receive, on terms that are no less favorable than failure of developers to comply with maintain, or transmit ePHI on behalf of it provides to itself and its own these additional requirements would or for the benefit of the covered entity customers, suppliers, partners, and impose impediments to consumer and (whether directly or through another other persons with whom it has a other stakeholder access to EHI without business associate). However, if the app business relationship. Additionally, we special effort and would be suspect was developed to create, receive, have finalized in § 170.404(a)(4)(i)(B) under the information blocking maintain, or transmit ePHI on behalf of that the terms on which a Certified API provision. the covered entity (API Information Developer provides certified API Source), or was provided by or on behalf technology must be based on objective vi. Openness and Pro-Competitive of the covered entity (directly or and verifiable criteria that are uniformly Conditions through its API Technology Supplier, applied to all substantially similar or We proposed in 84 FR 7595 in acting as the covered entity’s business similarly situated classes of persons and § 170.404(a)(4) that an API Technology associate), then a business associate requests. Furthermore, we have Supplier must grant API Data Providers agreement would be required.106 In such finalized in § 170.404(a)(4)(i)(C) that a the sole authority and autonomy to cases, API Information Sources have the Certified API Developer must not offer permit API Users to interact with the ability to conduct whatever ‘‘vetting’’ different terms or services on the basis API technology deployed by the API they deem necessary of entities (e.g., of: Competition or potential for Data Provider in a non-discriminatory app developers) that would be their competition and revenue or other value manner; provide all reasonably business associates under the HIPAA the other party receiving the services necessary support and other services to Rules before granting access and use of may receive from using the certified API enable the effective development, EHI to the entities. In this regard, technology. We note that we slightly deployment, and use of API technology covered entities must conduct necessary modified the finalized requirements in by API Data Providers and its API Users vetting in order to comply with the § 170.404(a)(4)(i) based on the revised to access, exchange, and use EHI in HIPAA Security Rule. definitions finalized in § 170.404(c). We production environments; not impose For third-party applications chosen by clarify that this rule does not prohibit collateral terms or agreements that individuals to facilitate their access to Certified API Developers from forming could interfere with the use of API their EHI held by actors, there would business relationships with API Users. technology; and provide reasonable not be a need for a BAA as discussed To the degree that a Certified API notice prior to making changes to its above. There would also generally not Developer seeks to charge an API User API technology or terms and conditions. be a need for ‘‘vetting’’ on security for particular services associated with Comments. The majority of grounds and such vetting actions its certified API technology, it would commenters supported the proposed otherwise would be an interference. need to do so pursuant to the ‘‘value- openness and pro-competitive Please see our discussion of ‘‘vetting’’ in added services’’ permitted fee. conditions. Several commenters the ‘‘Interference Versus Education Comments. Commenters requested requested clarification about API Data When an Individual Chooses clarification about how ‘‘the sole Providers’ rights and responsibilities Technology to Facilitate Access’’ authority and autonomy to unilaterally when providing access to an application discussion in the Information Blocking permit connections to their health IT of a patient’s choice. Specifically, they section of the preamble (Section VIII). through certified API technology’’ sought clarification on whether they can We also refer readers to our discussion applies to application registration. vet, deny, or limit access by of ‘‘vetting’’ versus verifying an app Specifically, they asked whether API applications that are using the API developer’s authenticity under the API Users are required to register once with technology inappropriately. Another Condition of Certification later in this the API Technology Supplier, or several commenter proposed that app section of the preamble. times with each instance of API developers be required to obtain a Comments. Several commenters technology deployed by API Data business associate agreement (BAA) requested clarification about the types Providers. with providers prior to the application of business relationships permitted Response. We appreciate the feedback developer gaining access to a patient’s between API Technology Suppliers and from commenters. We refer commenters EHI on behalf of a patient. API Users and requested examples of to § 170.315(g)(10)(iii) for the Response. We appreciate the feedback permitted activities and responsibilities application registration requirements for from commenters. Based on the support under each role. These comments Health IT Modules presented for from commenters, we have finalized expressed concern about prohibiting certification. In general, we do not that a Certified API Developer must API Technology Suppliers from being prescribe the registration paradigm that grant API Information Sources the able to form direct relationships with Certified API Developers create for independent ability to permit API Users API Users for the purpose of joint themselves and their customers. Thus, to interact with the certified API development and commercialization of in different scenarios, an API User may technology deployed by the API their products. Other commenters only be required to register once with an Information Source in § 170.404(a)(4). requested clarifications about Certified API Developer, or several Under the HIPAA Privacy Rule, a relationships that existed prior to the times with each instance of a business associate relationship exists if involvement of an API Data Provider. § 170.315(g)(10)-certified Health IT an entity creates, receives, maintains, or Module deployed by an API Information transmits ePHI on behalf of a covered 106 https://www.hhs.gov/hipaa/for-professionals/ Source. When it comes to apps that entity (directly or through another privacy/guidance/access-right-health-apps-apis/ focus on the ‘‘launch-ehr’’ ‘‘SMART on business associate) to carry out the index.html. FHIR Core Capability’’ from the

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00122 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25763

implementation specification adopted specific testing or certification authenticity of application developers, in 170.215(a)(3), such an approach will requirements’’ would include limited to a duration of no greater than be tightly integrated with the Health IT preconditions like registering and five business days of receipt of a request Modules deployed by API Information testing in a testing environment prior to to register an application developer’s Sources. Because of the tight integration moving to production, and meeting software with the API technology. We between API Information Sources and Certified API Developer-created noted the authenticity verification Health IT Modules, registration for these certification requirements. process would need to be objective, apps could more often fall to the API Comments. Commenters expressed apply to the application developer and Information Source. When it comes to concern about software applications not their software, and be the same for apps that enable patient access, maintaining compatibility when all application developers. We sought registration could be handled centrally upgrading API technology, and comment in 84 FR 7486 on factors that by Certified API Developers or in a highlighted the importance of adopting would enable registration with minimal distributed manner with each API backwards-compatible standards. barriers, including options and Information Source, especially in cases Response. We appreciate the feedback associated trade-offs. Additionally, we where API Information Sources take full from commenters. We share the concern sought comment at 84 FR 7486 on other responsibility for administering their expressed by commenters. We timing considerations for application § 170.315(g)(10)-certified Health IT specifically consider features of developer authenticity verification. Modules. standards like backwards compatibility Comments. Commenters asked for a Regarding ‘‘the sole authority and when proposing and finalizing testing longer timeframe to complete the autonomy to unilaterally permit and certification requirements for the authenticity verification process of connections to their health IT through Program. As mentioned above, we have application developers. Some certified API technology,’’ we have finalized the standard adopted in commenters asked to extend the finalized in 170.404(a)(4)(ii)(A) that § 170.215(a)(1) as the base standard for authenticity verification timeframe to Certified API Developer must have and, the certification criterion adopted in ten business days. Commenters upon request, must grant to API § 170.315(g)(10) Standardized API for suggested adding ‘‘and any receipt of Information Sources and API Users all Patient and Population Services. We any additional requested information rights that may be reasonably necessary note that the standard adopted in needed in order to verify the developer’s to (1) access and use certified API § 170.215(a)(1) includes many FHIR authenticity’’ to ‘‘within five business technology in a production resources that need to retain their days of receipt of an application environment; (2) develop products and compatibility over time, which will help developer’s request to register their services that are designed to interact as upgrades to newer standards occur. software application with the API with the Certified API Developer’s API Additionally, we have finalized in technology provider’s authorization technology; and (3) market, offer, and § 170.404(a)(4)(iii) the service and server.’’ distribute products and services support obligations required by a Commenters suggested various associated with the Certified API Certified API Developer, including the methods for verifying the authenticity of Developer’s certified API technology. requirements that a Certified API application developers and Additionally, we have finalized in Developer must provide all support and applications, including by proposing § 170.404(a)(4)(ii)(B) that a Certified API other services reasonably necessary to required registration information, or required attestation to model privacy Developer must not condition any of the enable the effective development, rights described in § 170.404(a)(4)(ii)(A) guidelines or industry best practices. deployment, and use of certified API on: (1) Receiving a fee, including but not Other commenters suggested various technology by API Information Sources limited to a license fee, royalty, or approaches for verifying application and API Users in production revenue-sharing arrangement; (2) developers and applications, including environments. These include agreeing to not compete; (3) agreeing to by working with industry to establish a requirements for changes and updates to deal exclusively with the Certified API verification body, privacy and security API technology finalized in Developer; (4) Obtaining additional trust or certification framework, and § 170.404(a)(4)(iii)(A), where Certified services that are not related to the other more detailed recommendations. API Developers must make reasonable certified API technology; (5) sharing Several commenters suggested requiring efforts to maintain the compatibility of intellectual property with the Certified application developers to attest to API Developer; (6) meeting any Certified its certified API technology and to providing a model privacy notice to API Developer-specific testing or otherwise avoid disrupting the use of patients. Commenters suggested certification requirements; and (7) certified API technology in production mandating terms and conditions and providing the Certified API Developer or environments, and requirements for consent requirements as part of the technology with reciprocal access to changes to terms and conditions registration process. application data. We slightly modified finalized in § 170.404(a)(4)(iii)(B), where Response. We appreciate feedback the conditions from the Proposed Rule Certified API Developers must provide from commenters. To improve the for what we finalized in notice and reasonable opportunity for organization of these Condition and § 170.404(a)(4)(ii)(B) for clarity, and its API Information Source customers Maintenance of Certification amended terms to the revised and registered API Users to update their requirements, we moved the definitions finalized in § 170.404(c). applications to preserve compatibility requirements proposed in Additionally, we clarify that while with API technology and to comply § 170.404(a)(2)(ii)(C) to the finalized Certified API Developers are not with applicable terms and conditions. § 170.404(b)(1)(i) under the combined permitted to condition the rights e. API Maintenance of Certification § 170.404(b)(1), ‘‘Authenticity described in § 170.404(a)(4)(ii)(A) on Requirements verification and registration for receiving a fee, Certified API Developers production use.’’ We accept are permitted to charge fees compliant i. Authenticity Verification commenters’ requests to establish a with the permitted fees described in We proposed in 84 FR 7486 in longer time period for this permitted, § 170.404(a)(3). We also clarify that § 170.404(a)(2)(ii)(C) to permit API but not required, process to verify the ‘‘meeting any Certified API Developer- Technology Suppliers to verify the authenticity of application developers

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00123 Fmt 4701 Sfmt 4700 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 API Information Source. This could should have the sole authority to application for use with the Certified include a warning that an application publish their endpoints. API Developer’s certified API attempting to access data on behalf of a Response. We thank commenters on technology. We have adopted ten patient is untrusted. We refer their feedback on our proposal requiring business days as the timeframe by commenters to the information blocking a Certified API Developer to publish which this process would need to be provisions in section VIII for additional service base URLs for all of its completed and as a result find it information about providing warnings customers. The public availability and unnecessary to add the text to patients. easy accessibility of this information is contemplating a back and forth between a central necessity to assuring the use of the Certified API Developer and API ii. Registration for Production Use certified API technology without special User. We recommend that Certified API We proposed in 84 FR 7494 in effort, particularly for patient-facing Developers who elect to institute a § 170.404(b)(1) to require API applications. We agree with the points verification process implement a Technology Suppliers to register and made by commenters on the need for a process that is as automated as possible enable all applications for production single or multiple publicly available to ensure they remain in compliance use within one business day of repositories that maintain provider with our final policy. Given that we completing its verification of an service base URLs. We encourage combined authenticity verification and application developer’s authenticity. industry to coalesce around the registration for production use in one Comments. Commenters generally development of a public resource from requirement finalized in § 170.404(b)(1), supported the proposed registration which all stakeholders could benefit. we reduced the scope of these requirements. Most commenters We believe this would help scale and requirements to Certified API suggested extending the registration enhance the ease with which service Developers with a Health IT Module timeframe to five business days. base URLs could be obtained and used. certified to the certification criterion Response. We appreciate the feedback While we support the concept of adopted in § 170.315(g)(10) to remain from commenters. We have reorganized repositories for service base URLs, we do not believe that creating a consistent with the scope of this section of the regulation text for requirement under the Program is the applicability of registration for readability by combining ‘‘Authenticity appropriate mechanism to foster production use from the Proposed Rule. verification’’ with ‘‘Registration for We also note that authenticity industry support around this concept at production use’’ under the heading verifications would likely occur more this time. ‘‘Authenticity verification and frequently for patient-facing We acknowledge that stakeholders registration for production use’’ in applications that are not sponsored by expressed concern about Certified API § 170.404(b)(1). We accepted the API Information Sources. We anticipate Developers publishing client service recommendation from commenters to that an API Information Source (e.g., a base URLs and revised our approach to extend the registration timeline and health care organization) that is a focus on service base URLs necessary to have finalized in § 170.404(b)(2)(ii) a HIPAA covered entity would vet and support patient access. We anticipate enter into a HIPAA business associate requirement for Certified API that many services related to certified agreement with a provider-facing Developers with Health IT Modules API technology will be developed and application developer prior to using the certified to the certification criterion made available and do not believe it is application within their internal finalized in § 170.315(g)(10) to register appropriate to burden Certified API technical enterprise. In comparison, a and enable all applications for Developers with publishing all service patient-facing application is likely to production use within five business base URLs for these services for all of connect to an API Information Source’s days of completing its verification of an their customers. We considered several resource server using a public service application developer’s authenticity options, including requiring Certified base URL of a § 170.315(g)(10)-certified pursuant to requirements finalized in API Developers to publish service base Health IT Module in service to the § 170.404(b)(1)(i). URLs for only those API Information patient’s HIPAA Privacy Rule right of iii. Service Base URL Publication Source customers for whom they access (45 CFR 164.524) or based on a manage/host an authorization server patient’s HIPAA authorization (45 CFR We proposed in 84 FR 7595 in centrally. However, we determined that 164.508) without first establishing a § 170.404(b)(2) to require an API alternative options would not meet our relationship with the API Information Technology Supplier to support the policy interests and would lead to Source. For patient-facing applications, publication of service base URLs for all unnecessarily complex and burdensome and to the comments suggesting we of its customers, and make such approaches and would not achieve the require various modes of attestation to information publicly available, in a Cures Act’s goals of enabling EHI to be privacy guidelines in such contexts, we computable format, at no charge. accessed, exchanged, and used without refer commenters to the information Comments. A majority of commenters special effort. Additionally, we blocking provisions in section VIII for a supported the proposal requiring API considered requiring that all Certified discussion of permitted behaviors Technology Suppliers to publish service API Developers with certified API regarding privacy attestations. base URLs for all of its customers. technology, that is, health IT developers Comments. Commenters suggested Several commenters recommended the with a Health IT Module certified to including a warning by the API Data creation of a single, publicly available § 170.315(g)(7) through (10), meet this Provider that the application developer repository to maintain all client requirement. However, we determined selected by the patient or patient- endpoints. Some stakeholders that it would be more beneficial to allow designee is untrusted. recommended ONC require additional health IT developers to focus energy and Response. We thank commenters for facility information be published with resources on upgrading their technology their feedback. An API Information the service base URL. Commenters who to the certification criterion finalized in Source would not be prohibited from disagreed with this proposal stated that § 170.315(g)(10). Therefore, we have showing a warning to patients as part of health IT developers cannot publish finalized in § 170.404(b)(2) that a the patient authorization for an client information without their Certified API Developer must publish application to receive their EHI from an consent, and that API Data Providers service base URLs for all Health IT

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00124 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25765

Modules certified to § 170.315(g)(10) APIs would be made available in a requirements finalized in § 170.404(a). that can be used by patients to access timely manner, we have retained a 24 This additional time provides Certified their EHI. We further require that a month compliance timeline, which will API Developers with Health IT Modules Certified API Developer must publicly start from the publication date of the already certified to § 170.315(g)(7), (8), publish service base URLs for all final rule. At that point, it will be or (9) a total of eight months from the customers in a machine-readable format approximately five years since the Cures final rule’s publication to update their at no charge regardless of whether the Act’s passage and we believe its policies and documentation to comply Health IT Modules certified to implementation should not be delayed with the requirements finalized in § 170.315(g)(10) are centrally managed any further. We also remind § 170.404(a). We did not allow a longer by the Certified API Developer or locally stakeholders that this is within 24 time period than six months in deployed by an API Information Source. months of this rule’s publication § 170.404(b)(4) due to the fact that we We note our focus for this criterion on compliance date for supplying all API have finalized our proposal in ‘‘service base URLs for Health IT Information Sources with Health IT § 170.404(b)(3) to require Certified API Modules certified to § 170.315(g)(10) Modules certified to § 170.315(g)(10) Developers with Health IT Modules that can be used by patients to access enables Certified API Developers (based previously certified to the certification their EHI.’’ We believe that Certified API on their client base and IT architecture) criterion in 170.315(g)(8) to provide Developers will have adequate to determine the most appropriate § 170.315(g)(10)-certified APIs to API relationships with API Information timeline for development, testing, Information Sources within 24 months Sources in the process of providing certification, and product release cycles. of final rule’s publication date. These Health IT Modules certified to Thus, we have finalized in policies finalized in § 170.404(b)(4) § 170.315(g)(10) and will be able to § 170.404(b)(3) that a Certified API provide API Information Sources with collect and publish all service base Developer with certified API technology Health IT Modules certified to URLs that support patient access on previously certified to the certification § 170.315(g)(8) with 18 months of behalf of their customers. Furthermore, criterion at § 170.315(g)(8) must provide updated documentation before the new we note that API Information Sources all API Information Sources with such requirements finalized in § 170.404(b)(3) would be obligated to share such service certified API technology deployed with become effective. Setting a more base URLs with Certified API certified API technology certified to the delayed compliance date than the one Developers to avoid violating the certification criterion in § 170.315(g)(10) finalized in § 170.404(b)(4) would have Technical Interference Information within 24 months of the publication unreasonably delayed and ultimately Blocking provisions as discussed further date of the final rule. diminished the benefits of the Program in section VIII. Certified API Developers v. Compliance for Existing Certified API requirements we have finalized in this must make available appropriately Technology rule. In summary, we finalized in scoped service base URLs that can be § 170.404(b)(4) that Certified API We proposed in 84 FR 7486 that API used by patients to access their EHI for Developers with Health IT Modules Technology Suppliers with Health IT Health IT Modules certified to certified to § 170.315(g)(7), (8), or (9) Modules certified to § 170.315(g)(7), (8), § 170.315(g)(10). must comply with § 170.404(a) no later or (9) must revise their existing API than six months after this final rule is iv. Providing (g)(10)-Certified APIs to documentation within six months from published in the Federal Register, API Data Providers the final rule’s effective date. We proposed in 84 FR 7494 in Comments. Some commenters including by revising their existing § 170.404(b)(3) that an API Technology supported the requirement to revise business and technical API Supplier with Health IT Modules existing API documentation within six documentation and making such previously certified to § 170.315(g)(8) months of the final rule’s effective date. documentation available via a publicly must provide all API Data Providers Others requested more time to allow accessible hyperlink that allows any Health IT Modules certified to documentation and all other websites to person to directly access the § 170.315(g)(10) within 24 months of come into alignment before enforcement information without any preconditions this final rule’s effective date. of this Condition of Certification or additional steps. Comments. The majority of comments requirement. One commenter requested 5. Real World Testing received urged ONC to extend the clarification on which documentation timeline beyond the 24 months requires revision within the six-month The Cures Act requires, as Condition proposed. Many commenters requested timeframe. and Maintenance of Certification separate timelines for developers and Response. In order to align the API requirements under the Program, that providers. Several commenters Condition of Certification requirements health IT developers successfully test recommended 36 months. Some policies, we have broadened the scope the real world use of the technology for 107 commenters offered alternatives ideas of the provision finalized in interoperability in the type of setting for timelines, including a stepwise § 170.404(b)(4) to apply to all API in which such technology would be approach, or ONC only determining Condition of Certification requirements marketed. As discussed in the Proposed technical timelines, and allowing CMS finalized in § 170.404(a), including Rule (84 FR 7495), the objective of real to cover provider timelines. Only a few § 170.404(a)(1) through (4). Given the world testing is to verify the extent to commenters encouraged faster adoption. change of scope, we renamed this which certified health IT deployed in Response. We appreciate commenters’ section to ‘‘Compliance for existing production contexts continues to feedback on our proposal. Given the certified API technology.’’ We demonstrate conformance to the full reduced scope of the overall updates considered commenters’ request for scope of applicable certification criteria required by this final rule, our belief more time, but given the already and functions with the intended use that the industry is well-prepared to delayed effective date of Part 170 we cases as part of the overall maintenance meet this certification criterion’s believed the proposed time of six 107 Defined in statute in section 3000 of the Public requirements once the final rule is months sufficient to enable Certified Health Service Act (as modified by section 4003 of published, and the Cure’s Act API Developers to become compliant the Cures Act) and defined in regulation at 45 CFR expectation that secure, standards-based with the Condition of Certification 170.102.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00125 Fmt 4701 Sfmt 4700 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 plan and method of execution. One environment (or ‘‘developer sandbox’’) testing should assess that the certified commenter recommended that ONC and require the use of a testing platform health IT is meeting the intended use provide more guidance around what and test scripts that validate the ability case(s) of the certification criteria to care settings must be covered by test of the API to meet the underlying which it is certified within the plans, and establish a minimum number requirements for the version of FHIR® to workflows, system architectures, and of settings and test sites that are which Health IT Module(s) are certified, type(s) of care setting(s) for which it is applicable for certified Health IT any applicable FHIR® profiles, and marketed (advertised, promoted, or Modules. implementation guides. sold). Response. In response to comments Response. As discussed in the For the purpose of this Condition of requesting additional guidance around Proposed Rule (84 FR 7496), we believe Certification requirement, in expectations and acceptable methods for health IT developers are in the best § 170.405(a), we proposed (84 FR 7495) real world testing, we provide below position to design and facilitate that successful real world testing means: additional discussion, explanation, and implementation of real world testing • The certified health IT continues to illustrative examples. At this time, we approaches that balance the burdens of be compliant to the full scope of the have decided not to establish a this statutory requirement with its certification criteria to which it is minimum number of settings or intended assurances that certified health certified, including the required minimum percentage or fraction of IT as deployed in the types of clinical technical standards and vocabulary production instances of the developer’s settings for which it is marketed codes sets; applicable certified Health IT Modules (advertised, promoted, or sold) • The certified health IT is that must be included in the developer’s continues to meet the Program exchanging electronic health annual real world testing activities. requirements, including but not limited information in the care and practice While health IT developers are not to interoperability performance, settings for which it is intended for use; required to test their certified health IT applicable under the certification it and in each and every setting in which it is holds. While we recognize that testing • Electronic health information is intended for use, we would expect a environments can be useful for a variety received by and used in the certified developer’s real world testing plan to of purposes, and would not generally health IT. address each type of clinical setting for discourage developers from offering test To fully implement the real world which their health IT is marketed. platforms specific to their products or testing Condition of Certification Developers must address in their real participating in the development and requirement, we proposed Maintenance world testing plans their choice of care use of open-source testing platforms, the of Certification requirements that would and/or practice settings to test and purpose of real world testing is to require health IT developers to submit provide a justification for their chosen demonstrate that Health IT Modules publicly available prospective annual approach. We also remind developers continue to perform in conformance to real world testing plans and that although we are not requiring their certification when and as they are retrospective annual real world testing testing in every setting for which the deployed in production environments results for the certification criteria certified health IT is marketed, we supporting the types of clinical settings focused on interoperability to which encourage real world testing in as many for which the Health IT Modules are each of its Health IT Modules is specific settings as feasible within each marketed. Thus, real patient data and certified (84 FR 7496). type of setting for which the certified real production environments will in Comments. Comments on the whole health IT is marketed. most cases best meet that need and support the establishment of a robust Comments. Some commenters should be first considered when process of real world testing. Several expressed a view that there has been too developing real world testing plans. commenters expressed concerns much focus on the export capabilities of Mandating creation or use of testing regarding the quality and usability of systems and not enough attention paid environments for real world testing health IT. Specifically, commenters to providers being able to ingest data would compete for developers’ time and indicated that issues related to health IT received in standardized formats—such effort with the focus on innovative ways usability may be contributing to as the Continuity of Care Document to best serve the purpose of the real clinician burn-out or impacting patient (CCD) standard—from other providers, world testing Conditions and safety, noting that they therefore including other providers who use the Maintenance of Certification strongly support the inclusion of robust same developer’s Health IT Modules requirements at the least burden on real world testing requirements. certified to produce exports in their customers and end users. We have Response. We appreciate all conformance with the standards. therefore not required health IT comments, and have finalized real Response. The interoperability developers to provide a testing world testing Condition and focused criteria listed in § 170.405(a) environment (or ‘‘developer sandbox’’) Maintenance of Certification include required capabilities for nor have we required the use of a testing requirements in § 170.405(a) and (b) as receiving and incorporating data in platform or test scripts in order to proposed, with minor adjustments to accordance with referenced standards satisfy real world testing Condition and due dates and clarifications of several and implementation specifications Maintenance of Certification points in response to specific comments adopted by the Secretary in part 170 requirements. as discussed below. subpart B. We believe this appropriately Comments. Several commenters Comments. Commenters indicated aligns requirements for real world requested that ONC be mindful of the that additional clarification of the real testing of Health IT Modules’ ability to burdens this testing could place on world testing requirements would make ingest data with the capabilities their health care providers in terms of time these Condition and Maintenance of certifications address. and cost and take all necessary steps to Certification requirements less Comments. A commenter minimize such burdens. Commenters burdensome to implement. These recommended that, for real world specifically stated real world testing commenters specifically sought testing of Health IT Modules certified to would require significant work by additional guidance around the the API criterion, the final rule require providers for whom, in the commenters’ expectations for an appropriate testing health IT developers to provide a testing stated view, there is no incentive to

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00126 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25767

participate in real world testing. Some In response to the recommendation Comments. A commenter expressed commenters specifically recommended that developers be allowed to concern that health care providers might that HHS incentivize providers to compensate their customers for be unwilling to use health IT that had participate, stating that without participating in the developer’s real not yet been certified, and that this providers’ participation, this proposal world testing activities, we note that could make real world testing of Health would become an untenable nothing in our proposed or finalized IT Modules prior to certification requirement. One commenter requested policy under part 170 would prohibit impractical. HHS clarify whether a developer would that. In the event a developer concludes Response. In our Proposed Rule (84 be permitted to compensate its that its real world testing approach FR 7429), we proposed in § 170.405(a) customers for the time the customer imposes on its customers directly to limit the applicability of this spends supporting the developer’s real participating in real world testing Condition of Certification to health IT world testing activities. activities a burden that the developer developers with Health IT Modules that Response. We thank commenters for would like to offset for those customers, are certified to one or more 2015 Edition their feedback noting the potential for we would not discourage the developer certification criteria focused on health IT developers’ real world testing from considering whether there may be interoperability and data exchange. We activities to impose burden on opportunities within the bounds of also proposed that the real world testing providers. We do appreciate the other applicable laws or regulations for Condition of Certification would be met importance of recognizing that developers of certified health IT to offer through meeting the real world testing providers engage directly and actively customers some types of burden- Maintenance of Certification requirements in § 170.405(b). We have in various types of activities supporting offsetting compensation or other finalized this proposal as proposed. advancement of health IT. The fact that incentive for real world testing Thus, the real world testing Condition many of these activities could be participation. Analysis, interpretation, and Maintenance of Certification included in robust real world testing or changes to such other law or requirements do not mandate testing regimes suggests that we should provide regulation is outside the scope of this real world use of a Health IT Module in developers with extensive flexibility to particular rulemaking action. Moreover, actual production environments before develop innovative real world testing outside the rulemaking process, it is certified. plans. We have therefore built into our developers should be aware that ONC is real world testing policy flexibility that not in a position to provide general a. Unit of Analysis at Which Testing offers the developer a substantial guidance on Federal laws specific to Requirements Apply compensation arrangements or advice opportunity to design real world testing Comments. One commenter requested specific to any particular circumstances approaches that minimize burden and confirmation if real world testing is fully optimize value of the real world or contemplated conduct related to required per CHPL listing, per product, testing activities and results to current developers compensating providers for or per company. and prospective customers. We do not participating in developers’ real world Response. The real world testing believe that HHS incentives to providers testing activities. However, if developers Condition and Maintenance of participating in real world testing would or providers may be contemplating a Certification requirements apply to each be the most effective means of potential compensation arrangement developer that has at least one Health IT alleviating burdens on health care related to offsetting providers’ cost or Module certified to at least one of the providers specifically attributable to burden of engagement in developers’ interoperability and exchange focused developers’ real world testing activities. real world testing, we offer as a point of criteria listed in § 170.405(a), because Rather, the flexibility of our policy information that one publicly stated Condition and Maintenance of allows for, and encourages, developers purpose of the HHS Office of the Certification requirements apply to the to approach real world testing in an Inspector General advisory opinion developer of certified health IT. innovative mode so that they can process is to provide meaningful advice However, each developer of certified maximize efficiency and minimize about of the applicability of the anti- health IT to which the real world testing burden of real world testing for both the kickback statute or other OIG sanction Condition and Maintenance of developer and its customers. A wide statutes in specific factual situations.108 Certification requirements apply must range of practical strategies are available Comments. One commenter expressed conduct real world testing for each for developers to potentially consider in concern that developers with small criterion within the scope of real world creating such optimized solutions for customer bases will have smaller pools testing (§ 170.405(a)) to which each real world testing of their specific health of participants willing to undergo a developer presents for certification a IT with their particular customer base. lengthy process which will require Health IT Module that is part of a health Examples of this range of practical significant resources and suggested IT product to be listed on the CHPL are strategies include, but are not developers submit results from a more certified. A health IT developer with necessarily limited to: Avoiding some limited scope of testing only every three multiple products that are listed on the activities that satisfy only the real world years. CHPL and that include one or more testing Maintenance of Certification Response. We reiterate that the policy Health IT Module(s) certified to one or requirements by including in its overall we have finalized includes substantial more of the criteria listed in § 170.405(a) real world testing plans the testing flexibility for developers to assess how need only submit one real world testing typically associated with confirming to meet the real world testing Condition plan, and one real world testing results functionality of new installations and and Maintenance of Certification report, for any given annual cycle of real upgrades of their software; and requirements in a way that world testing, but the real world testing innovating methods of measuring appropriately minimizes burden on the plan and results report must address products’ performance in real time use current users of their certified health IT. each of the developer’s products that is through system metadata and/or listed on the CHPL. Health IT 108 For more information about HHS Office of the feedback from health information Inspector General advisory opinions and advisory developers with multiple health IT networks and other exchange partners of opinion process, please visit: https://oig.hhs.gov/ products that may include the same their customers. compliance/advisory-opinions/index.asp. Health IT Module(s) certified to one or

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00127 Fmt 4701 Sfmt 4700 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) that required testing should be limited industry have benefit of experience and have discretion to design their real to Health IT Modules certified to one or innovation in real world testing. Thus, world testing plans in a way that more of the certification criteria listed in the finalized list of criteria to which real efficiently tests a combination of § 170.405(a) as proposed. world testing requirements apply products that include Health IT Response. We appreciate all feedback (§ 170.405(a)) does not include the Modules certified criteria listed in received. The list of criteria to which patient health information capture § 170.405(a) so long as testing plans and real world testing Condition and criterion in § 170.315(e)(3). results are traceable to specific certified Maintenance of Certification Comments. A few commenters Health IT Modules and each criterion to requirements apply is finalized in suggested expanding the scope of real which the Health IT Module(s) are § 170.405(a) as proposed. world testing requirements to include certified, and address the types of Comments. We received one comment the proposed ‘‘EHI export’’ criterion in settings for which the products are supporting and two comments opposing § 170.315(b)(10). marketed. Because the purpose of real the addition of patient health Response. We appreciate the world testing is to test health IT information capture criterion in confirmation that commenters products as they are deployed in § 170.315(e)(3) to the scope of real world supported inclusion of the ‘‘EHI export’’ production, developers of health IT testing. One commenter specifically criterion in § 170.315(b)(10) alongside products deployed through the cloud recommended against including the the rest of the care coordination criteria who offer their products for multiple patient health information capture in § 170.315(b). We have finalized the types of clinical settings will be criterion in § 170.315(e)(3) in real world criteria listed in § 170.405(a) including, required to test the same capability for testing because of the significant as proposed, all criteria within those different types of settings even if variability in how health IT certified to § 170.315(b). it uses a single instance of the deployed this criterion is implemented. They Comments. One commenter expressed capability to serve all of those types of stated that this variability in the real an opinion that the initial scope of settings. world could make cross-implementation criteria is more expansive than the comparisons difficult, and stated that commenter would suggest for an b. Applicability of Real World Testing testing for this criterion could present a introductory set, and asked that fewer Condition and Maintenance of particular challenge based on difficulty criteria be required for the initial rollout Certification Requirements they anticipated would be encountered of real world testing, delaying We proposed (84 FR 7495) to limit the in securing needed engagement from application of the requirement to more applicability of the real world testing patients as well as the exchange interoperability focused criteria until Condition of Certification requirement partners who would presumably receive experience has been amassed with real to health IT developers with Health IT the data as a result of the patient using world testing for a narrower selection of Modules certified to one or more of the the ‘‘transmit’’ functionality. criteria than we had proposed. certification criteria focused on Commenters opposed to addition of this Response. Noting that the majority of interoperability and data exchange or criterion to the real world testing comments received were supportive of the scope as proposed, we also balance availability listed in (then-proposed) Condition and Maintenance of suggestions such as that offered by this § 170.405(a): Certification requirements also stated • The care coordination criteria in this addition would add cost to the commenter against the Program’s needs § 170.315(b); developer which would then flow down and the purpose of the real world testing • The clinical quality measures to end users and be burdensome to Condition and Maintenance of (CQMs) criteria in § 170.315(c)(1) clinician practices. Certification requirements. We do not through (c)(3); Response. On balance, the comments believe it would be in the best interest • The ‘‘view, download, and transmit received do not support expansion of of the Program or the health care to 3rd party’’ criterion in § 170.315(e)(1); the scope of real world testing providers and patients who rely on • The public health criteria in requirements to include the patient certified health IT to meet their needs § 170.315(f); health information capture criterion in for interoperable health IT to narrow the • The application programming § 170.315(e)(3) at this time. In applicability of the real world testing interface criteria in § 170.315(g)(7) developing the proposed list of criteria Condition and Maintenance of through (g)(10); and to which real world testing Condition Certification requirements further than • The transport methods and other and Maintenance of Certification we proposed. We have, therefore, protocols criteria in § 170.315(h). requirements would apply, we finalized the criteria listed in We solicited comment on whether to concluded an initial focus on those § 170.405(a) as proposed. also include the ‘‘patient health particular criteria would strike an Comments. Some commenters information capture’’ certification appropriate balance between the advocated expanding the scope of the criteria in § 170.315(e)(3), including the magnitude of the challenge represented real world testing requirement to value of real world testing these by the new real world testing include select functionally-based functionalities compared to the benefit requirements and the potential benefits ‘‘clinical’’ criteria within § 170.315(a) for interoperability and exchange (84 FR of their broader application. The that are included in the base EHR 7496). We also solicited comment on concerns raised by the commenters definition. whether any other 2015 Edition recommending against adding the Response. As explained in the certification criteria should be included patient health information capture Proposed Rule (84 FR 7495), we did not or removed from the applicability list criterion in § 170.315(e)(3) to the scope propose to include in the scope of real (to be codified at 170.405(a)) for this of real world testing requirements at this world testing functionally-based Condition of Certification requirement. time, combined with other comments criteria, administrative criteria, or other Comments. The vast majority of more generally recommending against a criteria that do not focus on commenters addressing this proposal broader scope at this time, tend to interoperability and exchange or were in support of the specific criteria support the conclusion that the scope availability of data. The ‘‘clinical’’ proposed to be within the scope of real we proposed strikes an appropriately certification criteria in § 170.315(a) were world testing and expressed agreement practical balance until we and the noted in the Proposed Rule as an

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00128 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25769

example of criteria not proposed § 170.405(a) require exporting but do • The care and practice setting(s) that because they require only that the not require receipt and use of electronic will be tested for real world health IT enable the provider to record, health information by the certified interoperability, including conformance change, and access specific types of data health IT. to the full scope of the certification within the Health IT Module being Response. We appreciate commenters’ criteria requirements, and an certified (or within a product that bringing to our attention that additional explanation for the health IT includes the Health IT Module being discussion about the requirements developer’s choice of care setting(s) to certified to the particular criteria). would be helpful to the community. For test; 109 However, real world testing of health the criteria proposed and finalized in • The timeline and plans for IT’s ability to exchange the types of data the real world testing scope in voluntary updates to standards and these clinical criteria reference is § 170.405(a), such real world testing implementation specifications that ONC addressed through the inclusion of the needs to address the interoperability has approved (further discussed below); USCDI in the interoperability-focused characteristics and all other • A schedule of key real world testing criteria listed in § 170.405(a) as functionalities and capabilities milestones; proposed, which is finalized as applicable based on the specific criteria • A description of the expected proposed. In order to successfully to which the Health IT Module is outcomes of real world testing; • exchange interoperable EHI, the health certified. For example, even if a Health At least one measurement/metric IT must be able to access it, and in order IT Module is not certified to any associated with the real world testing criterion that specifically requires it to for each certification in scope; and to incorporate a type of data, the health • IT must be able to record it. demonstrate, in order to be certified, A justification for the health IT Comments. The majority of comments that the Health IT Module has the developer’s real world testing approach. received specifically referencing the capability to incorporate and use data We sought comment (84 FR 7497) on proposed inclusion of public health received directly from sources outside whether we should specify a minimum criteria in the real world testing the production environment in which it ‘‘core’’ set of metrics/measurements and requirement in § 170.405(a) support the is deployed, that Health IT Module will examples of suggested metrics/ importance and inclusion of the public still need to demonstrate conformance measurements as well as on the timing health criteria in the scope of real world to the full scope of each criterion to of required real world testing results testing requirements. One commenter which it is certified. This includes, reporting. We also invited comment on questioned the inclusion of the public though it is not limited to, the technical the annual frequency and timing of health criteria in § 170.315(f), stating the standards and vocabulary codes sets required real world testing results commenter’s perception that extensive included in each criterion to which it reporting. variation between registries would make certified. Comments. Most comments received this a challenging functionality to supported the proposed requirement for c. Testing Plans, Methods, and Results demonstrate. Health IT Modules to undergo real Response. Variations in system Reporting world testing. In addition, commenters configurations across different public We proposed (84 FR 7496) that a indicated that real world testing should health agencies’ infrastructures may health IT developers must submit an occur on a regular basis to ensure suggest different real world testing annual real world testing plan to its various types of changes in the Health strategies may be most appropriate, or ONC–ACB via a publicly accessible IT Modules or production environments most relevant to customers, compared to hyperlink no later than December 15, of have not affected functionality required what might be the case for some other each calendar year for each of its by the certification. Several commenters criteria within the scope of real world certified Health IT Modules that include recommended development of more testing. However, as noted below about certification criteria specified for this specific minimum requirements for test testing tools, we are aware of a wide Condition of Certification. We proposed plans and measurement of results. They variety of resources and opportunities to (84 FR 7497) that a health IT developer further recommended that ONC provide test real world interoperability must submit an annual real world additional guidance about what will performance of Health IT Modules testing plan to its ONC–ACB via a constitute a minimally acceptable certified to the public health criteria in publicly accessible hyperlink no later testing plan with explicit content § 170.315(f). Because interoperability than January 31, of each calendar year depicting the minimum requirements performance in actual production for the preceding calendar year’s real for each component of the testing plan. environments is an important feature of world testing. Response. We thank commenters for health IT certified to the public health We proposed that the real world their feedback. As discussed in the criteria in § 170.315(f), and noting the testing plan, which will be required to Proposed Rule and above, we believe support for its inclusion expressed by be available to ONC and the public via health IT developers are in the best most commenters, and we have the CHPL no later than December 15 of position to design and facilitate determined that the most appropriate each year once this final rule is implementation of real world testing course is to finalize the inclusion of the effective, will need to address the health approaches that balance the burdens of public health criteria in§ 170.315(f) in IT developer’s real world testing that this statutory requirement with its the scope of real world testing in will be conducted the upcoming intended assurances that certified health § 170.405(a). calendar year and must include, for Comments. One commenter expressed each of the certification criteria in scope 109 We do not specifically define or limit the care concern that some of the criteria for real world testing in § 170.405(a) and settings and leave it to the health IT developer to determine. As an example, health IT developers can proposed for inclusion in § 170.405(a) each Health IT Module certified to one consider categories, including but not limited to, be re-examined because they do not or more of these criteria (84 FR 7496): those used in the EHR Incentive Programs (https:// include all three of the characteristics • The testing method(s)/ www.cms.gov/Regulations-and-Guidance/ our Proposed Rule described as being methodology(ies) that will be used to Legislation/EHRIncentivePrograms/Downloads/ UserGuide_QNetHospitalObjectivesCQMs.pdf); demonstrated through real world demonstrate real world interoperability, long-term and post-acute care; pediatrics; testing. Examples offered included that including a mandatory focus on behavioral health; and small, rural, and some criteria proposed for inclusion in scenario- and use case-focused testing; underserved settings.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00129 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25770 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

IT meets Program requirements, discovering them (see § 170.405(b)(2)(i)). not to finalize the flexibility for including interoperability performance, We believe 30 days is an appropriate developers to use ONC–ACBs’ in-the- applicable under the certification it timeframe to allow developers the field surveillance as part of the holds. We have therefore finalized opportunity to gather all facts and report developer’s real world testing plan. We requirements in § 170.405(b)(1) to their ONC–ACBs the details and do not believe that use or replication of designed to avoid the risk of a ‘‘one size nature of the non-conformity. methods or protocols used by ONC– fits all’’ set of testing tools (discussed at Furthermore, we believe more than the ACBs for in-the-field surveillance of 84 FR 7496) that might not fully address 30 days would extend beyond the certified Health IT Modules would be the concerns raised or provide the timeframe by which a non-conformity the most effective or the least assurances of interoperability should be investigated by an ONC–ACB burdensome approach available to performance sought across the various and corrective action implemented, if health IT developers and are concerned types of care settings. By establishing in necessary. accepting real world testing approaches § 170.405(b)(1)(iii) the topics and We are aware that by choosing not to that rely on ONC–ACB in-the-field specify particular methods, tools, or considerations every developer must surveillance could slow rather than checklists of activities that must be address in its required real world testing accelerate development of more included in real world testing, and plan but not specifying how they must innovative approaches to real world address these required aspects we have providing instead extensive flexibility for developers to select tools and design testing. We are also concerned that provided health IT developers with a inclusion of ONC–ACB execution of in- requirement that at the same time overall methodologies based on their knowledge of their products and the-field surveillance within a provides them with the flexibility to customers, we are asking developers to developer’s real world testing approach develop and implement successful real apply innovation and problem solving could lead to confusion as to whether world testing plans that will best skills to their real world testing. We the organization that is an ONC–ACB balance burden and value for the believe that the alternative of was applying in-the-field surveillance customers of each of their products. The developing a catalog of detailed protocols in its capacity as an ONC– ONC–ACBs will be responsible for specifications and checklists, as some ACB as part of its oversight assessing real world testing plans and commenters suggested, would be responsibilities on behalf of ONC or in results reports for completeness in undesirably complex, less supportive of its private capacity on behalf of the comparison to what § 171.405(b)(1) ongoing innovation in the market, and health IT developer. We believe it is requires the plan and results reports to not ultimately less burdensome for important, to protect HIPAA covered include or address, but will otherwise developers or their customers. As we health care providers and other HIPAA not be formally evaluating the testing have noted in the context of prior covered entities and their business approach for quality as a testing Program rulemaking actions, we often associates from inadvertently violating approach. We note for clarity that while make additional information resources requirements related to disclosure of ONC–ACB’s will not be judging a and non-binding guidance regarding health information, to maintain a clear developer’s real world testing real world testing available through distinction of when an organization that approaches as planned or as executed, familiar communications channels, such is an ONC–ACB is acting in the ONC– the contents of a developer’s publicly as the HealthIT.gov website. ACB capacity and when it is acting in available real world testing results could Comments. Several commenters its private capacity. We note and be used by an ONC–ACB as part of its expressed concerns about the burden of emphasize this because, in the event a ongoing surveillance of certified health real world testing in specific reference developer may choose to engage IT. Additionally, we have finalized our to ONC–ACB processes for in-the-field proposed requirement in § 170.405(a) services in support of developing or surveillance of certified products’ implementing the developer’s real and (b) that requires developers subject continued conformance to applicable to the real world testing Condition and world testing plans from an organization certification criteria. Some comments or entity that also happens to be an Maintenance of Certification raised concerns about the burden that ONC–ACB, all activities undertaken by requirements (see § 170.405(b)(2)(i)) could be placed on developers’ the organization or entity to develop, who discover in the course of their real customers should developers choose to execute, or support the development or world testing any non-conformities with rely heavily on the procedures used by the standards, functionalities, or other ONC–ACBs for randomized or reactive execution of the developer’s real world requirements of any certification in-the-field surveillance. Some testing plan would be activities outside criterion under the Program, to address comments indicated concern that ONC the ONC–ACB role. In such these non-conformities in order for their would expect, encourage, or view more circumstances, the organization that is Health IT Modules to remain certified. favorably real world testing approaches an ONC–ACB would be acting in a This requirement will apply in the same that rely heavily or exclusively on use separate, private capacity. Note that an manner to Health IT Modules certified of ONC–ACB in-the-field surveillance organization providing such private under the SVAP flexibility in protocols. services that involve ePHI would likely § 170.405(b)(8) or (9) as to Health IT Response. In the Proposed Rule, we be characterized under the HIPAA Rules Modules not certified under the SVAP stated that ‘‘developers may consider as a business associate to the health care flexibility. Thus, developers who working with an ONC–ACB and have provider and subject to the HIPAA discover non-conformity to any Program the ONC–ACB oversee the execution of Rules. The oversight authorities requirement(s) will be required to report the health IT developer’s real world attached to its ONC–ACB role would not those non-conformities to their ONC– testing plans, which could include in- apply to the organization’s requests to ACB(s). In order to provide a clear the-field surveillance per § 170.556, as gain access to health care provider threshold for determining whether a an acceptable approach to meet the facilities or to EHI for purposes of developer has acted on this requirement requirements of the real world testing providing these separate support in a timely manner, we have finalized Condition of Certification’’ requirement services to health IT developers for the requirement to report non- (84 FR 7497). Having considered all conduct of the developers’ real world conformities within 30 days of comments received, we have decided testing.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00130 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25771

Comments. Several commenters testing plan, protocol, or approach must testing infrastructures developed sought confirmation that a test server address all the types of settings to which without appropriate involvement of key could be used for real world testing the product, with all its included Health participants in the use case would not instead of a production environment, IT Module(s), is marketed and do so be an optimal approach. Also, we given the permissible use of synthetic with traceability to each Health IT reiterate that we encourage developers data. Module of its real world performance in to consider a variety of options and Response. After considering the each type of setting for which it is approaches before finalizing their totality of comments received, we have marketed. We believe it is possible to annual real world testing plans. We decided to finalize that a test server construct a real world use scenario or would encourage developers to consider could be used for real world testing and use case that tests more than one type the real world testing potential of provide the flexibility included in the of setting applicable to the Health IT resources, tooling, and infrastructure Proposed Rule that allows for real world Module, and confirm that a developer is already offered by public health testing to occur in a production setting not required to develop unnecessarily or organizations and agencies before using real patient data in accordance artificially separate scenarios or use embarking on efforts to develop with applicable laws as well as in an cases across multiple types of settings to additional tooling. We also note that, for environment that mirrors a specific which a given developer markets its the interoperability-focused public production environment used in a type applicable Health IT Module(s). With health criteria, alternatives that would of clinical setting for which the health respect to the types of settings required avoid both overuse of simulation IT is marketed. We have also decided to to be addressed by a given developer’s environments and asking public health finalize the flexibility for the developer plan, we do not believe that additional agencies to engage in work unique to to use synthetic patient data in lieu of specification is necessary because we developers’ real world testing plans or in addition to real patient data in real believe each developer is well situated might include structured observation or simulated/test scenarios executed in to know for what types of settings the and measurement of interoperability environments that mirror production developer (or its authorized resellers) performance in actual public health data environments where the health IT is has marketed, is marketing, or intends reporting/exchange as well as the testing deployed. However, we emphasize that to market its Health IT Modules. For ordinarily conducted for onboarding/ the purpose of real world testing is to purposes of this Condition and confirming connectivity of newly demonstrate that the Health IT Maintenance of Certification deployed/upgraded implementations to Module(s) work as expected in real-life requirement as finalized, there is no public health data exchange clinical settings. We note, as a point of exclusion for settings or health care infrastructures. potential interest for such consideration, provider types based on their inclusion Comments. A number of commenters that real world testing plans that meet or lack of inclusion in, or eligibility or expressed support of requiring the use the Program requirement might include ineligibility for, and particular Federal of metrics/measurements for real world observation or measurement of the health care program or initiative. testing. One commenter stated that ONC health IT’s interoperability performance Therefore, the types of settings eligible should not allow just one measurement while actual scenarios and use cases are to be addressed in a developer’s real executed by end users on real patient world testing plan for a given year to suffice for real world testing of data in actual operational contexts. If a include all those to which product(s) interoperability of a Health IT Module. developer chooses to use synthetic data, including one or more Health IT Several commenters recommended ONC non-production (mirrored) Modules certified to one or more of the include a description of environments, or a combination of real criteria listed at § 170.405(a) as of ‘‘measurement,’’ provide clarity on the and synthetic data or production and August 31 of the year in which that role of measurement, and provide a mirrored environments, to complete any specific annual real world testing plan ‘‘sample’’ or suggested set of metrics/ portion of their annual real world is due have been or are marketed when measurements to help foster alignment testing requirements, the developer the real world testing plan is submitted, of reporting around meaningful must include in their real world testing and/or the types of settings for which common metrics/measurements across plan and results submissions a specific the developer anticipates marketing developers. Some commenters explanation justifying how the synthetic such product(s) in time to include them recommended ONC identify a core set of data, mirrored environment, or both are in a specific year’s real world testing metrics/measures that developers would appropriate and adequate to meet the activities. be required to include, or from which real world testing requirement(s) for Comments. Several commenters developers would be required to select which they will be or were used. requested ONC ensure that real world specific metrics/measures to include, in Comments. Several commenters testing requirements do not create their real world testing plans. Other sought confirmation that a product infrastructure for testing of public commenters advocated against serving multiple care settings could health transactions without public developers being required to submit complete a single test relevant to all health involvement. Several testing results for a minimum ‘‘core’’ set settings and ask ONC to provide a list commenters noted that public health of general metrics, providing the of eligible care settings for reference. organizations and many public health rationale that not all metrics will be Response. The finalized real world agencies already offer resources and available to all systems uniformly and testing Condition and Maintenance of processes used in onboarding processes suggesting that many metrics are Certification requirements include for public health reporting connections retained in the provider’s locally testing each criterion listed in and suggested these resources and integrated production systems and § 170.405(a) to which any Health IT processes could be used more broadly to unavailable to the developer of any Module(s) within the product are test health IT’s real world performance given Module(s) without considerable certified, and testing in each type of on public health interoperability criteria effort to retrieve the data. One setting to which it is marketed. To rather than requiring creation of new or commenter recommended requiring that satisfy these Condition and different tools. each developer’s real world test plan Maintenance of Certification Response. We would tend to agree include measures addressing all of the requirements as finalized, a single that relying for specific use cases on domains of the NQF report:

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00131 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25772 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

Measurement Framework to Assess major functional updates to the certified developers and effectively reviewed for Nationwide Progress Related to Health IT Module. One commenter who completeness by ONC–ACBs, and that Interoperable Health Information was overall not supportive of the real both the substance and clarity or Exchange to Support the National world testing requirement stated that efficacy of presentation can both be Quality Strategy.110 developers would need a two-year cycle examined and considered by any Response. The comments on real instead of a one-year cycle in order to interested parties—from health care world testing did not show clear, adequately demonstrate compliance providers to informatics and widespread support for any specific with full functionality testing. One interoperability researchers. Because subset of available metrics as a ‘‘core’’ commenter specifically expressed individual circumstances and needs set or catalog that a significant portion support for the annual frequency and may vary even within the same type of of the affected communities (health IT timing of required real world testing setting or clinician specialty, it would developers, health care providers, and results reporting. be not be possible at this time to define public health agencies) would generally Response. We thank the commenters a real world testing regime that agree should be consistently used across for their feedback regarding the eliminated all of the variability all developers’ real world testing plans. frequency and timing of real world developers may have in implementing Thus, we have finalized the real world testing. We have finalized the their real world testing plans. testing plan requirements (see requirement for annual testing in Comments. One commenter sought § 170.405(b)(1)(iii) and real world § 170.405(b)(1). Ongoing annual testing clarification on the total minimum testing results reporting requirements is needed to ensure that Health IT number of metrics required for a (see § 170.405(b)(2)(ii)) without Module(s) continue to perform as developer’s real world testing plan to be identifying a minimum set of measures intended in the types of settings where considered complete and in compliance that must be used or a catalog of patients and health care providers with the requirement. suggested measures from which a continue to rely on it to meet their Response. A developer’s real world developer would be expected to choose interoperability needs. testing plan must include at least one in constructing its real world testing Comments. Several commenters metric for each applicable certification plans. We reiterate that each developer expressed support of the proposed real criteria. To ensure that we are providing must choose a measurement approach, world testing plan requirements and clear guidance, we offer the following including at least one measurement/ requested we strengthen this provision illustrative example: A developer with metric per applicable criterion, for use to require that developers test their one Health IT Module that is certified to in each year’s real world testing and products within each clinical specialty five criteria would need to include in its explain the selection and relevance of to which the technology would be real world testing plan at least one its selected measures/metrics within its marketed. One commenter requested specific measurement/metric associated justification for its real world testing that we define with more particularity with the real world testing for each of approach in that year’s plan and results what is expected of developers during those five criteria. Depending on the report. the testing to account for the differing specific criteria and the developer’s real Comments. Comments were received conditions under which Health IT world testing approach, this could call on the frequency and timing of real Modules are deployed, and how for for up to five different measurements/ world testing. One commenter stated the example, the system works particular metrics, or could be addressed with policy should not require annual testing conditions like server degradation. fewer different measurements/metrics if the capability certified for a given Several other commenters suggested we but a specific measurement/metric criterion remains unchanged year to provide a standardized template for use would need to be identified/attributed year, offering the example that if a in developing test plans. Commenters within the plan to each of the applicable Health IT Module is certified for both described a template would include all certification criteria. § 170.315(b)(1) and (b)(2) and the required testing elements and promote Comments. A few commenters stated developer is planning to release material greater consistency in the way the test concerns regarding our mandatory focus updates to the capabilities specific to plans are written by the various on scenario- and use case-focused § 170.315(b)(1), but not make any developers. testing. One commenter expressed a material changes specific to the Response. For reasons stated in the view that this would be expensive and Module’s certification to § 170.315(b)(2), Proposed Rule (84 FR 7496) and above, time consuming, stating that this this commenter would prefer that the we do not believe a centrally developed expense limits scenario- and use case- Health IT Module would need to submit or standardized approach for real world focused testing in the number of settings a testing plan and subsequent results testing plans is the most appropriate that can realistically be tested in any addressing only the § 170.315(b)(1) solution at this time. By centrally given year. One commenter noted that criterion for the year the change is mandating or endorsing a single as more settings are tested, fewer made. Another commenter expressed template in the interest of consistently scenarios can be run per setting. Two skepticism regarding the value of annual formatted documentation, we are commenters sought more information real world testing requirements, concerned that we might inadvertently on the mandatory scenario- and use expressing a preference for an approach discourage innovation in both testing case-focused testing that will be that developers would, after an initial approaches and their communication to required, recommending that Health the customer community. What the plan cycle of post-certification real world Information Service Providers (HISPs) must include or address for each testing of a Health IT Module, be be able to attest to the relevant use cases applicable criterion to which the required to re-test only when updating and provide the proper evidence of developer’s Health IT Module(s) are to National Coordinator-approved newer testing associated to those scenarios. certified is outlined in Response. In light of comments versions of adopted standards included § 170.405(b)(1)(iii), as finalized by this received, we can see how our use of in applicable criteria or when making rule. We believe the plan requirements terms that are also used in the context 110 https://www.qualityforum.org/Projects/i-m/ finalized in the plan requirements in of ONC–ATL laboratory or ONC–ACB Interoperability_2016–2017/Key_Informant_ § 170.405(b) are specific enough to surveillance testing, and our reference Summary_Report.aspx (last accessed 12/17/2019). ensure the plans can be completed by in one instance to in-the-field

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00132 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25773

surveillance, could have led to an year (in other words, the August 31 that December 15 due date for real world inference that our use of these terms immediately preceded the December 15 testing plan publication on CHPL as implied we would expect to see the due date). proposed. We have also made clarifying same or similar testing protocols used in We further proposed that a health IT edits to the finalized regulation text (see real world testing. However, we did not developer would submit annual real § 170.405(b)(1)) in comparison to the propose that real world testing would world testing results to their ONC–ACBs proposed text to more explicitly require developers to set up and execute via a publicly accessible hyperlink no recognize the practical implication that artificial scenarios or activities solely for later than January 31 of each calendar the developers’ and ONC–ACBs’ purposes of testing. In fact, we do not year for the real world testing conducted responsibility for a single publication encourage use of the laboratory testing in the preceding calendar year (84 FR date for the plans means that the plan or ONC–ACB in-the-field surveillance 7497). We proposed that real world must be submitted by the developer to protocols to conduct real world testing, testing results for each certification the ONC–ACB on a date agreed between as those particular test methods, tools, criterion listed in § 170.405(a) would be them that allows for publication by the and surveillance protocols were not required to address the elements deadline. We encourage developers and designed and should not be relied upon required in the previous year’s testing ONC–ACBs to consider allowing at least for real world testing. The testing plan, describe the outcomes of real one calendar month so that the methods/methodologies need to address world testing with any challenges December 15 due date for ONC–ACBs’ realistic scenarios, use cases, and encountered, and provide at least one publication of real world testing plans workflows associated with measurement or metric associated with will be consistently met. We also note interoperability, and we do expect the real world testing. that nothing in § 170.405 as finalized developers to consider such factors as Comments. Some commenters precludes a developer and ONC–ACB the size of the organization that expressed concerns that the annual real from agreeing on the developer production systems support, the type of world testing plan due date falls in submitting its annual real world testing organization and setting, the number of December, noting that in addition to plan to the ONC–ACB more than one patient records and users, system multiple holidays widely celebrated in month prior to December 15. We have components and integrations, and the the U.S., December can be a busy time finalized the single plan publication volume and types of data exchange in for many health IT developers due to deadline as proposed. planning for real world testing. various year-end requirements and We did not receive comments specific Comments. One commenter expressed necessary preparations to support to August 31 as the annual date when agreement that the developer is best customers’ quality measurement data a Health IT Module must be certified by situated to determine the most effective submissions for CMS programs. in order to be required to be included real world testing plan for their Response. We understand the in the real world testing plan due that products. One commenter requested commenters’ concern that the proposed year. We have finalized this aspect of developers be allowed to work together real world testing plan publication due our policy as proposed in with their customers to define what real date falls in the preparatory run-up to § 170.405(b)(1)(ii). Thus, developers can world tests are. year-end deadlines, including for many submit their real world testing plans as Response. The requirements we developers completing preparations to early as September 1 and on a rolling proposed and finalized provide support their customers’ successful basis thereafter for products in scope for developers the opportunity to identify, clinical quality measurement data the following year, which also addresses potentially in partnership with their submission during CMS program commenter concerns. customers, the real-life scenarios, use windows that typically open on the first We did not receive comments specific cases, and work flows applicable to the Federal business day in January. In to this point, but have removed from customer’s day-to-day use of the Health consideration of comments received, we § 170.405(b) as finalized the language IT Module(s) to meet their have made edits to the phrasing of the that would have specifically required interoperability needs in their CFR text in § 170.405(b) to convey with the initial submission of the plan to the production environments. more precise clarity that under the ONC–ACB by the developer must be by policy we have finalized, the developer a publicly accessible hyperlink. While d. Submission Dates is required to submit its real world this remains an option, and could be the We proposed that a health IT testing plans so that the ONC–ACB can most efficient one for developers and developer must submit an annual real conduct its completeness review and ONC–ACBs in many instances, we world testing plan to its ONC–ACB via publish the plan hyperlink on CHPL no believe this is an unnecessarily limiting a publicly accessible hyperlink for later than December 15 of each year. specification of the manner of availability to ONC and the public no This allows for the ONC–ACB and interaction between developers and later than December 15, of each calendar developer to identify and agree on the ONC–ACBs in these instances. The URL year, and that the plan must address all date by which the developer will or hyperlink in CHPL will not be of its Health IT Modules certified to the actually submit its plan to the ONC– published on CHPL until the ONC–ACB 2015 Edition certification criteria listed ACB, which could be well in advance of takes action to publish it, and the ONC– in proposed in § 170.405(a) and (84 FR December. One practical implication of ACB is required to review the plan and 7496). We proposed requiring that prior the single-deadline feature of the policy ensure it is complete before publishing to submission to the ONC–ACB, the as proposed is that in order for the plans the plan link on CHPL. plan will need to be approved by a to be submitted to ONC and made Comments. We received some health IT developer authorized publicly available by the single comments that appeared to construe our representative capable of binding the deadline, the ONC–ACB’s requirement intent to be that real world testing for all health IT developer for execution of the to review plans for completeness per Health IT Modules certified as of August plan and include the representative’s Program requirements will in many 31 of a given year would need to be contact information. We proposed that cases mean that the ONC–ACB will planned, conducted, and reported the plan due in any given year will need need the developer to submit the plan within five months of that date. to include all health IT certified to the to the ONC–ACB in advance of the Comments that appeared to be based on 2015 Edition through August 31 of that single deadline. We have finalized the this interpretation also expressed

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00133 Fmt 4701 Sfmt 4700 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 comments received, we do recognize it a shorter duration and without the same accomplish on such an annual schedule. is possible developers may for various consequences for noncompliance). We Response. We proposed that each reasons not be able to complete their welcomed comments on this potential developer’s annual real world testing annual real world testing activities until approach. plan required to be published by fairly late in any given testing (calendar) Comments. The majority of comments December 15 of a given year would need year. We also recognize that the data specifically addressing this point were to address all of the developer’s Health submission window for CMS programs in support of 2020 being treated as a IT Modules certified to criteria listed in can be a busy time for developers, and pilot year. One commenter agreed that § 170.405(a) as of August 31 of that year would not wish to disadvantage newer deferring the implementation or (84 FR 7496). We also proposed that this or smaller developers who may not have constructing a pilot year for the Program annual real world testing plan would separate resources available to finalize a would be appropriate and stated their pertain to real world testing activities to report of real world testing not belief that 2020 may be too early even be conducted in the year following the concluded until late in the testing year to conduct a pilot. December 15 plan publication due date. while simultaneously supporting Response. We thank commenters for In light of comments received, we can customers’ data submissions. In light of their thoughts on potential piloting of see how we might have been more these comments, we have decided to real world testing and the timing of precise in how we stated that the annual finalize a deadline for publication on initiating real world testing results report would be due early in the the CHPL of the publicly accessible requirements. In consideration of the year following the year in which the hyperlink to developers’ report of real timing of the final rule, we have decided testing it reported was conducted. The world testing conducted in the prior not to finalize 2020 as a pilot year since full cycle of real world testing for a year at March 15 of each year (see developers will now have the majority given year was never specifically § 170.405(b)(2)(ii)). This finalized date of calendar year 2020 to develop a proposed to be contained within a gives an additional six weeks for prospective plan for real world testing single year, considering that the plan is finalization and submission by that would begin in 2021. However, we due in the year prior and the results developers compared to the date recognize that this first ‘‘performance’’ report was proposed to be due in the originally proposed. It also implements year of real world testing in 2021 year following the one in which a given a single deadline, to which the presents unique challenges with respect annual round of real world testing developers and ONC–ACBs are to the development of initial plans, and activity occurs. mutually accountable, in parallel to the we fully intend to approach both the Comments. Comments raised annual real world testing plan submission of initial plans and concerns that the January 31 publication submission requirement in submission of retrospective testing deadline might not leave enough time § 170.405(b)(1). We believe this strikes results for those plans (i.e., 2021 real for developers who do not or cannot an appropriate balance between timely world testing results) as learning complete their annual testing activities availability of annual real world testing experiences for developers that can be until late in the testing year to submit results and recognition that some used to inform future iterations of real their results reports, and ONC–ACBs developers may need to devote a world test plans. As noted in the complete their required reviews, prior to substantial amount of focus to the CMS proposed rule (84 FR 7497), the due the publication deadline. One quality measures data submission date for the first annual real world commenter raised a specific concern windows at the beginning of each year. testing plan would be finalized based in that the proposed January 31 due date Although we have opted not to mandate part on the timing of the final rule. for real world testing results falls in the developers submit their results reports Because this final rule is publishing submission window for several CMS to their ONC–ACBs by a date providing well in advance of the December 15 programs for which developers’ a minimum required lead time for ONC– annual due date for publication of customers need to submit their clinical ACBs’ required review of the report, we developers’ plans of real world testing quality measurement data for the would suggest that ONC–ACBs and activities to be conducted in the preceding year. One commenter developers consider the potential merits following year, we have concluded it is recommended leveraging the existing of allowing at least one calendar month reasonable to require the first annual quarterly update attestation process and between the developer’s initial real world testing plan be published via asking developers to conduct real world submission of their real world testing a publicly accessible hyperlink on the testing on those items identified as results report to the ONC–ACB and the CHPL no later than December 15, 2020. major changes. March 15 publication deadline. This initial real world testing plan must Response. As with the plan due date, address any and all of the developer’s the practical implication of this e. Real World Testing Pilot Year Health IT Modules that hold a current, proposal is that each developer will We acknowledged in the Proposed valid certificate under the Program as of need to submit their results reports to Rule that a subsequent final rule for that August 31, 2020. The real world testing their ONC–ACB sufficiently in advance may not provide sufficient time for plan due to be published in December of the due date for publication for the health IT developers to develop and 2020, will need to address the real ONC–ACB to be able to complete its submit plans for a full year of real world world testing activities that will occur pre-publication responsibilities for all of testing in 2020 (84 FR 7497). Therefore, during calendar year 2021. The report of the results reports and still publish no we indicated in the Proposed Rule that results for this initial (2021) annual real later than that due date. In theory, this we expected to provide an appropriate world test cycle will be due to be means that in some cases developers period of time for developers to submit published on the CHPL no later than could complete their real world testing their plans, and potentially treat 2020 as March 15, 2022. relatively early in a given testing year a ‘‘pilot’’ year for real world testing. We and submit their results report for that expected that the pilot testing of real f. Health IT Modules Certified But Not year before the CMS submission world testing would match up to the Yet Deployed window for that year’s measurement fullest extent practicable with our We proposed (84 FR 7497) that even data even opens for the developer’s proposed real world testing if a health IT developer does not have customers. However, considering the requirements (e.g., same criteria but for customers or has not deployed their

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00134 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25775

certified Health IT Module(s) at the time required to perform real world testing in pace with the industry’s standards the real world testing plan is due, the the subsequent year. development efforts. health IT developer would still need to The SVAP we proposed, with submit a plan that prospectively g. Standards Version Advancement corresponding proposed revisions for addresses its plans for real world testing Process (SVAP) §§ 170.500 and 170.555, introduces two types of administrative flexibility for that would occur in the coming year for As discussed in the Proposed Rule (84 those Health IT Modules that had been health IT developers participating in the FR 7497), as newer versions 111 become certified on or before August 31 of the Program (84 FR 7498). First, for those available for adopted standards and calendar year in which the plan is due health IT developers with existing implementation specifications included (the calendar year immediately certified Health IT Module(s), such preceding the calendar year during in the certification criteria subject to the Health IT Modules could be upgraded to which testing addressed by any given real world testing Condition and a new version of an adopted standard annual real world testing plan will take Maintenance of Certification within the scope of the certification and place). If a health IT developer has not requirements, we believe that a health have support for that updated version of yet deployed their certified Health IT IT developer’s ability to conduct the standard reflected on the Health IT Module to any real world users when ongoing maintenance on its certified Module’s certificate so long as: Such the annual real world testing results are Health IT Module(s) to incorporate these version was approved by the National due for that module, we proposed that newer versions of Secretary-adopted Coordinator for use in the Program; and the developer would need to report as standards and implementation the developer satisfied all requirements such to meet the proposed Maintenance specifications (‘‘standards’’) is essential of the SVAP including demonstration of of Certification requirement. to support interoperability in the real conformance through an acceptable Comments. We received no comments world. Updated versions of standards means (84 FR 7498 through 7500). For on this proposal. reflect insights gained from real-world purposes of the SVAP as applied to Response. We have finalized this implementation and use. They also updates to Health IT Modules with proposal. Any Health IT Module reflect industry stakeholders’ interests certificates to criteria listed in certified to at least one criterion within to improve the capacity, capability, and § 170.405(a) that include prior the scope of real world testing as of clarity of such standards to meet new, version(s) 113 of the standards, August 31 of a given year must be innovative business needs, which acceptable means of demonstrating addressed by its developer’s real world earlier standards versions cannot conformance include but are not testing plan for the subsequent year that support. Therefore, as part of the real necessarily limited to self-declaration of must be published via publicly world testing Condition of Certification, conformance, as proposed in 84 FR 7499 accessible hyperlink on the CHPL by the we proposed a Maintenance of and finalized in this final rule. Second, December 15 due date (see § 170.405(a)). Certification flexibility that we refer to for those health IT developers This requirement applies regardless of as the Standards Version Advancement presenting health IT for certification to whether that Health IT Module is in Process (SVAP).112 This flexibility a criterion listed in § 170.405(a), a actual real world use prior to December would permit health IT developers to National Coordinator-approved newer 15 (or the earlier date by which the voluntarily use in their certified Health version of a standard included in one of developer and ONC–ACB agree the these criteria could be used in lieu of or IT Modules newer versions of adopted developer will submit its annual real in addition to the version of that standards so long as certain conditions world testing plan to the ONC–ACB to standard incorporated by reference in are met. As we stated in the Proposed ensure the developer and ONC–ACB § 170.299 (84 FR 7498). However, for meet single, December 15, deadline for Rule, these conditions are not limited to purposes of the SVAP as applied to the plan to have been reviewed for but notably include successful real health IT that is presented for completeness and published on CHPL). world testing of the Health IT Module certification to any criterion listed in To ensure precise clarity about the effect using the new version(s) subsequent to § 170.405(a), developer self-declaration of the August 31 reference date for the inclusion of these newer standards is an acceptable means of demonstrating purposes of real world testing and implementation specification conformance only where there is not yet requirements, we reiterate that if a versions in the Health IT Module’s another conformance method available developer has at least one Health IT certification. We proposed to establish that can be validly used for that version Module certified to at least any one the SVAP not only to meet the Cures of that standard (84 FR 7499 through criterion within the real world testing Act’s goals for interoperability, but also 7500). The regulation text codifying scope of applicability as of August 31 of in response to the continuous requirements for health IT developers to a given year, the real world testing stakeholder feedback that ONC has avail themselves of each of the proposed Condition and Maintenance of received through prior rulemakings and types of administrative flexibility was Certification requirements apply to that engagements, which requested that ONC proposed (84 FR 7595 through 7596) in developer and the developer must establish a predictable and timely § 170.405(b)(5). Corresponding revisions submit an annual real world testing plan approach within the Program to keep to § 170.550 and § 170.555 were for that year, addressing each of their proposed in 84 FR 7598. Health IT Module(s) certified to any 111 We note that standards developing We proposed that the SVAP would be (one or more) criteria listed in organizations and consensus standards bodies use available only for National Coordinator- § 170.405(a) and that plan must meet the various nomenclature, such as ‘‘versions’’ or approved newer versions of standards requirements in § 170.405(b)(1)(iii) for ‘‘releases,’’ to identify updates to standards and and implementation specifications implementation specifications. each module and criterion. Only 112 Regulation text implementing the real world (‘‘standards’’) that have already been developers who have no Health IT testing Condition and Maintenance of Certification Module(s) certified to any criterion requirement was proposed in § 170.405, including 113 Prior versions for this purpose could include within the real world testing scope of but not limited to SVAP-specific provisions those incorporated by reference in § 170.299, proposed in § 170.405(b)(5). The SVAP-specific National Coordinator approved newer versions, or applicability as of August 31 of a given provisions have now been finalized in a mix of such versions for any or all of the year need not submit a real world § 170.405(b)(8) and (9) (see section VII.B.5.g of this standards adopted by the Secretary in subpart B of testing plan that year and would not be final rule). part 170 that are included in a given criterion.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00135 Fmt 4701 Sfmt 4700 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 § 170.405(a), a health IT developer will adopted standards, but only in addition Secretary through rulemaking in have flexibility to choose on an itemized to the version(s) of those standards accordance with applicable law basis which of the National Coordinator- incorporated by reference in § 170.299. including the Administrative approved updated standards versions In our experience, newer versions Procedures Act (5 U.S.C. 553) and they wish to have included in their render prior versions obsolete on a more sections 3001 and 3004 of the Public Health IT Module certification(s). Using rapid pace for some standards than for Health Service Act (PHSA) (42 U.S.C. the SVAP flexibility does not require a others and more rapidly than the 300jj–1 and 42 U.S.C. 300jj–11) (84 FR developer cease supporting prior versions incorporated by reference in 7498). We have finalized this aspect of version releases of standards referenced regulations could be updated. Prior the standards version advancement by applicable certification criteria. feedback had indicated that being flexibility as proposed. Under current Comments. Several commenters required to maintain support for the law and the finalized SVAP flexibility, expressed concerns about the effect of version of a standard that is a standard must be initially adopted by an uneven pace of advanced version incorporated by reference in § 170.299 the Secretary through rulemaking before implementation across health IT solely for the purpose of maintaining the National Coordinator can approve developers and products within and regulatory compliance under the the use of newer updated versions of outside the Program. Several of these Program represented a burden without that standard in the Program. commenters recommended that, as commensurate value in cases where We also proposed that a health IT developers voluntarily seek to support customers’ operational interoperability developer would be able to choose newer versions of standards and needs could be met only by use of which of the updated standards versions specifications through the SVAP, they newer version(s) of particular adopted approved by the National Coordinator also be required to maintain support for standards than the versions listed in the for use in certification to include in its the adopted version of the standard regulations. The SVAP is designed to updated certified Health IT Module and listed in the Code of Federal Regulations eliminate that burden and would be able to do so on an itemized (45 CFR part 170, subpart B) for the simultaneously provide, through basis (84 FR 7499). applicable criteria until HHS conducts inclusion of support for advanced We stated in the Proposed Rule that rulemaking that would require all standards versions within a Health IT we welcomed comments on any and all certified health IT upgrade to the newer Module’s certification, enhanced aspects of our proposed SVAP as an version of the standard and sunset older assurance to users that Health IT option available to developers through versions of the standard from the Modules supporting National maintenance requirements as part of the Program on a mandatory, coordinated Coordinator-approved newer versions of real world testing Condition and timeline. standards under the SVAP flexibility Maintenance of Certification Response. We do recognize the continue to meet all of the requirements requirements (84 FR 7500). We also importance of ensuring that updated of the criteria to which the Health IT invited comments on our proposal to versions of standards are approved and Module is certified. allow in conjunction with this available for use in the Program only Comments. A number of commenters maintenance flexibility the opportunity when such use is consistent with the requested clarification on how the for developers to elect to present health Program’s purposes. We do not proposed Standards Version IT for initial testing and certification anticipate that the National Coordinator Advancement Process would align with either to more advanced versions or to would approve a newer version of a expansion of the USCDI, or whether the the prior adopted versions of the standard for use in the Program where USCDI will be versioned through the standards included in regulatory text as that is inconsistent with the Program’s SVAP. Some commenters expressed an of the date the Health IT Modules are purposes, notably including the opinion that the USCDI expansion presented for certification. maintenance and advancement of process should not be executed or Comments. Comments were strongly interoperability. Moreover, we believe allowed via the SVAP and instead supportive of the SVAP. Several there is substantial value in allowing for require rulemaking. commenters recommended the the market to, in effect, sunset obsolete Response. As discussed in section description of this process include standards versions at its own pace IV.B.1, we have adopted the USCDI as recognition of the fact that developers unless a hard cutover (or other highly a standard in § 170.213 and and systems might need to maintain coordinated nationwide timeline for incorporated USCDI v1 by reference in operational support for previously abandoning older versions) would be § 170.299(n)(5). For purposes of the adopted versions of standards to avoid necessary to sustain functional SVAP, the USCDI will be treated like potential adverse effects on data access, interoperability. The SVAP flexibility any other standard. This means that exchange, and use. simply allows for a developer to choose health IT when presented for Response. We have finalized the to work with their ONC–ACB to obtain certification to any one or more criteria SVAP in § 170.405(b)(8) and (9) to certification, or to modify the scope of referencing § 170.213 will be required to provide the flexibility for which the of Health IT Module’s certification, support USCDI v1 or a later version, stakeholders’ comments expressed to reflect that the Health IT Module as with SVAP providing flexibility for support. This flexibility includes the certified includes: The version of each developers to choose whether to support option for a Health IT Module to be adopted standard that is incorporated by later versions of USCDI that the certified to the standards versions reference in § 170.299; or a specific National Coordinator may approve for incorporated by reference in § 170.299 National Coordinator-approved updated use in the Program in lieu of or in and/or one or more National version of each applicable standard; or complement to USCDI v1. Developers Coordinator-approved updated versions a National Coordinator-approved and will not be required to support of standards included in the criteria updated version for each of one or more newer versions of the USCDI standard listed in § 170.405(a). Thus, once the applicable standard(s); or multiple instead of USCDI v1 until such time as National Coordinator has approved for version(s) of any one or more adopted § 170.213 and § 170.299 are updated. use in the Program more advanced standard(s). Previously, developers were However, developers may voluntary version(s) of any standard(s) applicable free to upgrade certified Health IT choose to use the SVAP flexibility to to any of the criteria listed in Modules to support newer versions of voluntarily upgrade certified Health IT

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00136 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25777

Modules, or to seek certification of their their Health IT Modules to e-prescribing by the customer using it versus health IT, to newer version release(s) of criteria updated to reflect conformance software-as-a-service type of the USCDI if such release(s) have been of the Health IT Modules to newer implementation), or specific types or approved by the National Coordinator versions of adopted standards that characteristics of customers that could for use under the Program. As with any might be required by CMS Part D affect the minimum advance notice that other standard relevant to the SVAP program or other HHS regulatory should be considered reasonable across flexibility, we would anticipate that the requirements before we could update variations in these factors (84 FR 7499). National Coordinator would not the version(s) of e-prescribing standards Comments. Only a few commenters approve for voluntary use under the incorporated by reference in § 170.299. offered thoughts specifically on the Program an updated version of any This approach would avoid the need for minimum time prior to an anticipated standard that would render Health IT CMS or ONC to go through joint implementation of an updated standard Module(s) using it incapable of rulemaking in order maintain or implementation specification version exchanging EHI with other technology programmatic alignment. certified under the Program to other update that should be considered h. Updating Already Certified Health IT version(s) of the standard. We also note reasonable. Several of these commenters Leveraging SVAP Flexibility that, although HHS is the steward of the noted that different market segments USCDI standard, we have not at this We proposed that in instances where and provider types vary in their time foreclosed the possibility that we a health IT developer has certified a willingness or ability to upgrade to new could publish a newer update of the Health IT Module, including but not software versions. One comment USCDI that the National Coordinator limited to instances where its customers submission indicated two months would not immediately approve for are already using the certified Health IT would be a reasonable minimum time developers’ voluntary use under the Module, if the developer intends to prior to implementation of an updated Program via the SVAP flexibility. We update pursuant to the SVAP election, standard for their customers to be recognize a potential that expanding the the developer will be required to notified. Another commenter observed USCDI to include additional data provide advance notice to all affected that the minimum timeframe prior to an classes in future versions could lead to customers and its ONC–ACB: (a) anticipated implementation of an Health IT Modules certified to these Expressing its intent to update the updated standard is two to four years. more advanced versions of USCDI being software to newer versions of the Response. The comments received able to access, use, and exchange more standard approved by the National comport with our prior understanding data classes than Health IT Modules Coordinator through the SVAP; (b) the that the minimum advance notice certified only to earlier versions of the developer’s expectations for how the needed to offer customers reasonable USCDI. However, the technology update will affect interoperability of the opportunity to ask questions and plan certified to National Coordinator- affected Health IT Module as it is used for the update or modification of Health approved newer versions of the USCDI in the real world; and (c) whether the IT Modules the customers are using or developer intends to continue to would be capable of exchanging the data have purchased and scheduled for support the certificate for the existing classes included in prior version(s) of deployment varies across different Health IT Module version for some the standard. Thus, the flexibility circumstances. We have, therefore, period of time and how long, or if the maintains interoperability while decided to finalize the advance notice existing version of the Health IT Module allowing those who need additional requirement as proposed. The regulation data classes to be fully supported by certified to prior version(s) of applicable standards will be deprecated (e.g., that text for this requirement is finalized in certified health IT in their access, § 170.405(b)(8)(i). Thus, a developer exchange, and use of these additional the developer will stop supporting the earlier version of the module and choosing to take advantage of the SVAP data classes and not forcing other users flexibility must provide notice to its of certified health IT (who do not yet request to have the certificate customers sufficiently in advance of the need to access, exchange, or use such withdrawn) (84 FR 7498). The notice developer’s anticipated timeframe for additional data classes) to update their would be required to be provided implementation of the update to the health IT. We therefore believe that sufficiently in advance of the developer newer version(s) of applicable allowing for expansion of data for which establishing its planned timeframe for certified Health IT Modules can support implementation of the upgrade to the standard(s) to offer customers interoperability at a pace driven by the more advanced standard(s) version(s) in reasonable opportunity to ask questions market’s progress in standards order to offer customers reasonable and plan for the update. We note for development and demand for opportunity to ask questions and plan clarity that we intend to apply a interoperability is an important benefit for the update. We requested public reasonableness standard to evaluating of the SVAP flexibility. comment on the minimum time prior to adequacy of advance notice timeframes Comments. One commenter stated the an anticipated implementation of an for particular version updates in their SVAP would be more effective for updated standard or implementation specific factual contexts, prioritizing the electronic prescribing if it could be used specification version update that should perspective of a reasonable person in to allow voluntary adoption of a new be considered reasonable for purposes the situation of the developer’s version of the NCPDP SCRIPT standard of allowing customers, especially health customers because this requirement is by prescribers, pharmacies, and Part D care providers using the Health IT intended to protect the interests of those prescription drug plans without CMS Module in their health care delivery customers. We would anticipate that rulemaking. operations, to adequately plan for proactive engagement between the Response. CMS is solely responsible potential implications of the update for developers and their customers would for Medicare Part D program regulations their operations and their exchange result in mutually agreeable timeframes and other policies, including its relationships. We also requested and obviate the need for us to assess required e-prescribing standards and comments on specific certification reasonableness in at least the vast standards versions. In the future, the criteria, standards, characteristics of the majority, and ideally the totality, of SVAP flexibility could enable certified Health IT Module or its instances where developers choose to developers to have the certifications of implementation (such as locally hosted use the SVAP flexibility.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00137 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25778 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

i. Health IT Modules Presented for compliance with a conformance method flexibility when presenting Health IT Certification Leveraging SVAP approved by the National Coordinator. Modules for certification to a criterion Flexibility This provides flexibility for the National listed in § 170.405(a). Coordinator to approve a conformance In instances where a health IT j. Requirements Associated With All method other than ONC–ATL testing, developer presents health IT for Health IT Modules Certified Leveraging for evaluating conformance where the certification to a criterion listed in SVAP National Coordinator has approved a § 170.405(a) to which the health IT is As outlined in the Proposed Rule (84 not already certified, we proposed that version update of a standard for use in certification but an associated testing FR 7499), in all cases, regardless of the health IT developer would be whether a health IT developer is permitted to use National Coordinator- tool is not yet updated to test to the newer version. We have also made edits updating an existing certified Health IT approved newer versions of any or all of Module or presenting a new Health IT the standards included in the criterion, to the text in § 170.405(b) as finalized in comparison to the text included in the Module for certification to new versions instead of or in combination with the Proposed Rule to make more of adopted standards approved by the versions of these standards incorporated immediately clear which specific National Coordinator through the by reference in § 170.299. In such requirements apply when developers Standards Version Advancement circumstances, a health IT developer choose to take advantage of the SVAP Process, we proposed that any would be able to choose which National flexibility for updating Health IT developer choosing to take advantage of Coordinator-approved standard Modules already certified to a criterion the proposed flexibility would need to: version(s) it seeks to include in a new • listed in § 170.405(a) and which specific Ensure its mandatory disclosures in or updated certified Health IT Module requirements apply when developers § 170.523(k)(1) appropriately reflect its and would be able to do so on an choose to leverage the flexibility when use of any National Coordinator- itemized basis. To enable this flexibility presenting Health IT Modules for approved newer versions of adopted for developers seeking certification, we certification to a criterion listed in standards; and • proposed to amend ONC–ACB § 170.405(a). Address and adhere to all Program Principles of Proper Conduct (PoPC) to Comments. Commenters requirements—including but not limited require ONC–ACBs offer certification to recommended HHS give health IT to Conditions of Certification and National Coordinator-approved newer developers’ flexibility to choose which Maintenance of Certification versions of standards and provide the standards to advance through this requirements—that are applicable to its ability for ONC–ACBs to accept a process and not obligate them to update certified Health IT Modules regardless developer self-declaration of conformity to all possible standards at once. of whether those Health IT Modules as to the use, implementation, and Response. In the Proposed Rule, we were certified to the adopted standards conformance to a newer version of a noted (84 FR 7497) that a health IT found in 45 CFR part 170 or National standard (including but not limited to developer would be able to choose Coordinator-approved newer version(s) implementation specifications) as which National Coordinator-approved of the adopted standard(s). sufficient demonstration of conformance standard version(s) it seeks to include in For example, as we proposed, a in circumstances where the National a new or updated certified Health IT developer would need to ensure that its Coordinator has approved a version Module and would be able to do so on real world testing plan and actual real update of a standard for use in an itemized basis. Under the finalized world testing include the National certification but no testing tool is yet SVAP flexibility in § 170.405(b)(9), Coordinator-approved newer versions of available to test to the newer version (84 health IT developers are permitted to standards to which it is claiming FR 7501). choose to use National Coordinator- conformance, beginning with the plan Comments. Commenters supported approved version(s) or the version for and real world testing conducted in the proposal to allow for both updates incorporated by reference in § 170.299 the year immediately following the first to existing certifications of Health IT or both for any standard(s) included in year the developer’s applicable Health Modules and newly sought applicable criteria it seeks to use in its IT Module(s) were, as of August 31, certifications to applicable criteria to certified Health IT Module(s) on an certified to the National Coordinator- follow a process of self-declaration itemized, standard-by-standard basis at approved newer versions of standards. where approved test tools are not yet the developer’s discretion. Under the policies outlined in the available to support conformance In the Proposed Rule, the regulation Proposed Rule, developers would be validation of the pertinent National text for all SVAP requirements was held accountable for maintaining all Coordinator-approved newer version of proposed to be codified in applicable certified Health IT Modules a standard. A few commenters requested § 170.405(b)(5). The SVAP in conformance with any National we clarify how developers can requirements, as finalized, are codified Coordinator-approved newer versions of demonstrate conformance when a newer in § 170.405(b)(8) and (9). We decided to standards and implementation version of a standard is available for use codify the finalized SVAP requirements specifications that they voluntarily elect under this process but does not yet have in separate paragraphs because it to use in their certified health IT under testing tools available under the complements other wording changes to the real world testing Condition and Program. the finalized regulation text that we Maintenance of Certification Response. We proposed (84 FR 7456) made to make more immediately clear requirements proposed in § 170.405, the and have finalized modifications in on the face of the regulation which attestations Condition and Maintenance § 170.523(h) to permit ONC–ACBs to specific requirements (§ 170.405(b)(8)) of Certification requirements proposed certify Health IT Modules that the ONC– apply when developers choose to take in § 170.406, and through ONC–ACB ACB has evaluated for conformance advantage of the SVAP flexibility for surveillance applying to certificates that with certification criteria without first updating Health IT Modules already include National Coordinator-approved passing through an ONC–ATL. As certified to a criterion listed in updated versions as it does to those that finalized, § 170.523(h)(2) provides that § 170.405(a) and which specific do not. We also included discussion an ONC–ACB may certify a Health IT requirements (§ 170.405(b)(9)) apply indicating our intent that developers Module that has been evaluated by it for when developers choose to leverage the would be accountable for correcting

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00138 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25779

non-conformities with certification adopted in part 170 should be approved standards review and approval criteria that were discovered in real for developers’ voluntary use under the processes or the SVAP flexibility itself world testing of a Health IT Module Program. We requested commenters’ to inform assessments of various aspects certified using National Coordinator- input on our anticipated approach to of the health IT ecosystem such as the approved newer versions. Under the standards and implementation maturity and uptake of specific proposed policies, prompt corrective specification advanced version approval standards versions. action would be required by a developer as outlined in the Proposed Rule. Response. Although addressing their discovering such non-conformity Comments. Some commenters substance is outside the scope of this through real world testing, in similar expressed concerns that appeared to final rule, we appreciate these responses manner as a developer would be suggest an understanding that the SVAP to our call for comments. This accountable for correcting non- would be used to adopt new standards information will help to inform our conformities discovered through real into the Program. deliberations about future program world testing of Health IT Modules Response. As stated in the Proposed policies and operations. certified using only the versions of Rule, the SVAP flexibility can only be used for newer (sometimes known as l. Real World Testing Principles of Secretary-adopted standards that are Proper Conduct for ONC–ACBs incorporated by reference in § 170.299, ‘‘updated’’) versions of standards and or through other Program means. implementation specifications that the We proposed to include a new PoPC Comments. We did not receive Secretary has already adopted through for ONC–ACBs in § 170.523(p) that specific comments on these general notice-and-comment rulemaking.114 would require ONC–ACBs to review and requirements and details of the Comments. One commenter urged confirm that applicable health IT relationship between the proposed that in order to be considered for developers submit real world testing SVAP and other proposed Program approval for voluntary use under the plans and results in accordance with enhancements or existing accountability Program the full details of a version of our proposals (84 FR 7501). The mechanisms. a standard should be required to be proposed requirement was that the Response. We have finalized these publicly available online by the start of ONC–ACBs review the plans for details of our SVAP policies as opportunity for public review and completeness. Once completeness is proposed. discussion of the list of versions under confirmed, we proposed that ONC– We stated in the Proposed Rule that consideration. ACBs would provide the plans to ONC we anticipate providing ONC–ACBs Response. We appreciate the and make them publicly available by (and/or health IT developers) with a feedback. Although specifics of December 15 of each year (see means to attribute information on operational processes are outside the § 170.523(p)(1) and (3) in 84 FR 7598). Health IT Modules’ support for National scope of this rule, we wish to reassure We proposed that for the reasons Coordinator-approved updated versions all stakeholders that we do appreciate discussed above in context of developer of standards to the listings on the CHPL the value of ensuring public dialogue requirements, we have finalized (in for the Health IT Modules the ONC– around such matters as consideration of § 170.405(b)(1)) December 15 of each ACB has certified, and proposed to standards versions for potential year as the due date for the annual real require in the PoPC for ONC–ACBs that voluntary use in the program is world testing plans. We proposed in they are ultimately responsible for this appropriately supported by availability § 170.523(p)(2) that the ONC–ACB information being made publicly of relevant information. As we would ‘‘review and confirm that available on the CHPL (84 FR 7501). We operationalize support for finalized applicable health IT developers submit requested public comment on any policies including the SVAP, we plan to real world testing results in accordance additional information about updated provide ample public outreach and with § 70.405(b)(2).’’ And in standards versions that may be communications through channels § 170.523(p)(3) we proposed that the beneficial to have listed with certified familiar to affected stakeholders— ONC–ACBs would be required to submit Health IT Modules on the CHPL. including but not limited to ONC’s real world testing results by April 1 of Comments. One commenter HealthIT.gov website. each year to ONC for public availability recommended ONC provide a method Comments. Several commenters (84 FR 7598). on the ONC CHPL for documenting the suggested various potential features or Comments. The only comments dot version/release associated with the processes that could be used in received relevant to these PoPC new standard version implementation ascertaining whether a more recent proposals were about due dates, and and clarify the ONC–ACBs reporting version of any standard or were summarized above in context of timeline for these types of standard implementation specification that the the § 170.405 requirements applicable to version updates. Secretary as adopted in part 170 should developers (see section VII.B.5.d Response. We thank the commenter be approved by the National Submission Dates, in this final rule). for the feedback, which will help to Coordinator for developers’ voluntary Response. We thank commenters inform our internal deliberations about use under the Program. We also again for their feedback on this proposal future operational planning. received several comments regarding and have finalized the PoPC potential uses of information from the (170.523(p)(1)–(3)) as proposed, with k. Advanced Version Approval for the exception of having adjusted in SVAP 114 As also noted in the Proposed Rule, this policy § 170.523(p)(3) the annual due date for The Proposed Rule (84 FR 7500) considers the substance of a standard and not publication of developers’ real world included discussion of how, after a whether its name or version naming and testing results reports on CHPL from the identification track remains unchanged over time, standard has been adopted through as standards developing organizations and proposed April 1 to the finalized March notice and comment rulemaking, ONC processes may apply different naming or 15 date. anticipated undertaking an open and identification methods from one version to another Because we proposed to allow health transparent process to timely ascertain of the same standards or implementation IT developers to implement National specifications. For more information on version whether a more recent version of any naming and identification tracks for standards and Coordinator-approved newer versions of standard or implementation implementation specifications, please see the adopted standards and implementation specification that the Secretary as Proposed Rule (84 FR 7500). specifications in certified Health IT

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00139 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25780 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

Modules, we proposed two important to ensure the regulation text certification of Health IT Modules to requirements to ensure the public has finalized in § 170.523(m)(5) cannot be any one or more of the criteria knowledge and ONC–ACBs can misconstrued as precluding use of such referenced in § 170.405(a) based on maintain appropriate oversight and records as the data source for this newer versions of standards included in surveillance of the version of a standard requirement. the criteria which have been approved that certified health IT meets. First, we In complement to the above by the National Coordinator for use in proposed to revise the PoPCs in requirements to ensure transparency for certification through the Standards § 170.523(m) to add subparagraph (4) the public and end users, we proposed Version Advancement Process (84 FR requiring ONC–ACBs to aggregate, no in § 170.523(t) a new PoPC for ONC– 7598). less than quarterly, all updates ACBs requiring them to ensure that Comments. We received no public successfully made to use newer versions developers seeking to take advantage of comments on this proposed addition to of adopted standards in certified health the SVAP flexibility in § 170.405(b) § 170.550 to accommodate the SVAP IT per the requirements for developers comply with the applicable flexibility. choosing to take advantage of the SVAP requirements, and that the ONC–ACB Response. We have finalized the flexibility. This would ensure that ONC both retain records of the timing and substance of § 170.550(e) as proposed. is aware of the version of a standard that content of developers’ required 115 We have modified the regulatory text certified health IT meets for the notices and ensure each notice is timely finalized in § 170.550(e) in comparison purposes of Program administration. and publicly accessible, and easily with that proposed in 84 FR 7598 by Second, we proposed, that a developer located via the CHPL through adding a header. The finalized that chooses to avail itself of the SVAP attribution of the notice to the certified paragraph reads: ‘‘Standards Updates. flexibility must address its use of newer Health IT Modules to which it ONC–ACBs must provide an option for versions of adopted standards in its real applies.116 certification of Health IT Modules to world testing plans and results. We note that in the proposed any one or more of the criteria We sought comment on the proposed regulation text in § 170.523(t) as referenced in § 170.405(a) based on additions to the PoPC for ONC–ACBs. published in 84 FR 7598, there was an newer versions of standards included in More specifically, we sought comment editorial error. The editorial error was in the criteria which have been approved on whether ONC–ACBs should be title in § 170.523(t) as published in 84 by the National Coordinator for use in required to perform an evaluation FR 7598, which read ‘‘Standards certification.’’ beyond a completeness check for the Voluntary Advancement Process’’ We proposed to revise § 170.555(b)(1) real world testing plans and results and instead of ‘‘Standards Version to accommodate the SVAP flexibility. the value versus the burden of such an Advancement Process,’’ although the The revised text in § 170.555(b)(1) as endeavor. proposed introductory text correctly proposed (84 FR 7598) read: ONC–ACBs Comments. We did not receive any referenced ‘‘Standards Version are not required to certify Complete comments on this proposal. Advancement Process.’’ EHRs and/or Health IT Module(s) Response. The substance of the Comments. We did not receive public according to newer versions of requirement is finalized as proposed, comment on the proposed paragraph (t) standards adopted and named in though, we have made clarifying edits to or its addition to § 170.523. subpart B of this part, unless: (i) The the way in which the PoPC amendments Response. We have finalized National Coordinator identifies a newer are organized and phrased. The § 170.523(t) with a revised title more version through the Standards Version requirement proposed in consistent with the finalized titles of Advancement Process and a health IT § 170.523(m)(4) (84 FR 7599) has been paragraphs (8) and (9) in § 170.405(b), developer voluntarily elects to seek re-designated in § 170.523(m)(5). In the and a revised citation to § 170.405. The certification of its health IT in finalized § 170.523(m)(5), we have citation to § 170.405 was revised accordance with § 170.405(b)(5); or (ii) revised the citation to the SVAP because the SVAP requirements The new version is incorporated by requirements because they were 170.523(t) references were proposed in reference in § 170.299. proposed in § 170.405(b)(5) but are § 170.405(b)(5) but have been finalized Comments. We did not receive public finalized in § 170.405(b)(8) and (9). The in § 170.405(b)(8) and (9). The substance comments on revising paragraph (b)(1) wording of requirement finalized in of the PoPC requirement in § 170.523(t) of § 170.555 to accommodate the SVAP § 170.523(m)(5) was modified in is finalized as proposed. flexibility. comparison to that proposed in 84 FR Response. We have finalized the 7599 to make clear that ONC–ACBs are m. Health IT Module Certification & substance of this revision as proposed. required to report on all certifications of Certification to Newer Versions of However, we have struck ‘‘Complete Health IT Modules to National Certain Standards EHRs and/or’’ from the text finalized in Coordinator-approved newer versions of We proposed to add in § 170.550, § 170.555(b)(1) consistent with our Secretary-adopted standards, both those Health IT Module certification, a new finalizing the removal from 45 CFR part updated to include newer versions of paragraph (e), which would require that 170 of references to ‘‘Complete EHRs’’ adopted standards and those of Health ONC–ACBs must provide an option for in conjunction with the removal of the IT Modules first presented for 2014 Edition (as discussed in section certification using newer versions of 115 The advance notice requirement that was III.B.2 of this final rule). We have adopted standards. Another proposed in § 170.405(b)(5)(i) and that is now clarified the text in § 170.555(b)(1) as modification to the finalized regulation finalized in § 170.405(b)(8)(i) remains specific to finalized to use the word ‘‘approves’’ in text in § 170.523(m)(5) in comparison developers leveraging SVAP flexibility to update place of ‘‘identifies,’’ consistent with Health IT Modules with existing certifications. with that proposed clarifies that ONC– 116 We note for clarity that whether a copy of the our phrasing and terminology ACBs are permitted to obtain the content is hosted on CHPL, made available via a throughout the preamble of this final quarterly record of successful use in publicly accessible hyperlink provided by the rule and finalized regulation text certified Health IT Modules of newer developer, or another mechanism or method that implementing the SVAP flexibility. We may emerge as a more advanced and efficient versions of adopted standards from the technical approach to achieving this same goal is have replaced ‘‘under the Standards ONC–ACB’s records of certification an operational detail and does not need to be Version Advancement Process’’ with activity. We believe this clarification is defined in rulemaking. ‘‘for use in certification’’ because we

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00140 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25781

believe this wording prevents potential requirements, would be subject to ONC § 170.401. We have also revised confusion about whether the term direct review, corrective action, and § 170.406 to provide further clarity on ‘‘Standards Version Advancement enforcement procedures under the the applicability of each of the Process’’ refers to the administrative Program. Conditions and Maintenance of flexibility established in § 170.405(b)(8) We welcomed comments on the Certification requirements to health IT and (9) or to the National Coordinator’s proposed attestations Condition and developers for the purposes of approach to approving versions for use Maintenance of Certification attestation. For example, all health IT in the Program. We have also revised requirements, including the appropriate developers under the Program would the citation to § 170.405(b) in the frequency and timing of attestations. We attest to the ‘‘information blocking’’ finalized text in § 170.555 because the also welcomed comments on the Condition of Certification requirement SVAP provisions proposed in proposed responsibilities for ONC– (§ 170.401), while only health IT § 170.405(b)(5) have been finalized in ACBs related to the attestations of developers that have health IT certified § 170.405(b)(8) and (9). Condition and Maintenance of to the ‘‘API’’ certification criteria Certification requirements. (§ 170.315(g)(7)–(10)) would be required 6. Attestations Comments. We received many to attest to the ‘‘API’’ Condition of The Cures Act requires that a health comments supporting the ‘‘attestations’’ Certification and Maintenance IT developer, as a Condition and Condition and Maintenance of requirements (§ 170.404). We have also Maintenance of Certification Certification requirements. Commenters revised the ‘‘attestations’’ Conditions requirement under the Program, provide generally agreed that health IT and Maintenance of Certification to the Secretary an attestation to all of developers should attest that they are requirements in § 170.406 to clearly the Conditions of Certification complying with all the required reflect that all attestations must be requirements specified in PHSA Conditions and Maintenance of approved and submitted by an officer, § 3001(c)(5)(D), except for the ‘‘EHR Certification requirements. A few employee, or other representative the reporting criteria submission’’ commenters were concerned that the health IT developer has authorized to Condition of Certification requirement Condition of Certification requirements make a binding attestation(s) on behalf in § 3001(c)(5)(D)(vii). We proposed to set up unreasonable expectations that of the health IT developer. This implement the Cures Act by requiring health IT developers attest to statements provides regulatory clarity for health IT health IT developers to attest, as that are subject to interpretation and are developers as to their responsibility applicable, to compliance with the ambiguous, and that developers should under the attestation provisions Conditions and Maintenance of be able to articulate how their software (§ 170.406). Certification requirements proposed in and businesses meet the expectations. A requirement of attestation every 6 §§ 170.401 through 170.405. We also received comments months properly balances the need to We proposed that, as a Maintenance suggesting ways to reduce burden for support enforcement actions with the of Certification requirement for the health IT developers. Some commenters attestation burden placed on developers. ‘‘attestations’’ Condition of Certification suggested less frequent attestation In this regard, allegations of requirement under § 170.406(b), health periods ranging from once a year to inappropriate actions and non- IT developers would need to submit every two years as a means for reducing compliance by health IT developers their attestations every 6 months (i.e., burden on health IT developers. with Program requirements and the semiannually). We proposed to provide Another commenter suggested that we information blocking provision can be a 14-day attestation period twice a year. send reminders to health IT developers more readily cross-referenced against For health IT developers presenting when an attestation(s) needs renewal. their attestations for enforcement Health IT Modules for certification for One commenter recommended that we purposes comparative to a one-year or the first time under the Program, we include a specific deadline at the two-year attestation period. Based on proposed that they would be required to middle and end of each year for the efficient methods we are submit an attestation at the time of attestations in lieu of the proposed establishing for attestation as described certification and also comply with the predefined 14-day attestation window. below, we believe that we have semiannual attestation periods. As Another commenter recommended that implemented this statutory requirement stated in the Proposed Rule, we would attestations should only be sent for health IT developers in ways that publicize and prompt developers to electronically as any other process of will reduce the compliance burden for complete their attestation during the reporting (e.g., written letter) would be them. We also refer readers to section required attestation periods. We also onerous on all parties. VII.D of this preamble for discussion of proposed to provide a method for health Response. We thank commenters for ONC direct review, corrective action, IT developers to indicate their their support and have adopted in and enforcement procedures for the compliance, noncompliance with, or the § 170.406 the ‘‘attestations’’ Conditions Conditions and Maintenance of inapplicability of each Condition and and Maintenance of Certification Certification requirements under the Maintenance of Certification requirement with revisions discussed Program. requirement as it applies to all of their below. These revisions should both We recognize comments expressing health IT certified under the Program for provide clarity for compliance and concerns on the potential burden placed each attestation period. Last, we reduce burden. on health IT developers to attest proposed to provide health IT Health IT developers will be attesting semiannually. The process we plan to developers the flexibility to specify to the Conditions of Certification that implement for providing attestations noncompliance per certified Health IT are statutory requirements under section should minimize burden on health IT Module, if necessary. We noted, 4002 of the Cures Act. This final rule developers. To further minimize however, that any noncompliance with also addresses concerns of ambiguity potential burden on health IT the proposed Conditions and and interpretation by revising the developers, we have revised the Maintenance of Certification Conditions and Maintenance of proposed 14-day attestation window to requirements, including the Certification requirements and the extend the window to 30 days. In other ‘‘attestations’’ Conditions and information blocking provision, which words, health IT developers will be able Maintenance of Certification is a Condition of Certification in to submit their attestations within a

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00141 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25782 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

designated 30-day window twice a year to ensure that the health IT developer of than the Maintenance of Certification for purposes of compliance. To note, in the Health IT Module has met its requirements. For example, meeting the accordance with § 170.406(b), the first responsibilities related to the Maintenance of Certification attestation window will begin April 1, Conditions and Maintenance of requirement that requires a health IT 2021. This attestation period will cover Certification requirements as solely developer to not establish or enforce any the time period from the effective date evidenced by its attestation. For contract or agreement that contravenes of the final rule through March 31, 2021. example, if a health IT developer with the Communications Condition of This irregular time period is due to the an active certification under the Certification requirement does not publication of the final rule. Program provided noncompliant excuse a health IT developer from Subsequently, a regular 6-month period designations in their attestation but was meeting all the requirements specified will commence with the attestation already participating in a corrective in the Communications Condition of window for the 6-month period opening action plan (CAP) under ONC direct Certification requirement. This is on October 1, 2021 (attesting for the review to resolve the noncompliance, analogous to clarifications ONC has period of April 1 through September certification would be able to proceed previously provided about certification 30). We have also revised the while the issue is being resolved. criteria requirements whereby testing Conditions and Maintenance of Comments. One commenter requested prior to certification sometimes only Certification requirements to reflect that clarification on the specific tests a subset of the full criterion’s all health IT developers under the responsibilities of ONC–ACBs when intended functions and scope. However, Program would adhere to a similar collecting and submitting attestations to for compliance and surveillance semiannual attestation schedule, rather ONC, including instances of an purposes, we have stated that ONC and than new health IT developers also attestation indicating non-conformity its ONC–ACBs will examine whether attesting at the time of certification. We and the lack of a submission of an the certified health IT meets the full believe this is more practical, less attestation by a health IT developer. scope of the certification criterion rather burdensome for health IT developers Response. We thank commenters for than the subset of functions it was and ONC–ACBs, and creates less their input and have finalized as tested against (80 FR 62709 and 62710). confusion as to what actions and proposed. We refer readers to section Comments. We did not receive any statements a health IT developer is VII.D for further discussion of ONC comments specific to compliance with attesting to (i.e., for past actions under direct review, corrective action, and Maintenance of Certification the Program). enforcement procedures for the requirements as related to meeting As stated in the Proposed Rule, we Conditions and Maintenance of Conditions of Certification plan to implement several other means Certification requirements under the requirements. to minimize burden. First, we plan to Program, including the roles of ONC– Response. We continue to maintain publicize and prompt developers to ACBs in enforcement of the Conditions our position that Maintenance of complete their attestation during the and Maintenance of Certification Certification requirements do not define required attestation periods. Second, as requirements. all of the outcomes necessary to meet proposed in the Proposed Rule, we will the Conditions of Certification 7. EHR Reporting Criteria Submission provide a method for health IT requirements. Thus, while complying developers to indicate their compliance, As stated in the Proposed Rule, the with Maintenance of Certification noncompliance, or the inapplicability of Cures Act specifies that health IT requirements will provide evidence each Condition and Maintenance of developers shall be required, as a toward measuring whether a Condition Certification requirement as it applies to Condition and Maintenance of of Certification requirement is being all or each of their Health IT Modules Certification requirement under the met, reasons beyond the Maintenance of certified under the Program for each Program, to submit certain information Certification requirements could result attestation period. Third, to clarify our to satisfy the reporting criteria on in ONC determining that a Condition of proposal and respond to the comment certified health IT in accordance with Certification requirement has not been recommending electronic submission, the EHR Reporting Program met. requirements established under section we note ONC–ACBs have discretion to D. Enforcement specify the format and may choose to 3009A of the PHSA, as added by section require electronic submission. In 4002 of the Cures Act. We have not yet The Cures Act affirms ONC’s role in addition, to support electronic established an EHR Reporting Program. using certification to improve health submission, we will provide a web- Once ONC establishes such an EHR IT’s capabilities for the access, use, and based form and method for health IT Reporting Program, we will undertake exchange of EHI. The Cures Act developers to submit attestations in an future rulemaking to propose and provides this affirmation through efficient manner for ONC–ACBs’ review. implement the associated Condition and expanded certification authority for Maintenance of Certification ONC to establish Conditions and ONC–ACB Responsibilities requirement(s) for health IT developers. Maintenance of Certification We proposed that attestations would requirements for health IT developers be submitted to ONC–ACBs and C. Compliance that go beyond the certified health IT reviewed in accordance with The Maintenance of Certification itself. The new Conditions and § 170.523(q) as a means for ONC–ACBs requirements discussed above do not Maintenance of Certification to monitor health IT developers for necessarily define all the outcomes requirements in section 4002 of the compliance with Program requirements. necessary to meet the Conditions of Cures Act focus on the actions and ONC–ACBs would be required to share Certification. Rather, they provide business practices of health IT the attestations with ONC. ONC would preliminary or baseline evidence toward developers (e.g., information blocking then make the attestations publicly measuring whether a Condition of and appropriate access, use, and available through the CHPL. The other Certification requirement is being met. exchange of electronic health responsibility we proposed in Thus, ONC could determine that a information) as well as technical § 170.550(l) was that before issuing a Condition of Certification requirement interoperability of health IT (e.g., APIs certification, an ONC–ACB would need is not being met through reasons other and real world testing). Furthermore

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00142 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25783

and equally important, section 4002 of processes in order to properly a. Initiating Review and Health IT the Cures Act provides that the incorporate enforcement of these Developer Notice Secretary of HHS may encourage requirements. We note that the We proposed in 84 FR 7503 to fully compliance with the Conditions and Information Blocking Condition of incorporate the review of compliance Maintenance of Certification Certification (§ 170.401) and the related with the Conditions and Maintenance of requirements and take action to Assurances Condition of Certification Certification requirements into the discourage noncompliance. Given these requirement (§ 170.402(a)(1)) have a provisions of § 170.580(a) and (b). We considerations, we proposed a general delayed enforcement date of 6 months proposed in § 170.580(a)(2)(iii) that if enforcement framework outlining a after date of publication of the final rule. ONC has a reasonable belief that a corrective action process for ONC to health IT developer has not complied review potential or known instances 2. Review and Enforcement Only by with a Condition or Maintenance of where a Condition or Maintenance of ONC Certification requirement, then it may Certification requirement has not been initiate direct review. Similarly, we or is not being met by a health IT We proposed in 84 FR 7503 to retain proposed in § 170.580(b)(1) and (2) that developer under the Program, including use of the term ‘‘direct review’’ as ONC may issue the health IT developer the requirement for a health IT previously adopted in the EOA final a notice of potential non-conformity or developer to attest to meeting the rule to continue to distinguish actions notice of non-conformity and provide Conditions and Maintenance of ONC takes to directly review certified the health IT developer an opportunity Certification requirements. health IT or health IT developers’ to respond with an explanation and actions from actions taken by an ONC– 1. ONC Direct Review of the Conditions written documentation, including any and Maintenance of Certification ACB to review certified health IT under information ONC requests. Requirements surveillance. We proposed, however, Comments. We received one comment that ONC would be the sole party Historically we utilized the processes that ONC should communicate with a responsible for enforcing compliance previously established for ONC direct representative sample of users of a with the Conditions and Maintenance of review of certified health IT in the ONC health IT product when enforcing the Health IT Certification Program: Certification requirements. Conditions and Maintenance of Enhanced Oversight and Accountability Comments. We received comments Certification requirements. Act (EOA) final rule (81 FR 72404), and requesting clarification that ONC–ACBs Response. We appreciate this as codified in §§ 170.580 and 170.581, are not responsible for enforcement of comment. We are committed to to address non-conformities with the Conditions and Maintenance of consistent and thorough enforcement of Program requirements. For multiple Certification requirements. the Conditions and Maintenance of Certification requirements and review of reasons, we proposed in 84 FR 7503 to Response. We have finalized this utilize substantially the same processes complaints of noncompliance. Our goal review and enforcement approach in for the enforcement of the Conditions is to work with developers to remedy and Maintenance of Certification §§ 170.580(a)(1) and 170.580(a)(2)(iii) as any noncompliance in a timely manner. requirements. First, these processes proposed above. We clarify that ONC– During the course of our review of a were designed to address non- ACBs are not responsible for potential noncompliance, we may conformities with Program enforcement of the Conditions and communicate with users of the health requirements. Conditions and Maintenance of Certification IT, as appropriate. We have finalized Maintenance of Certification requirements. Under finalized this approach regarding initiation of requirements have been adopted as § 170.523(s), and as further discussed review and health IT developer notice Program requirements and, as such, any later in this section, ONC–ACBs must in §§ 170.580(a)(2)(iii) and 170.580(b) as noncompliance with the Conditions and report any information that could proposed. inform whether ONC should exercise Maintenance of Certification i. Complaint Resolution requirements constitutes a Program non- direct review of noncompliance with conformity. Second, health IT the Conditions and Maintenance of In the Proposed Rule, we noted and developers are familiar with the ONC Certification requirements to ONC. recommended in 84 FR 7503 that direct review provisions as they were ONC–ACBs also address non- customers and end users first work with established by the EOA final rule in conformities with technical and other their health IT developers to resolve any October 2016. Third, §§ 170.580 and Program requirements through issues of potential noncompliance with 170.581 have provided thorough and surveillance and by working with health the Conditions and Maintenance of transparent processes for working with IT developers through corrective action Certification requirements. We proposed health IT developers through notice and plans. that if the issue cannot be resolved, the corrective action to remedy Program end user should contact the ONC–ACB non-conformities. Last, the direct review 3. Review Processes for assessment. However, as discussed framework has provided equitable above and in section VII.D.5 below, the opportunities for health IT developers to As discussed above, we proposed to ONC–ACB purview for certified health respond to ONC actions and appeal utilize the processes previously IT generally applies to certified certain ONC determinations. established and codified in §§ 170.580 capabilities and limited requirements of As further discussed below, we have and 170.581 for ONC’s direct review developer business practices. We finalized our proposed approach to and enforcement of the Conditions and proposed that if neither of these utilize the processes previously Maintenance of Certification pathways resolves the issue, end users established and codified in §§ 170.580 requirements, along with certain may want to provide feedback to ONC and 170.581 for ONC direct review of proposed revisions and additions to via the Health IT Feedback Form. certified health IT for the enforcement these processes to properly incorporate Comments. We received one comment of the Conditions and Maintenance of enforcement of these requirements and recommending that we require Certification requirements, along with effectuate congressional intent conveyed complaints regarding developer our proposed revisions to these through the Cures Act. compliance with Conditions and

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00143 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25784 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

Maintenance of Certification with minimal effort (e.g., failure to make some of those considerations. These requirements go directly to ONC rather public a documentation hyperlink), considerations include, but are not than to an ONC–ACB. Another while other situations may be more limited to, whether: The party requests commenter requested that we provide complex and require additional time use of correspondence beyond email; guidance regarding how to report issues and effort (e.g., violation of API fee the party has responded via email to our related to developer compliance. prohibitions). Considering this wide communications; we have sufficient Response. We have finalized in range of potential noncompliance with information from the party to ensure § 170.580 our proposed approach the Conditions and Maintenance of appropriate delivery of such notice; and, regarding complaint resolution as Certification requirements, we proposed importantly, the alleged violation of a described above, which is guided by that ONC retain discretion to decide, on Condition or Maintenance of prior Program experience. a case-by-case basis, when to go beyond Certification requirement or other Comments. One commenter the provisions of § 170.505 to use means Program requirement within ONC’s recommended that we adopt a self- other than email in providing notices purview under § 170.580 indicates a disclosure mechanism for health IT and correspondence for noncompliance serious violation of the Program with developers to report any non-conformity with the Conditions and Maintenance of potential consequences of suspension, with the Program and enable such self- Certification requirements. certification termination, or a disclosure to offer health IT developers We solicited comment on the nature certification ban. regulatory protection. and types of noncompliance with the We did not propose any requirements Response. We appreciate the Conditions and Maintenance of regarding acknowledgment of receipt, comment and strongly encourage self- Certification requirements that ONC and we have finalized our proposed disclosure by developers, which health should consider in determining the approach to utilize the processes IT developers currently do under the method of correspondence. We also previously established and codified in Program. We note that currently there solicited comment on whether the type §§ 170.580 and 170.581 for ONC direct are methods by which health IT of notice should determine the method review of certified health IT for the developers may communicate with of correspondence. More specifically, enforcement of the Conditions and ONC–ACBs and/or ONC, and it is our we solicited comment on whether Maintenance of Certification longstanding policy to work with health certain types of notices under direct requirements, which include response IT developers to correct non- review should be considered more requirements already codified in conformities. While we believe this critical than others, thus requiring a §§ 170.580 and 170.581. approach works well, consistent with specific method of correspondence. Comments. One commenter requested Executive Order 13892, we are Comments. We received several clarification on ONC’s timeframe for considering whether it would be comments regarding the proposed responding to health IT developers appropriate to adopt additional method of correspondence with health during direct review. Another procedures that further encourage self- IT developers. Some commenters commenter requested clarity on reporting of non-conformities and stressed that time-sensitive notifications investigation timelines generally. voluntary information sharing, as well should not be sent via email, with one Response. We have finalized our as procedures to provide pre- commenter noting that ONC should use proposed approach to utilize the enforcement rulings to health IT certified mail, with a copy to a processes previously established and developers who make inquiries designated notice recipient, for notices currently codified in §§ 170.580 and regarding their compliance with of potential noncompliance and 170.581 for ONC’s direct review and regulatory requirements. noncompliance with the Conditions and enforcement of the Conditions and Maintenance of Certification Maintenance of Certification ii. Method of Correspondence With requirements. Other commenters requirements, which include specific Health IT Developers suggested that ONC should use both response timeframes throughout the Section 170.505 states that email and certified mail for notices direct review process. We refer correspondence and communication regarding initiation of direct review, commenters to §§ 170.580 and 170.581 with ONC or the National Coordinator potential non-conformity, non- for the timeframes applicable to the shall be conducted by email, unless conformity, suspension, proposed various steps in the direct review otherwise necessary or specified. We termination, and termination. One process. We also clarify that proposed noted in the Proposed Rule in 84 FR commenter recommended ONC termination and suspension are 7503 that in the EOA final rule we acknowledge receipt of communications excluded from ONC’s direct review signaled our intent to send notices of received. process for the Conditions and potential non-conformity, non- Response. We appreciate commenters’ Maintenance of Certification conformity, suspension, proposed support of our proposals, as well as the requirements, so any timeframes related termination, and termination via constructive suggestions. We have to proposed termination and suspension certified mail (81 FR 72429). However, finalized our proposal to use the do not apply. we proposed to follow § 170.505 for provisions in § 170.505 for correspondence regarding direct review correspondence regarding b. Relationship With ONC–ACBs and of noncompliance with the Conditions noncompliance with the Conditions and ONC–ATLs and Maintenance of Certification Maintenance of Certification Section 170.580(a)(3) outlines ONC requirements. requirements, with minor revisions. direct review in relation to the roles of As discussed in the Proposed Rule, While we agree with commenters that ONC–ACBs and ONC–ATLs, which we the type and extent of review by ONC there may be situations when sending proposed to revise to incorporate the could vary significantly based on the notice only via email would not be Conditions and Maintenance of complexity and severity of each fact adequate, such situations would be Certification requirements. In the pattern. For instance, ONC may be able contingent on the circumstances as Proposed Rule in 84 FR 7507, we to address certain noncompliance with described in the Proposed Rule. provided situational examples in the Conditions and Maintenance of Therefore, we have revised the section VII.D.5 ‘‘Effect on Existing Certification requirements quickly and regulation text of § 170.505 to specify Program Requirements and Processes’’

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00144 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25785

regarding ONC direct review and the Comments. We received one comment review for noncompliance with a role of an ONC–ACB. As finalized in the recommending that ONC detail the Condition or Maintenance of EOA final rule and per procedural and technical safeguards in Certification requirement failed to work § 170.580(a)(3)(v), we stressed that ONC place to protect information submitted with ONC or was otherwise may refer the applicable part of its to ONC by a developer as part of direct noncompliant with the requirements of review of certified health IT to the review of compliance with a Conditions the CAP and/or CAP process, ONC relevant ONC–ACB(s) if ONC or Maintenance of Certification could issue a certification ban for the determines this would serve the requirement. health IT developer (and its subsidiaries effective administration or oversight of Response. As we stated above, in the and successors). A certification ban, as the Program (81 FR 72427 and 72428). Proposed Rule, and in the EOA final it currently does for other matters under We did not receive comments on this rule (81 FR 72429), we will implement § 170.581, would prohibit future health specific aspect of the proposed rule and appropriate safeguards to ensure, to the IT by the health IT developer from being have finalized the relationship with extent permissible with Federal law, certified. ONC–ACBs and ONC–ATLs in that any proprietary business We proposed in 84 FR 7504 that ONC § 170.580(a)(3) as proposed. information or trade secrets ONC may would also consider termination of the encounter by accessing the health IT certificate(s) of the affected Health IT c. Records Access developer’s records, other information, Module(s) should the health IT We proposed in 84 FR 7504 to revise or technology, will be kept confidential developer fail to work with ONC or is § 170.580(b)(3) to ensure that ONC, or by ONC or any third parties working on otherwise noncompliant with the third parties acting on its behalf, have behalf of ONC. We have finalized in requirements of the CAP and/or CAP access to the information necessary to § 170.580(b)(3) our approach regarding process. We proposed that ONC may enforce the Conditions and Maintenance records access as proposed. consider termination if there is a nexus of Certification requirements. As Additionally, we have finalized our between the developer’s actions or specified in § 170.580(b)(1)(ii)(A)(2), recommendation, stated in 84 FR 7504 business practices in relation to the (b)(2)(ii)(A)(2) and (b)(3), in response to in the Proposed Rule and the EOA final Conditions and Maintenance of a notice of potential non-conformity or rule, that health IT developers clearly Certification requirements and the notice of non-conformity, ONC must be mark, as described in HHS Freedom of functionality of the affected certified granted access to, and have the ability Information Act regulations at 45 CFR Health IT Module(s). For example, as to share within HHS, with other Federal 5.65(c), any information they regard as discussed in the Proposed Rule, ONC agencies, and with appropriate entities, trade secret or confidential prior to may determine that a health IT all of a health IT developers’ records disclosing the information to ONC (81 developer is violating a Condition of and technology related to the FR 72431). Certification requirement due to a development, testing, certification, clause in its contracts that prevents its implementation, maintenance, and use d. Corrective Action users from sharing or discussing of its certified health IT, and any We proposed in 84 FR 7504 that if technological impediments to complaint records related to the ONC determines that a health IT information exchange. In this example, certified health IT. ‘‘Complaint records’’ developer is noncompliant with a the health IT developer’s conduct would include, but are not limited to issue logs Condition or Maintenance of violate the Communications Condition and help desk tickets (81 FR 72431). We Certification requirement (i.e., a non- of Certification requirement that we proposed in 84 FR 7504 to supplement conformity), ONC would work with the have finalized in § 170.403. If the same these requirements with a requirement health IT developer to establish a conduct were also found to impair the that a health IT developer make corrective action plan (CAP) to remedy functionality of the certified Health IT available to ONC, and third parties the issue through the processes Module (such as by preventing the acting on its behalf, records related to specified in § 170.580(b)(2)(ii)(A)(4) and proper use of certified capabilities for marketing and distribution, (c). We noted that a health IT developer the exchange of EHI), ONC may communications, contracts, and any may be in noncompliance with more determine that a nexus exists between other information relevant to than one Condition or Maintenance of the developer’s business practices and compliance with any of the Conditions Certification requirement. In such cases, the functionality of the certified Health and Maintenance of Certification we proposed that ONC would follow the IT Module, and may consider requirements or other Program proposed compliance enforcement termination of the certificate(s) of that requirements. If ONC determined that a process for each Condition or particular Health IT Module under the health IT developer was not cooperative Maintenance of Certification proposed approach. with the fact-finding process, we requirement accordingly, but may also We proposed this approach, which proposed ONC would have the ability to require the health IT developer to allows ONC to initiate a certification issue a certification ban and/or address all violations in one CAP for ban and/or certificate termination under terminate a certificate (see § 170.581 efficiency of process. We also proposed, certain circumstances, to ensure that discussed below and as we currently do with CAPs for health IT developers are acting in § 170.580(f)(1)(iii)(A)(1)). certified health IT, to list health IT accordance with the Conditions and We proposed in 84 FR 7504 that ONC developers under a CAP on ONC’s Maintenance of Certification would implement appropriate website. requirements. However, we stressed that safeguards to ensure, to the extent We did not receive any comments on our first and foremost priority is to work permissible with Federal law, that any this aspect of the Proposed Rule, and in with health IT developers to remedy any proprietary business information or § 170.580(c) we have finalized our noncompliance with Conditions and trade secrets ONC may encounter by proposals regarding corrective action as Maintenance of Certification accessing the health IT developer’s proposed (84 FR 7504). requirements through a corrective action records, other information, or process before taking further action. technology, would be kept confidential e. Certification Ban and Termination This emphasizes ONC’s desire to by ONC or any third parties working on We proposed in 84 FR 7504 that if a promote and support health IT behalf of ONC. health IT developer under ONC direct developer compliance with the

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00145 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25786 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

Conditions and Maintenance of health IT developer is noncompliant may impact health care providers that Certification requirements, and ensure with a Condition or Maintenance of are users of that product for HHS that certified health IT is compliant Certification requirement more than program participation, ONC would with Program requirements, in order to once (e.g., a minimum six months for continue to support HHS and other foster an environment where EHI is two instances, a minimum of one year Federal and State partners, such as exchanged in an interoperable way. for three instances). We also sought CMS, to help identify and make We proposed in 84 FR 7505 that in comment on whether additional factors available appropriate remedies for users considering whether termination of a should be considered for a certification of terminated certified health IT. This Health IT Module’s certificate(s) and/or ban and/or termination of a health IT would include supporting policies to a certification ban is appropriate, ONC developer’s certified health IT. mitigate negative impacts on providers, would consider factors including, but Comments. We received several such as the availability of hardship not limited to: Whether the health IT comments regarding a minimum ban exceptions for the Promoting developer has previously been found in length for repeat offenders. A couple of Interoperability (PI) Programs for noncompliance with the Conditions and the commenters recommended ONC hospitals as mandated by section Maintenance of Certification or other establish a minimum ban and agreed 4002(b)(1)(A) and (b)(2) of the 21st Program requirements; the severity and with ONC’s examples listed above. Century Cures Act and finalized by CMS pervasiveness of the noncompliance, Other commenters stated that a in the FY 2018 Inpatient Prospective including the effect of the minimum ban would not be Payment System final rule (80 FR 38488 noncompliance on widespread appropriate, with one commenter through 38490). interoperability and health information stating that a minimum ban could have Comments. We received one comment exchange; the extent to which the health unintended consequences and another that ONC should add a fine as part of IT developer cooperates with ONC to commenter stating that it would be the enforcement of the Conditions and review the noncompliance; the extent of better if the length of the ban was Maintenance of Certification potential negative impact on providers determined situationally. requirements. Response. We have finalized the who may seek to use the certified health Response. We appreciate this provisions regarding termination and IT to participate in CMS programs; and comment, but ONC does not have the certification ban in §§ 170.580 and whether termination and/or a authority to add a monetary fine as part 170.581 as proposed. We have not certification ban is necessary to ensure of the enforcement of the Conditions established a minimum ban length for the integrity of the certification process. and Maintenance of Certification In the Proposed Rule, we noted in 84 repeat offenders, as a reinstatement requirements. We note, however, that FR 7505 that, as found in § 170.580(f)(2), process has been established in health IT developers are subject to civil ONC would provide notice of the § 170.581(d) that affords ONC the termination to the health IT developer, discretion to determine whether a monetary penalties (CMPs) if they including providing an explanation for, developer has demonstrated appropriate engage in information blocking, and that information supporting, and remediation to all customers affected by a health IT developer must not take any consequences of, the termination, as the certificate termination, certificate action that constitutes information well as instructions for appealing the withdrawal, or noncompliance with a blocking as a Condition of Certification termination. We proposed to add Condition or Maintenance of requirement (§ 170.401). substantially similar notice provisions Certification requirement. Section Comments. One commenter to § 170.581 for certification bans issued 170.581(d)(4) allows ONC to grant recommended that certification bans under ONC direct review for reinstatement into the Program if ONC apply not only to health IT developers noncompliance with the Conditions and is satisfied with a health IT developer’s who are noncompliant, but also to the Maintenance of Certification demonstration of appropriate individual management representatives requirements. These provisions would remediation, and ONC may consider involved, and that account migration also include instructions for requesting any and all factors, including past bans, review plans be required as an aspect of reinstatement. In this regard, in 84 FR that may affect ONC’s decision to grant enforcement in order to address issues 7505 we proposed to apply the current reinstatement into the Program. around creation of new legal entities in reinstatement procedures under Comments. We received several response to a certification ban. § 170.581 to certification bans resulting comments expressing concern for how Response. We appreciate these from noncompliance with the physicians using products whose comments and note that certification Conditions and Maintenance of developer has been banned would be bans affect health IT developers Certification requirements, but with an impacted with respect to payment participating in the Program, their additional requirement that the health programs. subsidiaries, and their successors (81 FR IT developer has resolved the Response. We appreciate these 72443). We do not have the authority to noncompliance with the Condition or comments and clarify that the health IT regulate or enforce against individual Maintenance of Certification products of a health IT developer under management representatives, though we requirement. In sum, we proposed that a certification ban (not certificate believe the certification ban’s reach is a health IT developer could seek ONC’s termination) would still be considered an appropriate and sufficient incentive approval to re-enter the Program and certified. This means that those for health IT developers to resolve any have the certification ban lifted if it products would still be available for use noncompliance and meet all required demonstrates that it has resolved the by providers participating in programs conditions. As stated previously, we are noncompliance with the Condition or requiring the use of certified health IT. utilizing processes previously Maintenance of Certification However, while under a ban, a health IT established for ONC direct review of requirement, and ONC is satisfied that developer could not make updates to certified health IT for the enforcement all affected customers have been the certification of those products. This of the Conditions and Maintenance of provided appropriate remediation. We means that access to new certified Certification requirements, which we sought comment on whether ONC functionalities within a health IT believe are familiar to health IT should impose a minimum time period developer’s products would be limited. developers and provide a transparent for a certification ban, such as when a If the certification status of a product process for working with health IT

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00146 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25787

developers to remedy instances of Comments. One commenter stated Comments. We received a number of noncompliance. that in instances of information comments generally supporting our Comments. One commenter expressed blocking, the termination of a Health IT proposal to utilize the Appeals concern that there is no process for Module’s certificate or issuance of a processes in our enforcement of measuring the severity of a finding of certification ban should not occur until compliance with the Condition or noncompliance, and ONC’s proposed the health IT developer has had the Maintenance of Certification enforcement approach would allow for opportunity to respond to the charge of requirements. banning of all of a health IT developer’s information blocking and appeal the Response. We appreciate the certified health IT based on a finding of finding. comments expressing support for our noncompliance. The commenter Response. As stated previously, we proposal and have finalized our requested that the final rule specify have finalized in §§ 170.580 and proposal and proposed revisions to circumstances that could lead to this 170.581 our proposed approach to § 170.580(g) to incorporate ONC direct serious result. utilize the processes previously review of compliance with the Response. We appreciate the established for ONC direct review of Conditions and Maintenance of comment and clarify that, as proposed, certified health IT for the enforcement Certification requirements. of the Conditions and Maintenance of if a health IT developer under ONC g. Suspension Certification requirements. These direct review for noncompliance with a We proposed in 84 FR 7506 to not Condition of Certification requirement processes are open and transparent, and they provide an opportunity for health apply the suspension processes under failed to work with ONC to correct the § 170.580 to our review of compliance noncompliance, or was noncompliant IT developers to remedy instances of noncompliance through corrective with the Conditions and Maintenance of with the requirements of the CAP, ONC Certification requirements. Section could issue a certification ban. action. We again stress that it is our priority to first work with health IT 170.580 includes a process for However, we stress that our priority is suspending the certification of a Health to first work with health IT developers developers to correct any noncompliance with the Conditions and IT Module at any time if ONC has a to correct any noncompliance with the Maintenance of Certification reasonable belief that the certified Conditions and Maintenance of requirements through corrective action. health IT may present a serious risk to Certification requirements through We believe these processes provide public health and safety. While this will corrective action. As stated in the ample opportunity for a health IT remain the case for certified health IT Proposed Rule in 84 FR 7505, factors we developer to respond to and address under ONC direct review (i.e., would consider prior to issuing a information blocking prior to issuance suspension of certification is always certification ban, or termination of a of a certification ban or termination of available under ONC direct review Health IT Module’s certificate, include a Health IT Module’s certificate. when the certified health IT presents a whether the health IT developer has Comments. We received one comment serious risk to public health and safety), previously been found in stating that the final rule should provide we do not believe such circumstances noncompliance with the Conditions and for an emergency remedy when the would apply to noncompliance with the Maintenance of Certification blocking of information places an Conditions or Maintenance of requirements or other Program individual at risk of immediate harm. Certification requirements. Further, we requirements; the severity and Response. Our current process for believe the more streamlined processes pervasiveness of the noncompliance; direct review enables ONC to respond proposed for addressing noncompliance cooperation on the part of the health IT appropriately in the case of certified with Conditions and Maintenance of developer during ONC review; potential health IT that may be causing or Certification requirements alleviates the negative impact on providers contributing to conditions that present a need to proceed through a suspension participating in CMS programs; and serious risk to public health or safety process. whether termination and/or a (§§ 170.580(a)(2)(i) and 170.580(d)(1)). Comments. We received a number of certification ban is necessary to ensure We also refer readers to the information comments generally supporting our the integrity of the certification process. blocking section in this final rule proposal not to include Suspension in We clarify that while under a CAP or (section VIII of preamble and Part 171) our enforcement of compliance with the surveillance by ONC or an ONC–ACB, for a detailed discussion regarding the Condition or Maintenance of in the event a health IT developer’s information blocking provision and the Certification requirements. approach to remedy a non-conformity exceptions to the information blocking Response. We appreciate the and/or to meet Program requirements is definition, including those designed to comments expressing support for our to withdraw their current certificate(s) prevent harm to patients and others. proposal and have finalized our for replacement with a new certificate proposal as proposed. issued by the ONC–ACB to reflect a new f. Appeal scope, they will not be subject to a We proposed in 84 FR 7505 that a h. Proposed Termination certification ban. We note that any open health IT developer would have an We proposed in 84 FR 7506 to not non-conformities will be transferred to opportunity to appeal an ONC include an intermediate step between a the newly issued certificate(s) and must determination to issue a certification developer failing to take appropriate still be resolved by the health IT ban and/or certificate termination and timely corrective action and developer. Similarly, when an ONC– resulting from noncompliance with a termination of a certified Health IT ACB issues a new certificate to reflect Condition or Maintenance of Module’s certificate called ‘‘proposed 2015 Edition changes, and must Certification requirement. We proposed termination’’ (see § 170.580(e) and 81 withdraw a health IT developer’s to follow the processes specified in FR 72437)). Rather, as discussed above, current certificate to do so, the health IT § 170.580(g). As such, we proposed to ONC may proceed directly to issuing a developer will not be subject to a revise § 170.580(g) to incorporate ONC certification ban or notice of termination certification ban if the developer is direct review of compliance with the if it determines a certification ban and/ currently under a CAP or has health IT Conditions and Maintenance of or certificate termination are with open non-conformities. Certification requirements. appropriate per the considerations

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00147 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25788 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

discussed above. The Conditions and and certificate terminations, including a avenues for investigating non- Maintenance of Certification comment recommending that the public conformities with certified Health IT requirements focus on developer listing show the start and end date of Modules will continue to exist under business practices and actions for bans that were lifted. We also received the Program and generally focus on which, as previously discussed, one comment recommending that ONC functionality and performance of noncompliance is likely to undermine differentiate reinstated developers on certified health IT, or on more limited the integrity of the Program and impede the public listing. We also received one requirements of business practices of widespread interoperability and comment that there should be an option health IT developers found in subparts information exchange. As such, we for a ban to be lifted once the developer A, B, C and E of Part 170, respectively. stated that it is appropriate and comes into compliance. Thus, there may be instances where one consistent with the Cures Act to proceed Response. Responsive to comments or more Condition or Maintenance of immediately to a certification ban and/ and in order to support transparency, Certification requirement is not being or or termination of the affected Health IT we have decided not to set a time limit has not been met that also relate to Module’s certificate(s) if a developer for listings on the Certified Health IT certified Health IT Module non- does not take appropriate and timely Product List (CHPL) and to also provide conformities under subparts A, B, C and corrective action. A certification ban the start and end dates of bans that were E. We proposed that under these and/or termination serves as an lifted. We clarify that the CHPL situations, ONC could in parallel appropriate disincentive for provides transparency regarding implement both sets of processes— noncompliance with the Conditions and certified health IT listings, including existing processes to investigate Health Maintenance of Certification historical non-conformities assessed IT Module non-conformities and the requirements. through surveillance, even after the non- proposed process to enforce compliance Comments. We received a number of conformity is resolved. This approach to with the Conditions and Maintenance of comments generally supporting our historical transparency is applied to Certification requirements. We stressed, proposal not to include Proposed certification bans as well. We also however, that under the proposed Termination in our enforcement of clarify that a certification ban can be enforcement approach, only ONC would compliance with the Condition or lifted as long as the developer has have the ability to determine whether a Maintenance of Certification resolved the noncompliance and met all Condition or Maintenance of requirements. required conditions. We refer readers to Certification requirement per subpart D Response. We appreciate the § 170.581 for details about the has been or is being met. comments expressing support for our certification ban and reinstatement We proposed to delineate the scope of proposal and have finalized our processes. an ONC–ACB’s requirements to perform proposal as proposed. surveillance on certified Health IT 5. Effect on Existing Program Modules as related only to the 4. Public Listing of Certification Ban Requirements and Processes and Termination requirements of subparts A, B, C and E The Cures Act introduced new of Part 170. Given our proposed We proposed in 84 FR 7506 to Conditions and Maintenance of approach that would authorize solely publicly list on ONC’s website health IT Certification requirements that ONC to determine whether a Conditions developers and certified Health IT encompass technical and functional or Maintenance of Certification Modules that are subject to a requirements of health IT and new requirement per subpart D has been or certification ban and/or have been actions and business practice is being met, we proposed in 84 FR 7506 terminated, respectively, for requirements for health IT developers, to add a new PoPC for ONC–ACBs in noncompliance with a Condition or which we proposed to adopt in subpart § 170.523(s) that would require ONC– Maintenance of Certification D of Part 170. The pre-Cures Act ACBs to report to ONC, no later than a requirement or for reasons already structure and requirements of the week after becoming aware, any specified in § 170.581. We take this Program provide processes to enforce information that could inform whether same approach for health IT with compliance with technical and ONC should exercise direct review for terminated certifications (see 81 FR functional requirements of certified noncompliance with a Condition or 72438). Public listing serves to health IT, and to a more limited extent, Maintenance of Certification discourage noncompliance with requirements for the business practices requirement or any matter within the Conditions and Maintenance of of health IT developers (see, e.g., 45 CFR scope of ONC direct review. We did not Certification and other Program 170.523(k)(1)) under subparts C receive specific comments on this requirements, while encouraging (Certification Criteria for Health section of the Proposed Rule and have cooperation with ONC and ONC–ACBs Information Technology) and E (ONC finalized this approach regarding and remediation of non-conformities. It Health IT Certification Program) of Part delineation of the review activities of also serves to provide notice to all 170. ONC–ACBs are required to perform ONC and ONC–ACBs in §§ 170.580 and ONC–ATLs, ONC–ACBs, public and surveillance on certified Health IT 170.581 as proposed. private programs requiring the use of Modules and may investigate reported certified health IT, and consumers of allegations of non-conformities with 6. Coordination With the Office of the certified health IT of the status of Program requirements under subparts A, Inspector General certified health IT and health IT B, C, and E, with the ultimate goal of We clarified in the Proposed Rule in developers operating under the working with the health IT developer to 84 FR 7507 that the enforcement Program. We sought comment on this correct the non-conformity. Under approach would apply only to ONC’s proposal, including input on the certain circumstances, such as unsafe administration of the Conditions and appropriate period of time to list health conditions or impediments to ONC– Maintenance of Certification IT developers and affected certified ACB oversight, ONC may directly requirements and other requirements Health IT Modules on healthit.gov. review certified health IT to determine under the Program, but it would not Comments. We received several whether it conforms to the requirements apply to other agencies or offices that recommendations that we should enable of the Program (see § 170.580 and the have independent authority to indefinite posting of certification bans EOA final rule at 81 FR 72404). These investigate and take enforcement action

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00148 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25789

against a health IT developer of certified reporting and investigating claims of policies and procedures for reviewing health IT. Notably, section potential information blocking. To that and triaging complaints. We will 3022(b)(1)(A)(ii) of the PHSA, as added end, ONC and OIG are actively continue to work with OIG to establish by the Cures Act, authorizes the OIG to coordinating on establishing referral coordinated and aligned procedures and investigate claims that a health IT policies and procedures to ensure the reviews of information blocking developer of certified health IT has timely and appropriate flow of complaints as envisioned by the Cures engaged in information blocking, which information related to information Act. We also emphasize that in order to is defined by section 3022(a)(1) of the blocking complaints. We also note that promote effective enforcement, the PHSA as subject to reasonable and the information blocking section of this information blocking provision of the necessary activities identified by the final rule (part 171) has a delayed Cures Act empowers OIG to investigate Secretary as exceptions to the definition compliance date of 6 months after date claims of information blocking and as proposed in part 171 (see section of publication of the final rule. provides referral processes to facilitate VIII.D of this final rule). Additionally, OIG and ONC are also coordinating coordination with other relevant section 3022(b)(1)(A)(i) authorizes OIG timing of the effective date of this final agencies, including ONC, OCR, and the to investigate claims that a health IT rule and the start of information Federal Trade Commission (FTC). developer of certified health IT has blocking enforcement and enforcement Future notice and comment rulemaking submitted a false attestation under the of the Conditions of Certification related by OIG will provide more additional Condition of Certification requirement to information blocking (§ 170.401, detail regarding information blocking which is described at section § 170.404(a)(1), and § 170.406(a)(1)). We enforcement. 3001(c)(5)(D)(vi) of the Cures Act. We are providing the following information We clarify that there could be emphasized that ONC’s and OIG’s on timing for actors regulated by the situations when a health IT developer of respective authorities under the Cures information blocking provision. certified health IT’s practices could be Act (and in general) are independent Enforcement of information blocking reviewed by both ONC and OIG because and that either or both offices may civil monetary penalties (CMP) in ONC and OIG have separate and distinct exercise those authorities at any time. section 3022(b)(2)(A) of the PHSA will enforcement authority regarding claims We noted, however, that ONC and not begin until established by future of information blocking. We explained OIG may coordinate their respective notice and comment rulemaking by OIG. in the Proposed Rule that ONC has information blocking activities, as As a result, actors would not be subject statutory authority to enforce the appropriate, such as by sharing to penalties until CMP rules are final. At Information Blocking Condition and information about claims or suggestions a minimum, the timeframe for Maintenance of Certification of possible information blocking or false enforcement would not begin sooner requirements (§ 170.401) and that ONC attestations (including violations of than the compliance date of the would enforce the Conditions of Conditions and Maintenance of information blocking provision and will Certification requirements through the Certification requirements that may depend on when the CMP rules are direct review process. OIG has indicate that a developer has falsely final. Discretion will be exercised such investigatory authority for the attested to meeting a Condition or that conduct that occurs before that time information blocking provision (42 Maintenance of Certification will not be subject to the information U.S.C. 300jj-52(b)), which may lead to requirement). Therefore, we proposed in blocking CMPs. Individuals and entities the issuance of (CMPs) for information 84 FR 7507 that we may coordinate our are subject to the information blocking blocking conducted by health IT review of a claim of information regulations and must comply with this developers of certified health IT, health blocking with OIG or defer to OIG to rule as of the compliance date of this information networks, and health lead a review of a claim of information provision. information exchanges. OIG may also blocking. In addition, we proposed that The Cures Act directs the National investigate health care providers for we may rely on OIG’s findings to form Coordinator to implement a information blocking, which could the basis of a direct review action. standardized process for the public to result in health care providers being Comments. The majority of comments submit reports on claims of health subject to appropriate disincentives. In received supported the general information blocking. ONC intends to addition, OIG may investigate false enforcement approach proposed by implement and evolve this complaint attestations by health IT developers ONC. We did receive one comment process by building on existing participating in the Program. Since recommending that we use a process mechanisms, including the current ONC ONC’s and OIG’s respective authorities similar to OCR’s enforcement of the complaint process. We requested with regard to information blocking HIPAA Rules and centralize comment in the Proposed Rule on ways under the Cures Act (and in general) are enforcement of patient and provider to adapt our current complaint process independent, it is necessary that either rights with respect to privacy and access for claims of information blocking and or both offices may exercise those to EHI. Additionally, we received refer readers to section VIII.F of this authorities at any time. several comments seeking clarification final rule for a more detailed discussion However, we emphasize, as we regarding ONC’s coordination with OIG of the complaint process for claims of explained above in the Proposed Rule, and one expressing concern about the information blocking. OIG also has the that we anticipate that ONC and OIG potential for a developer to be under ability to receive and review complaints will coordinate their respective review by both OIG and ONC for the directly from the public. This ensures information blocking activities, as same conduct. that there is no ‘‘wrong door’’ by which appropriate, such as by sharing Response. We welcome the many a complainant can submit information. information about claims or suggestions comments in support of our proposed OIG will provide training to allow their of possible information blocking or false enforcement approach. We also investigators to identify information attestations (including violations of appreciate the comment regarding using blocking allegations as part of their Conditions and Maintenance of processes similar to OCR and other fraud and abuse investigations. Certification requirements that may centralizing enforcement of privacy and Additionally, as part of their continued indicate that a developer has falsely access rights. We agree that it is crucial efforts to implement the information attested to meeting a Condition or that we develop clear processes for blocking authorities, OIG will establish Maintenance of Certification

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00149 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25790 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

requirement). Therefore, we have VIII. Information Blocking into sharp focus in recent years. In 2015, at the request of Congress, we submitted finalized in § 170.580(a)(4) the proposed A. Statutory Basis approach that will allow us to a Report on Health Information coordinate our review of a claim of Section 4004 of the Cures Act added Blocking 117 (‘‘Information Blocking information blocking with the OIG, or section 3022 of the Public Health Congressional Report’’), in which we defer to OIG to lead a review of a claim Service Act (PHSA) (42 U.S.C. 300jj–52, commented on the then-current state of of information blocking. In addition, the ‘‘the information blocking provision’’). technology and of health IT and health Section 3022(a)(1) of the PHSA defines finalized approach will allow ONC to care markets. Notably, we observed that practices that constitute information rely on OIG findings to form the basis prevailing market conditions create blocking when engaged in by a health of a direct review action. incentives for some individuals and care provider, or a health information entities to exercise control over EHI in 7. Applicability of Conditions and technology developer, exchange, or ways that limit its availability and use Maintenance of Certification network. Section 3022(a)(3) authorizes (84 FR 7508). Requirements for Self-Developers the Secretary to identify, through notice We noted that we have continued to and comment rulemaking, reasonable receive complaints and reports of The HHS regulation that established and necessary activities that do not information blocking from patients, the Program, ‘‘Establishment of the constitute information blocking for clinicians, health care executives, Permanent Certification Program for purposes of the definition set forth in payers, app developers and other Health Information Technology’’ (76 FR section 3022(a)(1). We proposed in the technology companies, registries and 1261), addresses self-developers and Proposed Rule to establish exceptions to health information exchanges, describes the concept of ‘‘self- the information blocking definition, professional and trade associations, and developed’’ as referring to a Complete each of which would define certain many other stakeholders. We noted that EHR or EHR Health IT Module activities that would not constitute ONC has listened to and reviewed these designed, created, or modified by an information blocking for purposes of complaints and reports, consulted with entity that assumed the total costs for section 3022(a)(1) of the PHSA because stakeholders, and solicited input from testing and certification and that will be they are reasonable and necessary to our Federal partners in order to inform the primary user of the health IT (76 FR further the ultimate policy goals of the our proposed information blocking 1300 and 1301). While we proposed in information blocking provision. We also policies. Stakeholders described 84 FR 7508 in the ‘‘Enforcement’’ proposed to interpret or define certain discriminatory pricing policies that section of the Proposed Rule that all statutory terms and concepts that are have the obvious purpose and effect of general Conditions and Maintenance of ambiguous, incomplete, or provide the excluding competitors from the use of Certification requirements apply to such Secretary with discretion, and that we interoperability elements. Many developers, we also sought comment on believe are necessary to carry out the industry stakeholders who shared their which aspects of the Conditions and Secretary’s rulemaking responsibilities perspectives with us in listening Maintenance of Certification under section 3022(a)(3) (84 FR 7522). sessions, including several health IT developers of certified health IT, requirements may not be applicable to B. Legislative Background and Policy self-developers. condemned these practices and urged us Considerations to swiftly address them. We highlighted Comments. We received one comment In the Proposed Rule, we outlined the that our engagement with stakeholders that self-developers should not be purpose of the information blocking confirmed that, despite significant permitted to rely on the exception provision and related policy and public and private sector efforts to available under the ‘‘Communications’’ practical considerations that we improve interoperability and data Condition of Certification requirement considered in identifying the reasonable accessibility, adverse incentives remain that allows developers to place limited and necessary activities that we and continue to undermine progress restrictions on the communications of proposed as exceptions to the toward a more connected health system their employees who are using their information blocking definition (84 FR (84 FR 7508). products. 7508). Based on these economic realities and our first-hand experience working with Response. We agree with the 1. Purpose of the Information Blocking comment that self-developers should the health IT industry and stakeholders, Provision in the Information Blocking not be allowed to restrict the We explained in the Proposed Rule Congressional Report, we concluded communications of users of their that the information blocking provision that information blocking is a serious product who are also employees. We was enacted in response to concerns problem, and recommended that have revised the language of the that some individuals and entities are Congress prohibit information blocking ‘‘Communications’’ Condition of engaging in practices that unreasonably and provide penalties and enforcement Certification requirement in limit the availability and use of mechanisms to deter these harmful § 170.403(a)(2)(ii)(A)(2) to clarify that electronic health information (EHI) for practices (84 FR 7508). the limited prohibitions developers may authorized and permitted purposes. We noted in the Proposed Rule that place on employees under the Condition These practices undermine public and recent empirical and economic research of Certification requirement cannot be private sector investments in the further underscores the intractability of placed on users of the developers’ nation’s health IT infrastructure, and this problem and its harmful effects. In products who also happen to be frustrate efforts to use modern a national survey of health information employees or contractors of the technologies to improve health care organizations, half of respondents developer. Overall, we intend to hold quality and efficiency, accelerate reported that EHR developers routinely self-developers to all Conditions and research and innovation, and provide Maintenance of Certification greater value and choice to health care 117 ONC, Report to Congress on Health requirements of health IT developers, as Information Blocking (Apr. 2015), https:// consumers (84 FR 7508). www.healthit.gov/sites/default/files/reports/info_ applicable based on the health IT We emphasized that the nature and blocking_040915.pdf [hereinafter ‘‘Information certified. extent of information blocking has come Blocking Congressional Report’’].

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00150 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25791

engage in information blocking, and a General (OIG) to investigate claims of challenges that may prevent access to, quarter of respondents reported that information blocking and provides for exchange, or use of EHI in certain hospitals and health systems routinely referral processes to facilitate situations. We also explained our goal to do so. The survey reported that coordination among Federal agencies, accommodate practices that, while they perceived motivations for such conduct including ONC, the HHS Office for Civil may inhibit access, exchange, or use of included, for EHR vendors, maximizing Rights (OCR), and the Federal Trade EHI, are reasonable and necessary to short-term revenue and competing for Commission (FTC). The information advance other compelling policy new clients, and for hospitals and blocking provision also provides for a interests, such as preventing harm to health systems, strengthening their process for the public to submit reports patients and others, promoting the competitive position relative to other on claims of information blocking as privacy and security of EHI, and hospitals and health systems.118 We well as confidentiality protections to promoting competition and consumer noted that other research suggests that encourage and facilitate the reporting of welfare (84 FR 7509). these practices weaken competition information blocking. Enforcement of At the same time, we explained that among health care providers by limiting the information blocking provision is we sought to provide a comprehensive patient mobility, encouraging buttressed by section 3001(c)(5)(D)(i) response to the information blocking consolidation, and creating barriers to and (vi) of the PHSA, which requires the problem. Information blocking can entry for developers of new and Secretary to establish as a Condition and occur through a variety of business, innovative applications (also referred to Maintenance of Certification technical, and organizational practices as ‘‘apps’’) and technologies that enable requirement under the Program that that can be difficult to detect and that more effective uses of clinical data to health IT developers do not take any are constantly changing as technology improve population health and the action that constitutes information and industry conditions evolve. The patient experience 119 (84 FR 7508). blocking and require such developers to statute responds to these challenges by We explained in the Proposed Rule attest that they have not engaged in such defining information blocking broadly that the information blocking provision conduct (84 FR 7509). and in a manner that allows for careful provides a comprehensive response to consideration of relevant facts and these concerns. The information 2. Policy Considerations and Approach circumstances in individual cases. blocking provision defines and creates to Information Blocking Accordingly, we proposed in the possible penalties and disincentives for We explained in the Proposed Rule Proposed Rule to establish certain information blocking in broad terms, that the information blocking provision defined exceptions to the information while working to deter the entire encompasses a broad range of potential blocking provision as a way to identify spectrum of practices that unnecessarily practices in order to ensure that reasonable and necessary activities that impede the flow of EHI or its use to individuals and entities that engage in do not constitute information blocking improve health and the delivery of care. information blocking are held as required by section 3022(a)(3) of the The information blocking provision accountable. However, we explained PHSA. We proposed that these applies to the conduct of health care that it is possible that some activities exceptions would be subject to strict providers and health IT developers, that are innocuous, or even beneficial, conditions and would apply three exchanges, and networks, and seeks to could technically implicate the overarching policy criteria. First, each deter information blocking through civil information blocking provision. Given exception would be limited to certain monetary penalties and disincentives the possibility of these activities, section activities that are both reasonable and for violations. Additionally, developers 3022(a)(3) of the PHSA requires the necessary. These reasonable and of health IT certified under the Program Secretary, through rulemaking, to necessary activities include: Promoting are prohibited from information identify reasonable and necessary public confidence in the health IT blocking under 3001(c)(5)(D)(i) of the activities that do not constitute infrastructure by supporting the privacy PHSA (84 FR 7509). information blocking. We refer to such and security of EHI and protecting The information blocking provision reasonable and necessary activities patient safety; and promoting authorizes the HHS Office of Inspector identified by the Secretary as competition and innovation in health IT ‘‘exceptions’’ to the information and its use to provide health care 118 See, e.g., Julia Adler-Milstein and Eric Pfeifer, blocking provision. The information services to consumers. Second, we Information Blocking: Is It Occurring And What blocking provision also excludes from noted that each exception addresses a Policy Strategies Can Address It?, 95 Milbank Quarterly 117, 124–25 (Mar. 2017), available at the definition of information blocking significant risk that regulated http://onlinelibrary.wiley.com/doi/10.1111/1468- those practices that are required by law individuals and entities will not engage 0009.12247/full. (section 3022(a)(1) of the PHSA) and in these reasonable and necessary 119 See, e.g., Martin Gaynor, Farzad Mostashari, clarifies certain other practices that activities because of uncertainty and Paul B. Ginsburg, Making Health Care Markets would either not be considered Work: Competition Policy for Health Care, 16–17 regarding the breadth or applicability of (Apr. 2017), available at ≤https:// information blocking or penalized the information blocking provision. www.brookings.edu/research/making-health-care- (sections 3022(a)(6) and (7) of the Third, we explained that each exception markets-work-competition-policy-for-health-care/; PHSA) (84 FR 7509). is intended to be tailored, through Diego A. Martinez et al., A Strategic Gaming Model In considering potential exceptions to For Health Information Exchange Markets, Health appropriate conditions, so that it is Care Mgmt. Science (Sept. 2016). (‘‘[S]ome the information blocking provision, we limited to the reasonable and necessary healthcare provider entities may be interfering with strove to balance a number of policy and activities that it is designed to protect HIE across disparate and unaffiliated providers to practical considerations. To minimize and does not extend protection to other gain market advantage.’’) Niam Yaraghi, A compliance and other burdens for Sustainable Business Model for Health Information activities or practices that could raise Exchange Platforms: The Solution to stakeholders, we explained that we were information blocking concerns (84 FR Interoperability in Healthcare IT (2015), available at seeking to promote clear, predictable, 7509). http://www.brookings.edu/research/papers/2015/ and administrable policies. In addition, 01/30-sustainable-business-model-health- we emphasized our intention to 3. General Comments Regarding information- exchange-yaraghi; Thomas C. Tsai & Information Blocking Exceptions Ashish K. Jha, Hospital Consolidation, Competition, implement the information blocking and Quality: Is Bigger Necessarily Better?, 312 J. provision in a way that would be Comments. Numerous commenters AM. MED. ASSOC. 29, 29 (2014). sensitive to legitimate practical expressed support for the proposed

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00151 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25792 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

information blocking exceptions overall. person or entity designated by the Response. We thank commenters for Some commenters stated that individual. We emphasize that an their input. Taking these comments into information blocking is a widespread actor’s practice of charging an consideration, we have delayed the problem and perhaps the greatest barrier individual, their personal compliance date of the information to interoperability, and supported our representative, or another person or blocking section of this rule (45 CFR approach to addressing information entity designated by the individual for part 171). The compliance date for the blocking. electronic access to the individual’s EHI information blocking section of this While most commenters supported would be inherently suspect under an final rule will be six months after the our policy goals regarding information information blocking review. publication date of this final rule in the blocking, others questioned whether our We continue to receive complaints Federal Register. This six-month policies would have detrimental and reports alleging information delayed compliance date was consequences to the industry given the blocking from a wide range of established to provide actors with time breadth of the definitions, ambiguity of stakeholders. ONC has listened to and to thoroughly read and understand the the expectations, and narrowness of the reviewed these complaints and reports, final rule and educate their workforce in proposed exceptions. Another consulted with stakeholders, solicited order to apply the exceptions in an commenter stated that the proposed input from our Federal partners, and appropriate manner. We also note that information blocking exceptions are too reviewed public comments received in the finalized definition of information vague and that an alternative approach response to the Proposed Rule in order blocking (§ 171.103)) and the new is necessary to reduce confusion. The to inform our information blocking Content and Manner Exception commenter stated that we should align policies. We look forward to ongoing (§ 171.301(a)) reduce the scope of the the information blocking requirements collaboration with public and private EHI definition for the first 18 months with the certified capabilities of health sector partners as we implement the after the compliance date of the IT developers, and that information information blocking provision of this information blocking section of this blocking should be evaluated through final rule. To note, we have provided final rule to the EHI identified by the the lens of access, exchange, and use of clarifications and additional examples data elements represented in the USCDI. the USCDI. One commenter suggested throughout this final rule. Therefore, in addition to the that our information blocking policies Comments. Numerous commenters information blocking section’s be more patient-focused as offered by expressed concern over the proposed compliance date being six months after the Individual Health RecordTM (IHR) effective date of the information publication, actors will have an Model.120 A few commenters requested blocking policies. Commenters stated additional 18 months to gain experience clarification on how each of the that imposing stringent new mandates applying the exceptions with just the EHI identified by the data elements exceptions would be arbitrated, and with an overly aggressive represented in the USCDI as compared requested that we provide additional implementation timeframe could be to the full scope of EHI, which would examples of actions that may fall within counterproductive by increasing each exception. apply thereafter. administrative and financial burdens on During this combined period of 24 Response. We appreciate the support physician practices, threatening the expressed by many commenters. This months, we strongly encourage actors to security of health information, and apply the exceptions to all EHI as if the final rule maintains the general potentially compromising patient safety. direction of the Proposed Rule regarding scope were not limited to EHI identified Several provider organizations by the data elements represented in the information blocking but focuses the requested an enforcement ‘‘grace scope of certain terms, while also USCDI. However, given the initial scope period’’ after the new information of EHI identified in the information addressing the reasonable and necessary blocking requirements take effect to activities that would qualify for an blocking definition in § 171.103 and the allow providers sufficient time to Content and Manner Exception in exception under the information understand the requirements and blocking provision. As an example, we § 171.103, if an actor did not, in the first implement new procedures to be 24 months from this final rule’s have focused the scope of the EHI and compliant before any disincentives Health Information Network (HIN) publication date, enable access, would be applied. Specifically, exchange, or use of data outside the definitions and have included a new commenters recommended that OIG not exception in this final rule, the Content USCDI, or did not appropriately apply take any enforcement action for a period an exception to data outside the USCDI, and Manner Exception (§ 171.301). We of 18 months or two years after the appreciate the comment regarding the such practice or error would not be effective date of the final rule. Several considered information blocking IHR Model, but have determined that commenters recommended a period of the best approach to support because that data would not be enforcement discretion of no less than considered ‘‘EHI’’ during that time interoperability and the access, five years during which OIG would period. exchange, and use of EHI is through the require corrective action plans instead We have also delayed the compliance policies finalized in this final rule, of imposing penalties for information date of the Information Blocking which are patient-focused. For instance, blocking. One commenter also Condition of Certification requirement the Fees Exception (§ 171.302), which recommended that we ‘‘grandfather’’ in § 170.401 and the Assurances allows certain fees to be charged, does any economic arrangements that exist Condition of Certification requirement not apply to a fee based in any part on two years from date of the final rule. in § 170.402(a)(1). We also note that the electronic access (as such term is We did not receive any comments on under 45 CFR part 171, we have focused defined in § 171.302(d)) of an the proposed § 171.101, Applicability, the scope of the EHI definition and have individual’s EHI by the individual, their which stated that this part applies to revised the seven proposed exceptions personal representative, or another health care providers, health IT in a manner that is clear, actionable, and developers of certified health IT, health 120 likely to reduce perceived burden. The IHR is a digital tool that provides an all- OIG and ONC are coordinating timing in-one record of an individual’s health, enabling a information exchanges, and health person and their care team to help improve information networks, as those terms are of the compliance date of the collaboration and care. defined in § 171.102. information blocking section of this

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00152 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25793

final rule (45 CFR part 171) and the start outreach based on needs identified. We rule. Some commenters suggested that of information blocking enforcement. emphasize that the final rule details our EHI under the information blocking We are providing the following information blocking policies, and these provision should be limited to ePHI as information on timing for actors. educational materials are intended to defined in 45 CFR 160.103, while others Enforcement of information blocking educate stakeholders on our final requested that ONC consider civil monetary penalties (CMP) in policies established in the final rule. We constraining the EHI covered by the section 3022(b)(2)(A) of the PHSA will are also actively coordinating with OIG information blocking provision to only not begin until established by future and have provided OIG with comments the data included in the USCDI. notice and comment rulemaking by OIG. we received on the Proposed Rule Response. We have finalized the As a result, actors would not be subject related to information blocking proposed definition of information to penalties until CMP rules are final. At investigations and enforcement. Future blocking in § 171.103 with the addition a minimum, the timeframe for notice and comment rulemaking by OIG of paragraph (b). This new paragraph enforcement would not begin sooner will provide additional detail regarding states that until May 2, 2022—which is than the compliance date of the information blocking enforcement. 18 months after the 6-month delayed information blocking section of this C. Relevant Statutory Terms and compliance date for part 171 (a total of final rule (45 CFR part 171) and will Provisions 24 months after the publication date of depend on when the CMP rules are this final rule)—EHI for purposes of part final. Discretion will be exercised such In the Proposed Rule, we included 171 is limited to the EHI identified by that conduct that occurs before that time regulation text to codify the definition the data elements represented in the will not be subject to information of information blocking in § 171.103. United States Core Data for blocking CMP. We discussed how we proposed to Interoperability (USCDI) standard We have finalized § 171.101 with an interpret certain aspects of the adopted in § 170.213. This addition additional paragraph to codify the information blocking provision that we aligns with the content condition within compliance date for the information believe are ambiguous, incomplete, or the Content and Manner Exception, blocking section of this final rule (45 that provided the Secretary with which states that for up to May 2, 2022, CFR part 171). Section 171.101(b) states discretion. We proposed to define or an actor must respond to a request to that health care providers, health IT interpret certain terms or concepts that access, exchange, or use EHI with, at a developers of certified health IT, health are present in the statute and, in a few minimum, the EHI identified by the data information exchanges, and health instances, to establish new regulatory elements represented in the USCDI information networks must comply with terms or definitions that we believe are standard adopted in § 170.213 (see this part on and after November 2, 2020. necessary to implement the directive in § 171.301(a)(1)). Comments. Several commenters section 3022(a)(3) of the PHSA to This incremental expansion of the requested that we develop training and identify reasonable and necessary access, exchange, and use of EHI in both educational materials on the activities that do not constitute the information blocking definition information blocking provision. information blocking. We explained that (§ 171.103) and Content and Manner Commenters specifically stated that we our goal in interpreting the statute and Exception (§ 171.301) responds to should work with other agencies defining relevant terms is to provide commenters’ concerns regarding the (including CMS, OIG, FTC and OCR) to greater clarity concerning the types of breadth of health information actors are develop and widely disseminate practices that could implicate the required to share and the concern about comprehensive informational materials, information blocking provision and, the pace at which we are implementing such as sub-regulatory guidance and relatedly, to more effectively the information blocking provision. By frequently asked questions about what communicate the applicability and using USCDI as the baseline of EHI for constitutes information blocking. Some scope of the exceptions (84 FR 7509). 18 months after the compliance date of Comments. We did not receive any commenters recommended we work the information blocking section of this comments on the codification of the with OIG to ensure that enforcement final rule (45 CFR part 171),121 we have proposed definition of information focuses on education rather than created a transparent, predictable penalties against non-malicious blocking in § 171.103. starting point for sharing the types of information blockers. A few As discussed in more detail in section EHI that is understood by the regulated commenters suggested that we offer an VIII.C.3, we received many comments community and more readily available opportunity for stakeholders to seek expressing concerns regarding the for access, exchange, and use. In advisory opinions from OIG to clarify breadth of the proposed EHI definition addition, health IT that has been what constitutes information blocking, and requesting flexibility in the certified to the 2015 Edition ‘‘CCDS’’ or that we create a formal advisory implementation of the information certification criteria will be able to committee on information blocking. blocking provision. Many commenters immediately and readily produce almost Other commenters requested that heath stated that it would be difficult for all of the data elements identified in the care providers be provided an actors to provide the full scope of EHI USCDI. Furthermore, most, if not all, of opportunity to cure an alleged violation as it was proposed to be defined, and an opportunity to appeal the alleged particularly as soon as the final rule was such health IT already supports violation. published. Some commenters opined recording USCDI data elements and Response. We thank commenters for that we were trying to do too much too most HIEs/HINs are routinely their feedback, including their fast. Commenters requested that we exchanging such data elements. Further suggestions for establishing a formal provide flexibility for actors to adjust to those developers maintaining advisory committee. While we do not the scope of the EHI definition, as well certification over the 18-month period plan to establish an advisory committee, as the exceptions. Commenters asserted from the compliance date of the we plan to engage in multiple efforts to that such an approach would permit information blocking section of this educate stakeholders. We intend to them to adapt their processes, 121 The compliance date for the information provide educational resources such as technologies, and systems to enable the blocking section of this final rule (45 CFR part 171) infographics, fact sheets, webinars, and access, exchange, and use of EHI as is six months after the publication date of the final other forms of educational materials and required by the Cures Act and this final rule.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00153 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25794 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

final rule (45 CFR part 171) will be in fulfilling a request to access, exchange, and which include: Health care the process of updating their certified or use EHI in an alternative manner than providers, health IT developers, health IT to produce all of the data the manner requested. This approach networks, and exchanges. We proposed elements specified in the USCDI, will ensure that the requisite content to in the Proposed Rule to adopt including being certified to the new be included in an actor’s response to a definitions of these terms to provide standardized application programming request to access, exchange, or use EHI clarity regarding the types of interface (API) criterion during the 18-month period is clear and individuals and entities to whom the (§ 170.315(g)(10)) and API Condition of consistent throughout our information information blocking provision applies Certification (§ 170.404). blocking policies. (84 FR 7510). We noted that, for We believe the 18-month delay will convenience and to avoid repetition in 1. ‘‘Required by Law’’ provide actors with adequate time to the preamble, we typically refer to these prepare for the sharing of all EHI and With regard to the statute’s exclusion individuals and entities covered by the sunset any non-compliant technology, of practices that are ‘‘required by law’’ information blocking provision as while providing a clear deadline for from the definition of information ‘‘actors’’ unless it is relevant or useful when all EHI must be available for blocking, we emphasized in the to refer to the specific type of individual access, exchange, and use. During this Proposed Rule that ‘‘required by law’’ or entity. That is, when the term ‘‘actor’’ time period, actors can gain awareness, refers specifically to interferences with appears in the preamble, it means a experience, and comfort with the access, exchange, or use of EHI that are health care provider, health IT information blocking provision and explicitly required by State or Federal developer, health information exchange, exceptions without being required to law. By carving out practices that are or health information network. We apply the information blocking ‘‘required by law,’’ the statute proposed to codify this definition of exceptions to all EHI as it is defined in acknowledged that there are laws that ‘‘actor’’ in § 171.102. § 171.102 (see section VIII.C.3). We advance important policy interests and Comments. We did not receive any expect actors to use this 18-month delay objectives by restricting access, comments on this general approach to from the compliance date of the exchange, and use of EHI, and that use the term ‘‘actors’’ throughout the information blocking section of this practices that follow such laws should rule for clarity or the proposed final rule (45 CFR part 171) (in addition not be considered information blocking definition of ‘‘actor’’ in § 171.102. We to the 6-month period from the (84 FR 7509). note that we did receive comments publication date of this final rule to the We noted in the Proposed Rule that about the definitions of the four information blocking compliance date) for the purpose of developing an categories of actors, which are discussed to practice applying the exceptions to exception for reasonable and necessary below. real-life situations and to update their privacy-protective practices, we Response. We have finalized this processes, technologies, and systems to distinguished between interferences that approach and the definition of ‘‘actor’’ adapt to the new information blocking are ‘‘required by law’’ and those in § 171.102 as proposed. requirements. We believe actors will engaged in pursuant to a privacy law, a. Health Care Providers benefit from learning how to respond to but which are not ‘‘required by law.’’ requests for all EHI and applying the (The former does not fall within the We identified in the Proposed Rule exceptions during the 18-month delay. definition of information blocking, but that the term ‘‘health care provider’’ is Further, this approach will ensure the latter may implicate the information defined in section 3000(3) of the PHSA that the application of the information blocking provision and an exception (84 FR 7510). We proposed to adopt this blocking provision is equitable across may be necessary (84 FR 7510)). definition for purposes of section 3022 actors during the 18-month time period. Comments. We received comments of the PHSA (that is, for purposes of For instance, if we had required actors requesting additional clarity regarding information blocking) when defining to respond to a request to access, the meaning and scope of ‘‘required by ‘‘health care provider’’ in § 171.102. We exchange, or use EHI during this 18- law’’ within the information blocking noted that the PHSA definition is month time period with all EHI that the provision. different from the definition of ‘‘health actor is able to provide, then actors who Response. We thank commenters for care provider’’ under the HIPAA Rules. are able to provide more EHI would the feedback. We clarify that our We further stated that we were carry a heavier burden than actors who references to Federal and State law considering adjusting the information were only able to provide the data include statutes, regulations, court blocking definition of ‘‘health care elements specified in the USCDI. orders, and binding administrative provider’’ to cover all individuals and Nonetheless, and as discussed above, decisions or settlements, such as (at the entities covered by the HIPAA Rules we encourage actors to respond to Federal level) those from the FTC or the ‘‘health care provider’’ definition in 45 requests for access, exchange, or use of Equal Employment Opportunity CFR 160.103. We sought comment on EHI with as much EHI as possible in Commission (EEOC). We further note whether such an approach would be order to promote interoperability and to that ‘‘required by law’’ would include justified, and encouraged commenters to practice applying the exceptions. tribal laws, as applicable. For a detailed specify reasons why doing so might be We have included language regarding discussion of the application of necessary to ensure that the information this incremental expansion of the ‘‘required by law’’ in the context of the blocking provision applies to all health access, exchange, and use of EHI in both Privacy Exception, please see section care providers that might engage in the information blocking definition VIII.D.1.b. information blocking. (§ 171.103) and Content and Manner Comments. A significant number of Exception (§ 171.301) in order to ensure 2. Health Care Providers, Health IT commenters were in favor of using the that the 18-month delay is uniformly Developers, Exchanges, and Networks definition of health care provider used applied in the broad circumstances We explained in the Proposed Rule in the HIPAA Rules. However, other when requestors request access, that section 3022(a)(1) of the PHSA, in commenters asserted that doing so exchange, or use of EHI as well as in defining information blocking, refers to would exceed the scope intended by the situations when an actor seeks to satisfy four classes of individuals and entities Cures Act. Some commenters requested the Content and Manner Exception by that may engage in information blocking exclusions or a ‘‘phased-in’’ approach

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00154 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25795

for the requirements for State agencies, The health care provider definition Limiting the Definition of Health IT institutions, public health departments, and resources we have made available Developer to Developers of Certified ambulatory surgical centers, and other provide clarity and examples of the Health IT small providers due to their limited types of individuals and entities Comments. A number of commenters resources or limited access to health IT. covered by the definition. To this point, suggested broadening the definition of Other commenters suggested limiting medical device manufacturers and ‘‘health IT developers’’ to include all the application of the information community-based organizations, as developers of health IT, whether or not blocking provisions only to those health described by commenters, generally any of their products include Health IT care providers using certified health IT would not meet the health care provider Module(s) certified under ONC’s Health though some commenters also opposed definition unless they are also a type of IT Certification Program. Several of such a limitation. Some commenters individual or entity identified in the these commenters expressed concern suggested including additional definition. that developers of only non-certified categories such as medical device health IT would, under our proposed manufacturers and community-based b. Health IT Developers of Certified definition, be able to continue to block organizations that address social Health IT patients from accessing or directing determinants of health (e.g., access to Section 3022(a)(1)(B) of the PHSA their EHI to third parties of their choice. food, housing, and transportation). defines information blocking, in part, by A majority of these commenters Response. We have retained in this reference to the conduct of health final rule the definition of ‘‘health care expressed concerns that an information information technology developers. In blocking prohibition limited to provider’’ as set forth in section 3000(3) the Proposed Rule (84 FR 7510), we of the PHSA as proposed. The developers who participate in the ONC explained that, because title XXX of the Health IT Certification Program (also definitions listed in section 3000 of the PHSA does not define ‘‘health PHSA apply ‘‘[i]n this title,’’ which referred to as ‘‘the Program’’) will result information technology developer,’’ we in an uneven playing field for refers to Title XXX of the PHSA. Section interpreted section 3022(a)(1)(B) in light 3022 of the PHSA is included in Title developers who participate in the of the specific authority provided to OIG Program in comparison to those who do XXX. We note that the last clause of the in section 3022(b)(1)(A) and (b)(2). We health care provider definition in not participate in the Program. Some noted that section 3022(b)(2) discusses commenters suggested that this could section 3000(3) of the PHSA gives the developers, networks, and exchanges by Secretary discretion to expand the motivate developers to avoid or referencing any individual or entity withdraw from the Program. definition to any other category described in section 3022(b)(1)(A) or determined to be appropriate by the Response. We believe that ‘‘health (C). Section 3022(b)(1)(A) states, in information technology developer’’ as Secretary. We will consider whether the relevant part, that OIG may investigate definition should be expanded in the used in PHSA section 3022(a)(1)(B) any claim that a health information should be interpreted in light of the future if the scope of health care technology developer of certified health providers subject to the information specific authority provided to OIG in information technology or other entity section 3022(b)(1)(A) and (b)(2). Section blocking provision does not appear to be offering certified health information broad enough in practice to ensure that (b)(1)(A) states, in relevant part, that technology engaged in information OIG may investigate any claim that a the information blocking provision blocking. applies to all health care providers that health information technology We believe it is reasonable to interpret developer of certified health might engage in information blocking. these sections together to mean that the With respect to the requested information technology or other entity information blocking provision extends offering certified health information exclusions or a ‘‘phased-in’’ approach to individuals or entities that develop or for certain types of entities, we do not technology engaged in information offer certified health IT. That the believe that this is necessary due to the blocking. We recognize that health IT individual or entity must develop or addition of paragraph (b) within the developers that are not developers of offer certified health IT, we explained, information blocking definition in certified health IT could engage in is further supported by section § 171.103 and the new Content and conduct meeting the definition of 3022(a)(7) of the PHSA—which refers to Manner Exception in § 171.310. Section information blocking in section 3022(a) developers’ responsibilities to meet the 171.103(b) states that until May 2, of the PHSA. However, the statute requirements of certification—and 2022—which is 18 months after the places health IT developers of certified section 4002 of the Cures Act—which compliance date of the information health IT on different footing than other identifies information blocking as a blocking section of this final rule (part developers of health IT with respect to 171)—EHI for purposes of part 171 is Condition of Certification. Consistent information blocking enforcement. A limited to the EHI identified by the data with this, we proposed a definition of broader definition of ‘‘health IT elements represented in the United ‘‘health IT developer of certified health developer’’ in § 171.102 would not States Core Data for Interoperability IT’’ in § 171.102 (84 FR 7601) and an change the scope or effect of section (USCDI) standard adopted in § 170.213 interpretation of the use of ‘‘health 3022(b)(1)(A) and (b)(2) of the PHSA. (see the discussion in section VIII.C). information technology developer’’ in We acknowledge that the information Similarly, the Content and Manner section 3022 of the PHSA that would blocking provision may change some Exception allows actors to make apply to part 171 only, and would not health IT developers’ assessments of available a limited set of EHI (the apply (84 FR 7511) to the whether participation in the voluntary USCDI) during the first 18 months after implementation of any other section of ONC Health IT Certification Program is 122 the six-month delayed compliance date the PHSA or the Cures Act, such as the right decision for their health IT for part 171 (a total of 24 months after section 4005(c)(1) of the Cures Act. products and customers. However, we publication of this final rule). This believe the value certification offers to approach, as well as the Infeasibility 122 Because part 171 is referenced by part 170 the health IT developers’ customers, subpart D, the definition and interpretation are Exception, will address concerns about relevant to developers’ obligations to meet such as health care providers, is certain actors having limited resources Condition and Maintenance of Certification substantially enhanced by both the or limited access to health IT. Requirements. information blocking provision and the

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00155 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25796 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

enhancements to certification called for blocking provision, which is further section 3022(b)(1), specific to claims in PHSA section 3001(c)(5)(D). We supported by PHSA sections 3022(a)(7) that a health care provider engaged in believe the benefit that certification and 3001(c)(5)(D). Section 3022(a)(7) information blocking, nor subparagraph offers health IT developers’ customers refers to developers’ responsibilities to (C), specific to claims that health will continue to weigh in favor of the meet the requirements of certification, information exchanges (HIEs) or health developers obtaining and maintaining and section 3001(c)(5)(D) identifies as a information networks (HINs) engaged in certification of their products. For Condition of Certification that a health information blocking, includes language example, the Promoting Interoperability IT developer not engage in information limiting the Inspector General to Programs (formerly known as the blocking. Moreover, PHSA § 3022 does investigating claims tied to these actors’ Medicare and Medicaid EHR Incentive not specifically address all of the types use of certified health IT. Programs) continue to require use of of individuals and entities (such as Moreover, our observation is that the Certified EHR Technology (CERHT), health plans and claims data customers of health IT developers of which makes certification important for clearinghouses) that could or currently certified health IT seldom, if ever, rely developers seeking to market certain do engage in practices that might solely on Health IT Modules certified types of health IT (notably including, otherwise meet the definition of under the Program to meet their needs but not limited to, that within the ‘‘Base information blocking in PHSA § 3022(a). to access, exchange, and use EHI. A EHR’’ definition in § 170.102) to eligible Applicability of Information Blocking developer’s health IT product suite that clinicians, eligible hospitals, and critical Provision to Non-Certified Health IT a hospital, clinician office practice, or access hospitals (CAHs). other health care provider uses (and Comments. Several commenters Products of a Developer of Certified Health IT colloquially references) as its ‘‘EHR recommended alternative approaches to system’’ will typically include a wide Comments. On the whole, the interpreting the Cures Act, to justify variety of functions, services, majority of comments supported broadening the definition of ‘‘health IT components, and combinations thereof. defining ‘‘health IT developer’’ in a developer’’ in 45 CFR 171.102 to Even where such a health IT product manner that includes all health IT include all developers of any products suite meets the definition of ‘‘Certified products developed or offered by within the definition of ‘‘health EHR Technology’’ for purposes of developers who have at least one Health information technology’’ in section 3000 participation in the Promoting IT Module certified under the Program. of the PHSA. These commenters offered Interoperability Programs, there is no However, multiple comments, a variety of rationales, including guarantee that every part of the overall consideration of information that would predominantly from the perspective of product suite will meet the have been available to Congress at the developers of certified health IT, requirements of at least one certification time the Cures Act was enacted, as the recommended that we limit the criterion adopted by the Secretary. In basis for inferring that Congress did not definition of ‘‘health IT developers of fact, typically only a subset of the intend to limit the scope of the certified health IT’’ in § 171.102 so that functions, services, components, and information blocking provision to it would encompass only the combinations thereof within the overall developers that participate in the developers’ conduct specific to their product suite will meet the voluntary ONC Health IT Certification certified health IT products. requirements of at least one certification Program. Some commenters stated the Commenters advocating this more criterion adopted by the Secretary and phrasing of the Cures Act’s information limited definition stated that these blocking provision appeared to exclude developers’ non-certified health IT be Health IT Modules certified under health IT developers that do not products would be competing against the Program. participate in our Program and similar products of developers who are If we were to interpret the information recommended that we address what not subject to the information blocking blocking provision as applying only to some comments described as a potential provision. the certified Health IT Modules within enforcement gap by broadening the Response. The Cures Act does not a developer’s product suite(s), we are regulatory definition of ‘‘health IT prescribe that only practices involving concerned the developers’ customers developer’’ in 45 CFR 171.102, although certified health IT may implicate PHSA might too easily presume, based on the they did not identify a specific statutory section 3022(a). If Congress had developer’s participation in the ONC basis for closing what their comments intended to limit the application of Health IT Certification Program, that the described as a gap or drafting issue in section 3022 of the PHSA to practices developer will not engage in the statute. One commenter asked that involving certified health IT, we believe information blocking with respect to we work with Congress to expand the PHSA section 3022 would have any of the EHI that the customer uses of definition of health IT developer beyond included language that tied enforcement the developer’s product suite(s) to those with at least one product that is of that section to the operation or access, exchange, or use. Moreover, or that includes at least one Health IT performance of health IT products that limiting our definition of ‘‘health IT Module certified under the Program. include one or more Health IT developer of certified health IT’’ for Response. As explained in the Module(s) certified under the Program. purposes of part 171 to only the subset Proposed Rule and in the immediately Instead, PHSA section 3022(b)(1)(A) of an individual or entity’s products that preceding response to comments, we provides that the HHS Inspector General are, or that specifically include, Health believe that ‘‘health information may investigate under PHSA section IT Modules certified under our Program technology developer’’ as used in PHSA 3022 any claim that ‘‘a health could encourage developers to split section 3022(a)(1)(B) should be information technology developer of various functions, services, or interpreted in light of the specific certified health information technology combinations thereof into multiple authority provided to OIG in section or other entity offering certified health products so that they could more easily 3022(b)(1)(A) and (b)(2). Our information technology—submitted a or broadly avoid accountability for interpretation is that the individual or false attestation under section engaging in practices otherwise meeting entity must develop or offer certified 3001(c)(5)(D)(vii); or engaged in the definition of information blocking in health IT to be considered a health IT information blocking.’’ Similarly, § 171.103 with respect to various pieces developer covered by the information neither subparagraph (B) of PHSA of their product suite(s) rather than

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00156 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25797

composing products in response to engage in information blocking in leaving the Program, citing concerns customers’ needs and preferences. connection with EHI that was stored or such as burden. We do not believe this outcome controlled by the developer or offeror Response. We thank commenters for would be in the best interest of patients, while they were participating in the their feedback. We have finalized in health care providers, or other Program. One such approach would § 171.102 that a ‘‘health IT developer of customers of health IT developers of have defined ‘‘health IT developer of certified health IT’’ for purposes of part certified health IT. Thus, while certified health IT’’ as including 171 means an individual or entity, other acknowledging that our definition of developers and offerors of certified than a health care provider that self- ‘‘health IT developer of certified health health IT that continue to store EHI that develops health IT for its own use, that IT’’ in specific may, like the information was previously stored in health IT develops or offers health information blocking provision in general, change certified in the Program. The other technology (as that term is defined in 42 some health IT developers’ assessments would have continued to define a U.S.C. 300jj(5)) and which has, at the of whether participation in the developer or offeror of health IT as a time it engages in a practice that is the voluntary ONC Health IT Certification ‘‘health IT developer of certified health subject of an information blocking Program is the right decision for their IT’’ for purposes of part 171 for an claim, one or more Health IT Modules health IT products and customers, we appropriate period of time, such as one certified under a program for the believe the definition we have finalized year, after the developer or offeror left voluntary certification of health offers necessary assurance to purchasers the Program (no longer had any Health information technology that is kept or and users that a health IT developer that IT Modules certified under part 170). recognized by the National Coordinator has chosen to participate in the Program Comments. We received several pursuant to 42 U.S.C. 300jj–11(c)(5) can be held accountable under part 170 comments in support of defining (ONC Health IT Certification Program). subpart D and under part 171 should ‘‘health IT developer of certified health This definition will ensure conduct a that developer also engage in any IT’’ in a way that would include developer or offeror engages in while it conduct meeting the definition of developers and offerors who have left has any health IT product certified information blocking in § 171.103. the Program so long as they continue to under the Program will be within the definition of ‘‘health IT developer of Duration of Health IT Developer of store or control EHI that had been stored certified health IT’’ for purposes of part Certified Health IT Status in or by their health IT products while the products were, or included one or 171. We proposed that ‘‘health IT We have not extended the definition more, Health IT Module(s) certified in developer of certified health IT’’ would of ‘‘health IT developer of certified the Program. We also received several mean an individual or entity that health IT’’ beyond the date on which a develops or offers health information comments recommending developers of developer or offeror no longer has any technology (as that term is defined in 42 certified health IT remain subject to the health IT certified under the Program. It U.S.C. 300jj(5)) and which had, at the information blocking provision for a may be that extending duration of time it engaged in a practice that is the period of time after leaving the Program. ‘‘health IT developer of certified health subject of an information blocking A couple of commenters recommended IT’’ status beyond the date on which a claim, health information technology a hybrid approach that would include developer or offeror stops participating (one or more) certified under the ONC individuals and entities in the in the Program could help motivate Health IT Certification Program. We definition of ‘‘health IT developer of such a developer or offeror to better proposed (84 FR 7511) that the term certified health IT’’ while they continue support transfers of EHI in their custody ‘‘information blocking claim’’ within to store EHI that had been stored in if their customers choose to switch this definition should be read broadly to certified health IT or for a reasonable products because of the developer’s encompass any statement of information period of time after they ceased withdrawal from the Program. However, blocking or potential information participating in the Program, whichever we believe that ensuring continuity of blocking. We also noted in the Proposed is longer. access to patients’ EHI is an essential Rule that ‘‘claims’’ of information One reason commenters stated in consideration in the process of selecting blocking within this definition would support of extending the definition of and contracting for health IT. All not be limited, in any way, to a specific ‘‘health IT developer of certified health transitions between different health IT form, format, or submission approach or IT’’ beyond the time a developer ceased products will require transfer of EHI process. participating in the program was that in between those products. Planning for We stated in the Proposed Rule that commenters’ view this could help this transfer is, as a practical matter, we were also considering additional former customers access the EHI that the integral to a successful transition approaches to help ensure developers customers need to provide the best care between products that ensures and offerors of certified health IT for patients and that they had contracted continuity of access to EHI essential to remain subject to the information with a developer to manage while the safe, well-coordinated patient care. We blocking provision for an appropriate developer had certified health IT. Some are not persuaded that any of the period of time after leaving the Program. commenters stated that the need for alternative approaches to duration of While encouraging commenters to customers to ensure their contracts with ‘‘health IT developers of certified health identify alternative approaches for Program-participating developers IT’’ status could eliminate the need for identifying when a developer or offeror include provisions for retrieval of the health care providers and other should, and when they should no EHI upon termination or conclusion of customers of ‘‘health IT developers of longer, be subject to the information the contract would be eliminated if the certified health IT’’ to ensure their blocking provision, we requested period of time during which the ‘‘health health IT planning and contracting comment on whether one of two IT developer of certified health IT’’ provides for appropriate transfer(s) of specific approaches would best achieve definition applied extended beyond the data at the conclusion or termination of our policy goal of ensuring that health date a developer leaves the Program. any particular contract. IT developers of certified health IT will Other comments recommended against We also note that in the market for face consequences under the developers remaining subject to the certified Health IT Modules today, many information blocking provision if they information blocking provision after of the customers of health IT developers

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00157 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25798 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

or offerors are HIPAA-covered entities provision to those practices by simply themselves develop the health IT in the (such as health care providers) or leaving the Program before any claim(s) definition of ‘‘health IT developer of HIPAA business associates (BAs) (such about the practice may come to light. certified health IT.’’ Some commenters as health information exchanges or Our reference to claims of information recommended the exclusion of offerors clinical data registries) with whom blocking in the finalized definition of who do not modify or configure the covered entities contract for particular ‘‘health IT developer of certified health health IT in question. Some commenters services. In such cases, the HIPAA Rules IT’’ is not intended to imply that any advocated treating entities that include generally require that a HIPAA covered actor whose conduct is the subject of a other developers’ certified health IT in entity (or BA) enter into a business claim of information blocking that is the health IT products or services they associate agreement (BAA) that requires received by HHS necessarily will be offer, but do not themselves develop that the BA (or subcontractor BA) return found to have engaged in conduct certified health IT, as being outside the or destroy the PHI after the termination meeting the definition of information definition of ‘‘health IT developer of of its service as a BA (or subcontractor blocking in § 171.103 or that is certified health IT.’’ Commenters stated BA). Because a contract for health IT otherwise contrary to requirements of that these offerors do not themselves products or services, and any associated the ONC Health IT Certification Program develop the certified health IT and thus BAA, could extend beyond a developer (such as the Condition and Maintenance do not control its design. Commenters or offeror’s departure from the ONC of Certification requirements established also stated that the products offered by Health IT Certification Program, we in subpart D of part 170).123 If subject some of these offerors (such as clinical believe such contracts and agreements to an investigation, each practice that data registries which may be certified to provide an appropriate mechanism for implicates the information blocking clinical quality measurement and customers to guard against a health IT provision and does not meet an measure reporting criteria) are not developer or offeror who has left the exception would be analyzed on a case- primary sources of patients’ EHI, and Program refusing to relinquish EHI. We by-case basis to evaluate, for example, that offerors of health IT that is not a note further that limiting the definition whether it rises to the level of an primary source of EHI should be of ‘‘health IT developer of certified interference, and whether the actor excluded from the definition of health health IT’’ to the time period during acted with the requisite intent. IT developer of certified health IT. One which the individual or entity has at commenter specifically recommended least one Health IT Module certified Developers and Offerors of Certified excluding from the definition under the Program would not require Health IT individuals and entities that offer under claims of information blocking to come We stated in the proposed rule that their own brand, but do not modify or to our attention during that same period. within the definition of ‘‘health IT configure, certified health IT developed We have finalized the definition as developer of certified health IT’’ for by others. These commenters suggested proposed, with modification to its purposes of part 171, we interpret an that this is desirable in order to hold wording that is discussed below. ‘‘individual or entity that develops the developers accountable for information Comments. A commenter suggested certified health IT’’ as the individual or blocking conduct in the course of that the definition of ‘‘information entity that is legally responsible for the development. blocking claim’’ should not include any certification status of the health IT, Response. Including both developers ‘‘potential information blocking,’’ but which would be the individual or entity and other offerors in the definition of instead should be evaluated with facts that entered into a binding agreement ‘‘health IT developer of certified health and evidence necessary to support a that resulted in the certification status of IT’’ is consistent with the policy goal of verifiable claim. the health IT under the Program or, if holding all entities who could, as a Response. We did not propose to such rights are transferred, the developer or offeror, engage in define in regulation ‘‘information individual or entity that holds the rights information blocking accountable for blocking claim.’’ We did note in the to the certified health IT (84 FR 7511). their practices that are within the preamble to the Proposed Rule that for We also stated that an ‘‘individual or definition of information blocking in purposes of the definition of ‘‘health IT entity that offers certified health IT’’ § 171.103. PHSA section 3022(b)(1)(A) developer of certified health IT’’ would include an individual or entity expressly references both ‘‘a health proposed in § 171.102, claims of that under any arrangement makes information technology developer of information blocking would not be certified health IT available for purchase certified health information technology’’ limited, in any way, to a specific form, or license. We requested comment on and ‘‘other entity offering certified format, or submission process (84 FR both of these interpretations, and health information technology’’ in the 7511). In the definition of ‘‘health IT whether there are particular types of context of authority to investigate developer of certified health IT’’ arrangements under which certified claims of information blocking. As finalized in § 171.102, we have retained health IT is ‘‘offered’’ in which the stated in the Proposed Rule (84 FR reference to the time at which the offeror should not be considered a 7510), we interpret PHSA section individual or entity that develops or ‘‘health IT developer of certified health 3022(a)(1)(B) in light of the specific offers certified health IT engages in a IT’’ for the purposes of the information authority provided to OIG in PHSA practice that is the subject of an blocking provision. section 3022(b)(1)(A) and (b)(2). information blocking claim so that it is Comments. Several comments We interpret these sections together as immediately clear on the face of the questioned the inclusion of offerors of the basis for applicability of the regulation text that the claim need not certified health IT who do not information blocking provision to be brought while the developer still has individuals or entities that develop or certified health IT. If a health IT 123 Section 3022(b) of the PHSA authorizes the offer certified health IT. We refer developer of certified health IT engages HHS Office of the Inspector General to investigate commenters concerned about holding in a practice that is within the definition claims of information blocking. Simultaneously, offerors that do not develop, modify, or of information blocking in § 171.103 ONC has responsibility for assessing developers’ configure health IT accountable for the compliance with requirements of the ONC Health while they remain in the Program, that IT Certification Program. Coordination between conduct of others to PHSA section health IT developer cannot avoid ONC and OIG in our respective roles is discussed 3022(a)(6), which states that the term applicability of the information blocking in section VII.D.3 of this preamble. ‘‘information blocking,’’ with respect to

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00158 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25799

an individual or entity, shall not developer for Program purposes 125 health IT may be made accessible to include an act or practice other than an would mean that they would not be individuals or entities other than the act or practice committed by such supplying or offering their certified self-developer and its employees individual or entity. Where the health IT to other entities (84 FR 7511 without that availability being individual or entity that develops health and 7512). We stated in the Proposed interpreted as offering or supplying the IT is different from the individual or Rule that self-developers would still be health IT to other entities in a manner entity that offers certified health IT, subject to the proposed Conditions and inconsistent with the concept of ‘‘self- each such individual or entity would Maintenance of Certification developer.’’ For example, if a hospital have the potential to engage in various requirements because they have health were to self-develop an EHR system, we practices within the definition of IT certified under the Program (see also would not consider inclusion in that information blocking in PHSA section section VII.D.7 of the Proposed Rule (84 system of certain functionalities or 3022(a) and 45 CFR 171.103, and we FR 7507) and section VII.D.7 of this features—such as APIs or patient believe each should be accountable for preamble). We requested comments on portals—to be offering or supplying the their own conduct. Actors who are not our treatment of ‘‘self-developers’’ for hospital’s self-developed health IT to primary generators of EHI or who may information blocking purposes and other entities. We would also not hold only a few data classes or elements whether there are other factors we interpret as offering or supplying the for any given patient (as would be the should consider. self-developed health IT to other entities case for examples specifically cited by Comments. A number of comments the issuance of login credentials commenters), could nevertheless engage expressed support of treating ‘‘self- allowing licensed health care in conduct that constitutes information developer’’ health care providers who professionals who are in independent blocking as defined in § 171.103 with do not supply or offer their certified practice to use the hospital’s EHR to respect to that EHI they do hold or health IT to other entities as health care furnish and document care to patients control. We therefore see no reason to providers for purposes of information in the hospital. Keeping in the hospital’s exclude them from the definition of blocking. EHR a comprehensive record of a health IT developer of certified health Response. We appreciate commenters’ patient’s care during an admission is a IT. To do so would not be consistent input. The definition of ‘‘health IT practice we view as reasonable and it with the policy goal of addressing the developer of certified health IT’’ that we typically requires that all the problem of information blocking. have finalized in § 171.102 expressly professionals who furnish care to Comments. Several commenters excludes health care providers who self- patients in the hospital be able to use recommended that public health develop health IT for their own use. the hospital’s EHR system. It is also agencies that develop and/or offer However, we remind health care customary practice amongst hospitals health IT products and services, such as providers who may be considering or that purchase commercially marketed are embarking on self-development of those related to syndromic surveillance health IT, as well as those that self- certified Health IT Modules that ‘‘self- and immunization registries, be develop their health IT, to enable health developers’’ are subject to certain excluded from the definition of health care professionals in independent Condition and Maintenance of IT developer in § 171.102. practice who furnish care in the hospital Certification requirements finalized in Response. We believe the vast to use the EHR in connection to subpart D of part 170. These majority of public health agencies furnishing and documenting that care. requirements include, though they are would remain outside of our definition Clinician portals made available to not limited to, providing assurances and of ‘‘health IT developer of certified facilitate independent licensed health attestations that they will not, have not, health IT’’ finalized in § 171.102. The care professionals furnishing and/or and do not engage in conduct ‘‘public health’’ certification criteria documenting care to patients in the constituting information blocking. within the ONC Health IT Certification hospital would also not be interpreted For purposes of the definition of Program are applicable to the health IT as negating the hospital’s ‘‘self- ‘‘health IT developer of certified health that health care providers would use to developer’’ status. However, if a health IT,’’ we interpret ‘‘a health care provider exchange information with public care provider responsible for the that self-develops health IT for its own health information infrastructure. These certification status of any Health IT use’’ to mean that the health care criteria are not applicable to the public Module(s) were to offer or supply those provider is responsible for the health information reporting or Health IT Module(s), separately or certification status of the Health IT exchange infrastructure itself. integrated into a larger product or Module(s) and is the primary user of the software suite, to other entities for those Treatment of ‘‘Self-Developers’’ of Health IT Module(s). Moreover, we entities’ use in their own independent Certified Health IT interpret ‘‘a health care provider that operations, that would be inconsistent self-develops health IT for its own use’’ We stated in the proposed rule (84 FR with the concept of the health care to mean that the health care provider 7511) that a ‘‘self-developer’’ of certified provider self-developing health IT for its does not offer the health IT to other health IT, as the term has been used in own use. entities on a commercial basis or the ONC Health IT Certification Program In deciding to exclude health care (Program) and described in section otherwise. This interpretation rests on our established concept of ‘‘self- providers who self-develop health IT for VII.D.7 of the Proposed Rule (84 FR their own use from the definition of 7507), section VII.D.7 of this preamble, developed’’ certified Health IT Modules. In this context, it is important to note ‘‘health IT developer of certified health and previous rulemaking,124 would be that some use of a self-developer’s IT’’ finalized in § 171.102, we rely treated as a health care provider for the substantially on our Program experience purposes of information blocking 125 The language in the final rule establishing that self-developed certified health IT because our description of a self- ONC’s Permanent Certification Program describes currently represents a small, and the concept of ‘‘self-developed’’ as referring to a diminishing, share of the Health IT 124 The final rule establishing ONC’s Permanent complete EHR or EHR Module designed, created, or Modules certified under our Program. Certification Program, ‘‘Establishment of the modified by an entity that assumed the total costs Permanent Certification for Health Information’’ (76 for testing and certification and that will be the We also note that we may consider FR 1261), addresses self-developers. primary user of the health IT (76 FR 1300). amending this definition in future

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00159 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25800 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

rulemaking in response to changing individual or entity that is legally that does not assume the application or market conditions. For example, the responsible for the certification status of use of certain technologies and is market might evolve in ways that would the health IT, which would be the flexible enough to apply to the full increase risk of abuse of this exclusion individual or entity that entered into a range and diversity of exchanges and of health care providers who self- binding agreement that resulted in the networks that exist today and that may develop certified health IT from the certification status of the health IT arise in the future. application of the § 171.103 definition under the Program or, if such rights are We stated that in considering the most of ‘‘information blocking’’ to their transferred, the individual or entity that appropriate way to define these terms, conduct as a developer of health IT. In holds the rights to the certified health we examined how they are used such circumstances, we might IT. As we clarified in the final rule throughout the Cures Act and the contemplate appropriate revisions to the ‘‘ONC Health IT Certification Program: HITECH Act. Additionally, we definition of ‘‘health IT developer of Enhanced Oversight and considered dictionary and industry certified health IT’’ for purposes of part Accountability’’ (81 FR 72404), the definitions of ‘‘network’’ and 171. consequences under 45 CFR part 170 for ‘‘exchange.’’ While the terms have a developer’s having had one or more of varied usage and meaning in different Summary of Finalized Policy: Definition its products’ certification terminated industry contexts, we noted that certain of Health IT Developer of Certified apply to developers, their subsidiaries, concepts are common and were Health IT and their successors (81 FR 72443). incorporated into the proposed In § 171.102, we have finalized that For purposes of part 171 and the definitions. ‘‘health IT developer of certified health information blocking provision, we Health Information Network IT’’ means an individual or entity, other interpret an entity that has health IT to than a health care provider that self- include not only the entity that entered We proposed a functional definition develops health IT for its own use, that into a binding agreement that resulted of ‘‘health information network’’ (HIN) develops or offers health information in the certification status of the health that focused on the role of these actors technology (as that term is defined in 42 IT under the Program, but also its in the health information ecosystem. We U.S.C. 300jj(5)) and which has, at the subsidiaries, and its successors. The stated that the defining attribute of a time it engages in a practice that is the facts and circumstances of a particular HIN is that it enables, facilitates, or subject of an information blocking case may determine which individual(s) controls the movement of information claim, one or more Health IT Modules or entity (or entities) are culpable and between or among different individuals certified under a program for the whether enforcement against particular or entities that are unaffiliated. voluntary certification of health individual(s), the developer entity, a Therefore, we proposed that two parties information technology that is kept or successor in rights to the health IT, the are affiliated if one has the power to recognized by the National Coordinator developer or successor’s subsidiary, or a control the other, or if both parties are pursuant to 42 U.S.C. 300jj–11(c)(5) parent entity will be pursued. Similarly, under the common control or ownership (ONC Health IT Certification Program). use of the word ‘‘individual’’ in this of a common owner. We noted that a This is substantially the definition we context does not limit responsibility for significant implication of the definition proposed (84 FR 7601), but with minor practices of an entity that develops or is that a health care provider or other modifications to its text. offers health IT to the particular natural entity that enables, facilitates, or We have added to this finalized person(s) who may have signed binding controls the movement of EHI within its definition ‘‘other than a health care agreement(s) that resulted in the own organization, or between or among provider that self-develops health IT for certification status of the health IT its affiliated entities, is not a HIN in its own use,’’ so that this feature of the under the Program. Depending on the connection with that movement of proposed definition which we stated in nature of the organization, the person information for the purposes of the HIN the Proposed Rule’s preamble (84 FR who signs the binding agreement that definition. 7511) is immediately clear on the face results in the certification status may be We proposed that an actor could be of the regulation text itself. We also different from the person who considered a HIN if it performs any one replaced the proposed phrasing ‘‘health determines the fees, the person who or any combination of the following information technology (one or more) implements the health IT, and the activities. First, the actor would be a certified’’ (84 FR 7601) with ‘‘one or person who sets the overall business HIN if it were to determine, oversee, more Health IT Modules certified’’ strategy for the company. The facts and administer, control, or substantially because it is more consistent with our circumstances of each case may influence policies or agreements that Program terminology. We also replaced determine who the culpable individual define the business, operational, ‘‘under the ONC Health IT Certification or individual(s) are and whether technical, or other conditions or Program’’ from the proposed phrasing enforcement against the entity or against requirements that enable or facilitate the with the finalized ‘‘under a program for specific individual(s) will be pursued. access, exchange, or use of EHI between the voluntary certification of health As stated in the Proposed Rule, for or among two or more unaffiliated information technology that is kept or purposes of this definition, a developer individuals or entities. Second, an actor recognized by the National Coordinator or offeror of a single certified health IT would be a HIN if it were to provide, pursuant to 42 U.S.C. 300jj–11(c)(5) product that has had its certification manage, control, or substantially (ONC Health IT Certification Program).’’ suspended will still be considered to influence any technology or service that Currently, we keep a single Program that have certified health IT (84 FR 7511). enables or facilitates the access, we refer to as the ONC Health IT exchange, or use of EHI between or Certification Program. For purposes of c. Health Information Networks and among two or more unaffiliated precision, we decided to refer to the Health Information Exchanges individuals or entities. statutory basis for the Program, and The terms ‘‘network’’ and ‘‘exchange’’ We noted that, typically, a HIN will indicate parenthetically the manner in are not defined in the information influence the sharing of EHI between which we currently reference it. blocking provision or in any other many unaffiliated individuals or We interpret ‘‘individual or entity that relevant statutory provisions. We entities. However, we did not propose to develops’’ certified health IT as the proposed to define these terms in a way establish any minimum number of

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00160 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25801

parties or ‘‘nodes’’ beyond the entity specifically created for the exchange, or use of EHI primarily requirement that there be some actual or purpose of managing a network—for between or among a particular class of contemplated access, exchange, or use policies and technology, but individuals or entities or for a limited of information between or among at nevertheless dictates the movement of set of purposes. We noted that our least two unaffiliated individuals or EHI over that network. As an example, research and experience in working entities that is enabled, facilitated, or a large health care provider could with exchanges drove the proposed controlled by the HIN. We stated that decide to lead an effort to establish a definition of this term. We stated that any further limitation would be artificial network that facilitates the movement of HIEs would include, but were not and would not capture the full range of EHI between a group of smaller health limited to, regional health information entities that should be considered care providers (as well as the large organizations (RHIOs), State health networks under the information health care provider) and through the information exchanges (State HIEs), and blocking provision. We clarified that technology of health IT developers. To other types of organizations, entities, or any individual or entity that enables, achieve this outcome, the large health arrangements that enable EHI to be facilitates, or controls the access, care provider, together with some of the accessed, exchanged, or used between exchange, or use of EHI between or participants, could create a new entity or among particular types of parties or among only itself and another that administers the network’s policies for particular purposes. As an example, unaffiliated individual or entity would and technology. we noted an HIE might facilitate or not be considered a HIN in connection In this scenario, we noted that the enable the access, exchange, or use of with the movement of that EHI large health care provider would come EHI exclusively within a regional area (although that movement of EHI may within the functional definition of a (such as a RHIO), or for a limited scope still be regulated under the information HIN and could be held accountable for of participants and purposes (such as a blocking provision on the basis that the the conduct of the network if the large clinical data registry or an exchange individual or entity is a health care health care provider used its control or established by a hospital-physician provider or health IT developer of substantial influence over the new organization to facilitate Admission, certified health IT). To be a HIN, we entity—either in a legal sense, such as Discharge, and Transfer (ADT) alerting). emphasized that the individual or entity via its control over the governance or We further noted that HIEs may be would need to be enabling, facilitating, management of the entity, or in a less established under Federal or State laws or controlling the access, exchange, or formal sense, such as if the large health or regulations but may also be use of EHI between or among two or care provider prescribed a policy to be established for specific health care or more other individuals or entities that adopted—to interfere with the access, business purposes or use cases. We also were not affiliated with it. exchange, or use of EHI. We clarified mentioned that if an HIE facilitates the We provided multiple examples to that the large health care provider in access, exchange, or use of EHI for more illustrate how the proposed definition this example would be treated as a than a narrowly defined set of purposes, would operate. An entity is established health care provider when utilizing the then it may be both an HIE and a HIN. within a state for the purpose of network to move EHI via the network’s We sought comment on the proposed improving the movement of EHI policies, technology, or services, but HIE definition and encouraged between the health care providers would be considered a HIN in commenters to consider whether the operating in that state. The entity connection with the practices of the proposed definition was broad enough identifies standards relating to security network over which the large health (or too broad) to cover the full range of and offers terms and conditions to be care provider exercises control or individuals and entities that could be entered into by health care providers substantial influence. considered exchanges within the wishing to participate in the network. We sought comment on the proposed meaning of the information blocking The entity offering (and then overseeing definition of a HIN. In particular, we provision, and whether the proposed and administering) the terms and requested comment on whether the definition was sufficiently flexible to conditions for participation in the proposed definition was broad enough accommodate changing technological network would be considered a HIN for (or too broad) to cover the full range of and other conditions. the purpose of the information blocking individuals and entities that could be Comments on the HIN and HIE provision. We noted that there is no considered HINs within the meaning of Definitions need for a separate entity to be created the information blocking provision. in order for that entity to be considered Additionally, we specifically requested As mentioned above, we received a HIN. To illustrate, we stated that a comment on whether the proposed substantially similar comments on both health system that ‘‘administers’’ definition would effectuate our policy proposed definitions. Based on those business and operational agreements for goal of defining this term in a way that comments and our approach to the final facilitating the exchange of EHI that are does not assume particular technologies definition for these terms, we have adhered to by unaffiliated family or arrangements and was flexible combined our comment summary and practices and specialist clinicians in enough to accommodate changes in response for the proposed definitions. order to streamline referrals between these and other conditions. Comments. Many commenters those practices and specialists would We note that we summarize and suggested that the definitions of HIN likely be considered a HIN. respond to the comments received on and HIE should be combined because We noted that the proposed definition the HIN definition below with the confusion could arise in trying to would also encompass an individual or comments received on the health distinguish between the two terms. entity that does not directly enable, information exchange definition (HIE) Commenters asserted that these facilitate, or control the movement of due to the overlap in the comments definitions are used to describe entities information, but nonetheless exercises received and our responses. that perform the same or similar control or substantial influence over the functions. Some commenters expressed policies, technology, or services of a Health Information Exchange support for the broad functional network. In particular, we stated that We proposed to define a ‘‘health definitions of HIE and HIN, while others there may be an individual or entity that information exchange’’ (HIE) as an expressed concern that many relies on another entity—such as an individual or entity that enables access, organizations could be unintentionally

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00161 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25802 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

covered by the proposed definitions due to commenters who asserted the terms the intermediary is simply performing a to the broad scope of the definitions as refer to entities performing the same service on behalf of one entity in proposed. function. To this point, we have found providing EHI to another or multiple Many commenters suggested numerous associations and publications entities and no actual exchange is taking excluding certain individuals and referring to entities that perform the place among all entities (e.g., acting as entities from the HIE and/or HIN same or similar functions that we have an intermediary between two entities definitions, while other commenters specified in the HIN/HIE definition as where the first sends non-standardized noted such an approach could HINs, HIEs, and regional health data to be converted by the intermediary significantly limit the application of the information organizations (RHIOs).126 into standardized data for the receiving information blocking provision. We have finalized under § 171.102 that entity). To be clear, to be enabled, the Proposed exclusions offered by a health information network or health parties must have the ability and commenters included, but were not information exchange means an discretion to exchange with each other limited to: Health plans, payers, health individual or entity that determines, under the policies, agreements, care providers, business associates, controls, or has the discretion to technology, and/or services. Third, we accountable care organizations, health administer any requirement, policy, or focused the definition on three care clearinghouses, public health agreement that permits, enables, or activities: Treatment, payment, and agencies, research organizations, requires the use of any technology or health care operations, as each are clinical data registries, certified health services for access, exchange, or use of defined in the HIPAA Rules (45 CFR information technology providers, EHI: (1) Among more than two 164.501). The activities described by the software developers, mobile app unaffiliated individuals or entities terms treatment, payment and health providers, cloud storage vendors, (other than the individual or entity to care operations were selected for internet service providers, and patient which this definition might apply) that multiple reasons. Many, but not all, or consumer focused social media. are enabled to exchange with each individuals and entities that would Some commenters suggested limiting other; and (2) that is for a treatment, meet the definition of HIN/HIE for the types of activities and/or the payment, or health care operations information blocking purposes will be purposes for those activities that might purpose, as such terms are defined in 45 familiar with these terms because they be necessary to be considered a HIN or CFR 164.501 regardless of whether such currently function as a covered entity or HIE. individuals or entities are subject to the business associate under the HIPAA Commenters also raised concerns requirements of 45 CFR parts 160 and Rules. Last, this approach serves to with particular language in the 164. ensure that certain unintended proposed HIN definition, noting that the In consideration of comments, we also individuals and entities are not covered term ‘‘substantially influences’’ was narrowed the definition in three ways. by the definition, which we discuss in vague and that we should remove First, the types of actions (e.g., manages more detail below. ‘‘individual’’ from the definitions as or facilitates) that would be necessary commenters could not foresee an Two important points about the for an actor to meet the definition of definition require clarification. First, the individual acting as a HIN or HIE. HIN or HIE were reduced. This includes Response. The definitions of HIN and reference to the three types of activities removing the ‘‘substantially influences’’ HIE in the Proposed Rule achieved a key does not limit the application of the element of the proposed definition of goal which was to solicit feedback from HIN/HIE definition to individuals or HIN to address concerns about possible a wide array of stakeholders that might entities that are covered entities or ambiguity. Second, we have revised the be considered HINs or HIEs under the business associates (as defined in definition to specify that to be a HIN or proposed definition, including on HIPAA). For example, if three HIE there must be exchange among whether the definitions were too broad unaffiliated entities exchanging or not broad enough. We have adopted more than two unaffiliated individuals information were health care providers a modified definition in this final rule or entities besides the HIN/HIE that are that were not HIPAA covered entities, to address much of the feedback without enabled to exchange with each other. their exchange of information for expressly excluding any specific type of This revision ensures that the definition treatment purposes through a HIN or entity, which we believe would be does not unintentionally cover what are HIE would qualify for this element of unwieldy to appropriately administer essentially bilateral exchanges in which the definition even though the HIN/HIE and, more importantly, in conflict with would not be a business associate to any 126 See HIMSS FAQ, Health Information our overarching approach to include Exchange: A catch-all phrase for all health of the providers. We expect such any individual or entity that performs information exchange, including Regional Health situations to be rare, but they may certain functional activities as outlined Information Organizations (RHIOs), Quality occur. Second, the three activities serve in the Proposed Rule. Information Organizations (QIOs), Agency for as elements of the definition such that Healthcare Research and Quality (AHRQ)-funded if an individual or entity meets them, Foremost, in this final rule, we are communities and private exchanges, https:// combining the definitions of HIN and protect2.fireeye.com/url?k=7d5b6f82-210e6652- then the individual or entity would be HIE to create one functional definition 7d5b5ebd-0cc47a6a52de- considered a HIN/HIE under the that applies to both statutory terms in fe4abdcde0e54deb&u=https://www.himss.org/ information blocking regulations for any library/health-information-exchange/FAQ; AHIMA, practice they conducted while order to clarify the types of individuals ‘‘An HIE is the electronic movement of health- and entities that would be covered. This related information among organizations according functioning as a HIN/HIE. To illustrate, approach is consistent with statements to nationally recognized standards. HIE is also if a HIN/HIE was exchanging EHI on we made in the Proposed Rule noting sometimes referred to as a health information behalf of a health care provider for network (HIN)’’, http://bok.ahima.org/ treatment purposes, but denied an that a HIE could also be an HIN. In PdfView?oid=104129; SHIEC Member List, SHIEC is addition, section 3022 of the PHSA the trade association of HIEs, called the Strategic individual access to their EHI available often groups these two terms together, Health Information Exchange collaborative, which in the HIN/HIE, then the HIN/HIE and as we noted previously, does not has 17 members with ‘‘network’’ in their name, would be considered a HIN/HIE under https://protect2.fireeye.com/url?k=f84ddacd- the circumstances for the purposes of define them. This approach will also a418d31d-f84debf2-0cc47a6a52de- eliminate stakeholder confusion as 8424832df6e921dc&u=https://strategichie.com/ information blocking. Having said this, expressed by commenters and respond membership/member-list/. the HIN/HIE may not have ‘‘interfered

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00162 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25803

with’’ the individual’s access to their • is transmitted by or maintained in use for the purposes of complying with EHI depending on the terms of the HIN/ electronic media, as defined in 45 CFR the information blocking provision. HIE’s business associate agreements 160.103; Some other commenters posited that with the participating covered entities • identifies the individual, or with they could be put in a situation of or for other reasons such as the EHI respect to which there is a reasonable having to separate EHI from PHI for could not be disclosed by law or the basis to believe the information can be compliance purposes, noting this would HIN/HIE met an exception under the used to identify the individual; and be extremely burdensome. Many information blocking provision. To be • relates to the past, present, or future commenters stated simply trying to clear, the HIN/HIE definition is only health or condition of an individual; the determine what constitutes EHI for applicable to the circumstances of an provision of health care to an compliance purposes would be information blocking claim. For individual; or the past, present, or extremely burdensome and costly. example, a health care provider that future payment for the provision of Commenters offered various options may have ownership of a HIN/HIE, health care to an individual (84 FR for narrowing the scope of the EHI would not be considered a HIN/HIE, but 7513). definition. Many commenters suggested instead a ‘‘health care provider’’ with We explained in the Proposed Rule that EHI should only be electronic respect to situations that involve their that this definition of EHI includes, but protected health information (ePHI) as behavior as a health care provider, such is not limited to: Electronic protected defined under the HIPAA Rules. Some as denying another health care health information and health of these commenters specifically provider’s ability to access, exchange, or information that is created or received recommended that the EHI definition be use EHI for treatment purposes or by a health care provider and those limited to align with the definition of a denying an individual’s access to their operating on their behalf; health plan; designated record set under HIPAA. A EHI via the health care provider’s health care clearinghouse; public health few commenters stated that EHI should patient portal. authority; employer; life insurer; school; be limited to observational health or university. In addition, we clarified information as described in the With respect to suggestions to exclude that under our proposed definition, EHI Proposed Rule (84 FR 7516). specific types of entities, we believe that includes, but is not limited to, Commenters also recommended that the the Cures Act goals of supporting greater electronic protected health information EHI definition be limited to only interoperability, access, exchange, and (ePHI) as defined in 45 CFR 160.103. We standardized health information, with use of EHI are best advanced by a noted that EHI may also be provided, some commenters recommending that functional definition without specific directly from an individual, or from EHI be specifically limited to exclusions. We note, however, that the technology that the individual has information that meets the USCDI narrower definition of HIN/HIE in this elected to use, to an actor covered by the standard. final rule should clearly exclude entities information blocking provisions. We Response. We appreciate the that might have been included under also proposed that EHI does not include comments and agree that actors should the proposed definitions, such as social health information that is de-identified not have to separate ePHI from EHI in networks, internet service providers, consistent with the requirements of 45 order to comply with both the HIPAA and technology that solely facilitates the CFR 164.514(b) (84 FR 7513). Rules and the information blocking exchange of information among patients We clarified that the EHI definition provision. It is also important for actors and family members. The definition in provides for an expansive set of health to clearly understand what health this final rule continues to focus on the information, which could include information should be available for functional activity of the individual or information on an individual’s health access, exchange, and use. To address entity in question and not on any title insurance eligibility and benefits, billing these concerns, we have focused the EHI or classification of the person or entity. for health care services, and payment definition at this time on terms that are The reference to ‘‘individual’’ was information for services to be provided used in the HIPAA Rules and that are maintained in the final rule because the or already provided, which may include widely understood in the health care Cures Act states that penalties apply to price information (84 FR 7513). industry as well as on a set of health any individual or entity that is a We generally requested comment on information that is currently collected, developer, network, or exchange (see this proposed definition as well as on maintained, and made available for section 3022(b)(2)(A) of the PHSA). whether the exclusion of health access, exchange, and use by actors. By information that is de-identified doing so, we believe we have eliminated 3. Electronic Health Information consistent with the requirements of 45 any perceived burden and actors will be In the Proposed Rule, we noted that CFR 164.514(b). We also sought in a situation that will permit them to the information blocking definition comment on the parameters and readily and continually comply with the applies to electronic health information implications of including price information blocking provision. While (EHI) (section 3022(a)(1) of the PHSA). information within the scope of EHI for we understand that some commenters We further noted that while section purposes of information blocking (84 FR supported the EHI definition as 3000(4) of the PHSA by reference to 7513). proposed or included alternative Comments. Some commenters were section 1171(4) of the Social Security definitions in their comments, we strongly supportive of the proposed EHI Act defines ‘‘health information,’’ EHI is believe that, for the above reasons, the definition, stating that it covers the not specifically defined in the Cures EHI definition we have codified in breadth of EHI that should be addressed Act, PHSA, HITECH Act, or other regulation through this final rule will within the regulation. Conversely, many relevant statutes. Therefore, we enable effective implementation. other commenters, including health care We have defined EHI (§ 171.102) to proposed to include the definition of providers and health IT developers, mean electronic protected health EHI in § 171.102 and define it to mean contended that the definition was overly information (ePHI) as the term is (84 FR 7513): broad and vague. They expressed defined for HIPAA in 45 CFR 160.103 to (i) Electronic protected health concern about their ability to know the extent that the ePHI would be information; and what health information they must included in a designated record set as (ii) any other information that— make available for access, exchange, and defined in 45 CFR 164.501 (other than

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00163 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25804 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

psychotherapy notes as defined in 45 EHI comprised of the data elements clinical interpretation or relevancy of CFR 164.501 or information compiled in included in the USCDI for access, the results of the algorithms or reasonable anticipation of, or for use in, exchange, and use during the first 18 processes. However, any such a civil, criminal, or administrative months after the compliance date of the information would be considered EHI if action or proceeding), regardless of information blocking provisions (24 it was ePHI included in the designated whether the group of records are used months after publication of this final record set (such as the inclusion of the or maintained by or for a covered entity rule). The data elements represented in clinical interpretation of an algorithm’s as defined in 45 CFR 160.103. The ePHI the USCDI represent an even more results in an individual’s clinical note). definition in 45 CFR 160.103 focused set of data than the finalized Like with price information, this incorporates the definitions in that EHI definition (§ 171.102). We refer approach is intended to ensure that the section for protected health information readers to section VIII.D.2.a of this final current scope of EHI for purposes of and electronic media. Although the rule for further discussion of this new information blocking is aligned with the definition of designated record set refers exception. definitions of ePHI and designated to records maintained by or for a Comments. Commenters argued both record set under the HIPAA Rules, with covered entity, the EHI definition has for and against the inclusion of price limited exception. been finalized to apply to groups of information in the EHI definition. Comments. Many commenters records (as they are included in the Commenters that argued for the supported the position that health designated record set) regardless of inclusion of price information stated information which is de-identified in whether they are maintained by or for that it was well within the meaning of accordance with HIPAA regulations a covered entity (e.g., a developer of the term health information found in the should not be considered EHI. certified health IT, a health information PHSA. Many of these commenters Response. We agree that health network, a health information exchange, argued that the availability of this type information that is de-identified or even a health care provider that may of information would be helpful to consistent with the requirements of 45 not be a covered entity or may not be patients in selecting and obtaining CFR 164.514(b) should not be included acting as a business associate of a health care. Commenters also contended in EHI. It is not, however, necessary to covered entity). that the availability of price information specifically exclude such de-identified We did not focus the EHI definition would increase competition and reduce information from the EHI definition finalized in this final rule on health care costs. Conversely, other because information that does not observational health information (OHI) commenters made various arguments for identify an individual, and with respect as described in the Proposed Rule (84 not including price information within to which there is no reasonable basis to FR 7516) for multiple reasons. We did the definition of EHI. Some of these believe that the information can be used not and cannot not at this time define commenters asserted that price to identify an individual, is not OHI concretely. The use of OHI as a information was not within the scope of individually identifiable information, so definition would also not align with our health information as specified in it would not be EHI (see 45 CFR above stated goals to provide alignment section 3022 of the PHSA because 164.514(a)). To note, once PHI has been with the HIPAA Rules and ease of Congress did not specifically include it. de-identified, it is no longer considered implementation for actors. We also did Commenters also asserted that price to be PHI. So, such information would not focus the EHI definition solely on information is too vague and lacks not be considered EHI by definition (see the data identified in the USCDI standardization to be clearly understood standard. We are strong supporters of and made available for access, 45 CFR 164.514 (b)). interoperability and standards-based exchange, and use. Other commenters Comments. One commenter viewed access and exchange. To this point, the contended that disclosing price the proposed EHI definition as overly ONC Health IT Certification Program information would violate trade secret restrictive by requiring EHI to be (Program) supports standards-based laws and would harm competitive individually identifiable. interoperability through the adoption of pricing by health plans. Response. The EHI definition codified standards and the certification of health Response. The EHI definition codified through this final rule retains the core IT to those standards. In this respect, we through this final rule does not requirement that the health information have made the USCDI a baseline set of expressly include or exclude price be individually identifiable in order to data that certified health IT must be able information. However, to the extent that be consistent with HIPAA and general to make available for access and ePHI includes price information and is health care industry practice regarding exchange (see section IV.B.1 of this included in a designated record set, it use and disclosure of health preamble). However, this set of EHI is would be considered EHI. This information. too limiting in terms of what actors are approach is intended to assure that the 4. Price Information—Request for capable of making available in both the current scope of EHI for purposes of Information near and long term as is evident by information blocking is aligned with the compliance with HIPAA’s right of definitions of ePHI and designated In the Proposed Rule, we requested access regulatory provision in 45 CFR record set under the HIPAA Rules, with comment on the technical, operational, 164.524. limited exceptions. legal, cultural, environmental, and other To be further responsive to Comments. A few commenters challenges to creating price commenters expressing compliance specifically questioned whether transparency within health care, and concerns about the EHI definition, we algorithms or processes that create EHI, posed multiple specific questions for have established a new ‘‘Content and or the clinical interpretation or commenters to consider (84 FR 7513 Manner’’ exception in this final rule relevancy of the results of the and 7514). (§ 171.301) that will provide actors time algorithms or processes, would be We received over 1,000 comments to adjust to the new information considered EHI. regarding price information and price blocking paradigm and make EHI Response. The EHI definition codified transparency in response to our request, available for access, exchange, and use. through this final rule does not which included recommendations from The new exception permits an actor to expressly include or exclude algorithms the HITAC. We thanks commenters for provide, at a minimum, a limited set of or processes that create EHI, or the their comments and have shared this

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00164 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25805

feedback with appropriate Department identifiable health information within definition would inappropriately partners. an entity that maintains the information increase administrative burden. (45 CFR 160.103). Response. We have revised these 5. Interests Promoted by the Information We stated that the types of access, definitions in response to comments. Blocking Provision exchange, and use described above These revisions do not narrow the scope a. Access, Exchange, and Use of EHI would be promoted under the of the definitions in regard to their We stated in the Proposed Rule that information blocking provision, as intended interpretation and purpose in the information blocking provision would other types of access, exchange, supporting interoperability and the promotes the ability to access, or use not specifically contemplated in goals of the information blocking exchange, and use EHI, consistent with these or other regulations. provision. We believe, however, the We emphasized in the Proposed Rule the requirements of applicable law. We revisions and their explanations below the interrelated nature of the definitions interpreted the terms ‘‘access,’’ will provide the necessary clarifications and proposed to define these terms in for stakeholders to properly implement ‘‘exchange,’’ and ‘‘use’’ broadly, § 171.102. For example, the definition of and comply with the terms. consistent with their generally ‘‘use’’ that we proposed includes the understood meaning in the health IT ability to read, write, modify, Access industry and their function and context manipulate, or apply EHI to accomplish We have finalized the definition of in the information blocking provision a desired outcome or to achieve a ‘‘access’’ as ‘‘the ability or means (84 FR 7514). desired purpose, while ‘‘access’’ is necessary to make EHI available for We explained in the Proposed Rule defined as the ability or means exchange, use, or both’’ (§ 171.102). This that the concepts of access, exchange, necessary to make EHI available for use. final definition improves on the and use are closely related: EHI cannot As such, we specified that the proposed definition (see 84 FR 7601) in be used unless it can be accessed, and interference with ‘‘access’’ would a couple of ways. First, it makes clear this often requires that the EHI be include, for example, an interference that ‘‘access’’ is the ability or means exchanged among different individuals that prevented a health care provider necessary to make EHI available not or entities and through various from writing EHI to its health IT or from only for ‘‘use,’’ but also for ‘‘exchange’’ technological means. Moreover, the modifying EHI stored in health IT, or both (the proposed definition only technological and other means whether by the provider itself or by, or included ‘‘for use’’). This modification necessary to facilitate appropriate access via, a third-party app. We encouraged will provide clarity because, as we and exchange of EHI vary significantly comment on these definitions. In noted in the Proposed Rule, these terms depending on the purpose for which the particular, we asked commenters to are interrelated and EHI cannot be information will be used. We stated that consider whether these definitions are exchanged or used if it is inaccessible. this explanation is consistent with the broad enough to cover all of the Second, to be responsive to comments way these terms are employed in the potential purposes for which EHI may and in order to promote additional information blocking provision and in be needed and ways in which it could clarity in the definition, we have other relevant statutory provisions. conceivably be used, now and in the removed ‘‘including the ability to Noting, for example, that section future. securely and efficiently locate and 3022(a)(2) of the PHSA contemplates a Comments. Several commenters retrieve information from any and all broad range of purposes for which EHI supported our proposed definitions of source systems in which the may be accessed, exchanged, and ‘‘access,’’ ‘‘exchange,’’ and ‘‘use,’’ based information may be recorded or used—from treatment, care delivery, on our broad interpretation of the maintained’’ from the definition. This and other permitted purposes, to definitions, which they stated supports language was exemplary and resulted in exporting complete information sets and interoperability. Several health IT some confusion among stakeholders. transitioning between health IT systems, developers and developer organizations Last, we clarify that the definition of to supporting innovations and stated that the definition of ‘‘access’’ ‘‘access’’ is not limited to direct advancements in health information was overly broad. They suggested that interfaces, which we believe is evident access, exchange, and use. we clarify and narrow the scope of our by the final definition. In addition, we stated in the Proposed proposed definition of ‘‘access.’’ One Exchange Rule that we considered how the terms commenter specifically suggested that access, exchange, and use have been we clarify that ‘‘access’’ need not be We have finalized the definition of defined or used in existing regulations provided through a direct interface. ‘‘exchange’’ as ‘‘the ability for electronic and other relevant health IT industry Some commenters suggested that we health information to be transmitted contexts. We explained that, while those remove the proposed language regarding between and among different definitions have specialized meanings ‘‘any and all source systems.’’ technologies, systems, platforms, or and are not controlling for the purposes Some commenters expressed concern networks.’’ As with the finalized of information blocking, they are that the proposed definition of ‘‘access’’ definition, we have maintained instructive insofar as they illustrate the ‘‘exchange’’ is overly broad. Other the general scope of the proposed breadth with which these terms have commenters requested additional clarity definition while modifying the been understood in other contexts. We regarding the scope of the definition. definition for clarity. First, we removed noted that the HIPAA Security Rule One commenter suggested that we ‘‘securely and efficiently’’ as proposed defines ‘‘access’’ as the ability or the clarify the meaning of ‘‘transmission’’ descriptors of the way that EHI is to be means necessary to read, write, modify, within the definition. transmitted under the definition. While or communicate data/information or Some health care providers and we continue to advocate for and otherwise use any system resource (45 provider organizations stated that our promote secure and efficient exchange, CFR 164.304). Last, we noted that the proposed definition of ‘‘use’’ was overly we do not think this descriptive HIPAA Privacy Rule defines the term broad. Some commenters suggested that language is necessary within the ‘‘use,’’ which includes the sharing, we look to more established definitions definition of ‘‘exchange’’ because employment, application, utilization, of ‘‘use,’’ such as HIPAA. Other ‘‘exchange’’ for the purposes of the examination, or analysis of individually commenters suggested that the proposed information blocking provision can

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00165 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25806 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

occur regardless of whether the structure, content, and meaning of the b. Interoperability Elements transaction is ‘‘secure’’ or ‘‘efficient.’’ information from the proposed We proposed to use the term Our intent with this definition was definition. However, we clarify that ‘‘interoperability element’’ to refer to never to exclude unsecure or ‘‘understood’’ just like the proposed any means by which EHI can be ‘‘inefficient’’ exchanges from the term ‘‘comprehend’’ does not mean the accessed, exchanged, or used. We definition or enforcement of the ability to understand the clinical proposed that the means of accessing, information blocking provision because significance or relevance of the EHI. For exchanging, and using EHI is not the exchange of EHI was not secure or example, if an ambulatory provider limited to functional elements and ‘‘inefficient,’’ so we have removed this received patient EHI from a hospital that technical information but also extraneous language. We also refer included a risk score, the concept of encompasses technologies, services, stakeholders to the information blocking ‘‘use’’ does not require the hospital to policies, and other conditions 127 exceptions included in this final rule provide additional resources to interpret necessary to support the many potential that discuss how EHI may be the score nor would the tool or uses of EHI. Because of the evolving transmitted and the importance of technology needed to interpret the nature of technology and the diversity of security as it relates to the access, information be considered an privacy and other laws and regulations, exchange, and use of EHI. interoperability element because its sole institutional arrangements, and policies Second, we have removed the purpose is clinical interpretation. that govern the sharing of EHI, we did provision at the end of the proposed not provide an exhaustive list of definition, that in order for ‘‘exchange’’ Similarly to ‘‘understood,’’ ‘‘acted interoperability elements in the to occur, it must be ‘‘in a manner that upon’’ within the final definition Proposed Rule. We requested comment allows the information to be accessed encompasses the ability to read, write, on the proposed definition. and used.’’ This language was modify, manipulate, or apply the Comments. Some commenters potentially confusing because the information from the proposed supported the proposed definition, manner of transmittal is not a necessary definition. We also clarify that ‘‘use’’ is noting that the breadth and scope of the component of the ‘‘exchange’’ bi-directional (to note, we also clarified definition is appropriate. Some definition. If EHI is exchanged but is above in the ‘‘exchange’’ discussion that commenters requested clarifications and done so in way that does not permit the ‘‘exchange’’ is bi-directional). Thus, an modifications regarding aspects of the use of the EHI, then that practice may actor’s practice could implicate the proposed definition. A few commenters implicate the information blocking information blocking provision not only requested that we clarify whether provision because the ‘‘use’’ of the EHI if the actor’s practice interferes with the specific functionalities and is being prevented. Further, to be requestor’s ability to read the EHI (one- technologies, such as certified Health IT responsive to comments, we emphasize way), but also if the actor’s practice Modules and proprietary APIs, would that ‘‘transmitted’’ within the definition interferes with the requestor’s ability to be considered interoperability elements. is not limited to a one-way write the EHI (bi-directional) back to a A commenter requested, within the transmission, but instead is inclusive of health IT system. context of the Licensing Exception all forms of transmission such as bi- directional and network-based We note that the ability ‘‘to access (§ 171.303), clarification regarding transmission. We note this as a point of relevant EHI’’ from the proposed whether interoperability elements are clarification, as it was always our intent definition will fall under the ‘‘access’’ limited to those elements to which an that ‘‘transmission’’ would be definition, particularly in light of the actor can lawfully confer rights or interpreted this way. modifications we have made to the licenses without the agreement of a ‘‘access’’ definition discussed above. third party. A few commenters stated Use Last, we note that we have removed the that the definition should exclude We have finalized ‘‘use’’ to mean ‘‘the requirement from the final definition underlying substantive content or health ability for EHI, once accessed or that it would only be considered ‘‘use’’ facts because such content is not a exchanged, to be understood and acted if the action were ‘‘to accomplish a potential means by which EHI may be upon.’’ Put another way, ‘‘use’’ is an desired outcome or to achieve a desired accessed, exchanged, or used. One of individual or entity’s ability to do purpose.’’ We do not believe this those commenters also requested that something with the EHI once it has been language is necessary because the we clarify that legally required data tags accessed or exchanged. We believe this ultimate purpose of the ‘‘use’’ of the EHI are excluded from the ‘‘interoperability final definition is more concise and is not relevant to the definition of ‘‘use.’’ element’’ definition. A commenter clear than the proposed definition—‘‘the suggested that we clarify that whether a ability of health IT or a user of health We appreciate the comments functionality is considered an IT to access relevant EHI; to suggesting that we look to more interoperability element should be comprehend the structure, content, and established definitions of ‘‘use,’’ such as determined without regard to whether it meaning of the information; and to read, that within the HIPAA Privacy Rule. We can be protected under copyright or write, modify, manipulate, or apply the did consider adopting the HIPAA patent law. One commenter requested information to accomplish a desired Privacy Rule definition, but ultimately additional examples of interoperability outcome or to achieve a desired decided that our finalized definition is elements. Another commenter requested purpose’’ (84 FR 7602). Again, we more appropriate and easier to clarification regarding the meaning of emphasize the general scope and understand within the information ‘‘transmit’’ within the definition. meaning of the definition is the same as blocking context. We also appreciate the Some commenters stated that the proposed as explained below. comments suggesting that the proposed definition is too broad and should be First, we have removed language that definition would inappropriately narrowed. A couple of commenters is more appropriately used as examples increase administrative burden; in this preamble. For instance, the use however, we do not believe there is a 127 See ONC, Connecting Health and Care for the basis for such assertion, particularly Nation: A Shared Nationwide Interoperability of the word ‘‘understood’’ in the final Roadmap at x–xi, https://www.healthit.gov/topic/ definition encompasses the ability to with the clarifications we have provided interoperability/interoperability-roadmap (Oct. comprehend various things such the and the focusing of the EHI definition. 2015) [hereinafter ‘‘Interoperability Roadmap’’].

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00166 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25807

stated that the definition is confusing noted in the regulation text, which definition, but were not called out in the and ambiguous. A few commenters included the language: ‘‘Any other proposed definition (these types of noted that we should focus the means by which electronic health interoperability elements would have definition on specific elements that are information may be accessed, been covered by the provision in the currently certified and/or are employed exchanged, or used.’’ The removal of proposed definition that an to support interoperability through this language makes the definition interoperability element could be any existing standards and requirements clearer and more concise. We note that other means by which EHI may be that enable the exchange of EHI in a we provide examples of accessed, exchanged, or used). We chose usable fashion. ‘‘interoperability elements’’ in the not to substitute the PHSA health Response. We appreciate commenters’ discussion below. information technology definition in its support of the proposed definition, as Second, we leveraged the definition of entirety for the ‘‘interoperability well as the comments that requested ‘‘health information technology’’ from element’’ definition in this final rule clarifications and suggested title XXX of the PHSA (specifically, because some aspects do not fit within improvements to the definition. We section 3000(5) of the PHSA), as added the ‘‘interoperability element’’ have streamlined the definition, with by title XIII of the HITECH Act. The definition. For instance, the concept of the intent of maintaining a broad Cures Act amended title XXX of the ‘‘packaged solutions’’ is undefined and definition of interoperability elements, PHSA to establish the information would not add clarity to the and leveraged other regulatory and blocking provision in section 3022 of interoperability element definition. industry terms to add clarity. We have the PHSA. Section 3000(5) of the PHSA Thus, we believe this approach will finalized the definition of defines ‘‘health information technology’’ achieve our goal of establishing a ‘‘interoperability element’’ to mean as ‘‘hardware, software, integrated definition of interoperability element hardware, software, integrated technologies or related licenses, that is tailored for the information technologies or related licenses, intellectual property, upgrades, or blocking context. technical information, privileges, rights, packaged solutions sold as services that Last, we have clarified within the intellectual property, upgrades, or are designed for or support the use by definition that a requisite component of services that: (1) May be necessary to health care entities or patients for the an interoperability element is that it is access, exchange, or use EHI; and (2) is electronic creation, maintenance, controlled by the actor. As used in the controlled by the actor, which includes access, or exchange of health interoperability element definition, the ability to confer all rights and information.’’ We emphasize that this controlled by the actor includes the authorizations necessary to use the definition includes intellectual ability to confer all rights and element to enable the access, exchange, property. authorizations necessary to use the or use of EHI. When we drafted the Proposed Rule, element to enable the access, exchange, While this definition remains broad, it we chose to use the term or use of EHI. In order to make this is confined by changes we have made to ‘‘interoperability element’’ to describe point clear, we have added and other parts of the information blocking the means necessary to access, finalized paragraph (2) within the section. Specifically, the more focused exchange, or use EHI instead of ‘‘health interoperability element definition (see definitions of ‘‘electronic health IT’’ because we believed that defining a § 171.102). Thus, if an actor could not information’’ and ‘‘access,’’ ‘‘exchange,’’ new term (interoperability element) confer a right or authorization necessary or ‘‘use’’ will result in a smaller scope would allow us to tailor and focus the to use the interoperability element to of interoperability elements, as defined definition to the specific issue of enable the access, exchange, or use of above, being necessary to enable access, information blocking. However, after electronic health information, (e.g., by exchange, or use of EHI. Further, under further reflection and review of way of sub-license or assignment), the the Content and Manner Exception stakeholder comments—specifically actor would not have the requisite (§ 171.301), we establish that an actor is those requesting additional clarity ‘‘control’’ under the ‘‘interoperability not required to respond to a request to regarding the definition of element’’ definition. This clarification access, exchange, or use EHI in the ‘‘interoperability element’’—we believe reinforces our position that our rule manner requested if the actor would be a better approach is to leverage the does not require or encourage actors to required to license its IP (which could definition of ‘‘health information infringe on IP rights. constitute an interoperability element) technology’’ from section 3000(5) of the We appreciate the comments that and cannot reach agreeable terms for the PHSA because that definition provides asked that we specify whether specific license with the requestor the statutory basis for the types of functionalities and technologies, such as (§ 171.301(b)(1)(i)(B)). This means that technology, services, functionality certified Health IT Modules and actors who do not want to license their necessary to support interoperability, proprietary APIs, would be considered interoperability elements will not be including the access, exchange, and use interoperability elements. We clarify required to do so if they are able to of EHI. We believe this approach of that most certified Health IT Modules respond in an alternative manner in leveraging an established, statutory and proprietary APIs would be accordance with § 171.301(b)(2). definition will promote transparency considered interoperability elements We believe the above definition and clarify ONC’s expectations for under the interoperability element improves on the proposed definition in regulated actors. definition. We also clarify that the multiple ways. First, while preserving As such, we have added ‘‘integrated underlying substantive content or health the meaning described in the Proposed technologies,’’ ‘‘intellectual property,’’ facts are not considered interoperability Rule that would constitute an and ‘‘upgrades’’ from the PHSA elements because substantive content interoperability element (i.e., hardware, definition into our definition of and health facts are not a means by software, technical information, interoperability element. These which EHI is accessed, exchanged, or technology, service, license, right, additions will strengthen the used. Regarding legally required data privilege), we have removed descriptive ‘‘interoperability element’’ definition by tags, we would need additional language and examples from the explicitly identifying types of information concerning the specific data regulation text. Such language did not interoperability elements that would tag to determine whether it could add clarity, as it was not exhaustive as have been covered by our proposed constitute an interoperability element.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00167 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25808 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

Generally, data tags would likely be existing standards or requirements the information blocking provision for considered technical information under because such a narrowed focus would certain reasonable and necessary the ‘‘interoperability element’’ unduly limit the definition, activities. We proposed that if an actor definition, but such data tags would interoperability, and the access, can establish that an exception applies need to be necessary to access, exchange, and use of EHI. The finalized to each practice for which a claim of exchange, or use EHI to be considered definition reflects that there are information blocking has been made, an interoperability element. countless means by which EHI may be including that the actor satisfied all A determination regarding whether a accessed, exchanged, or used that are applicable conditions of the exception functionality is considered an not certified or standardized. We note at all relevant times, then the practice interoperability element will be that the new Content and Manner would not constitute information determined without regard to whether it Exception (§ 171.301) supports certified blocking. is protected under copyright or patent and standards-based exchange as Comments. There was broad support law. In fact, the finalized definition of suggested by the commenter. We refer from commenters regarding the interoperability element includes readers to VIII.D.2.a of this preamble for categories of practices identified in the ‘‘licenses’’ and ‘‘intellectual property.’’ a discussion of that exception. Proposed Rule that may implicate the We have also established an exception We note that we have removed the information blocking provision, as well to information blocking that supports term ‘‘transmit’’ from the regulatory text as the non-exhaustive list of specific the licensing of intellectual property. because it no longer fit in the context of examples provided in the Proposed Rule Thus, we make clear that functionalities other changes made to the definition. to assist with compliance. Commenters generally covered by copyright, patent, noted that the illustrative examples 6. Practices That May Implicate the or other such laws can be provided were helpful in providing Information Blocking Provision interoperability elements. further clarity on the scope of the In response to the commenter who To meet the definition of information information blocking provision. Many requested additional examples of blocking under section 3022(a) of the commenters noted that considerable interoperability elements, we provide PHSA, a practice must be likely to barriers continue to obstruct both the following non-exhaustive list of interfere with, prevent, or materially provider and patient access to patient examples: discourage the access, exchange, or use data and our approach to the • Functional elements of health IT of EHI. In this section and elsewhere in information blocking provision can that could be used to access, exchange, the Proposed Rule, we discussed increase access to this data. or use EHI for any purpose, including various types of hypothetical practices Several commenters suggested the information exchanged or maintained in that could implicate the information need for a comprehensive inventory or disparate media, information systems, blocking provision. We did this to repository of examples, including or by HINs/HIEs; illustrate the scope of the information examples of information blocking • Technical information that blocking provision and to explain our conduct that have been submitted to describes the functional elements of interpretation of various statutory ONC. Many commenters suggested technology, such as a standard, concepts. However, we stressed that the specific clarifications and modifications specification, protocol, data model, or types of practices discussed in the to the examples provided in the schema, that would be required to use preamble of the Proposed Rule are Proposed Rule in the sections below, as a functional element of a certain illustrative and not exhaustive and that well as additional examples for technology, including for the purpose of many other types of practices could also inclusion in the final rule, such as developing compatible technologies that implicate the provision. We emphasized additional examples applicable to incorporate or use the functional that the fact that we did not identify or specific contexts (e.g., imaging elements; discuss a particular type of practice did providers, and pharmacies) or specific • System resources, technical not imply that it is less serious than practices (e.g., practices involving infrastructure, or HIN/HIE elements that those that were discussed in the clinical data registries and are required to enable the use of a preamble. Indeed, we explained in the pharmacogenomics). compatible technology in production Proposed Rule that because information Response. We thank commenters for environments; or blocking may take many forms, it is not their support and feedback. We have not • Licenses, rights, or privileges that possible to anticipate or catalog all revised the examples provided in the may be required to commercially offer potential types of practices that may Proposed Rule because we believe they and distribute compatible technologies raise information blocking concerns. are clear, accurate, and helpful to and make them available for use in We emphasized that any analysis of readers. To be responsive to production environments. information blocking necessarily commenters who requested additional We appreciate the comments requires a careful consideration of the examples be added to the final rule, we requesting that we clarify and narrow individual facts and circumstances, have added examples in the discussion the ‘‘interoperability element’’ including whether the practice was of ‘‘Limiting or Restricting the definition. As discussed above, we required by law, whether the actor had Interoperability of Health IT’’ in section believe the revised definition addresses the requisite knowledge, and whether VIII.C.6.c.ii. as well as additional commenters’ concerns regarding the an exception applies. A practice that examples within the preamble clarity of the definition. Responsive to seemingly meets the statutory definition discussion for the exceptions. We used commenters, the final definition is also of information blocking would not be commenters’ suggestions to help inform narrower than the proposed definition, information blocking if it was required these examples and highlight important as we have removed the proposed by law, if one or more elements of the use cases and circumstances that provision that an interoperability definition were not met, or if it was required additional clarification. We element could be any other means by covered by one of the exceptions for emphasize that these listed examples which EHI may be accessed, exchanged, reasonable and necessary activities. are illustrative, but not exhaustive. or used (see 84 FR 7602). In accordance with section 3022(a)(3) We also clarify that when we say that We have decided not to focus the of the PHSA, we proposed in the the actor must satisfy all applicable definition on certified elements or Proposed Rule to establish exceptions to conditions of the exception at all

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00168 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25809

relevant times to meet each exception, practice interferes with access, exchange In the Proposed Rule, we stated that all relevant times means any time when or use of EHI.’’ We also note that we we believe that information blocking an actor’s practice relates to the access, received many comments requesting concerns are especially pronounced exchange, or use of EHI. clarification of whether certain practices when the conduct at issue has the would constitute interference with the a. Prevention, Material Discouragement, potential to interfere with the access, access, exchange, and use of EHI, and and Other Interference exchange, or use of EHI that is created thus implicate the information blocking or maintained during the practice of We explained in the Proposed Rule provision. We address these comments medicine or the delivery of health care that the information blocking provision in section VIII.C.6.c (Examples of services to patients, which we referred and its enforcement subsection do not Practices Likely to Interfere with the to collectively as ‘‘observational health define the terms ‘‘interfere with,’’ Access, Exchange or Use of EHI) below. information’’ (84 FR 7516 and7517). We ‘‘prevent,’’ and ‘‘materially discourage,’’ b. Likelihood of Interference received a few comments seeking and use these terms collectively and clarification regarding our use of the without differentiation. Based on our We noted in the Proposed Rule that term ‘‘observational health information’’ interpretation of the information the information blocking provision is or that we provide a regulatory blocking provision and the ordinary preventative in nature. That is, the definition for the term. meanings of these terms in the context information blocking provision of EHI, we interpreted these terms to not proscribes practices that are likely to Comments. We received some be mutually exclusive. Instead, interfere with (including preventing or comments requesting clarification prevention and material discouragement materially discouraging) access, regarding the meaning of ‘‘timely’’ may be understood as types of exchange, or use of EHI—whether or not access in the discussion in the Proposed interference, and that use of these terms such harm materializes. By including Rule. in the statute to define information both the likely and the actual effects of Response. We have not established a blocking illustrates the desire to reach a practice, the information blocking set timeframe for what ‘‘timely’’ access all practices that an actor knows, or provision encourages individuals and means because there is so much should know, are likely to prevent, entities to avoid engaging in practices variability regarding what ‘‘timely’’ will materially discourage, or otherwise that undermine interoperability, and to mean based on the specific facts and interfere with the access, exchange, or proactively promote access, exchange, circumstances, and particularly with use of EHI. Consistent with this and use of EHI. regard to the broad scope of health IT understanding, we used the terms We explained that a practice would being discussed. We emphasize that ‘‘interfere with’’ and ‘‘interference’’ as satisfy the information blocking whether access is considered timely will provision’s ‘‘likelihood’’ requirement if, inclusive of prevention and material be determined based on the specific under the circumstances, there is a discouragement. facts and circumstances. We refer We explained that interference could reasonably foreseeable risk that the readers to the discussion in section take many forms. In addition to the practice will interfere with access, VIII.C.6.c. on ‘‘Limiting or Restricting prevention or material discouragement exchange, or use of EHI. We explained the Interoperability of Health IT’’ where of access, exchange, or use, we stated that a policy or practice that limits we discuss how slowing or delaying that interference could include practices timely access to information in an access, exchange, or use of EHI could be that increase the cost, complexity, or appropriate electronic format creates a considered information blocking. other burdens associated with accessing, reasonably foreseeable likelihood of exchanging, or using EHI. Interference interfering with the use of the Comments. We did not receive any could also include practices that limit information. additional comments regarding out the utility, efficacy, or value of EHI that We noted that whether the risk of interpretation of the information is accessed, exchanged, or used, such as interference is reasonably foreseeable blocking provision’s ‘‘likelihood’’ by diminishing the integrity, quality, will depend on the particular facts and requirement discussed above. completeness, or timeliness of the data. circumstances attending the practice or Response. We have finalized our Relatedly, to avoid potential ambiguity practices at issue. Because of the interpretation as described above. and clearly communicate the full range number and diversity of potential Comments. We received comments of potential practices that could practices, and the fact that different requesting clarification regarding the implicate the information blocking practices will present varying risks of meaning of ‘‘observational health provision, we proposed to codify a interfering with access, exchange, or use information’’ as used in the Proposed definition of ‘‘interfere with’’ in of EHI, we did not attempt to anticipate Rule. § 171.102, consistent with our all of the potential ways in which the interpretation set forth above (84 FR information blocking provision could be Response. As discussed earlier in 7516). implicated. Nevertheless, to assist with section VIII.C.3, after consideration of Comments. We did not receive compliance, we clarified certain concerns raised by commenters, we comments on our proposed definition of circumstances in which, based on our have not finalized the definition of EHI ‘‘interfere with.’’ experience, a practice will almost as proposed. Instead, we have finalized Response. We have finalized the always be likely to interfere with access, a more focused definition of EHI. definition of ‘‘interfere with’’ (also exchange, or use of EHI. We cautioned Because we have finalized a definition referred to as ‘‘interference’’) in that the situations listed are not of EHI with a more focused scope than § 171.102 as proposed, but with a exhaustive and that other circumstances proposed, we no longer believe our modification to remove the phrase may also give rise to a very high proposed approach regarding ‘‘access, exchange, or use of electronic likelihood of interference under the observational health information is health information’’ from the definition. information blocking provision. We necessary. Accordingly, we are not We removed this language because it noted that in each case, the totality of using the term ‘‘observational health was not necessary in the definition, and the circumstances should be evaluated information’’ in this final rule. We refer to avoid duplication, as we often say in as to whether a practice is likely to readers to section VIII.C.3. for further the preamble of this final rule that ‘‘a constitute information blocking. discussion of the definition of EHI.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00169 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25810 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

i. Purposes for Which Information May We specifically emphasize that into their information management Be Needed practices that involve an actor charging strategies, clinical workflows, and We explained in the Proposed Rule an individual a fee to access, exchange, business operations. As a result, they that the information blocking provision or use their EHI would be inherently may be reluctant to switch to other will almost always be implicated when suspect, as discussed in more detail in technologies due to the significant cost a practice interferes with access, the Fees Exception (section VIII.D.2.b), and disruption this would entail. exchange, or use of EHI for certain as there are few, if any, legitimate We explained that another important purposes, including but not limited to: reasons for an actor to charge an driver of technological dependence is • Providing patients with access to individual for access to their EHI. the ‘‘network effects’’ of health IT their EHI and the ability to exchange ii. Control Over Essential adoption, which are amplified by and use it without special effort (see Interoperability Elements; Other reliance on technologies and approaches section VII.B.4). Circumstances of Reliance or that are not standardized and do not • Ensuring that health care Dependence enable seamless interoperability. Consequently, health care providers and professionals, care givers, and other We explained in the Proposed Rule authorized persons have the EHI they other health IT users may gravitate that an actor may have substantial towards and become reliant on the need, when and where they need it, to control over one or more make treatment decisions and proprietary technologies, HIEs, or HINs interoperability elements that provide that have been adopted by other effectively coordinate and manage the only reasonable means of accessing, patient care and can use the EHI they individuals and entities with whom exchanging, or using EHI for a particular they have the greatest need to exchange may receive from other sources. purpose. We noted that, in these • Ensuring that payers and other EHI. We noted that these effects may be circumstances, any practice by the actor especially pronounced within particular entities that purchase health care that could impede the use of the services can obtain the information they products or geographic areas. For interoperability elements—or that could example, a HIN that facilitates certain need to effectively assess clinical value unnecessarily increase the cost or other and promote transparency concerning types of exchange or transactions may burden of using the elements—would be so widely adopted that it is a de facto the quality and costs of health care almost always implicate the information services. industry standard. A similar blocking provision. phenomenon may occur within a • Ensuring that health care providers We explained that the situation particular geographic area once a critical can access, exchange, and use EHI for described above is most likely when mass of hospitals, physicians, or other quality improvement and population customers or users are dependent on an providers adopt a particular EHR health management activities. actor’s technology or services, which technology, HIE, or HIN. • Supporting access, exchange, and can occur for any number of reasons. We emphasized that in these and use of EHI for patient safety and public For example, technological dependence other analogous circumstances of health purposes. may arise from legal or commercial reliance or dependence, there is a We emphasized that the need to relations, such as a health care heightened risk that an actor’s conduct ensure that EHI is readily available and provider’s reliance on its EHR developer will interfere with access, exchange, or usable for these purposes is paramount. to ensure that EHI managed on its behalf Therefore, practices that increase the is accessible and usable when it is use of EHI. To assist with compliance, cost, difficulty, or other burdens of needed. Relatedly, most EHI is currently we highlighted the following common accessing, exchanging, or using EHI for stored in EHRs and other source systems scenarios, based on our outreach to these purposes would almost always that use proprietary data models or stakeholders, in which actors exercise implicate the information blocking formats. Knowledge of the data models, control over key interoperability 128 provision. We stressed that individuals formats, or other relevant technical elements. and entities that develop health IT or information (e.g., proprietary APIs) is Health IT developers of certified have a role in making these technologies necessary to understand the data and health IT that provide EHR systems or and services available should consider make efficient use of it in other other technologies used to capture EHI the impact of their actions and take applications and technologies. Because at the point of care are in a unique steps to support interoperability and this information is routinely treated as position to control subsequent access to and use of that information. avoid impeding the availability or use of confidential or proprietary, the • EHI (84 FR 7517). developer’s cooperation is required to HINs and HIEs may be in a unique Comments. We did not receive enable uses of the EHI that go beyond position to control the flow of comments of the discussion above. the capabilities provided by the information among particular persons or Response. Consistent with the developer’s technology. This includes for particular purposes, especially if the Proposed Rule, in this final rule we the capability to export complete HIN or HIE has achieved significant continue to emphasize that practices information sets and to migrate data in adoption in a particular geographic area that interfere with the access, exchange, the event that a user decides to switch or for a particular type of health information use case. or use of EHI for the purposes listed in to a different technology. • this section and that do not meet any of We noted that separate from these Similar control over EHI may be the final exceptions will almost always contractual and intellectual property exercised by other entities, such as implicate the information blocking issues, users may become ‘‘locked in’’ to health IT developers of certified health provision and will be inherently a particular technology, HIE, or HIN for IT, that supply or control proprietary suspect. These practices may jeopardize financial or business reasons. For technologies, platforms, or services that the core functions of the health care example, many health care providers are widely adopted by a class of users system that require the access, have invested significant resources to or that are a ‘‘de facto standard’’ for exchange, or use of EHI. We believe adopt EHR technologies—including 128 As an important clarification, we note that there are few, if any, legitimate reasons costs for deployment, customization, control over interoperability elements may exist for an actor to interfere with the use of data migration, and training—and have with or without the actor’s ability to manipulate the EHI in the context of these purposes. tightly integrated these technologies price of the interoperability elements in the market.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00170 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25811

certain types of EHI exchanges or (VIII.D.2.a). We refer readers to those of an express contractual restriction, an transactions. discussions. actor may achieve the same result by • exercising intellectual property or other Health care providers within health c. Examples of Practices Likely To rights in ways that restrict access, systems and other entities that provide Interfere With Access, Exchange, or Use exchange, or use (84 FR 7518). health IT platforms, infrastructure, or of EHI information sharing policies may have a We explained that access, exchange, degree of control over interoperability or To further clarify the scope of the or use of EHI can also be restricted in the movement of data within a information blocking provision, we less formal ways. The information geographic area that is functionally described in the Proposed Rule several blocking provision may be implicated, equivalent to the control exercised by a types of practices that would be likely for example, where an actor simply dominant health IT developer, HIN, or to interfere with access, exchange, or refuses to exchange or to facilitate the HIE. use of EHI. Those examples clarified access or use of EHI, either as a general To avoid engaging in conduct that and expanded on those set forth in practice or in isolated instances. The may be considered information section 3022(a)(2) of the PHSA. refusal may be expressly stated or it may Because information blocking can blocking, actors with control over be implied from the actor’s conduct, take many forms, we emphasized that interoperability elements should be such as where the actor ignores requests the categories of practices described in careful not to engage in practices that to share EHI or provide interoperability the Proposed Rule were illustrative only exclude persons from the use of those elements; gives implausible reasons for and did not provide an exhaustive list elements or create artificial costs or not doing so; or insists on terms or or comprehensive description of other impediments to their use. conditions that are so objectively practices that may implicate the We encouraged comment on these unreasonable that they amount to a information blocking provision and its refusal to provide access, exchange, or and other circumstances that may penalties. We also reiterated that each present an especially high likelihood use of the EHI (84 FR 7518). case will turn on its unique facts. We We emphasized that restrictions on that a practice will interfere with access, noted that, for the categories of practices access, exchange, or use that are exchange, or use of EHI within the described in the Proposed Rule, we did required by law would not implicate the meaning of the information blocking not consider the applicability of any information blocking provision. provision. exceptions. We reiterate that the Moreover, we recognized that some Comments. A few commenters examples provided in the Proposed Rule restrictions, while not required by law, appreciated the examples provided and were designed to provide greater clarity may be reasonable and necessary for the ONC’s acknowledgement in the on the various types of hypothetical privacy and security of individuals’ EHI Proposed Rule that certain parties are in practices that could implicate the and noted that such practices may a unique position to control access, information blocking provision. qualify for protection under an exchange, and use of EHI. Other Comments. We received comments exception (84 FR 7519). commenters urged ONC to only hold requesting that we revise or clarify Comments. Commenters requested accountable those parties that actually examples provided in the Proposed Rule that we clarify the types of contract and have control of the EHI or control of in the following sections. agreement terms that could implicate interoperability elements necessary to Response. We have not revised or the information blocking provision access, exchange, or use the EHI in clarified the majority of the examples beyond terms specifying fees and the question. for purposes of this final rule, and we licensing of intellectual property rights. Response. We thank commenters for believe the majority of the examples are Some commenters stated that ‘‘legacy their support. We stress that any still applicable. We note in the EHR platforms’’ impede real time data analysis of whether an actor’s practices discussion below necessary flow between EHRs and the clinical constitute information blocking will clarifications concerning concepts workflow, including the use of third- depend on the particular facts and expressed in some of the proposed party clinical decision support circumstances of the case, which may examples. We refer readers to the applications, through various contract include an assessment of the actor’s Proposed Rule (84 FR 7518 through terms. Many commenters also indicated control over the EHI or interoperability 7521) for a complete listing of the that EHR developers place onerous elements necessary to access, exchange, examples provided for each category of contract terms on developers of or use the EHI in question, as practices below. applications that enable patient access applicable. A key element of to EHI through APIs. A few commenters information blocking is that the actor’s i. Restrictions on Access, Exchange, or asserted that a business associate (BA), practice is likely to interfere with an Use as defined under the HIPAA Privacy individual or entity’s ability to access, We explained in the Proposed Rule Rule, should not be liable under the exchange, or use EHI. Thus, we look at that the information blocking provision information blocking provision (or there accountability through the lens of establishes penalties, including civil should be an exception for information whether the actor is the individual or monetary penalties, or requires blocking) for not responding to or entity engaging in the practice. appropriate disincentives, for practices fulfilling requests for access, exchange, Regarding the comment that we that restrict access, exchange, or use of or use of EHI if such access, exchange, should only hold accountable those EHI for permissible purposes. We noted or use of EHI would violate the BA’s parties that actually have control of the that one means by which actors may business associate agreement (BAA). EHI or interoperability elements restrict access, exchange, or use of EHI Response. We first clarify that all of necessary to access, exchange, or use the is through formal restrictions. These the scenarios provided by the EHI, we note that we have addressed may be expressed in contract or license commenters might implicate the this issue within preamble discussion terms, EHI sharing policies, information blocking provision. We concerning the definition of organizational policies or procedures, or offer specific situations as follows ‘‘interoperability element’’ (VIII.C.5.b), other instruments or documents that set where there might be an implication. As Infeasibility Exception (VIII.D.1.d), and forth requirements related to EHI or a first example, an actor (e.g., a health Content and Manner Exception health IT. Additionally, in the absence care provider that is a covered entity

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00171 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25812 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

under HIPAA) may want to engage an HIPAA Privacy Rule (or any other law), has an agreement with the covered entity for services (e.g., use of a clinical then the information blocking provision entity to provide EHI to a third party decision support application (‘‘CDS App would require that the actor provide that requests it and the BA refuses to Developer’’)) that require the CDS App that access, exchange, or use of EHI so provide the access, exchange, or use of Developer to enter into a BAA with the long as the actor is not prohibited by EHI to a requestor in response to the health care provider and, in order to law from doing so (assuming that no request received by the CE, then the BA gain access and use of the EHI held by exception is available to the actor). (who is also an actor under the another BA of the health care provider Under the HIPAA Privacy Rule, a information blocking provision) may (e.g., EHR developer of certified health BAA must contain the elements have violated the information blocking IT), the CDS App Developer is required specified in 45 CFR 164.504(e), provision unless an exception applied. by the EHR developer of certified health including a description of the permitted Successors to Contractors and IT to enter into a contract to access its and required uses of PHI by the business Agreements EHR technology. As a second example, associate, and provide that the business an entity may offer an application that associate will not use or further disclose We note that there may be facilitates patients’ access to their EHI the protected health information other circumstances in which there is a through an API maintained by an actor than as permitted or required by the successor to a contract or agreement (e.g., EHR developer of certified health contract or as required by law.129 While when, for example, an actor goes out of IT) that is a BA of a health care provider the information blocking provision does business, a provider leaves a practice, or that is a covered entity under HIPAA. not require actors to violate these an actor engages in a merger or adopts As a third example, a health care agreements, a BAA or its associated a new corporate structure. If not provider may request EHI from an actor service level agreements must not be handled appropriately, it is possible that that is a BA of another health care used in a discriminatory manner by an information blocking could occur. provider under HIPAA, such as an EHR actor to forbid or limit disclosures that ii. Limiting or Restricting the developer of certified health IT or HIN, otherwise would be permitted by the Interoperability of Health IT that is contracted to make EHI available Privacy Rule. For example, a BAA for treatment purposes. entered into by one or more actors that We explained in the Proposed Rule In response to comments and for the permits access, exchange, or use of EHI that the information blocking provision situations described above, we clarify by certain health care providers for includes practices that restrict the that contracts and agreements can treatment should generally not prohibit access, exchange, or use of EHI in interfere with the access, exchange, and or limit the access, exchange, or use of various ways (see section 3022(a)(2) of use of EHI through terms besides those the EHI for treatment by other health the PHSA). These practices could that specify unreasonable fees and care providers of a patient. include, for example, disabling or commercially unreasonable licensing To be clear, both the health care restricting the use of a capability that terms (see sections VIII.D.2.b (Fees) and provider(s) who initiated the BAA and enables users to share EHI with users of VIII.D.2.c (Licensing) for further the BA who may be an actor under the other systems or to provide access to discussion of unreasonable fees and information blocking provision (e.g., a EHI to certain types of persons or for commercially unreasonable licensing health IT developer of certified health certain purposes that are legally terms and associated exceptions to the IT) would be subject to the information permissible. In addition, the information blocking provision). For blocking provision in the instance information blocking provision may be instance, a contract may implicate the described above. To illustrate the implicated where an actor configures or information blocking provision if it potential culpability of a BA, a BA with otherwise implements technology in included unconscionable terms for the significant market power may have ways that limit the types of data access, exchange, or use of EHI or contractually prohibited or made it elements that can be exported or used licensing of an interoperability element, difficult for its covered entity customers from the technology. We noted that which could include, but not be limited to exchange EHI, maintained by the BA, other practices that would be suspect to, requiring a software company that with health care providers that use an include configuring capabilities in a produced a patient access application to EHR system of one of the BA’s way that removes important context, relinquish all IP rights to the actor or competitors. To determine whether structure, or meaning from the EHI, or agreeing to indemnify the actor for acts there is information blocking, the that makes the data less accurate, beyond standard practice, such as gross actions and processes (e.g., negotiations) complete, or usable for important negligence on part of the actor. Such of the actors in reaching the BAA and purposes for which it may be needed. terms may be problematic with regard to associated service level agreements Likewise, implementing capabilities in information blocking in situations would need to be reviewed to determine ways that create unnecessary delays or involving unequal bargaining power whether there was any action taken by response times, or that otherwise limit related to accessing, exchanging, and an actor that was likely to interfere with the timeliness of EHI accessed or using EHI. the access, exchange, or use of EHI, and exchanged, may interfere with the access, exchange, and use of that Business Associate Agreements (BAAs) whether the actor had the requisite intent. We further note that if the BA information and therefore implicate the We designed the final rule to operate information blocking provision. We in a manner consistent with the 129 45 CFR 164.514(e)(3) limits the use and noted that any conclusions regarding framework of the HIPAA Privacy Rule disclosure of a limited data set (LDS) to only the such interference would be based on and other laws providing privacy rights purposes of research, public health or health care fact-finding specific to each case and operations. Some of the other restrictions on use for patients. Foremost, we do not and disclosure by a party that receives LDS would need to consider the applicability require the disclosure of EHI in any way Recipient are similar to those imposed by the of the exceptions. that would not already be permitted HIPAA Rules on business associates so the We explained that the information under the HIPAA Privacy Rule (or other discussion that follows generally applies to blocking provision would be implicated recipients of LDS and their data use agreements as Federal or State law). However, if an well as to business associates (and their business if an actor were to deploy technological actor is permitted to provide access, associate agreements) to the extent of such similar measures that limit or restrict the ability exchange, or use of EHI under the provisions. to reverse engineer the functional

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00172 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25813

aspects of technology in order to behalf of API Information Sources. We considered an interference with the develop means for extracting and using also clarify that the public availability of access, exchange, or use of EHI. EHI maintained in the technology. We FHIR service base URLs is a requirement We note that we have added noted that this may include, for that is scoped specifically to the context definitions of ‘‘API Information example, employing technological of patients’ access to their EHI and is Source,’’ ‘‘API User,’’ ‘‘Certified API protection measures that, if not intended to be interpreted as Developer,’’ and ‘‘certified API circumvented, would trigger liability requiring all FHIR service base URLs to technology’’ to § 171.102. Each of those under the Digital Millennium Copyright be made publicly available (i.e., FHIR terms is defined as they are in Act (see 17 U.S.C. 1201) or other laws. service base URLs that are created and § 170.404(c). We note that ‘‘API used among business partners would Information Source’’ replaced the Additional Examples not need to be made publicly available). proposed definition of ‘‘API Data In the context of ONC’s certification Along the same lines discussed in the Provider’’ and ‘‘Certified API rules, including certification criteria and example directly above, for a patient to Developer’’ replaced the proposed Conditions and Maintenance of be able to use an application of their definition of ‘‘API Technology Certification requirements, we provide choice with certified API technology, Supplier’’ in order to align with the the following more explicit examples of the software application will need to be terms used in § 170.404(c) (see the actions by actors that would likely ‘‘registered.’’ In that regard, as a second proposed terms in 84 FR 7601). constitute information blocking. example, an actor’s refusal to register a Comments. A few commenters The first example of a technical software application that enables a requested that we provide further clarity interference that restricts the patient to access their EHI would on whether slowing or delaying access, interoperability of health IT relates to effectively prevent its use given that exchange, or use of EHI could be the publication of ‘‘FHIR service base registration is a technical prerequisite considered information blocking. URLs’’ (sometimes also referred to as for software applications to be able to Response. We clarify that slowing or ‘‘FHIR endpoints’’). As discussed in the connect to certified API technology. As delaying access, exchange, or use of EHI API Condition of Certification preamble a result, such refusals in the context of could constitute an ‘‘interference’’ and (section VII.B.4), an API User needs to patient access unless otherwise implicate the information blocking know a certified API technology’s FHIR addressed in this rule would be highly provision. We understand that some service base URL to interact with the suspect and likely to implicate delays may be legitimate and inevitable certified API technology. This information blocking. We note, due to factors such as limited legal, knowledge is foundational for the use of however, for the first and second project management, and technical certified API technology without special example that neither app registration resources. Notwithstanding such effort. Therefore, a FHIR service base nor the public availability of a FHIR understandable challenges, we are URL cannot be withheld by an actor as service base URL means that an aware that some actors use and it (just like many other technical application will be able to access any embellish legitimate challenges to create interfaces) is necessary to enable the EHI. On the contrary, the application extended and unnecessary delays. For access, exchange, and use of EHI. would be unable to do so unless a instance, an actor could have legitimate Notably, in the case of patients seeking patient authenticates themselves via an technical scoping and architecture access to their EHI, the public appropriate workflow or, in the case of questions regarding data integrations availability of FHIR service base URLs is a health care provider, the application is that require attention and take time to an absolute necessity and without appropriately configured to work within address. However, these scoping and which the access, exchange, and use of the provider’s IT infrastructure. architecture questions could constitute EHI would be prevented. Thus, any As a third example, there is often interference and implicate the action by an actor to restrict the public specific information that may be information blocking provision if they availability of URLs in support of necessary for certain actors, in this case are not necessary to enable access, patient access would be more than just health care providers, to effectively exchange, or use of EHI and are being likely to interfere with the access, access, exchange, and use EHI via their utilized as a delay tactic. When exchange, or use of EHI; it would Certified EHR Technology and certified assessing such practices, facts indicating prevent such access, exchange, and use. Health IT Modules. A health care that an actor created extended or Accordingly, as noted in § 170.404(b)(2), provider’s ‘‘direct address’’ is an unnecessary delays may be evidence of a Certified API Developer must publish example of this kind of information. If an actor’s intent. We expect actors to FHIR service base URLs for certified API this information were not made known make good faith efforts to work through technology that can be used by patients to a health care provider upon request, common and understandable challenges to access their electronic health were inaccessible or hidden in a way and limitations to enable requestors to information. that a health care provider could not access, exchange, and use EHI as Consistent with this example, the identify (or find out) their own direct quickly and efficiently as possible. above interpretation means that API address, or were refused to be provided Information Sources (i.e., health care to a health care provider by a health IT iii. Impeding Innovations and providers) who locally manage their developer with certified health IT, we Advancements in Access, Exchange, or FHIR servers without Certified API would consider all such actions to be Use or Health IT-Enabled Care Delivery Developer assistance cannot refuse to information blocking because We explained in the Proposed Rule provide to Certified API Developers the knowledge of a direct address is that the information blocking provision FHIR service base URL(s) that is/are necessary to fully engage in the encompasses practices that create necessary for patients to use to access exchange of EHI. impediments to innovations and their EHI. Equally, pursuant to the As a last example, we note that, to the advancements to the access, exchange, Maintenance of Certification extent that a legal transfer of IP to an and use of EHI, including care delivery requirement finalized for Certified API individual or entity that is not an actor enabled by health IT (section Developers in § 170.404, they would be is intended to facilitate circumvention 3022(a)(2)(C)(ii) of the PHSA). required to publish the FHIR service of the information blocking provision, Importantly, the information blocking base URLs they centrally manage on the transfer itself by an actor could be provision may be implicated and

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00173 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25814 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

penalties or appropriate disincentives applicable and encourage readers to constitute an interference under the may apply if an actor were to engage in review the examples in the Proposed information blocking provision. We exclusionary, discriminatory, or other Rule (84 FR 7520). refer readers to the Licensing Exception practices that impede the development, Not all instances of differential preamble discussion in section dissemination, or use of interoperable treatment would necessarily constitute a VIII.D.2.c. technologies and services that enhance discriminatory practice that may Interference Versus Education When an access, exchange, or use of EHI. implicate the information blocking We emphasized that, most acutely, provision. For example, we explained Individual Chooses Technology To the information blocking provision may that different fee structures or other Facilitate Access be implicated if an actor were to refuse terms may reflect genuine differences in In the Proposed Rule, we stated that to license or allow the disclosure of the cost, quality, or value of the EHI and the information blocking provision interoperability elements to persons the effort required to provide access, would likely be implicated when an who require those elements to develop exchange, or use. We also noted that, in EHR developer of certified health IT and provide interoperable technologies certain circumstances, it may be requires third-party applications to be or services—including those that might reasonable and necessary for an actor to ‘‘vetted’’ for security before use but does complement or compete with the actor’s restrict or impose reasonable and non- not promptly conduct the vetting or own technology or services. The same discriminatory terms or conditions on conducts the vetting in a discriminatory would be true if the actor were to allow the use of interoperability elements, or exclusionary manner (84 FR 7519). access to interoperability elements but even though such practices could We also stated under the proposed were to restrict their use for these implicate the information blocking ‘‘promoting the privacy of EHI’’ purposes. We provided a list of non- provision. For this reason, and as exception that when the consent or exhaustive examples to illustrate further explained in section VIII.D, we authorization of an individual was practices that would likely implicate the proposed to establish a narrow necessary for access, exchange, or use of information blocking provision by exception for licensing interoperability EHI, to qualify for the exception, an interfering with access, exchange, or use elements (see § 171.303) that would actor must not have improperly of EHI (84 FR 7519 and 7520). We apply to these types of practices. encouraged or induced the individual to encourage readers to review those Comments. We received some not provide the consent or examples in the Proposed Rule, as they recommendations to describe specific authorization. We further stated that are still applicable. scenarios when a refusal to license this does not mean that an actor cannot We explained that, rather than would be considered information inform an individual about the restricting interoperability elements, an blocking. advantages and disadvantages of actor may insist on terms or conditions Response. We note that for the exchanging EHI and any associated that are burdensome and discourage purposes of the categories of practices risks, so long as the information their use. These practices may implicate described in the Proposed Rule (84 FR communicated is accurate and the information blocking provision as 7518 through 7521), we did not consider legitimate. However, we noted that an well. We have chosen not to include the applicability of any exceptions, and actor could not mislead an individual those examples in this final rule, but strongly encouraged readers to review about the nature of the consent to be emphasize that they are still applicable the discussion of practices in this provided, dissuade individuals from and encourage readers to review the section in conjunction with the section providing consent in respect of examples in the Proposed Rule (84 FR on the exceptions (84 FR 7518). disclosures to the actor’s competitors, or 7520). Regarding the specific comment above impose onerous requirements to We explained that the information regarding licensing, we direct readers to effectuate consent that were blocking provision may also be our discussion of the Licensing unnecessary and not required by law (84 implicated if an actor were to Exception (section VIII.D.2.c.) for FR 7531). discourage efforts to develop or use additional examples and a discussion of interoperable technologies or services substantive conditions we have Overview of Comments by exercising its influence over finalized for the licensing of Commenters expressed concerns that customers, users, or other persons, and interoperability elements under the app developers not covered by the we provided a non-exhaustive list of exception. HIPAA Rules frequently do not provide examples. We have chosen not to We note one important clarification patients (individuals) with clear terms include those examples in this final that applies to all examples in the of how their EHI will be subsequently rule, but emphasize that they are still Proposed Rule concerning the licensing used by the app developer once patients applicable and encourage readers to of interoperability elements. As clarified authorize (approve) the app to receive review the examples in the Proposed in the Licensing Exception preamble their EHI. These commenters, many of Rule (84 FR 7520).We noted that similar discussion, an actor will not implicate whom would be actors under the concerns would arise were an actor to the information blocking provision in information blocking provision, engage in discriminatory practices— circumstances where the entity expressed these concerns in comments such as imposing unnecessary and requesting to license or use the recited below, while also requesting burdensome administrative, technical, interoperability element is not seeking clarification about what steps they may contractual, or other requirements on to use the interoperability element to take to assist individuals in protecting certain persons or classes of persons— interoperate with either the actor or the the privacy and security of their EHI. that interfere with access and exchange actor’s customers in order for EHI to be Comments. Commenters requested of EHI by frustrating or discouraging accessed, exchanged, or used. In other that we clarify the extent of vetting that efforts to enable interoperability. We words, if there is no nexus between a would be permitted by actors for third- provided a list of non-exhaustive requestor’s need to license an party apps. examples to illustrate some ways this interoperability element and existing Response. We first clarify that the could occur. We have chosen not to EHI, an actor’s refusal to license the example provided in the Proposed Rule include those examples in this final interoperability element altogether or in and recited above was to illuminate rule, but emphasize that they are still accordance with § 171.303 would not practices, such as delaying access and

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00174 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25815

discriminatory behavior, which could without the individual’s consent or including API technology suppliers, to implicate the information blocking could expose all of the individual’s EHI verify the existence of a privacy notice provision. ‘‘Vetting’’ in the example’s without the individual’s knowledge. for each application requesting context meant a determination regarding Response. This final rule supports an registration by an API User (third-party whether the app posed a security risk to individual’s ability to choose which app developer). Commenters also the EHR developer’s API, which may be third-party developer and app are best suggested that the privacy notices the situation with a proprietary API. For for receiving all or part of their EHI from should be commensurate with ONC’s certified API technology, which a health care provider and to agree to Model Privacy Notice (MPN). One includes the use of OAuth2 among other clear and public terms of use on how commenter recommended that all third- security requirements in addition to its that initial and ongoing engagement party developers should have to attest focus on ‘‘read-only’’/responses to with the third-party developer and app ‘‘yes’’ or ‘‘no’’ to having a privacy notice requests for EHI to be transmitted, there occurs. As discussed in more detail for each app it makes available for use/ should be few, if any, security concerns below, this final rule also supports and (for patients to use) to access EHI. The about the risks posed by patient-facing strongly encourages providing commenter asserted that requiring apps to the disclosing actor’s health IT individuals with information that will attestation would provide transparency systems (because the apps would only assist them in making the best choice for about the existence or lack of privacy be permitted to receive EHI at the themselves in selecting a third-party policies and practices and data uses and patient’s direction). Thus, for third- application. We believe that allowing serve as a means to support enforcement party applications chosen by actors to provide additional information of acts of deceptive or misleading individuals to facilitate their access to to individuals about apps will assist conduct in relation to stated privacy their EHI held by actors, there would individuals as they choose apps to policies and practices. generally not be a need for ‘‘vetting’’ on receive their EHI and such an approach Response. As noted above, an actor security grounds and such vetting is consistent with statements in the may provide factually accurate, actions otherwise would be an Proposed Rule recited above regarding objective, unbiased, fair, and non- interference. We refer readers to our informing individuals about the discriminatory information about the discussion of ‘‘vetting’’ versus verifying advantages and disadvantages of third party or third-party app that an an app developer’s authenticity under exchanging EHI and any associated individual chooses to use to receive EHI the API Condition of Certification risks. Individuals concerned about on their behalf. And as also noted earlier in section VII.B.4 of this information privacy and security can above, we strongly encourage actors to preamble. We do note, however, that gain a better understanding about how educate patients and individuals about actors, such as health care providers, the third-party apps are using and the risks of providing other entities or have the ability to conduct whatever storing their EHI, how individuals will parties access to their EHI. This type of ‘‘vetting’’ they deem necessary of be able to exercise any consent options, education can be designed to inform the entities (e.g., app developers) that and more about what individuals are patient about the privacy and security would be their business associates consenting to before they allow the app practices of the third party and the under HIPAA before granting access and to receive their EHI. third-party app, including whether the Practices that purport to educate use of EHI to the entities. In this regard, third-party developer has not acted in patients about the privacy and security covered entities must conduct necessary accordance with elements of its privacy practices of applications and parties to policy. In this regard, we think there are vetting in order to comply with the whom a patient chooses to receive their many efficient and allowable ways of HIPAA Security Rule. EHI may be reviewed by OIG or ONC, providing such education without such Comments. Several commenters as applicable, if there was a claim of practices being considered or creating stated that the information blocking information blocking. However, we an interference under the information proposals would open the door for believe it is unlikely these practices blocking provision, including those third-party apps (e.g., patient-facing would interfere with the access, similar to the one suggested by the apps) to access, exchange, and use exchange, and use of EHI if they meet commenter. copious amounts of patient data without certain criteria. Foremost, the For example, to the commenter’s providing patients with clear terms of information provided by actors must specific point, actors may establish use. Commenters stated that most focus on any current privacy and/or processes where they notify a patient, individuals may be surprised when security risks posed by the technology call to a patient’s attention, or display commercial application companies that or the third-party developer of the in advance (as part of the app are not subject to the HIPAA Rules technology. Second, this information authorization process with certified API shared health information obtained from must be factually accurate, unbiased, technology) whether the third-party a hospital or health plan, such as objective, and not unfair or deceptive. developer of the app that the patient is diagnoses, medications, or test results, Finally, the information must be about to authorize to receive their EHI in ways the HIPAA Rules would not provided in a non-discriminatory has attested in the positive or negative permit. These commenters asserted that manner. For example, all third-party whether the third party’s privacy policy individuals would incorrectly blame the apps must be treated the same way in and practices (including security hospital or health plan if a third-party terms of whether or not information is practices such as whether the app app developer sold their EHI or used it provided to individuals about the encrypts the EHI) meet certain ‘‘best for marketing or other purposes. privacy and security practices practices’’ set by the market for privacy Additionally, the commenters employed. To be clear, an actor may not policies and practices. We note that we contended that because the third-party prevent an individual from deciding to identify minimum best practices for apps and the third-party app developers provide its EHI to a technology third-party privacy policies and are not subject to the HIPAA Rules, such developer or app despite any risks noted practices below. This notification, developers may, through their apps’ regarding the app itself or the third- would enable a patient to pause, required terms of use, grant the party developer. consider this educational information developers the right to sell the EHI Comments. Several commenters provided by the actor, and decide received or generated by the app requested that we require actors, whether to proceed with approving the

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00175 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25816 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

app to receive their EHI or to stop mid- We note that the market may set health care provider does not provide way in the process to do more research different and more stringent the patient’s EHI to App-Y. into the app or to pick a different app, expectations for third-party privacy Example 2: Patient sending EHI using in which case the patient would not notices and practices than the above certified health IT capabilities provided approve the original app in question to minimum. As described above and in by health IT developer. receive their EHI. Understandably, in the examples below, an actor may An individual has made an order for an actor to execute this kind provide information or notice to the appointment with a health care of notification or attention grabbing individual whose EHI is requested from specialist for a second medical opinion. process and to attribute certain app the actor that the privacy policy that During the initial scheduling, the developer practices to educational applies to the technology used to make administrative staff requested that the insights provided to a patient in real- the request does or does not meet the individual bring all their prior health time, certain information may need to minimum privacy policy notice and information to the specialist. The be collected by an actor in advance. practices outlined above. patient portal of the individual’s Such information may include whether Example 1: Providing education to an primary care provider allows EHI to be the app developer has a privacy notice, individual of a third-party app transmitted to a third party using Direct policies, or practices. Actors providing developer’s privacy and security policies protocol. The individual identifies a patients with educational information (a and practices through an automated third-party app that is able to receive notice) could help patients better attestation and warning process. EHI using Direct protocol and creates an account with the app as well as obtain/ understand how their EHI may be used An API User (third-party app create a ‘‘Direct address.’’ During the by the app and the third-party developer) develops a software account creation process with the app, developer. application (named ‘‘App-Y’’) and the individual reviews the ‘‘privacy While the ONC 2018 MPN is a registers it with the Certified API policy’’ for the app. The third-party app voluntary, openly available resource Developer’s (developer of certified also sends the individual a copy of the designed to help developers clearly health IT) authorization server. During privacy policy via email once the convey comprehensive information the registration process, the Certified individual completes the account about their privacy and security policies API Developer requests, as a business creation process. and practices to their users, the privacy associate and on behalf of a HIPAA Subsequently, the individual logs into notice and practices of a third-party covered entity, that the API User attest the primary care provider’s portal to developer’s app or personal health that for App-Y, the API User follows the transmit her EHI to her direct address record does not have to be identical to privacy policies and practices outlined linked to her new account on the third- the ONC’s 2018 MPN. There may be above. Given the ‘‘yes or no’’ choice, the party app. Her provider uses certified other privacy policies and practices API User attests ‘‘no.’’ The Certified API health IT that is capable of sending EHI (including security practices) of third- Developer completes App-Y’s securely using Direct protocol to third- party developers and apps that registration process and provides it with party organizations (including apps) accomplish the same goals and even a client identifier. An individual seeks with which they have exchanged trust provide more information relevant to a to use App-Y to obtain their EHI from anchors. It turns out, the health care user. At a minimum, as it relates to the the health care provider (covered entity) provider has established prior trust with above, all third-party privacy policies that is a customer of the Certified API the third-party app and is able to send and practices should adhere to the Developer. The individual then opens EHI to the application. To note, this following: App-Y on their smartphone and after health care provider may offer (1) The privacy policy is made authenticating themselves to their education, including a warning (notice), publicly accessible at all times, health care provider (covered entity), to the patient, as discussed above, if the including updated versions; but prior to the app receiving the EHI provider is being directed by the patient (2) The privacy policy is shared with from the health care provider, the to transmit their EHI to a recipient that all individuals that use the technology patient is provided with an app is unknown to the provider. prior to the technology’s receipt of EHI authorization screen controlled by the Prior to sending the EHI, the portal from an actor; health care provider. provides a summary screen that (3) The privacy policy is written in Using the certified API technology provides the privacy policy ‘‘warning’’ plain language and in a manner and the normal OAuth2 workflow the about the third-party app. The patient calculated to inform the individual who patient is asked by the health care reviews and accepts it. The provider’s uses the technology; provider via the app authorization system/API technology sends EHI to her (4) The privacy policy includes a screen whether they want to approve or Direct address. The patient logs into her statement of whether and how the reject App-Y’s ability to receive their application and confirms that the EHI individual’s EHI may be accessed, EHI via certified API technology. On the has been received. exchanged, or used by any other person authorization screen, there is a Comments. Commenters stated that, or other entity, including whether the ‘‘warning’’ from the health care provider given the access to personal health individual’s EHI may be sold at any that the application has not ‘‘attested’’ information that patient-directed third- time (including in the future); and to having privacy policies and practices party apps are expected to have and the (5) The privacy policy includes a that adhere to the minimum policies potential privacy risks they pose, a requirement for express consent from and practices outlined above or to process should be implemented by the the individual before the individual’s having other specified privacy and Federal Trade Commission (FTC) to vet EHI is accessed, exchanged, or used, security policies. When presented with apps for the adequacy of the consumer including receiving the individual’s that warning, the patient has two disclosures which should include the express consent before the individual’s choices: (1) Choose to ignore the privacy and security of the information EHI is sold (other than disclosures warning and approve App-Y’s ability to and secondary uses that should be required by law or disclosures necessary receive their EHI and App-Y receives permitted. A commenter suggested that in connection with the sale of the the patient’s PHI; or (2) reject App-Y’s the vetting process should be at the application or a similar transaction). ability to receive their EHI, and the application and application developer

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00176 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25817

level, and that the results of such vetting Interactive Tool; 131 and more recently medical history becomes part of the process should be made public in the published and developed the Privacy medical record, the individual/patient form of an application ‘‘safe list.’’ and Security Framework for Patient- may exercise the rights under the Response. The privacy practices of Centered Outcomes Research (PCOR). HIPAA Privacy Rule, 45 CFR 164.524, to developers of patient-facing health IT This project developed tools and this information in the same fashion as resources that address the many any other information in the medical products and services are typically different types of data that can be used record, including the right of access. As regulated by the Federal Trade to conduct patient-centered outcomes discussed above, actors may educate Commission Act (FTC Act). The FTC research. The framework consists of two patients of the risks related to providing Act prohibits unfair or deceptive acts or initiatives: The Legal and Ethical other persons and entities with their practices in or affecting commerce (15 Architecture for PCOR Data EHI, including the various the types of U.S.C. 45(a)(1)), but it does not prescribe (Architecture), which guides readers EHI (e.g., family health history) that will specific privacy requirements. The FTC through the responsible use and be provided to an entity (e.g., third- has authority to enforce the FTC Act’s protection of electronic health data for party app) at the patient’s request. prohibition on deception, for example, PCOR and The Patient Choice Technical iv. Rent-Seeking and Other by challenging deceptive statements Project which harmonized existing Opportunistic Pricing Practices made in privacy policies, user technical mechanisms to enable interfaces, FAQs, or other consumer- interoperable exchange of patient Certain practices that artificially facing materials. The FTC could also, for consent for basic and granular choice for increase the cost and expense associated example, challenge a particular use or research and treatment, payment, and with accessing, exchanging, and using disclosure of EHI as unfair if it causes health care operations. This project, EHI may implicate the information or is likely to cause substantial injury to which remains active, also identifies, blocking provision. We emphasized in consumers that is not reasonably tests and validates technical standards the Proposed Rule that such practices avoidable by consumers themselves and that support an individual’s consent are plainly contrary to the information not outweighed by countervailing preferences.132 blocking provision and the concerns benefits to consumers or to competition We will continue to monitor how that motivated its enactment. We explained that an actor may seek (15 U.S.C. 45(n)). We will continue to individuals are educated about potential to extract profits or capture revenue work with our Federal partners, privacy and security risks of third-party streams that would be unobtainable including the FTC, to assess education apps and will continue to work with without control of a technology or other opportunities for consumers and app HHS OCR and industry stakeholders to further educate individuals as part of interoperability elements that are developers about the privacy and necessary to enable or facilitate access, security of EHI collected, used, or our implementation of section 4006 of the Cures Act. In this regard, we also exchange, or use of EHI. Most EHI is received by health apps. encourage individuals to review currently stored in EHRs and other Comments. A commenter consumer education materials related to source systems that use proprietary data recommended the development of a protecting their EHI on our website at models or formats; this puts EHR privacy framework regarding how healthit.gov (‘‘What You Can do to developers (and other actors that control health information should be shared Protection Your Health Information’’— data models or standards) in a unique and to empowering consumers; and it https://www.healthit.gov/topic/privacy- position to block access to (including noted that it should be developed and security/what-you-can-do-protect-your- the export and portability of) EHI for use matured in concert with the health-information; and ‘‘Health IT: in competing systems or applications or modernization of our nation’s health IT How to Keep Your Health Information to charge rents for access to the basic infrastructure. They expressed that there Privacy and Secure: Fact Sheet’’— technical information needed to are private sector and public-private https://www.healthit.gov/sites/default/ accomplish the access, exchange, or use examples of models that we should look files/how_to_keep_your_health_ of EHI for these purposes. We to from both health care and other information_private_and_secure.pdf). emphasized that these information industries. They believed that the Comments. Commenters expressed blocking concerns may be compounded Proposed Rule does not, however, fully concerns that if patients access their to the extent that EHR developers do not address patient and consumer privacy health data—some of which could disclose, in advance, the fees they will protections. They recommended that the contain family history and could be charge for interfaces, data export, data Center for Medicare and Medicaid sensitive—through a smartphone, they portability, and other interoperability- Services and ONC should work together should have a clear understanding of related services (see 80 FR 62719 through 62725; 80 FR 16880 through with relevant agencies and departments the potential uses of that data by third- 16881). We noted that these concerns and private-sector colleagues to develop party app suppliers. Response. Under the HIPAA Privacy are not limited to EHR developers. a companion consumer privacy Rule, when a covered health care Other actors who exercise substantial framework. provider, in the course of treating an control over EHI or essential Response. We are aware of various individual, collects or otherwise obtains interoperability elements may engage in industry initiatives regarding a ‘‘privacy an individual’s family medical history, analogous behaviors that would framework.’’ We have previously this information may become part of the implicate the information blocking published the Nationwide Privacy and individual’s medical record (45 CFR provision (84 FR 7520). Security Framework for Electronic 164.501 (definition of ‘‘Designated To illustrate, we provided a list of Exchange of Individually Identifiable Record Set’’). Thus, if the family non-exhaustive examples that reflected Health Information; 130 produced, in some of the more common types of rent- cooperation with the FTC, FDA, and 131 https://www.ftc.gov/tips-advice/business- seeking and opportunistic behaviors of center/guidance/mobile-health-apps-interactive- which we were aware and that are likely OCR, the Mobile Health Apps tool. 132 See https://www.healthit.gov/topic/scientific- to interfere with access, exchange, or 130 https://www.healthit.gov/sites/default/files/ initiatives/pcor/privacy-and-security-framework- use of EHI. Those examples are still nationwide-ps-framework-5.pdf. pcor-psp. applicable and we encourage readers to

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00177 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25818 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

review the examples in the Proposed actor does not implement the standard, of health IT implementation, such as Rule (84 FR 7520 and 7521). does not implement updates to the implementing newly adopted standards The information blocking provision standard, or implements the standard in or requirements. One commenter may be implicated by these and other a way that materially deviates from its highlighted the importance of being able practices by which an actor profits from formal specifications. We noted that to retain certain types of optionality, its unreasonable control over EHI or these practices lead to unnecessary especially for specialized use cases. interoperability elements without complexity and burden, such as the Other commenters expressed concern adding any efficiency to the health care additional cost and effort required to that considering non-standard system or serving any other pro- implement and maintain ‘‘point-to- implementation practices as likely to competitive purpose. However, we point’’ connections, custom-built implicate the information blocking stressed that the reach of the interfaces, and one-off trust agreements. provision could have the unintended information blocking provision is not While each case will necessarily consequence of stymying innovative or limited to these types of practices. We depend on its individual facts, and novel technologies used in information interpreted the definition of information while we recognized that the exchange. blocking to encompass any fee that development and adoption of standards Response. We appreciate the materially discourages or otherwise across the health IT industry is an commenters’ suggestions. We emphasize imposes a material impediment to ongoing process, we explained that the that the problematic nature of non- access, exchange, or use of EHI. We information blocking provision would standard design and implementation used the term ‘‘fee’’ in the broadest be implicated in at least two distinct choices was identified by Congress in possible sense to refer to any present or sets of circumstances. First, we stated section 3022(a)(2)(B) of the PHSA, future obligation to pay money or that information blocking may arise which states that information blocking provide any other thing of value and where an actor chooses not to adopt, or may include implementing health IT in proposed to include this definition in to materially deviate from, relevant non-standard ways that are likely to § 171.102. We noted that this scope may standards, implementation substantially increase the complexity or be broader than necessary to address specifications, and certification criteria burden of accessing, exchanging, or genuine information blocking concerns adopted by the Secretary under section using EHI. We continue to be concerned and could unnecessarily diminish 3004 of the PHSA. Second, even where that these practices will lead to investment and innovation in no federally adopted or identified unnecessary complexity and burden interoperable technologies and services. standard exists, if a particular related to the access, exchange, or use Therefore, as further explained in implementation approach has been of EHI, and depending on the section VIII.D, we proposed to create an broadly adopted in a relevant industry circumstances, we maintain that such exception that, subject to certain segment, deviations from that approach practices would be likely to interfere conditions, would permit the recovery would be suspect unless strictly with access, exchange, or use of EHI. We of costs that are reasonably incurred to necessary to achieve substantial refer readers to the discussion of this provide access, exchange, and use of efficiencies. topic in the Fees Exception (section EHI (84 FR 7521). To further illustrate these types of VIII.D.2.b). Comments. We did not receive practices that may implicate the We also agree, however, that we must comments specifically on our proposed information blocking provision, we give each case careful consideration and definition of ‘‘fee.’’ provided a list of non-exhaustive assess the individual facts and examples of conduct that would be Response. We have finalized the circumstances to determine whether likely to interfere with access, exchange, definition in § 171.102 as proposed. such practices would be likely to or use of EHI. We have chosen not to Comments. A few commenters interfere with access, exchange, or use include those examples in this final requested additional examples and of EHI. clarity on the types of rent-seeking and rule, but emphasize that they are still opportunistic pricing practices that applicable and encourage readers to 7. Applicability of Exceptions would be likely to implicate the review the examples in the Proposed a. Reasonable and Necessary Activities information blocking provision. Rule (84 FR 7521). Response. We refer readers to our We explained that even where no Section 3022(a)(3) of the PHSA discussion of the Fees Exception standards exist for a particular purpose, requires the Secretary to identify, (section VIII.D.2.b.) for additional actors should not design or implement through notice and comment examples, as well as for a detailed health IT in non-standard ways that rulemaking, reasonable and necessary discussion of fees that may and may not unnecessarily increase the costs, activities that do not constitute be charged under this exception. complexity, and other burdens of information blocking for purposes of the accessing, exchanging, or using EHI. We definition in section 3022(a)(1). Section v. Non-Standard Implementation also noted that we were aware that some 3022(a)(1) of the PHSA defines Practices actors attribute certain non-standard information blocking by referring to We explained in the Proposed Rule implementations on legacy systems that practices likely to interfere with, that section 3022(a)(2)(B) of the PHSA the actor did not themselves design but prevent or materially discourage access, states that information blocking may which have to be integrated into the exchange or use of electronic health include implementing health IT in non- actor’s health IT. We noted that such information. Based on this terminology standard ways that substantially instances will be considered on a case- used in the PHSA, we noted that increase the complexity or burden of by-case basis. conduct that implicates the information accessing, exchanging, or using EHI. In Comments. A few commenters blocking provision and that does not fall general, this type of interference is requested additional clarity on when within one of the exceptions or does not likely to occur when, despite the non-standard based interoperability is meet all conditions for an exception, availability of generally accepted permissible. Some commenters urged would be considered a ‘‘practice.’’ technical, policy, or other approaches ONC to be careful and flexible in its Conduct that falls within an exception that are suitable for achieving a interpretation of this information and meets all the applicable conditions particular implementation objective, an blocking practice given the complexities for that exception would be considered

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00178 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25819

an ‘‘activity.’’ We noted that the identifying exceptions, we describe met an exception. In particular, many challenge with this distinction is that practices that, if all the applicable commenters noted that meeting the when examining conduct that is the conditions are met, are reasonable and exceptions will substantially increase subject of an information blocking necessary and not information blocking. documentation burden and other claim—an actor’s actions that are likely administrative costs for actors. b. Treatment of Different Types of to interfere with access, exchange, or Commenters also noted that Actors use of EHI—it can be illusory to organizations may need to update, distinguish, on its face, conduct that is We explained in the Proposed Rule develop and/or implement policies and a practice and conduct that is an that the proposed exceptions would procedures focused on documenting activity. Indeed, conduct that implicates apply to health care providers, health IT compliance with information blocking the information blocking provision but developers of certified health IT, HIEs, exceptions. Many commenters falls within an exception could and HINs who engage in certain requested that ONC develop and nonetheless be considered information practices covered by an exception, provide examples, templates, and blocking if the actor has not satisfied the provided that all applicable conditions guidance on the type of documentation conditions applicable to that exception. of the exception are satisfied at all that would be acceptable to support the Acknowledging the terminology used relevant times and for each practice for conditions for each information in the PHSA, we proposed to define which the exception is sought. We blocking exception. Several commenters ‘‘practice’’ in § 171.102 as one or more noted that the exceptions are generally noted that the supporting related acts or omissions by an actor. applicable to all actors. However, in documentation should clearly We also proposed to use the term some instances, we proposed conditions demonstrate why the actor qualifies for ‘‘practice’’ throughout the Proposed within an exception that apply to a the exception, why the exception is Rule when we described conduct that is particular type of actor. required, and how all conditions of the likely to interfere with, prevent, or Comments. Several commenters exception are fulfilled. One commenter materially discourage the access, agreed that the exceptions should apply asked that we provide guidance on the exchange, or use of EHI, and clarify to all actors. A few commenters appropriate storage method for this when describing the conduct at issue requested that ONC identify exceptions documentation, as this information may whether it is a practice that is that apply to all actors and identify not be appropriate for the clinical information blocking, a practice that exceptions that only apply to select record. implicates the information blocking actors. Response. We thank commenters for provision, or a practice that is Response. We appreciate the support these thoughtful comments and reasonable and necessary and not for our approach to the exceptions, as suggestions. We have tailored the information blocking (84 FR 7522). We well as the suggestion to restructure the exceptions and provided significant stated that adopting the terminology of exceptions. We continue to believe that detail within each exception to clearly ‘‘activity’’ to describe conduct that may the clearest and most equitable explain what an actor must do to meet or may not be information blocking approach to the exceptions is to make each exception. For each exception, we would be confusing and obfuscate our all of the exceptions apply to all actors, have proposed and finalized conditions intent in certain circumstances. as proposed. We have addressed the that we believe can be consistently Consistent with this approach, when commenters’ concerns by creating applied across a range of actors and describing the exceptions in the final conditions within certain exceptions practices and also further the goals of rule, we describe practices that, if all the that apply to one or a subset of actors, the information blocking provision. For applicable conditions are met, are as applicable. some exceptions, this includes a writing reasonable and necessary and not c. Establishing That Practices Meet the or documentation requirement to information blocking. demonstrate that the practice precisely Conditions of an Exception Comments. We received no comments meets all of the conditions to afford an specifically on the distinction between We proposed that, in the event of an actor the enhanced assurance an ‘‘activities’’ and ‘‘practices’’ and our investigation of an information blocking exception offers. Many of these proposed definition and use of the term complaint, an actor must demonstrate conditions are related to other existing ‘‘practice.’’ that an exception is applicable and that regulatory requirements that have Response. We have finalized the the actor met all relevant conditions of similar documentation standards. For definition of ‘‘practice’’ in § 171.102 as the exception at all relevant times and example, an actor’s practice may meet ‘‘an act or omission by an actor.’’ This for each practice for which the the Security Exception at § 171.203 if it definition is a modification of the exception is sought (84 FR 7522). We is consistent with an organizational proposed definition, which was ‘‘one or considered this allocation of proof to be security policy and that policy meets more related acts or omissions by an a substantive condition of the proposed several requirements. We expect that actor.’’ We finalized this definition of exceptions. As a practical matter, we many actors have existing ‘‘practice’’ in order to clarify that a proposed that actors are in the best organizational security policies based practice need only be a single act or position to demonstrate compliance on the ‘‘Policy and procedures and omission. This modification does not with the conditions of the exceptions documentation requirements’’ in the substantively change the proposed and to produce the detailed evidence HIPAA Security Rule at 45 CFR 164.316. definition, as we included in the necessary to demonstrate that Consequently, the burden associated proposed definition that a ‘‘practice’’ compliance. We requested comment with meeting the documentation could be one act or omission. about the types of documentation and/ requirement in the Security Exception We have finalized the use of the term or standardized methods that an actor should be less if actors are already ‘‘practice,’’ rather than the term may use to demonstrate compliance complying with the HIPAA Security ‘‘activity,’’ to describe conduct that is with the exception conditions. Rule. likely to interfere with, prevent or Comments. Many commenters We encourage actors to voluntarily materially discourage the access, requested clarification regarding the comply with an exception so that their exchange, or use of EHI. We have also type and amount of documentation practices do not meet the definition of finalized our approach that when required to demonstrate that they have information blocking and are not subject

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00179 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25820 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

to information blocking enforcement. strict conditions to prevent the access, exchange, and use of EHI.133 However, failure to meet an exception exceptions from being misused. We More than this, we emphasized that does not necessarily mean a practice discussed that without these exceptions, information blocking may harm meets the definition of information actors may be reluctant to engage in the competition not just in health IT blocking. If subject to an investigation, reasonable and necessary activities and markets, but also in markets for health each practice that implicates the that this could erode trust in the health care services.134 Dominant providers in information blocking provision and IT ecosystem and undermine efforts to these markets may leverage their control does not meet an exception would be provide access and facilitate the over technology to limit patient mobility analyzed on a case-by-case basis to exchange and use of EHI for important and choice.135 They may also pressure evaluate, for example, whether it rises to purposes. We stressed that such a result independent providers to adopt the level of an interference, and whether would be contrary to the purpose of the expensive, hospital-centric technologies the actor acted with the requisite intent. information blocking provision and the that do not suit their workflows, limit broader policies of the Cures Act. their ability to share information with D. Exceptions to the Information We explained that the next three unaffiliated providers, and make it Blocking Definition exceptions addressed activities that are difficult to adopt or use alternative We proposed to establish seven reasonable and necessary to promote technologies that could offer greater exceptions to the information blocking competition and consumer welfare. efficiency and other benefits.136 The provision. The exceptions would apply First, we proposed to permit the technological dependence resulting to certain practices that may technically recovery of certain types of reasonable from these practices can be a barrier to meet the definition of information costs incurred to provide technology entry by would-be competitors. It can blocking but that are reasonable and and services that enable access to EHI also make independent providers necessary to further the underlying and facilitate the exchange and use of vulnerable to acquisition or induce public policies of the information that information, provided certain them into exclusive arrangements that blocking provision. We appreciate that conditions are met. Second, we enhance the market power of incumbent most actors will want to meet an proposed to permit an actor to decline providers while preventing the exception to guarantee that their to provide access, exchange, or use of formation of clinically-integrated practice or practices do not meet the EHI in a manner that is infeasible, products and networks that offer more definition of information blocking and subject to a duty to provide a reasonable choice and better value to consumers be subject to enforcement. The statute alternative. And third, we proposed an and purchasers of health care services. defines information blocking broadly exception that would permit an actor to We noted in the Proposed Rule that and in a manner that allows for careful license interoperability elements on section 3022(a)(5) of the PHSA provides consideration of relevant facts and reasonable and non-discriminatory that the Secretary may consult with the circumstances in individual cases, terms. We emphasized that the Federal Trade Commission (FTC) in which includes analysis of an actor’s exceptions would be subject to strict defining practices that do not constitute intent and whether it meets the requisite conditions to ensure that they do not information blocking because they are knowledge standard. extend protection to practices that raise necessary to promote competition and The proposed exceptions were based information blocking concerns. consumer welfare. We expressed on three related policy considerations. The last exception recognized that it appreciation for the expertise and First, each exception was limited to may be reasonable and necessary for informal technical assistance of FTC certain activities that clearly advance actors to make health IT temporarily staff, which we took into consideration the aims of the information blocking unavailable for the benefit of the overall in developing the exceptions for provision. These reasonable and performance of health IT. This recovering costs reasonably incurred, necessary activities included providing exception would permit an actor to responding to requests that are appropriate protections to prevent harm make the operation of health IT infeasible, and licensing of to patients and others; promoting the unavailable to implement upgrades, interoperability elements on reasonable privacy and security of EHI; promoting repairs, and other changes. and non-discriminatory terms. We noted competition and innovation in health IT As context for the proposed that the language in the Cures Act and its use to provide health care exceptions, we noted that addressing regarding information blocking is services to consumers, and to develop information blocking is critical for substantively and substantially different more efficient means of health care promoting competition and innovation delivery; and allowing system in health IT and for the delivery of 133 See also Martin Gaynor, Farzad Mostashari, downtime to implement upgrades, health care services to consumers. We and Paul B. Ginsberg, Making Health Care Markets repairs, and other changes to health IT. noted that the information blocking Work: Competition Policy for Health Care, 16–17 (Apr. 2017), available at http://heinz.cmu.edu/ Second, each proposed exception provision itself expressly addresses news/news-detail/index.aspx?nid=3930. addressed a significant risk that practices that impede innovation and 134 See, e.g., Keynote Address of FTC regulated actors will not engage in these advancement in health information Chairwoman Edith Ramirez, Antitrust in Healthcare beneficial activities because of access, exchange, and use, including Conference Arlington, VA (May 12, 2016), available at https://www.ftc.gov/system/files/documents/ uncertainty concerning the breadth or care delivery enabled by health IT public_statements/950143/ applicability of the information blocking (section 3022(a)(2)(C)(ii) of the PHSA). 160519antitrusthealthcarekeynote.pdf. provision. Finally, each exception was We also noted that health IT developers 135 See, e.g., Martin Gaynor, Farzad Mostashari, subject to strict conditions to ensure of certified health IT, HIEs, HINs, and, and Paul B. Ginsberg, Making Health Care Markets that it was limited to activities that are in some instances, health care Work: Competition Policy for Health Care, 16–17 (Apr. 2017), available at http://heinz.cmu.edu/ reasonable and necessary. providers, may exploit their control over news/news-detail/index.aspx?nid=3930. We explained that the first three interoperability elements to create 136 See, e.g., Healthcare Research Firm Toughens exceptions extended to certain activities barriers to entry for competing Survey Standards as More CIOs Reap the Profits of that are reasonable and necessary to technologies and services that offer Reselling Vendor Software, Black Book, available at http://www.prweb.com/releases/2015/02/ prevent harm to patients and others; greater value for health IT customers prweb12530856.htm; Arthur Allen, Connecticut promote the privacy of EHI; and and users, provide new or improved Law Bans EHR-linked Information Blocking, promote the security of EHI, subject to capabilities, and enable more robust Politico.com (Oct. 29, 2015).

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00180 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25821

from the language and goals in the questions for additional clarity. We and necessary to prevent harm to a antitrust laws enforced by the FTC. We believe this new structure will help patient or another person. As discussed explained that we view the Cures Act as actors better understand our in the Proposed Rule’s preamble (84 FR addressing conduct that may be expectations of them and enhance 7523 and 7524), this exception is considered permissible under the transparency around the exceptions. intended to allow for the protection of antitrust laws. On this basis, the We note that we use the term ‘‘fulfill’’ patients and other particular persons Proposed Rule required that actors who throughout the exceptions in the context against substantial risks of harm control interoperability elements of an actor ‘‘fulfilling’’ a request to otherwise arising from the access, cooperate with individuals and entities access, exchange, or use EHI. This term exchange, or use of EHI in defined that require those elements for the is intended to reflect not just a response circumstances. Strict conditions were purpose of developing, disseminating, to a request to access, exchange, or use proposed to prevent this exception from and enabling technologies and services EHI, but also making the EHI available being misused. that can interoperate with the actor’s for the requested access, exchange, or As explained in the Proposed Rule, technology. use. we use the term ‘‘patient’’ to denote the We emphasized that ONC took this We have finalized the seven context in which the threat of harm approach because we view patients as exceptions with modifications arises (84 FR 7523). That is, this having an overwhelming interest in EHI discussed below. Based on requests for exception has been designed to about themselves. As such, access to comment we included in the Proposed recognize practices taken for the benefit EHI, and the EHI itself, should not be Rule regarding the scope of the EHI of recipients of health care — those traded or sold by those actors who are definition (84 FR 7513) and the individuals whose EHI is at issue — and custodians of EHI or who control its Infeasibility Exception (84 FR 7542 other persons whose information may access, exchange, or use. We through 7544), we have also established be recorded in that EHI or who may be emphasized that such actors should not a new exception in § 171.301 (referred at risk of harm because of the access, be able to charge fees for providing to as the Content and Manner use, or exchange of the EHI. This use of electronic access, exchange, or use of Exception) under section 3022(a)(3) of the term ‘‘patient’’ in the Proposed Rule patients’ EHI. We explained that the the PHSA as a means to identify did not imply that practices to which information blocking provision reasonable and necessary activities that the exception is applicable could be prohibits actors from interfering with do not constitute information blocking. implemented only by the licensed the access, exchange, or use of EHI We discuss the details of the new health professionals with a clinician- unless they are required to do so under Content and Manner Exception in patient relationship to the person whose an existing law or are covered by one of section VIII.D.2.a of this preamble. EHI is affected by the practices. the exceptions detailed in this We appreciate the FTC’s comments on This exception was proposed to apply preamble. In addition, we explained the Proposed Rule and the expertise and to practices when the actor engaging in that any remedy sought or action taken informal technical assistance provided a practice has a reasonable belief that by HHS under the information blocking by FTC staff for this final rule, which we the practice will directly and provision would be independent of the took into consideration throughout our substantially reduce a risk of harm to antitrust laws and would not prevent development of the final rule, including the patient, and/or other particular FTC or DOJ from taking action with as it relates to the definitions of various individuals, that would otherwise arise regard to the same actor or conduct. terms in the final rule (e.g., the from the particular access, exchange, or We proposed to include a provision in definitions of ‘‘electronic health use of EHI affected by the practices. We § 171.200 that addresses the availability information’’ and ‘‘health information proposed that actors including but not and effect of exceptions. network’’ (discussed above)) and the limited to health care providers would, We requested comment on the seven exceptions (e.g., the Infeasibility consistent with conditions of the proposed exceptions, including whether Exception, Fees Exception, and exception applicable to the they will achieve our stated policy Licensing Exception; as well as the circumstances in which the practices goals. establishing of the new Content and are used, be able to engage in practices Comments. We received comments Manner Exception). recognized under this exception without regarding each of the proposed Comments. We did not receive any the actor needing to have a clinician- exceptions. comments on the provision in § 171.200. patient relationship with any of the Response. We have responded to the Response. We have finalized individuals at risk of harm. comments regarding each exception in § 171.200 as proposed and have Comments. Of more than ninety the preamble discussions for each included an identical provision in comment submissions specifically exception. Overall, we have made § 171.300 that is applicable to Part C. referencing the Preventing Harm modifications to the structure and scope This addition was necessary based on Exception, half expressed overarching of the proposed exceptions. the new structure of the exceptions or general support for the exception. In this final rule, we have restructured discussed above. None of the comments specifically the proposed exceptions (proposed in 1. Exceptions that involve not referencing this exception expressed §§ 171.201–207) and have added fulfilling requests to access, exchange, opposition to the exception. Some another exception for clarity. In or use EHI commenters advocated broadening addition, we have divided the a. Preventing Harm Exception — certain aspects of the proposed exceptions into two categories: (1) When will an actor’s practice that is exception, as discussed in more detail Exceptions that involve not fulfilling likely to interfere with the access, below. Several other commenters requests to access, exchange, or use EHI, exchange, or use of electronic health expressed support for a relatively which are finalized in §§ 171.201–205; information in order to prevent harm narrow exception, and a few of these and (2) exceptions that involve not be considered information blocking? commenters recommended that once the procedures for fulfilling requests to We proposed to establish an final rule is effective ONC should access, exchange, or use EHI, which are exception to the information blocking engage in monitoring to ensure the finalized in §§ 171.301–303. We also provision in § 171.201 that would apply exception is not abused in practice. changed the titles of the exceptions to to certain practices that are reasonable Many commenters requested

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00181 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25822 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

clarification on specific points, or — such as other health care providers statements of finalized policy. We will expressed concerns or suggested treating the same patient, or an HIE/HIN also provide, in connection to this final modifications to particular aspects of supporting access, exchange, or use of rule, educational resources such as the exception, as will be discussed in the patient’s EHI — could rely on such infographics, fact sheets, webinars, and more detail below. a determination of a risk of harm. The other forms of educational materials and Response. We appreciate the many actor’s knowledge of a licensed health outreach. We emphasize, however, that thoughtful comments on the value of care professional’s individualized we believe the final rule clearly this exception, particular aspects of the determination (consistent with describes our information blocking proposed exception, and areas where we § 171.201(c)(1)) that access, exchange, or policies, and these educational could streamline how we express the use posed a risk of a harm of a type materials are intended only to educate policy so it is easier to understand. consistent with § 171.201(d)(1), (2), or stakeholders on our final policies Considering all of the comments (3) (as applicable) could factor into a established in the final rule. received, we have decided to finalize determination based on facts and Comments. Several commenters the exception largely as proposed, with circumstances known or reasonably questioned whether ‘‘directly and modifications to better align with believed by the actor (consistent with substantially’’ may be a more stringent HIPAA Rules as discussed below and to the condition finalized § 171.201(f)(2)). standard than is necessary for the make the regulation text more easily An actor could also implement reduction of risk of harm to a patient or understood. These revisions include practices based on knowledge of an to another person. A number of modification of the title of § 171.201, individualized determination of risk commenters indicated it could be from ‘‘Exception—Preventing Harm’’ (84 (§ 171.201(c)(1)) of harm of a type difficult for actors to know where to FR 7602) to ‘‘Preventing Harm consistent with § 171.201(d)(1), (2), or draw the line between direct and Exception — When will an actor’s (3) as applicable and based on an indirect reductions of risk of harm, practice that is likely to interfere with organizational policy (consistent with given the potential for reasonable minds the access, exchange, or use of the condition finalized § 171.201(f)(1)). to disagree on the extent to which a risk electronic health information in order to Thus, the exception is broad enough to arises directly, as opposed to indirectly, prevent harm not be considered cover all actors implementing practices from the EHI access, exchange, or use information blocking?’’ Throughout this that meet its conditions. We are affected by a practice. Several preamble, we use ‘‘Preventing Harm finalizing this aspect of the exception as commenters recommended, as an Exception’’ as a short title for ease of proposed, with clarifications to the alternative, that the condition be that reference to the exception that has been regulation text to make it easier to the actor have a reasonable belief the finalized in § 171.201. understand what the specific conditions practice is ‘‘reasonably likely’’ to reduce Comments. Several comments of the Preventing Harm Exception are a risk of harm. suggested broadening the scope of the and how they relate to one another. Response. After considering exception to allow a broader array of Comments. A large number of comments received, we have finalized actors to decide what might pose a risk commenters requested additional in § 171.201(a) that the actor must hold of harm to a patient. guidance in this final rule preamble or a reasonable belief that the practice Response. The finalized exception is, through other avenues. For example, ‘‘will substantially reduce’’ a risk of as we proposed it would be, available to some commenters requested sub- harm to a patient or another natural any actor defined in § 171.102, provided regulatory guidance and educational person. In comparison to the regulation that the actor’s use of a practice for resource materials to further illustrate text of this exception in the Proposed purposes of harm prevention meets the and help actors understand how the Rule (84 FR 7602), we have removed ‘‘directly’’ from the finalized text of conditions in § 171.201. Only where Preventing Harm Exception might apply § 171.201(a). We believe omitting practices are applied to a specific or what it might require without a ‘‘directly’’ from the finalized condition patient’s EHI and based upon a stakeholder needing to raise particular obviates concerns about actors’ ability to determination of a risk of harm by a questions or hypothetical fact patterns. determine whether the practice directly licensed health care professional in the Response. With the revisions we have reduces a risk of harm that could itself exercise of professional judgment does made to this exception, we do not arise indirectly. We have retained this exception explicitly require the believe sub-regulatory guidance is ‘‘substantially’’ in the finalized determination to have been made by a necessary for actors who wish to avail § 171.201(a) because we believe it is particular subset of actors within the themselves of this exception to necessary to ensure this exception understand the Preventing Harm definitions in § 171.102. In order to cannot be misused to justify practices Exception, its conditions, or to conform meet the risk of harm condition based that interfere with access, exchange, or their practices to the conditions. We on an individualized determination use of EHI to achieve only a trivial or have made revisions to the regulation consistent with § 171.201(c)(1), the illusory reduction in risk of harm. By text to provide enhanced clarity, such as licensed health care professional who extension, we interpret a ‘‘substantial made the determination must have done separately expressing each of its reduction’’ as necessarily implying that so in context of a current or prior substantive conditions and the risk intended to be reduced was clinician-patient relationship with the incorporating granular alignment to 45 itself substantial and not trivial or patient whose EHI is affected by the CFR 164.524(a)(3) harm standards. This illusory. 137 determination. However, other actors final rule preamble provides additional We note that the harm standard under information and feedback through § 164.524(a)(3) of the HIPAA Rules 137 For purposes of this exception, we interpret discussion of the particular questions includes that the access requested be ‘‘clinician-patient relationship’’ to include any and suggestions posed by various therapeutic or relationship where the licensed ‘‘reasonably likely’’ to cause the type of health care professional has or at some point had commenters and this preamble’s harm described in the sub-paragraph some clinical responsibility for or to the patient applicable to a particular denial of within the professional’s scope of practice. Thus, a in the course of the first or only occasion on which clinician-patient relationship on which a qualifying the clinician furnishes or furnished professional access under § 164.524(a)(3). As individualized determination of risk of harm could services to the patient in any setting, including but discussed in context of the finalized be one of substantial duration over time or formed not limited to telehealth. type of harm condition (§ 171.201(d)),

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00182 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25823

below, we have aligned the conditions under particular circumstances would To make the alignment between the of the Preventing Harm Exception also be cognizable under § 171.201. Preventing Harm Exception and the finalized in § 171.201 to use the same Response. We understand Privacy Rule clear, the final regulation harm standards as § 164.524(a)(3) in commenters’ concerns about text at § 171.201(d) cross-references the circumstances where both apply and in inconsistency across this exception and specific types of harm that would serve circumstances where only § 171.201 the Privacy Rule. In particular, concerns as grounds for denying an individual or applies. In order to maintain alignment that center on the fact that requiring in their personal representative access to and consistency, we clarify that in § 171.201 that the risk must be to the their PHI under the Privacy Rule circumstances where only § 171.201 ‘‘life or physical safety’’ of the patient or (§ 164.524(a)(3)) in particular types of applies, the risk of harm must also another person in all circumstances circumstances.138 By cross-referencing initially be at least ‘‘reasonably likely,’’ where § 171.201 applies would have set to § 164.524(a)(3), we align the regardless of whether the risk of harm a different harm standard than applies regulations to streamline compliance for is consistent with subparagraph (1) or under § 164.524(a)(3) in particular actors. We also believe this approach (2) of the type of risk condition finalized circumstances where both §§ 171.201 will allow that alignment to remain in in § 171.201(c). To satisfy the reasonable and 164.524(a)(3) apply. Specifically, place if changes were to be made to belief condition finalized in where § 164.524(a)(3)(ii) or (iii) apply, § 164.524(a)(3) harm standards in the § 171.201(a), the actor must reasonably the reviewable grounds for denial of future.139 In particular types of believe their practices (that are likely to, right of access include where a licensed circumstances where both or in fact do, interfere with otherwise health care professional has determined, § 164.524(a)(3) and § 171.201 apply, the permissible access, exchange, or use of in the exercise of professional judgment, subparagraphs of finalized § 171.201(d) EHI) will substantially reduce that that the access requested is likely to (the type of harm condition) cross- likelihood of harm. Actors who are cause ‘‘substantial harm.’’ In contrast, a reference to the § 164.524(a)(3)(i), (ii), HIPAA covered entities or business uniform application of the ‘‘life or and (iii) harm standard that applies associates have extensive experience in physical safety’’ type of harm under under § 171.201 in each of these types complying with § 164.524(a)(3). § 171.201 would have applied the ‘‘life of circumstances. Moreover, where only Therefore, we believe the belief or physical safety’’ type of harm § 171.201 applies to a practice where the standard finalized in § 171.201(a), standard to practices that interfere with type of risk is consistent with combined with reliance on the harm access, exchange, or use of EHI for § 171.201(c)(1), the finalized standards used in § 164.524(a)(3), will purposes of § 171.201 even where subparagraphs of § 171.201(d) cross- address commenters’ concerns about § 164.524(a)(3)(ii) or (iii) would also reference and apply the harm standard their ability to understand and apply the apply and where § 164.524(a)(3)(ii) or that § 164.524(a)(3)(i), (ii), or (iii) would reasonable belief and type of harm (iii) would apply the ‘‘substantial harm’’ apply to denial of the individual’s conditions finalized under § 171.201. standard. (§ 164.524) right of access to their own In response to comments, we have PHI, the individual or their Comments. A number of commenters reviewed the potential for conflict representative’s access to the PII of advocated closer alignment with the between § 171.201 requiring ‘‘life or another person within that PHI, or the HIPAA Privacy Rule. Some commenters physical safety’’ as the type of harm in individual’s personal representative’s expressed concerns about our ability to circumstances where § 164.524(a)(3(ii) access to the individual’s PHI. maintain such alignment without or (iii) also apply. We have determined One example of a particular interruption if this rule were to be that for particular types of circumstance in which both finalized prior to any applicable circumstances where both §§ 171.201 § 164.524(a)(3) and § 171.201 would potential updates to the HIPAA Privacy and 164.524(a)(3) apply, the best apply is where a health care provider (as Rule pursuant to a proposed rule that approach is to apply under § 171.201 defined in § 171.102) that is also a HHS had publicly expressed an aim to the exact same harm standard that each HIPAA covered entity (as defined in publish in 2019. Some commenters specific sub-paragraph of § 164.524(a)(3) § 160.103) denies the patient’s personal specifically questioned whether ‘‘life or applies in each of these types of representative access to the patient’s physical safety’’ would remain the circumstances. We believe that EHI based on a licensed health care standard for the type of harm cognizable extending the application under professional’s determination in the under the Privacy Rule for denying an § 171.201 of the specific harm standards exercise of professional judgment individual’s right to access their own in § 164.524(a)(3)(i) through (iii) to (§ 171.201(c)(1)) that granting that information. One commenter stated they situations that are similar in significant personal representative access to the had heard the Privacy Rule harm respects to situations where each of patient’s EHI would pose a risk of standard might be broadened to these sub-paragraphs of § 165.524(a)(3) substantial harm to the patient.140 In recognize additional types of harm, such would apply, but where § 164.524(a)(3) as emotional or psychological harm, in does not apply, provides consistency 138 Meeting the harm standard is necessary but circumstances where the Privacy Rule that simplifies compliance for actors not alone sufficient for a practice to be recognized would currently recognize only danger subject to both 45 CFR part 171 and 45 as reasonable and necessary under this exception; all other conditions of the exception must also be to life or physical safety. A number of CFR part 164. Situations where met. comments stated that the requirement § 171.201 could apply but where 139 Alignment between part 171 subpart B and for the risk to be to life or physical § 164.524(a)(3) would not apply include, § 164.524(a)(1) and (2) is discussed in Section safety for all circumstances where this but are not limited to, those where the VIII.D.2. We also acknowledge that it is possible exception would apply would conflict actor’s practice is likely to interfere with some types of revision to 45 CFR part 164 could necessitate modifications to 45 CFR part 171 in the with current Privacy Rule provisions an individual or their legal future. applicable to individual or proxy access representative’s access, exchange, or use 140 For purposes of how the § 171.201 to PHI. A number of commenters of the individual’s EHI but not to the requirements and cross-references to § 164.524 recommended we revise the conditions extent of failing to provide access (as the operate within this example, it makes no difference whether the health care provider acting on the for practices to be recognized under the term is used in context of § 164.524) individualized determination is the licensed health Preventing Harm Exception so that harm within the timeframe allowed under care professional who made the determination cognizable under the Privacy Rule § 164.524. Continued

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00183 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25824 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

this circumstance, the finalized EHI are implemented to substantially provisions. We believe this alignment § 171.201(d)(1), which cross-references reduce a risk of harm arising from data achieves the level of granular cross- the harm standard applicable under that is known or reasonably suspected reference necessary and that is § 165.524(a)(3)(iii), applies. In this to be misidentified or mismatched, preferable to selecting only one of these example situation, the qualifying corrupt due to technical failure, or standards to apply in all types of determination of risk of harm erroneous for another reason circumstances under § 171.201. We (§ 171.201(c)(1)) is that any access (or (§ 171.201(c)(2)). Provided its conditions further note that the revised regulation exchange, or use) of the EHI by the are met in full, the Preventing Harm text is consistent with our decision to personal representative is reasonably Exception (§ 171.201) would apply to completely align the EHI definition with likely to cause harm consistent with the such practices as delaying access, the definition of ePHI within the standard established in exchange, or use, for the time necessary designated record set.144 § 164.524(a)(3)(iii), and thus the health to correct the errors that would Comments. A number of commenters care professional, or another HIPAA otherwise pose a risk of harm to the advocated for expanding the definition covered entity or business associate patient (or another person) that would of harm that is contemplated under this with knowledge of the determination, be cognizable under § 164.524(a)(3)(i) if exception to encompass psychological could also deny a request by the § 164.524(a)(3)(i) applied.143 Such and/or emotional harm in addition to representative to access the individual’s delays are not explicitly addressed risks to life or physical safety, including ePHI under § 164.524(a)(iii). under § 164.524(a)(3), which provides a but not limited to expanding the Under § 164.524(a)(iii), the harm must maximum timeframe for disclosure of concept of individualized be a ‘‘substantial harm’’ to qualify for PHI to which patients have the right of determinations of risk of harm by health the denial of the patient’s personal access, and § 164.524(a)(3) does not care professionals. A few commenters representative’s request to access the expressly contemplate risks of harm specifically advocated recognizing the patient’s PHI. Similarly, both § 171.201 arising from data issues as would be potential for financial, reputational, or and § 164.524(a)(3) apply where an consistent with § 171.201(c)(2). By social/cultural harms. A number of information blocking actor that is also a contrast, § 171.201 defines when a other commenters expressed a concern HIPAA covered entity, acting in reliance practice that is likely to, or does, that broadening the exception to address on a determination of risk of harm made interfere with the access, exchange, or additional types of potential harm could by a licensed health care professional in use of EHI is excepted from the risk its being overused to withhold the exercise of professional judgment, definition of information blocking in information from patients where does not provide the patient or the § 171.103 that applies to the actor available evidence does not indicate patient’s personal representative any engaged in the practice, and expressly there is a risk. One commenter reported access to information within the applies where the actor can demonstrate having observed that some clinicians patient’s EHI that references another a reasonable belief the practice will express a belief that mere disclosure of person. In this type of circumstance, substantially reduce a risk of harm health data directly to patients without § 171.201(d)(2) by cross-reference to arising from data issues consistent with the clinician’s professional § 164.524(a)(3)(ii) applies the same § 171.201(c)(2). interpretation will routinely cause ‘‘substantial harm’’ standard under Because risks of harm arising from harm, despite what the commenter § 171.201 that applies to the actor’s data that is known or reasonably described as existing evidence to the denying the patient or their suspected to be misidentified or contrary. representative access to that information mismatched, corrupt due to technical Response. We believe it would be under § 164.524(a)(3)(ii).141 failure, or erroneous for another reason challenging to define an appropriate and In § 171.201(d)(1), (2), and (3), as (§ 171.201(c)(2)) would apply equally to unique standard for purposes of this finalized, we also apply the harm an individual’s or their representative’s exception for non-physical harms that standards described in § 164.524(a)(3)(i), or their health care provider’s access, all actors defined in § 171.102 could (ii), or (iii) to particular types of exchange, or use of the patient’s EHI, apply consistently and, most circumstances where § 164.524 does not § 171.201(d)(4) applies the standard in importantly, without unduly restricting apply, but that are similar with respect § 164.524(a)(3)(i) to all of these patients’ rights to access their health to whether it is the patient or their circumstances. Thus, as information. We also recognize, as representative requesting access, and § 164.524(a)(3)(i) stands at the time of discussed above, the practical utility of whether the access requested is to publication of this final rule, the access, alignment with relevant Privacy Rule information within the patient’s EHI exchange, or use of the EHI affected by provisions. At this time, only danger to that is another person’s identifiable the practice must be reasonably likely to the individual’s ‘‘life or physical safety’’ information. For example, endanger the life or physical safety of is recognized as grounds for denial of an § 171.201(d)(3) applies the harm the patient or another person were the individual’s right of access under standard described in § 164.524(a)(3)(i) practice not implemented. (Please see § 164.524(a)(3)(i). However, ‘‘substantial where practices that are likely to Table 3 for a crosswalk of the particular harm’’ is the standard applied under the interfere with a patient’s access, Privacy Rule where the access denied is 142 types of circumstances addressed by the exchange, or use of the patient’s own subparagraphs under § 171.201(d) to the to information identifying another § 164.524 harm standard applicable to person (other than a health care consistent with § 171.201(c)(1), another licensed health care professional, or another type of health each type of circumstance.) provider) or where an individual’s care provider (such as a hospital or skilled nursing The finalized regulatory text in personal representative is denied access facility). § 171.201 is revised from the Proposed to the individual’s PHI under 141 Note that the ‘‘individual’’ and ‘‘access’’ have Rule to reflect this more granular and § 164.524(a)(3)(ii) or (iii). To align with different meanings under 45 CFR 164.524 from comprehensive alignment of harm the relevant Privacy Rule provisions, the those in 45 CFR part 171. Regarding an individual’s right of access under 45 CFR 164.524, the term standards across the two regulatory final regulation text (§ 171.201(d)(1) and ‘‘access’’ should be understood in that HIPAA Privacy Rule context. 143 Note, again, that ‘‘access’’ has a different 144 See section VIII.C.3 of this preamble and the 142 As the terms ‘‘access,’’ ‘‘exchange,’’ and ‘‘use’’ meaning in subpart E of 45 CFR part 164 than it finalized definition of ‘‘electronic health are defined in § 171.102. does in 45 CFR part 171. information’’ in § 171.102.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00184 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25825

(2)) references the same harm standards operation of this exception where State or request or authorize access, exchange, as the Privacy Rule uses where law provides for minors to be able to or use of a minor’s EHI on behalf of the § 164.524(a)(3)(ii) or (iii) as well as consent to some or all types of health minor, should be analyzed in the § 171.201 applies, and in circumstances care but does not provide for or allow context of the Privacy Exception as where § 164.524(a)(3) is not implicated the minors to access their health records finalized in § 171.202 and/or the but the actor’s practice is both based on information at all, or in specific Security Exception as finalized in an individualized determination of format(s). § 171.203. Where otherwise applicable harm (consistent with § 171.201(c)(1)) Response. We appreciate commenters’ law prohibits a specific access, and likely to interfere with: offering us the opportunity to reiterate exchange, or use of information, an (§ 171.201(d)(2)) a patient’s or their legal that where a particular access, exception to part 171 is not necessary representative’s access, exchange, or use exchange, or use of EHI is prohibited by due to the exclusion of ‘‘required by of information within their EHI that applicable Federal, State, or tribal law, law’’ practices from the statutory identifies another person (other than a an exception to the definition of information blocking definition in health care provider); or information blocking is not needed. section 3022 of the PHSA (as discussed (§ 171.201(d)(1)) the patient’s legal Nothing in part 171 calls for access, in section VIII.C.1 of this preamble). representative’s access, exchange, or use exchange, use, or other disclosure of However, where an actor simply lacks of the patient’s EHI. The finalized EHI that is prohibited by other the technical capability to provide § 171.201(d)(3) and (4) also re-use the applicable law. If an actor simply access, exchange, or use in a specific familiar § 164.524(a)(3)(i) type of harm cannot effectively segment EHI they requested mechanism, format, or for the wide variety of circumstances could safely and permissibly share from manner, we would encourage the actor where § 171.201 applies but the type of EHI they are not permitted to share in to review its practices for consistency risk is consistent with § 171.201(c)(2) or a given requested format, the actor with the new Content and Manner the (otherwise legally permissible) should refer to the exception for Exception finalized in § 171.301 or the access, exchange, or use of EHI with requests that are infeasible (§ 171.204). Infeasibility Exception finalized in which the practice is likely to interfere However, if the EHI they could legally § 171.204. is by someone other than the patient or disclose could be shared in a different Comments. Several commenters their legal representative. Thus, the manner than that initially requested but requested clarification as to whether the finalized § 171.201 does not establish a the different manner would support Preventing Harm Exception would standard for non-physical harm that segmentation, then an actor should apply to 42 CFR part 2 data when it is would be unique to the Preventing provide the EHI they can safely and not made available for access, exchange, Harm Exception but instead recognizes legally share in the most appropriate or use because the patient did not ‘‘substantial harm’’ in circumstances manner consistent with the Content and consent to its access, exchange, or use. where § 164.524(a)(3)(ii) or (iii) apply, Manner Exception (§ 171.301). Response. We appreciate the and also applies this familiar type of Comments. Several commenters opportunity to remedy any confusion harm in situations where neither specifically requested clarification as to that may have been caused by the § 164.524(a)(3)(ii) nor (iii) applies but the information blocking implications Proposed Rule’s use of an illustrative where re-use of this same standard where State law and/or the example (84 FR 7524) within which the under § 171.201 is consistent with the organization’s account provisioning requirement to withhold data subject to goal of aligning the types of harm process do not provide for minors to 42 CFR part 2 regulations rendered a recognized under Preventing Harm obtain the login credentials needed to particular access, exchange, or use of Exception with the grounds for denying access their own records through an only a portion of the patient’s EHI a right of access request under the electronic portal, which will often be legally permissible. In the example, only Privacy Rule. the login credentials a patient would those portions of the patient’s EHI to Comments. One commenter use to authorize an app to receive the which 42 CFR part 2 does not apply specifically recommended allowing records through the provider’s API. could be permissibly accessed, actors to rely on an individual’s own Response. Where the actor does not exchanged, or used. This example was subjective beliefs related to harm. have a reasonable belief that a practice intended only to illustrate that the mere Response. We interpret this comment interfering with minors’ access to their fact that an actor has knowledge, as pertaining to the beliefs of the patient own EHI will substantially reduce a risk possession, custody, or control of more whose EHI would be affected by a of harm cognizable under this EHI than the actor could legally share practice. We appreciate this opportunity exception, the Preventing Harm would not, itself, provide a basis for to explain that practices implemented to Exception (§ 171.201) would not apply. application of the Preventing Harm honor and apply the patient’s expressed This exception would also not apply Exception to the actor’s withholding of preferences regarding access, exchange, where any person—whether adult, any of the EHI that the actor could or use of their EHI are addressed by the emancipated minor, or non- legally share. When an actor that is Privacy Exception finalized in emancipated minor—is not able to subject to 42 CFR part 2 cannot honor § 171.202. provide adequate verification of their a request for access, exchange, or use of Comments. A number of commenters identity consistent with the actor’s data subject to 42 CFR part 2 requested clarification of how the health information privacy or security specifically because the patient has not Preventing Harm Exception and its protection policies. Actors should assess provided the consent that would be conditions might operate in situations practices related to verifying the required by 42 CFR part 2 before the involving minors where applicable State identity of a patient, or a legal actor could disclose that specific data laws allow non-emancipated minors to representative of the patient, for for access, exchange, or use, the independently consent to certain types consistency with the conditions of the Preventing Harm Exception (§ 171.201) of health care and provide for keeping Privacy Exception as finalized in would not apply. When an actor has 42 records of such care confidential from § 171.202 and/or the Security Exception CFR part 2 data for a patient but does the minor’s parents/guardians. Several as finalized in § 171.203. Likewise, not believe it has documented the of these commenters specifically practices implemented to confirm a patient consent that is legally required requested clarification about the representative’s legal authority to access before the actor can fulfill a request for

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00185 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25826 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

access, exchange, or use of that data, the laboratory information only from EHI was corrupted or mismatched due actor should refer instead to the Privacy providers that are (or that employ) to a technical failure of an actor’s Exception finalized in § 171.202. If the professionals whose scope of practice systems. The risk of potential harm actor lacks the technical capability to allows them to order the tests. If a described by the comment was effectively segment data that it can laboratory, or a HIN/HIE, has the data in specifically of misinterpretations of EHI legally share from data that it cannot an interoperable format to support its leading to research findings that legally share, the actor should also exchange across providers, but does not negatively impact scientific discovery. consider the new Content and Manner have the technical capability to This risk is too far removed from a Exception finalized in § 171.301 or the appropriately display it for human reasonable, and reasonably foreseeable, Infeasibility Exception finalized in readability (such as in a patient portal), likelihood of cognizable harm to § 171.204. then the laboratory, or HIN/HIE, should particular patients or other particular Comments. Several commenters noted make the data available in the natural persons to fit within the intent that some State laws prohibit the release interoperable format to providers or of the Preventing Harm Exception of specific information, such as results patients who can then view the data finalized in § 171.201. Therefore, we did of particular diagnostic tests, to patients using technology the provider or patient not modify the exception in response to through electronic means (e.g., patient has chosen as appropriate to their this comment. portals or APIs) until particular needs. If any actor receives a request for Finalized Belief and Harm Conditions protocols have been completed. data access, exchange, or use via a for § 171.201 Commenters cited, as an example, State specific mechanism that the actor does law mandates for initial communication not have the technical capability to Having considered comments of particular information to the patient support, the actor should consider the received on the belief and harm by a health professional in real time. Content and Manner Exception finalized standards, we have finalized the The commenters requested clarification in § 171.301 or the Infeasibility exception at § 171.201 with of whether or how § 171.201 would Exception finalized in § 171.204. modification, as discussed in responses apply in those circumstances. Comments. One commenter suggested to comments. These modifications Response. As is the case with 42 CFR recognizing a new exception under the simplify the belief standard, and more part 2 data that the patient has not Preventing Harm Exception that would thoroughly and specifically align the consented to disclose, the exception allow a health care provider who is also harm standard applicable for this finalized in § 171.201 would not apply a research institution to require, as a exception with either the Privacy Rule in these particular types of condition of making EHI available for harm standard applicable under circumstances. The information use in research, that the health care § 164.524(a)(3)(i) (in most blocking definition proposed and provider be a collaborator in that circumstances) or the harm standard in finalized in § 171.103 does not include research. The commenter stated that § 164.524(a)(3)(ii) or (iii) (in particular a practice that is likely to, or in fact institutions ensure accuracy in the way circumstances). The harm standard in does, interfere with the access, data is used and analyzed by requiring § 164.524(a)(3)(ii) or (iii) applies where exchange, or use of EHI when the they participate in any research both §§ 171.201 and 164.524(a)(3)(ii) or practice is required by law. If the actor involving their patients’ information so (iii) would apply, or in particular lacks the technical capability to segment that they can explain for the research circumstances that are sufficiently data at the level of granularity needed team any anomalies or other similar as to be analogous to to withhold only those data points, characteristics unique to their own circumstances where both §§ 171.201 elements, or classes that it is legally institutions’ data and collection and 164.524(a)(3)(ii) or (iii) would prohibited from disclosing in response methods. This commenter stated that apply.146 Please reference the finalized to a particular request, the actor should disclosing EHI for research purposes § 171.201(a) for the regulatory text of the consider the Content and Manner when the research being conducted does belief standard. Please reference the Exception finalized in § 171.301 or the not involve the health care provider finalized §§ 171.201(d)(1)–(3) for Infeasibility Exception finalized in disclosing the EHI could lead to regulatory text that establishes the § 171.204. misinterpreted outcomes based on specific § 164.524(a)(3) harm standard Comments. Several commenters flawed data that could have a negative that applies in each of the three recommended that we recognize under impact on scientific discovery. particular types of circumstances § 171.201 practices requiring patients to Response. We considered this specific to patients and their obtain their laboratory results suggested expansion of the Preventing representatives’ access to the patient’s information only through the ordering Harm Exception specifically in the EHI, and reference § 171.201(d)(4) for provider’s EHR. Commenters stated that context of the definition of ‘‘electronic regulatory text establishing the specific inaccurate display of such results is a health information’’ that we proposed, § 164.524(a)(3) harm standard safety risk and that other actors such as and the more focused definition of applicable in all other types of laboratories and HINs/HIEs may not ‘‘electronic health information’’ that we circumstances where § 171.201 applies. have the technical capability to display have finalized.145 The Preventing Harm The circumstances where both the information accurately in a human- Exception is intended to apply to §§ 171.201 and 164.524(a)(3) would readable interface that would be in full practices an actor reasonably believes apply are where the practices do compliance with regulatory will substantially reduce a risk of harm requirements otherwise applicable to (of a type cognizable under this 146 Please note that the Preventing Harm human-readable displays of laboratory exception) to particular person(s), such Exception will not normally apply where a patient or their representative may seek access to EHI that results information. as a patient or a natural person in the is excluded from the right of access under Response. We agree that display of patient’s life or multiple patients whose § 164.524(a)(1) or to which access may be denied on inaccurate values for laboratory results, unreviewable grounds under § 164.524(a)(2). In or other clinical observations, could 145 We note that, although various types of circumstances where § 171.201 conditions are not represent a safety risk. We do not research data and data sets may be or include met but an actor wishes to withhold EHI from an ‘‘electronic health information’’ as defined in individual’s right of access under § 164.524(a)(1) or believe it would be appropriate to § 171.102, not all research data or data sets are or (2), the actor should refer to the privacy exception broadly limit patients to obtaining their include data meeting this definition. (§ 171.202).

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00186 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25827

interfere with access, exchange, or use This provides, under § 171.201, individualized basis (§ 171.201(c)(1)) or by the patient or their legal consistency across this wide array of arises from data that is known or representative (who is their personal circumstances where § 164.524(a)(3) reasonably suspected to be corrupt due representative for purposes of § 164.524) would not be implicated regardless of to technical failure, erroneous for of some or all of the patient’s EHI to the the extent of interference or length of another reason, or misidentified or point of denying access (as used in delay the practice may pose to the mismatched (§ 171.201(c)(2)). context of § 164.524) on grounds of a access, exchange, or use of the EHI. Under § 164.524(a)(3)(ii) and (iii), the risk of harm determined on an Because the circumstances to which the standard of ‘‘substantial harm’’ applies individualized basis by a licensed finalized § 171.201(d)(4) applies include where the individual or their health care professional in the exercise access, exchange, or use of the patient’s representative are denied access to of professional judgment EHI by health care providers furnishing information in the individual’s record (§ 171.201(c)(1) as finalized). services to the patient, we believe it is that identifies another person (other Circumstances where § 164.524(a)(3) is most appropriate to apply under not implicated but that are analogous to § 171.201(d)(4) the same standard of than a health care provider), or an circumstances where both harm that would apply to denying a individual’s personal representative is §§ 164.524(a)(3) and 171.201 apply are patient access to the patient’s EHI. This denied access to the individual’s those where the risk of harm is is consistent with our proposal (84 FR information. Thus, the type of harm determined on an individualized basis 7602) to require that practices likely to standard applicable under § 171.201 consistent with finalized § 171.201(c)(1) interfere with any access, use, or will in most cases require that the and the practice does not entirely deny exchange of EHI would need to reduce actor’s practice be based on a reasonable but is likely to, or does, interfere with a risk to the ‘‘life or physical safety’’ of belief that the requested access, the patient’s or their legal a patient or another person to satisfy the exchange, or use with which the representative’s access, exchange, or use conditions in § 171.201 and be excepted practice is likely to or does interfere of the EHI that is otherwise legally from the definition of information would otherwise endanger the ‘‘life or permissible. (For example, the practice blocking in § 171.103. We have also physical safety’’ of the patient or may result in delaying access, exchange, clarified the regulation text so it is another person. However, the or use of the EHI but for less time than expressly clear on its face that the risk ‘‘substantial harm’’ standard included in is permitted for granting of a right of to be reduced must be one that would § 164.524(a)(3)(ii) and (iii) would apply access request under § 164.524.) otherwise arise from the specific access, in specific circumstances as shown in In a wide variety of circumstances use, or exchange of EHI affected by the Table 3. As discussed above, we have where § 171.201 will apply, § 164.524 practice. made this change to the finalized would not apply. Such circumstances Under § 164.524(a)(3)(i), a covered § 171.201 to align the harm standard include those where the access, entity may deny an individual access to applied by § 171.201 with the one exchange, or use of EHI with which the protected health information (PHI) applied by § 164.524(a)(3) where both practice is likely to, or does, interfere is about that individual in a designated would apply, and in analogous not related to right of access under the record set only if a licensed health care circumstances (as described above). As HIPAA Privacy Rule, such as access, professional in the exercise of explained above, we revised the harm exchange, or use of the patient’s EHI by professional judgment determines that standard applicable in particular the patient’s health care providers. releasing the information to them would circumstances to avoid setting a higher Likewise, § 171.201 will apply but endanger the life or physical safety of threshold under § 171.201 for practices § 164.524(a)(3) will not apply when the the individual or another person. Under likely to interfere with access, exchange, risk of harm arises from data issues § 171.201(d)(3), an actor 148 may or use 149 of EHI than would be (§ 171.201(c)(2)) rather than having been implement a practice that is likely to, or applicable to entirely denying access determined on an individualized basis does, interfere with the patient’s access, under § 164.524(a)(ii) or (iii) 150 in the by a licensed health care professional exchange, or use of their own EHI when same circumstances. In the finalized (§ 171.201(c)(1)). In these circumstances the actor reasonably believes the § 171.201(d), we have applied the type where § 164.524 would not apply, and practice will substantially reduce a risk of harm described in § 164.524(a)(ii) and that are not analogous to circumstances of harm to life or physical safety of the (iii) to particular circumstances where where § 164.524(a)(3) would apply, patient or another person, regardless of § 164.524(a)(ii) and (iii) do not apply, § 171.201(d)(4) (type of harm condition) whether that risk is determined on an but that are analogous to such applies the harm standard that would be circumstances, for the reasons stated in cognizable under § 164.524(a)(3)(i) so § 171.201 is, consistent with the requirement that in responses to comments above. that the actor must reasonably believe most circumstances the risk of harm at issue must be to life or physical safety. the practice will reduce a risk otherwise 149 148 An actor could be any individual or entity As ‘‘access,’’ ‘‘exchange,’’ and ‘‘use’’ are posed to the life or physical safety of the meeting the definition of ‘‘health care provider,’’ defined in § 171.102. 147 patient or another natural person. ‘‘health IT developer of certified health IT’’ or 150 Please note that ‘‘access’’ has a different ‘‘health information network or health information meaning under 45 CFR 164.524 than in 45 CFR part 147 Please note that although ‘‘individual’’ as exchange’’ in § 171.102, and may or may not also 171. Regarding an individual’s right of access under defined in 45 CFR 169.103 is not limited to natural be a HIPAA covered entity or business associate as 45 CFR 164.524, the term ‘‘access’’ should be persons, the belief standard in the finalized defined in the HIPAA Rules. understood in that HIPAA Privacy Rule context.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00187 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25828 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

TABLE 3—MAPPING OF CIRCUMSTANCES UNDER § 171.201(D) TO APPLICABLE HARM STANDARDS

Requirements under § 171.201(d) type of harm condition Applicable harm standards 151

§ 171.201(d)(1)—where the practice interferes with access, exchange, The harm of which the actor reasonably believes the practice will sub- or use of the patient’s EHI by their legal representative and the prac- stantially reduce a risk must be the type of harm described in 45 tice is implemented pursuant to an individualized determination of CFR 164.524(a)(3)(iii), which is substantial harm to the individual or risk of harm made by a licensed health care professional in the exer- another person.152 cise of professional judgment (§ 171.201(c)(1)). § 171.201(d)(2)—where the practice interferes with the patient’s or their The harm of which the actor reasonably believes the practice will sub- legal representative’s access to, use or exchange of information that stantially reduce a risk must be the type of harm described in 45 references another natural person and the practice is implemented CFR 164.524(a)(3)(ii), which is substantial harm to such other per- pursuant to an individualized determination of risk of harm made by a son. licensed health care professional in the exercise of professional judg- ment (§ 171.201(c)(1)). § 171.201(d)(3)—where the practice interferes with the patient’s access, The harm of which the actor reasonably believes the practice will sub- exchange, or use of their own EHI, regardless of whether the risk the stantially reduce a risk must be the type of harm described in 45 practice is implemented to substantially reduce is determined on an CFR 164.524(a)(3)(i), which is a harm to the life or physical safety of individualized basis by a licensed health care professional in the ex- the individual or another person. ercise of professional judgment (§ 171.201(c)(1)) or arises from data that is known or reasonably suspected to be corrupt due to technical failure, erroneous for another reason, or misidentified or mismatched (§ 171.201(c)(2)). § 171.201(d)(4)—where the practice interferes with the patient’s legal The harm of which the actor reasonably believes the practice will sub- representative’s otherwise legally permissible access, exchange, or stantially reduce a risk must be the type of harm described in 45 use of the patient’s EHI and the practice is implemented to reduce a CFR 164.524(a)(3)(i), which is a harm to life or physical safety of the risk arising from data that is known or reasonably suspected to be individual or another person. misidentified or mismatched, corrupt due to technical failure, or erro- neous for another reason (§ 171.201(c)(2)).

Types of Risk of Harm to Patients rule (84 FR 7524 and 7425). We also calling broadly for additional Cognizable Under This Exception requested comment (84 FR 7525) on: clarification or information, we have • Whether these categories of harm provided detailed responses to We proposed (84 FR 7524) that to capture the full range of safety risks that comments received. Where useful to qualify for this exception, an actor’s might arise directly from accessing, enrich the discussion, some responses practice must respond to one or more exchanging, or using EHI; and discuss hypothetical example situations type(s) of risk of harm cognizable under • Whether we should consider other that illustrate how a particular aspect of this exception. The three types of risk of types of patient safety risks related to the exception would operate in such a harm that we proposed would satisfy data quality and integrity concerns or situation. the conditions of this exception are: that may have a less proximate Comments. Some comments • Risks arising from corrupt or connection to EHI but that could suggested that the determinations and inaccurate data being recorded or provide a reasonable and necessary the rationale for individualized incorporated in a patient’s EHI; basis for an actor to restrict or otherwise determinations by health care • risks arising from misidentification impede access, exchange, or use of EHI professionals in the exercise of of a patient or patient’s EHI; and in appropriate circumstances. professional judgment should be • risks identified by a determination We will first discuss those comments documented in the electronic health made by a licensed health care that pertain to the cognizable types of record. professional that a specific access or risk of harm in general. Comments Response. We believe documentation disclosure of EHI is reasonably likely to specific to each of the three types of risk in the EHR, such as in appropriate notes endanger the life or physical safety of of harm will be discussed separately, in field(s), may be a practical, efficient the patient or another person. the order they were presented in the approach to documentation of We provided additional explanation Proposed Rule. determinations of risk of harm and discussion of these types of risk of Comments. Overall, comments were consistent with § 171.201 for some — harm in the preamble of the proposed supportive of the exception recognizing perhaps many — licensed health care risks of harm arising from corrupt or professionals. Therefore, we confirm 151 Note that the ‘‘individual’’ and ‘‘access’’ have misidentified information, and that EHRs are considered an appropriate different meanings under 45 CFR 164.524 from individualized determinations of risk of approach or method for the those in 45 CFR part 171. Regarding an individual’s harm made by licensed health care documenting, and for retaining right of access under 45 CFR 164.524, the term professionals in the exercise of documentation, of determinations of ‘‘access’’ should be understood in that HIPAA Privacy Rule context. professional judgment. Numerous risk consistent with § 171.201(c)(1). We 152 Note that grounds for denial of an individual’s commenters requested clarification or also note that much (perhaps all) of the right of access include that the access is reasonably additional information to help actors information about the patient’s likely to cause the harm identified in the particular more effectively understand and individual circumstances that factors subparagraph under § 164.524(a)(3). For purposes of 45 CFR part 171, we interpret that the stated type efficiently document their risk into the professional’s determination of of harm must, to the best of the actor’s knowledge determinations in connection to risk will most naturally and most often and belief, be substantial, in absence of particular practices for which they would seek to be documented in the EHR in the practice(s), in order for an actor to reasonably claim that the Preventing Harm ordinary course of furnishing care to the believe the practice(s) will substantially reduce that risk. We would interpret a reasonable likelihood of Exception applies. patient. Nothing in § 171.201 would the described harm, as used under § 164.524(a)(3) Response. We appreciate the feedback require duplicating information already to be a substantial risk for purposes of § 171.201. received. In response to comments captured in the EHR in a different form

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00188 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25829

or format specific or unique to that does not include identified Comments. Commenters were § 171.201, whether in the EHR or information about another person, the supportive of the Preventing Harm elsewhere. However, we also believe Preventing Harm Exception will apply Exception applying to appropriate that there is substantial potential for only to those practices reasonable and practices to address corrupt or incorrect variability in health care professionals’ necessary to address risk to the life or data in EHI and the risks that would current methods for documenting risk physical safety of another person otherwise arise from propagation of factors and determinations. consistent with § 171.201(d)(3) and its corrupt or otherwise incorrect EHI In addition, we do not believe it is specific cross-reference to within a patient’s record. necessary to require different or § 164.524(a)(3)(i). The Privacy Exception Response. We appreciate all of the duplicate documentation of information (§ 171.202) is intended to recognize feedback received, including but not that is already otherwise captured in reasonable and necessary practices to limited to confirmation that responding reliable business records consistent with protect patients’ privacy. We also note stakeholders are supportive of this the HIPAA Privacy Rule and applicable that we have clarified in this final rule exception applying to practices an actor State laws—including, but not limited that although practices that purport to reasonably believes will substantially to, laws protecting patient privacy or educate patients about the privacy and reduce a risk of harm otherwise arising mandating provider reporting of security practices of applications and from access, exchange, or use of corrupt particular types of abuse their patients parties with which a patient chooses to or inaccurate data within a patient’s may experience. Therefore, requiring via share their EHI would always be subject record. regulation that all health care to review by OIG if there were a claim Comments. One commenter, professionals document their of information blocking, such practices acknowledging that patients’ wishes determination specifically in the EHR in likely would not be considered to that specific information not be shared order to satisfy this exception’s interfere with the access, exchange, and should be honored, advocated conditions could impose an use of EHI if they meet certain criteria expanding this exception to cover unnecessary burden on those who (see section VIII.C.6, above). physicians’ declining to disclose any would like to conform their practices to EHI to other physicians where this exception but currently take a Risk of Corrupt or Inaccurate Data Being withholding of some information at the different approach to documenting risk Recorded or Incorporated in a Patient’s patient’s request would, in the factors or to documenting Electronic Health Record disclosing physician’s view, render the individualized determinations of risk patient’s record so distorted as to be specific to access, exchange, or use of We proposed (84 FR 7524) that the misleading. the patient’s EHI by the patient or their Preventing Harm Exception could apply Response. As we explained in the legal representative(s). Thus, we have to practices that address risks of harm Proposed Rule, we would not recognize not finalized a requirement that licensed arising from corrupted or inaccurate EHI incompleteness of the EHI that an actor health care professionals must being recorded or incorporated in a can disclose as a source of a risk of harm document in their EHR or in any other patient’s electronic health record. We cognizable under this exception. For particular system(s) their individualized further proposed that recognized risks instance, patients may make requests determinations of risk of harm in order from incorrect or inaccurate information that specific information not be for the determinations of risk to satisfy would be limited to those arising from accessed, exchanged, or used beyond a the risk of harm condition finalized in known or reasonably suspected specific clinician-patient (or other 171.201(c)(1). corruption and inaccuracies caused by relevant) relationship because the Comments. One commenter noted performance and technical issues information is associated with a that minors may not fully understand affecting health IT. We clarified that the stigmatized condition, or for personal the implications of downloading and Preventing Harm Exception would not reasons (such as the patient’s subjective sharing their EHI, which represents a extend to purported accuracy issues perception the information may be different type of risk than the three arising from the incompleteness of a embarrassing or otherwise detrimental discussed in the Proposed Rule. The patient’s electronic health record to them). In the Proposed Rule, we commenter advocated for health care generally. We acknowledged that provided an illustrative example of a providers to have discretion to impose Federal and State laws may require an patient declining consent to share 42 restrictions on non-emancipated minors’ actor to obtain an individual’s written CFR part 2 substance abuse treatment ability to access their EHI through an consent before sharing specific health information, and stated we would not API. information, such as information subject consider the remainder of the patient’s Response. We did not modify the to 42 CFR part 2. However, we expressly record inaccurate based on its Preventing Harm Exception in response noted in the Proposed Rule that this incompleteness (84 FR 7524). Health to this comment. The Preventing Harm exception would not apply to an actor’s care providers receiving any patient’s Exception (§ 171.201) is intended to conduct in refusing to provide access, records of prior care presumably have apply to practices an actor reasonably exchange, or use of the remainder of the an awareness of the potential that some believes will substantially reduce a risk patient’s record on the basis that the information may be omitted from the of harm to one or more particular information withheld per patient’s non- information they receive for a wide person(s), and in many circumstances consent would render the remainder of variety of reasons that include, but that (§ 171.201(d)(3) or (4)) a risk of harm to the patient’s record incomplete and thus are not limited to, patients’ intentional the life or physical safety of particular inaccurate. We also noted that known choices to withhold some information. persons, such as: A patient or person in inaccuracies in some data within a Therefore, we do not believe it would be the patient’s life; or multiple patients record may not be sufficient justification appropriate to consider EHI to be whose EHI was corrupted or to withhold the entire record so long as corrupt, inaccurate, or otherwise mismatched due to a technical failure of the remainder of the patient’s EHI could erroneous where it is simply a subset of an actor’s systems. Where a non- be effectively shared without also everything an actor knows about the emancipated minor, or other patient, is presenting the known incorrect or patient. otherwise legally entitled to access or corrupted information as if it were We are not persuaded that a patient’s receive their own health information trustworthy. withholding consent to share specific

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00189 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25830 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

portions of their overall EHI, regardless permissible access, exchange, or use of otherwise not yet considered by the of the patient’s rationale for withholding a patient’s EHI by their health care hospital reliable for purposes of clinical consent, would render the data set their providers must be one the actor decision making; or notes that the physician (or other health care provider) implementing the practice reasonably clinician has begun to draft but cannot could share more dangerous to the believes will substantially reduce a risk finalize until they receive (confirmed) patient than sharing none of the of harm of a type that could serve as laboratory or pathology results or other patient’s EHI with another of the grounds for denial of the individual’s information needed to complete their patient’s providers. Instead, we remind right of access to their EHI under the 45 decision making. We hope it is, and will health care providers that nothing in CFR 164.524(a)(3)(i). Therefore, in order be increasingly, rare that an actor cannot part 171 overrides Federal, State, or for a practice likely to interfere with the effectively sequester non-finalized EHI tribal law protections of patients’ access, exchange, or use of EHI by one from finalized EHI. However, we cannot privacy preferences. Likewise, nothing of the patient’s health care providers to rule out the possibility that some actors in part 171 reduces variation in what satisfy the conditions of the Preventing may face that problem at some point. If and how much information patients Harm Exception, the actor must hold a an actor cannot effectively sequester remember, or are willing, to disclose to reasonable belief that the practice will non-finalized EHI from a particular their health care providers. Patients substantially reduce a risk to the access, exchange, or use where remain free to withhold various patient’s, or another natural person’s, inclusion of non-finalized EHI would information from their health care life or physical safety that would not be appropriate, the actor should providers, including but not limited to otherwise arise from the access, refer to the new Content and Manner what other providers they may have exchange, or use of the EHI with which Exception (finalized in § 171.301) or the seen in the past. the practice interferes. Erroneous Infeasibility Exception finalized in Before enactment of the Cures Act, misrepresentations that a patient is not § 171.204. health care providers could not safely known to be taking any medications, Comments. A number of commenters assume every patient record they when in fact they are known to be expressed concerns that many actors’ received from any source necessarily taking one or more medications, is health IT systems currently lack the included all the information that could typically a system problem and one that capability to segment data by class and or should be known by that source that can give rise to risk to the physical element that would be needed to would be relevant to the patient’s health safety, or even the life, of any or all withhold only those classes or elements or care by that provider, even where the patients whose EHI may be affected by that were corrupted or erroneous as source can permissibly share everything the problem. described in the Proposed Rule. they do know. Thus, we reiterate that Comments. One comment submission Commenters requested clarification on we do not believe it is reasonable or highlighted a tension between the data- whether the § 171.201 Preventing Harm necessary for purposes of preventing provision preferences of health care Exception would in these cases apply to harm that a provider withhold the EHI providers requesting data and other the entirety of the patient’s EHI, how it that they could permissibly share in any actors (such as other providers and their would apply, or if another exception particular circumstance simply because health IT developers) from whom data would also be needed. they happen to have more EHI than they is requested. This commenter indicated Response. In the circumstances these can permissibly share. providers requesting data, such as long- comments described, the Preventing However, we also highlight that for term/post-acute providers caring for Harm Exception will apply only to the purposes of this exception a data export patients after a hospital stay, may EHI known or reasonably suspected to or access mechanism appropriately currently have to wait days to receive be corrupt or erroneous. If an actor lacks showing that some data may be any of the patient’s clinical data from the data segmentation capabilities that unavailable or omitted from the export the hospital stay because the hospital or would be needed to sequester only that or presentation is materially different its health IT developer refuses to data known or reasonably suspected to from a data export or presentation that generate and send the C–CDA document be corrupt or erroneous from the misrepresents the patient’s EHI. For until every last data element is requested access, exchange, or use, we example, exports or presentations finalized. The commenter suggested we would encourage the actor to consider omitting all medication data and clarify whether § 171.201 would apply meeting the conditions of another correctly stating ‘‘medication data not to such circumstances. exception with respect to the remaining available,’’ 153 we would not consider Response. An actor’s practice of EHI. For example, the Content and corrupt, inaccurate, or otherwise delaying fulfillment of an otherwise Manner Exception (§ 171.301) may erroneous. By contrast, however, an feasible and legally permissible request allow for the actor to provide the export or presentation stating ‘‘no for exchange, access, or use of EHI that requestor with the EHI not known or current medications,’’ or stating ‘‘none’’ is finalized and available to the actor reasonably suspected to be corrupt or or ‘‘none known’’ in the medication merely because the actor knows more erroneous, albeit in a different way than section, when in fact the system EHI for that patient will become was initially requested. Or, if the actor producing the export or representation available at some later date would not lacks the technical capability to share does include current known satisfy the conditions of § 171.201. As the EHI that is not known or reasonably medications for the patient, represents a we stated in the Proposed Rule, we do suspected to be corrupt or erroneous type of risk recognized under not view mere incompleteness of a consistent with the Content and Manner § 171.201(c)(2). patient record as rendering the Exception (§ 171.301), then the actor Under § 171.201(d)(4), as finalized, a remainder of the patient’s record may wish to meet the Infeasibility practice that is likely to, or that in fact inaccurate (84 FR 7524). We recognize Exception (§ 171.204). The applicability does, interfere with otherwise that specific data points may not be of the exceptions will depend on the appropriate to disclose or exchange particularized circumstances, including 153 Or otherwise indicating, in a manner until they are finalized. Such data but not limited to the specific request appropriate to the circumstances, that absence of points would include, but are not made. We believe the conditions of information in the extract or representation should not be understood as a statement that there is no necessarily limited to: Laboratory these exceptions also offer frameworks such data in the source system. results pending confirmation or within which a responding actor and an

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00190 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25831

EHI requester may be able to identify a or the Infeasibility Exception finalized EHI in order to substantially reduce a mutually agreeable approach to making in 171.204. risk of harm. Presuming its conditions trustworthy EHI appropriately available Comments. Several commenters are otherwise met, § 171.201 would in at least some of the instances where requested clarification on whether an apply to a variety of practices a request cannot be safely fulfilled in actor has a responsibility to assess the appropriate to correct mismatched, exactly the manner of the requester’s data in their possession, custody, or corrupt due to technical failure, or first preference. control for risk of harm before making otherwise erroneous EHI in a manner it available for access, exchange, or use. consistent with otherwise applicable Comments. One comment expressed a Response. The conditions finalized in law, regulations, accreditation concern that some health care providers, § 171.201 for practices that interfere standards, and payment program particularly those already receiving with the access, exchange, and use of standards. feedback from payers about their data EHI for purposes of preventing harm to Comments. One comment requested quality, might believe the Preventing be excepted from the definition of clarity regarding the applicability of this Harm Exception would allow them to information blocking (§ 171.103) do not exception to data received from a third withhold patients’ access to the require that actors generally evaluate party, where the actual accuracy of the patients’ own EHI to prevent the data requested for data quality issues or data cannot be, or has not been, patients from seeing data quality issues other sources of risk of harm before confirmed by the actor asked to make the provider knows or believes are fulfilling requests for access, exchange, that data available for access, exchange, present in that EHI. or use of the EHI. At the same time, or use. Response. If a provider knows that the actors should be aware that where an Response. We recognize that in some data quality issues in their records serve actor may have an affirmative duty circumstances the available and feasible as a source of risk consistent with under otherwise applicable law for the mechanisms for EHI access, exchange, § 171.201(c)(2), so as to form the basis quality or accuracy of data, or for or use may not support as much data of a reasonable belief the patient’s assessing other types of risk of harm that provenance information as an actor accessing or using the data would place could be implicated by an EHI access, might prefer. In such circumstances, the the patient at risk of harm cognizable exchange, or use request, nothing in actor would be free to communicate under this exception,154 the exception § 171.201 should be construed as supplemental information about specific would apply if all other conditions of lessening or otherwise changing that data’s provenance to a requestor. the exception were met. However, duty. For example, the Preventing Harm However, the conditions of the known corruption or other errors that Exception does not lessen or otherwise Preventing Harm Exception would not would place a patient accessing their change an actor’s existing obligations to be met where EHI requested was EHI at risk of harm cognizable under ensure patient EHI is created, recorded, received from a third party and the actor this exception on the basis of and maintained to standards of accuracy could not confirm the accuracy of the accessing—and presumably making and reliability consistent with laws, EHI. Comments. A comment from the health or care decisions based on—that regulations, and accreditation requirements applicable to the perspective of health IT developers and EHI would also raise a substantial particular actor in any given implementers stated that this exception concern regarding the safety of that EHI circumstance. should allow an actor to err on the side for use by the provider. Thus, we would Comments. Commenters expressed of caution as the actor looks to expect that whenever a given health appreciation for the inclusion of this determine the extent of potential care provider believes the EHI within exception so that health care providers distortions in a record before sharing it. their records is safe enough for their will not be forced to share incorrect A number of commenters described own use in the delivery of patient care, data. Several of these commenters practices used today by HIEs to assess the Preventing Harm Exception would requested we clarify a provider’s and resolve data quality issues, not excuse the provider from honoring responsibility for correcting corrupt or including but not limited to taking all of their patients’ requests to access, incorrect information once it is the records from a particular source exchange, or use that EHI simply discovered. offline while assessing the extent or because the patients might discover Response. For health care providers, cause of issues identified in some error(s) in that EHI. If, to the actor’s existing State and Federal laws and record(s) from that source. knowledge or reasonable belief, only regulations address the responsibility to Response. The Preventing Harm some data classes or elements within a maintain appropriate records of health Exception is intended to apply to a patient’s EHI are a source of risk care furnished and in support of variety of practices reasonable and consistent with § 171.201(c)(2), the actor reimbursement sought from various necessary to protect patients from risk of should continue to make the remaining programs and payers. Health care harm arising from access, exchange, or data classes and elements available to providers that have obtained voluntary use of data that is known or reasonably the patients and other requestors (as accreditations may have made suspected to be corrupt, inaccurate, appropriate under applicable law). additional commitments related to mismatched, or misidentified. To be Where the actor lacks the technical record-keeping and data quality in covered by the exception, the practice ability to appropriately sequester only context of obtaining and maintaining may interfere with the access, exchange, the corrupt or erroneous data within the those accreditations. These existing or use of EHI only to the minimum EHI they hold for given patient(s), the responsibilities of health care providers extent necessary to substantially reduce actor should reference the Content and are not lessened or otherwise changed a risk of harm cognizable under the Manner Exception finalized in § 171.301 by the Preventing Harm Exception. The exception, but the exception does not exception simply provides for exception require that every record affected by the 154 Note that where the practice interferes with a from the definition of information practice have first been confirmed to patient’s access to their own EHI, the applicable blocking at § 171.103 of practices contain corrupt, mismatched, or harm standard is established in § 171.201(d)(3) and otherwise dangerously problematic data. is the same one established at § 164.524(a)(3)(i). interfering with the access, exchange, or Currently, that would be harm to life or physical use of mismatched, corrupt due to In some circumstances, such as a safety. technical failure, or otherwise erroneous particular data source experiencing a

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00191 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25832 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

known or reasonably suspected system Comments. Commenters noted that various types of sources, we would do or other technical failure producing integration of data from various types of so in context of the specific widespread corruption, mismatching, or sources is challenging because of circumstances in which particular other dangerous errors, the minimum differences in the data elements that practices were applied by particular reasonable and necessary precautions different types of sources can exchange, actor(s). may make all records from that source and because of technical differences in Finalized Policy for Risks of Harm unavailable pending resolution of the how similar data elements may be Arising From Corrupt or Inaccurate Data technical failure and its risk-producing structured, defined, or encoded across effects. The actor’s knowledge or different types of sources. Commenters We have finalized the type of risk reasonable suspicion could be also stated that data from new exchange condition with modifications to the appropriately derived in various ways. partners may raise questions about proposed regulation text. We have These ways would include, but are not potential accuracy issues in interpreting reorganized the regulation text, and in limited to: Detection of specific data and integrating different types of data as the context of that reorganization quality issues in a sampling of records well as integrating similar data from rephrased the statement of some from the particular source; or receipt of various types of sources. Commenters conditions. We have also, in notice from a source that they had recommended that § 171.201 recognize § 171.201(c)(2) replaced the word experienced technical issues or failures that practices may delay integration and ‘‘inaccurate’’ (used in proposed resulting in corruption, mismatching, or availability of EHI in order to address § 171.201(a)(2)) with ‘‘erroneous’’ to other data quality issues giving rise to these issues, and also recommended better differentiate between normal risks of harm cognizable under this that a time limit be established for shortfalls in the complete accuracy of a exception. completing evaluations of incoming record and risk-generating errors in the data. We also combine all data-specific Comments. A commenter noted that data. sources of risk of harm in the final this exception should be applied rarely, Response. We appreciate commenters’ § 171.201(c)(2) instead of splitting them and when applied should not be a highlighting that the U.S. health care across two paragraphs as was the case mechanism to selectively block system as a whole includes in § 171.201(a)(1) (‘‘corrupt or information from specific actors. opportunities for access, exchange, and inaccurate’’ in the Proposed Rule) and However, several other commenters use of a wider variety of data classes § 171.201(a)(2) (‘‘misidentified or made observations that, in current and elements than are currently mismatched’’ in the Proposed Rule). We practice, EHI coming from sources addressed by standards and made this change because misidentified, whose data has a pattern of higher-than- implementation specifications adopted mismatched, corrupt, and otherwise normal error rates may be subjected to in part 170, and more sources than just erroneous data are all sources of risk more extensive review, and potentially those actors currently using certified arising from issues with the data rather delayed in broader availability, health IT. We are aware that, in a variety than characteristics unique to a patient compared with EHI from sources whose of circumstances, safely and or their circumstances. Additional data error rate is within a more normal appropriately integrating data from a conditions must be met for § 171.201 to range. Comments describing such new source may require time to apply to practices implemented to current practices recommended that this determine and apply appropriate substantially reduce a risk of harm exception should allow for continued processing approaches to ensure that arising from data issues (consistent with application of additional data quality data are not corrupted in the process of § 171.201(c)(2)), including § 171.201(a), assurance processing to EHI from mapping or converting them to the (b), (d)(3) or (4), and (f)(1) or (2). sources whose data exhibits a history or structures and standards used by the Whether (d)(3) or (d)(4) applies turns on pattern of more numerous or more risky recipient. Our finalized exception will whether the practice is likely to, or data quality issues. apply to appropriately tailored practices does, interfere with a patient’s own or Response. If an actor were to engage for assessing and mitigating risks other legally permissible access, in practices systematically interfering otherwise posed by integration of data exchange, or use of the patient’s EHI. with access, exchange, or use of EHI from new sources, that is not Whether (f)(1) or (f)(2) applies turns on from a particular source based on standardized, or that is standardized to whether the actor implements the considerations extraneous to the non-published, proprietary, or obsolete practice consistent with an prevalence and risk profile of data standards. In cases where the original organizational policy (f)(1) or based on quality issues in the EHI, such practices meaning of EHI received cannot be a determination based on the would not meet the conditions to be determined in a manner allowing for particularized facts and circumstances excepted under § 171.201 from the conversion to the formats and standards known or reasonably believed by the definition of information blocking used by the recipient’s systems, it may actor at the time the determination was finalized in § 171.103. Examples of sometimes be necessary to decline to made and while the practice remains in considerations we would consider to be integrate such data in the recipient’s use (f)(2). extraneous in this context notably production systems. However, we For purposes of providing additional include, but are not limited to, whether believe it would be premature to information and explanation as the data source was competitor of the establish via this rulemaking specific requested by many commenters, we actor and whether the actor may harbor time limits for assessment and reiterate that a risk of harm arising from personal animus toward the data source. processing of EHI received from new data that is known or reasonably However, this exception would apply to exchange partners, in large part due to suspected to be misidentified or practices not based in whole or any part the considerable variability in systems mismatched, corrupt due to technical on considerations extraneous to the and circumstances of the actors failure, or erroneous for another reason prevalence and risk profile of data involved in such exchange (§ 171.201(c)(2) as finalized) will not, quality issues in the EHI, provided each relationships. Should the need arise to consistent with discussion and such practice meets all conditions in assess the reasonableness, necessity, illustrative examples in the preamble to § 171.201 that are applicable to the and timeliness of an actor’s practices the Proposed Rule (84 FR 7524), satisfy circumstances in which it is used. applied to data received from new or the conditions of the Preventing Harm

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00192 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25833

Exception if it turns on mere facility/organizational accreditations or broader than necessary to mitigate the speculation about, or possibilities of, as- professional board certifications the risk of harm arising from the potentially yet-undetected inaccuracies or other provider may also hold. misidentified record or misattributed imperfections in the EHI. An electronic Where an actor lacks the technical data (84 FR 7524). For example, under health record, like the paper chart it capability to sequester from otherwise the proposed exception, an actor—such replaces, is inevitably less than perfectly legally permissible access, exchange, or as a health IT developer of certified complete and precisely accurate across use only that subset of EHI the actor health IT—refusing to provide a batch 100 percent of the variables potentially knows or reasonably suspects is affected export on the basis that the exported relevant to the individual’s health. by data issues giving rise to risk of harm records might contain a misidentified Because the risk that records in general consistent with § 171.201(c)(2), the record would not find that practice may be imperfect is a risk that we Preventing Harm Exception will not recognized under this exception. understand as inherent to (and thus recognize withholding of the remaining Similarly, a health care provider or ordinarily addressed in the course of) EHI. In such circumstances, an actor other actor that identified that a clinical practice, it will not be should refer to the exceptions for particular piece of information had been recognized as justifying practices that Content and Manner (§ 171.301) and misattributed to a patient would not be implicate the information blocking Infeasibility (§ 171.204), as may be excused under § 171.201 from definition. Thus, the Preventing Harm applicable, in regard to the EHI that they exchanging or providing access to all Exception finalized in § 171.201 does do not know or reasonably suspect to be other EHI about the patient that had not not extend to purported accuracy issues affected by data issues giving rise to risk been misattributed. The actor knowing arising from potential, suspected, or of harm consistent with § 171.201(c)(2). or reasonably suspecting some data had known incompleteness of a patient’s been misidentified or misattributed Risk Arising From Misidentifying a electronic health record generally, such would also be expected to confirm the Patient or Mismatching Patients’ as the possibility of a patient choosing, extent of such errors and to take Electronic Health Information or not remembering, to mention some of appropriate steps to correct their own the medications they regularly take. The Preventing Harm Exception is records, consistent with applicable law, Similarly, the possibility that any given intended to apply to practices that are regulations, and accreditation standards patient’s EHI could at any time contain designed to promote data quality and applicable to the actor, and best sporadic, undetected, inaccurate data integrity and to support health IT practices or other appropriate industry points as a result of data entry errors— applications properly identifying and benchmarks for health records and such as an entered weight of 123 instead matching patient records or EHI. As information management. of the accurate observation of 132— discussed in the preamble to the Comments. Commenters would not be interpreted as satisfying Proposed Rule (84 FR 7524), accurately recommended we consider that actors the condition finalized in identifying patients and correctly bear significant responsibility to § 171.201(c)(2). attributing their EHI to them is a preserve and promote data quality and integrity, and that actors generally take The Preventing Harm Exception will complex task and involves layers of safeguards. The task requires risk-averse approaches to preventing apply in those instances where specific and to assessing and resolving errors in EHI of one or more patients is affected application of appropriate procedures for verifying a patient’s identity and identifying EHI and matching patient by a risk consistent with the finalized EHI. § 171.201(c)(2). Assuming its other properly registering the patient in health IT systems. Safeguards include such Response. We appreciate the conditions that are applicable to the opportunity to assure all stakeholders specific circumstances are met, the usability and implementation decisions such as ensuring the display of a that we are aware that the EHI an actor Preventing Harm Exception will apply receives from various sources may patient’s name and date of birth, and to appropriately tailored practices that feature a variety of characteristics that perhaps a recent photograph, on every affect a particular patient’s EHI call for varying degrees of pre- screen from which clinicians and other regardless of the origin or cause of processing to achieve a level of caregivers access, enter, and/or modify known or reasonably suspected data matching accuracy considered by the data in the patient’s record. When a issues giving rise to risk of harm health care provider community to be clinician, other health IT user, or other consistent with § 171.201(c)(2), and to sufficient for safe use of the data in actor knows or reasonably suspects that the use of the practices for such time as patient care. In some circumstances, we specific EHI is not correctly attributed to is reasonable and necessary to amend or understand additional or special one or more particular patient(s), it correct the patient’s EHI. In assessing processing—including but not would be reasonable for them to avoid timeliness and reasonableness of an necessarily limited to human eyes-on actor’s approach to making such sharing the EHI that could introduce or analysis to confirm matches—may be corrections, we would take into propagate errors in patient records and needed before records are deemed to consideration the facts and thereby pose risks to the patient(s) 155 have been accurately matched, and that circumstances within which they affected. data requiring human processing may be operate, including but not limited to Under the Preventing Harm Exception delayed in integration and availability licensure or certification requirements as proposed, an actor’s response to the compared with data that can be applicable to the actor’s EHI risk of misidentified patient health satisfactorily matched through an actor’s governance. For a health care provider, information would need to be no automated means. Section 171.201 will we anticipate such licensure or apply to such practices provided all of 155 Please note that practices designed and certification requirements will typically implemented to ensure that persons requesting its conditions are met. include clinical records standards set by access to their EHI are who they claim to be and Comments. Commenters State licensure laws and additional give them access to only that EHI that is theirs recommended the finalized exception standards applicable to that provider would not be cognizable under the Preventing Harm recognize as reasonable and necessary to Exception; we have established two other given their specific circumstances, such exceptions designed to address practices reasonable protect patient safety practices such as as patient records maintenance and necessary to protect the privacy (see § 171.202) sequestering from access and exchange standards set by issuing bodies of and security (see § 171.203) of individuals’ EHI. all records from a particular source, or

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00193 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25834 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

affected by a particular system or Response. The potential for EHI to be commenter requested ONC clarify that technical process, until the scope and mismatched (or otherwise mishandled) this exception does not allow for an cause of patient matching or attribution by an application, whether mobile or actor to take a position that it will not issues can be identified and otherwise, is neither unique to pediatric share EHI unless the requesting entity appropriately resolved. Commenters patients’ EHI nor particular to apps that demonstrates it will match patients stated such practices are commonly receive the patient’s data from a using a method, or to a degree of used today by HINs/HIEs, and provided provider’s API. A patient whose accuracy, satisfactory to the actor being illustrative examples of current practice. provider has not yet implemented a requested to share the information. Comments described as an example standards-based API could use other Response. We do not believe it would current practice of HIEs not making means to get their EHI into their chosen be appropriate to extend the Preventing available any record(s) that their direct-to-consumer app. Such means Harm Exception to apply to practices monitoring for technical or other issues could include accessing view, whereby actors would limit otherwise identifies as an improperly matched download, and transmit functionality of legally permissible access, exchange, or patient record—and any other records the provider’s certified health IT via the use of patient EHI based on concerns that may be affected by a similar patient portal and transmitting an that a requestor will not handle patient technical issue—until the record(s) can extract of their data in C–CDA format to matching in a manner acceptable to the be corrected to include only accurately the recipient of the patient’s (or their actor. Various recipients and users of matched data. legal representative’s) choice. An EHI will have different purposes and Response. We do understand that a individual or their representative could contexts of data use and thus may variety of methods and approaches may also exercise the individual’s right of appropriately deem differing levels of currently be needed to assess the scope, access under the HIPAA Privacy Rule to assurance of match accuracy satisfactory identify, and appropriately address the obtain the individual’s EHI that is to meet their obligations, for patient cause of patient matching or attribution accessible under this right, in another safety or otherwise. Therefore, this errors. Section 171.201 will apply to format in which it is readily producible, exception will not apply to actors’ practices otherwise meeting its and then upload it to an app of their refusal to allow access, exchange, or use conditions that affect more patients’ choosing. In general, we do not believe of EHI on grounds that the actor may not records than those specifically it would be appropriate to extend the know, or may not be satisfied with, the confirmed to include mismatched or Preventing Harm Exception to apply to matching methods to be used by a misattributed EHI. Where its conditions practices whereby actors would limit recipient of the EHI after the EHI has are otherwise met, the exception will otherwise legally permissible access, been securely transferred to the apply to use of practices likely to exchange, or use of patient EHI based on recipient. Comments. Some commenters interfere with access, exchange, or use concerns that a requestor will not specifically discussed concerns about of EHI that the actor knows includes handle patient matching in a manner potential misuse of this exception on a mismatched or misattributed data or acceptable to the actor. Therefore, this claim of patient matching concerns, and reasonably suspects includes such exception will not apply to actors’ that this exception could lessen actors’ errors. Reasonable suspicion could be refusal to allow access, exchange, or use motivations for improving their patient formed on various bases, such as of EHI on grounds that the actor may not match capabilities. Some commenters objectively observable patterns of know, or may not be satisfied with, the suggested specific additional association between detected errors and matching methods to be used by a a particular data source, application, requirements for applicability of this recipient of the EHI after the EHI has system, or process. However, a practice exception to practices implemented to been securely transferred to the of delaying the availability of records reduce risks of harm arising from recipient. Provided the practices meet from any particular data source based mismatch or misidentification of patient its conditions, the Security Exception on factors extraneous to matching EHI, in order to guard against its misuse (§ 171.203) will apply to a variety of processes and accuracy would not be or potentially incentivizing stagnation practices directly related and tailored to excepted from the definition of in rates of patient matching capabilities specific security threats to the actor’s information blocking. Examples of advancement. Additional requirements systems and EHI within those systems extraneous factors include, but are not that commenters suggested were: that may be posed by particular limited to, whether the data source was • That an actor only be able to take competitor of the actor and whether the connections or interfaces with third- advantage of this exception on basis of actor may harbor personal animus party systems or software. We also note mismatch if the actor’s matching toward the data source. that practices that do not methods met or exceeded a performance Comments. One commenter suggested inappropriately discourage patients threshold; the Preventing Harm Exception allow from accessing, exchanging, or using • that the actor proactively for providers to refuse to release their EHI as they choose, but that are communicates to requestors the actor’s pediatric data to direct-to-consumer appropriately designed and minimum matching criteria and other applications unless the provider was implemented to help patients make aspects of its matching methods; and satisfied with the applications’ ability to more informed choices about their EHI • a requirement for specific features properly segment the data where and apps can be designed and in the actor’s systems, such as returning multiple users’ records might be stored implemented to avoid meeting the informative error messages regarding in the same instance of the application. definition of information blocking match failures. Specifically, the comment expressed a finalized in § 171.103. Response. We are aware there is concern that if applications are not set Comments. One commenter expressed variation across actors in technical up to safely handle multiple patients, a concern that this exception could capabilities relevant to patient data from multiple patients could be become a pretext for an actor to avoid matching, resources to improve those mixed together in ways that create a sharing EHI on basis of the actor not capabilities, and other operational potential for serious harm stemming being satisfied with the accuracy considerations. We are not aware of from how those data might then be used achieved by a prospective recipient’s clear evidence or broad industry or interpreted. patient matching methods. This consensus on specific practices or

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00194 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25835

performance thresholds that should matching performance before this Comments. Commenters requested, in apply to across all EHI use cases and exception will apply to practices context and reference to the Preventing operational contexts. We believe it otherwise meeting the conditions of Harm Exception, guidance regarding would be premature to limit the § 171.201 applicable in the particular what an actor is obligated to do if they availability of this exception to actors circumstances, including that the actor receive EHI as a result of provider able to implement specific practices or can demonstrate a reasonable belief the matching failure. One commenter meet particular metrics of patient practice(s) will substantially reduce a specifically requested guidance on what matching performance specified through risk of harm cognizable under § 171.201. sort of good faith efforts to direct the this rulemaking. Because this exception We emphasize that we have not EHI to the correct recipient would be is intended to except from the definition established a pre-requisite for expected of an inadvertent recipient of of information blocking in § 171.103 applicability of § 171.201 that would mis-directed EHI. practices that are reasonable and call upon an actor to use particular Response. A provider or other actor necessary to protect patients from risks methods, or satisfy particular threshold who receives EHI that they have reason of cognizable harm attributable to types performance rates on any specific to believe may have been directed to of risk specifically including risks metric, for patient identification and them by mistake has no obligation arising from mismatched EHI, rather matching. under part 171 to identify the correct than to drive changes in patient Comments. A few commenters recipient or to forward the EHI to the matching practices in the industry, such requested clarification as to whether a correct recipient. The actor who requirements could render this patient would be liable for accessing believes they may have received mis- exception unavailable in circumstances another patient’s EHI that had been directed EHI should upon forming such where it is intended to apply. Thus, we mismatched or misattributed to the belief follow their established practices have determined that it is more patient accessing the information. for handling of PHI and PII received in appropriate to leave actors engaged in Response. This issue is outside the known or suspected error. We presume using data the discretion and scope of this rulemaking. Those these established practices are responsibility for determining what concerned or curious about it should consistent with Federal, State, or tribal level of certainty in the accuracy of reference Federal,156 State, or tribal law law applicable to the particular actor in record matching is necessary for their and regulations—or reliable sources of the particular operational use of the EHI. We appreciate this information about Federal,157 State, or circumstances. tribal law and regulations—applicable opportunity to clarify that the Statement of Finalized Policy for Risks Preventing Harm Exception would not to any individual’s (or entity’s) unauthorized access to or use of Arising From Misidentified or excuse actors from making appropriate Mismatched EHI good faith efforts to match patient another’s personally identifiable records, which we expect will information (PII) in the particular We are finalizing the substance of this ordinarily include communication and jurisdiction(s) and circumstances of part of the exception as proposed, with cooperation between data sources and potential concern. modifications to how it is expressed in recipients. Moreover, we believe an Comments. One commenter suggested regulation text in comparison with the actor will generally have a natural creation of a hold-harmless or ‘‘safe Proposed Rule. We have reorganized the incentive to communicate proactively, harbor’’ policy protecting data regulation text in response to comments appropriately, and in good faith with recipients from liability for actions requesting our regulatory text in general those with whom they exchange data, taken in good faith reliance on be laid out in a way that is easier to use. specifically to minimize unnecessary information received after applying For example, we have combined risks extra processing and follow-up best-practice matching methods. arising from misidentified or communications on the part of both Response. The suggestion appears to mismatched EHI with other data- exchange partners. Therefore, we have reference a safe harbor from liability for specific sources of risk of harm in the not modified the Preventing Harm decisions or other actions taken in final § 171.201(c)(2), instead of splitting Exception’s conditions in response to reliance on the EHI in question. That is them across two paragraphs as was the these comments. outside the scope of this rule. Actors case in § 171.201(a)(1) (‘‘corrupt or Comments. One commenter expressed should implement matching inaccurate’’ in the Proposed Rule) and a concern that to ensure they do not methodologies and practices in full § 171.201(a)(2) (‘‘misidentified or release information that has potential awareness that this final rule will not mismatched’’ in the Proposed Rule). We errors in patient matching or attribution, change their responsibility under other believe this makes the finalized text of they will need to invest in improved applicable law for maintaining § 171.201 easier to use because patient record matching accuracy, appropriately reliable medical or other misidentified, mismatched, corrupt, and which the commenter indicates would business records. This final rule also otherwise erroneous data are all sources for them include new technical does not alter clinicians’ responsibilities of risk arising from issues with the data solutions compared with their current for exercising sound professional rather than characteristics unique to a practice. judgment in making clinical decisions patient or their circumstances. As was Response. This exception is not based on EHI available to them in the case in the Proposed Rule, intended, and we are not persuaded that context of what they know or reasonably additional conditions must be met for as finalized it will function, to impose believe about the EHI’s reliability. § 171.201 to apply to practices a new or specific obligation on actors to implemented to substantially reduce a ensure they do not release information 156 Potentially applicable Federal law and risk of harm arising from data issues regulations are not limited to HIPAA and the (consistent with § 171.201(c)(2)). In the that could contain latent errors. Other HIPAA Privacy Rule, but the HIPAA Privacy Rule commenters did recommend we may be a useful place for those who share interest structure of the finalized regulation text, consider doing so. However, for the in the question raised by these comments to begin these additional conditions are found in reasons stated above in response to obtaining additional information. § 171.201(a) and (b), and as applicable those comments, we have not 157 Authoritative information about the HIPAA in the particular circumstances also in Privacy Rule is available in the health information established a pre-requisite that an actor privacy section of the HHS website, starting at (d)(3) or (4), and (f)(1) or (2). Whether meet a particular threshold of patient- https://www.hhs.gov/hipaa/index.html. (d)(3) or (d)(4) sets out the harm

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00195 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25836 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

standard that applies to a practice an determinations of risk made by a individualized knowledge stemming actor believes will substantially reduce licensed health care professional in from the clinician-patient relationship a risk of harm consistent with order for the actor’s application of that, for a particular patient and for that § 171.201(c)(2) turns on whether the practices consistent with that patient’s circumstances, harm could practice is likely to, or does, interfere determination to be recognized under result if certain EHI were shared or with a patient’s own or another other this exception. The finalized exception transmitted electronically. To ensure legally permissible access, exchange, or also does not generally require that that both the requirement for a use of the patient’s EHI. (We note, actors relying on an individualized clinician-patient relationship and its however, that the harm required to determination made by a licensed specificity to individualized satisfy this condition is the same under health care professional in the exercise determinations of risk of harm by (d)(3) and (d)(4), as both cross-reference of professional judgment take steps to licensed health care professionals in the § 164.524(a)(3)(i).) Whether (f)(1) or review or confirm the health care exercise of judgment are immediately (f)(2) applies to a practice an actor professional’s judgment.158 Actors other clear to all actors, we have stated it in believes will substantially reduce a risk than the licensed health care the finalized text of § 171.201(c)(1). We of harm consistent with § 171.201(c)(2) professional who makes the are finalizing this as a requirement turns on whether the actor implements determination—including but not because a clinician who has never the practice based on an organizational limited to HINs/HIEs or hospitals— established a clinician-patient policy (f)(1) or a determination based on could implement practices based on relationship to the particular patient facts and circumstances known or organizational policy (consistent with would not be expected to have the same reasonably believed by the actor at the § 171.201(f)(1) as finalized) to rely on individualized knowledge of the time the determination was made and such determinations upon becoming individual patient and that patient’s while the practice remains in use (f)(2). aware of the determination and until circumstances as one who has such a such time as they become aware that the clinician-patient relationship. Determination by a Licensed Health determination has been reversed or In contrast, however, we reiterate that Care Professional That the Disclosure of revised. Such other actors also, either in a risk is less individualized when it EHI Is Reasonably Likely To Endanger absence of such policy or in arises from data issues (consistent with Life or Physical Safety (§ 171.201(c)(1)) particularized facts or circumstances not § 171.201(c)(2)) and as a result may be We proposed that this exception fully covered by their existing policy at identified by clinicians or by other would recognize practices interfering the time they became aware of a persons with relevant expertise, with EHI access, exchange, or use in licensed health care professional’s including but not limited to biomedical circumstances where a licensed health individualized determination of risk, informaticists who are not licensed care professional has determined, in the could demonstrate for those health care professionals. Nothing in exercise of professional judgment, that particularized circumstances the § 171.201 requires the involvement of a the access, exchange, or use of the EHI reasonable belief required by licensed health care professional with a is reasonably likely to endanger the life § 171.201(a) by referencing the licensed clinician-patient relationship to any or physical safety of the patient or health care professional’s determination patient(s) whose data may be affected by another person (84 FR 7524 and 7525). in making their own determination the practices in the design of, or As we explained, the clinician may have consistent with § 171.201(f)(2). decision to implement, practices an in certain cases individualized Comments. One commenter suggested actor reasonably believes will knowledge stemming from the clinician- that this exception should recognize substantially reduce a risk arising from patient relationship that, given the determinations of the existence of a risk data issues consistent with particular patient and that patient’s of harm made by licensed health care § 171.201(c)(2). circumstances, harm could result if professionals without requiring a Comments. Several commenters certain EHI were shared or transmitted clinician-patient relationship. recommended that, in the context of a electronically. We proposed that, Response. In order for practices clinician-patient relationship, the consistent with the HIPAA Privacy implemented to substantially reduce a clinician should have broader latitude Rule, a decision not to provide access, type of risk consistent with finalized to consider specifics of a patient’s exchange, or use of EHI on this basis § 171.201(c)(1) to be excepted under circumstances in determining the would be subject to any right that an § 171.201 from the definition of existence of a risk of harm or potential affected individual is afforded under information blocking finalized in harm. applicable Federal or State laws to have § 171.103, the individualized Response. It may be helpful to the determination reviewed and determination of risk of harm in the highlight the significant and broad potentially reversed. exercise of professional judgment must discretion inherent in the policy as we Comments. Commenters be made by a licensed health care proposed it. An individualized recommended that actors, such as HINs/ professional who has a current or prior determination made in the exercise of HIEs, implementing practices based on clinician-patient relationship with the professional judgment by a licensed a determination by a health care patient whose EHI is affected by the health care professional allows for that professional, not be required to take determination. In the preamble to the professional to consider a wide array of steps to review or assess the Proposed Rule (84 FR 7524) we individual patient characteristics and reasonableness of the health care explained that the clinician may have circumstances and to apply all of the professional’s judgment or knowledge and skills within the determination that a risk of harm exists 158 To the extent any particular actor may have an licensed health care professional’s scope or that the harm of which a risk was obligation under other Federal, state, or tribal law of practice. The exception’s conditions or regulations (as may be applicable in any determined to exist met the standard for particularized circumstances) to afford a patient a as proposed would provide licensed recognition under this exception. right of review of the determination—or to facilitate health care professionals broad Response. We did not propose to the patient’s requesting a review of the discretion in how or why they form a require that other actors would determination from another actor—the actor’s reasonable belief that a cognizable risk practices would need to be in compliance with such ordinarily need to evaluate whether law or regulations in order for this exception to of harm is associated with particular they agreed with individualized apply to those practices. access, exchange, or use of their

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00196 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25837

patient’s EHI (including by the patient Comments. Several commenters patient’s personal representative in or their legal representative). We have expressed a concern that the exception accordance with § 164.502(g)(5)(i). finalized this aspect of the Preventing as proposed might not sufficiently Because the finalized § 171.201(d)(1) Harm Exception as proposed, though we recognize the entire array of applies when a practice is likely to, or have revised how the conditions, and circumstances where persons should does, interfere with a legal specific requirements within particular not be granted access, exchange, or use representative’s access to the patient’s conditions, are organized and phrased of EHI. For instance, commenters EHI, the harm standard required in such in regulation text. Nothing in the suggested no access, exchange, or use of a situation is that stated in finalized § 171.201 would limit the a patient’s EHI should be available to a § 164.524(a)(3)(iii). Currently, that harm types of information on which the person suspected to be abusing, or at standard is ‘‘substantial harm.’’ licensed health care professional may risk of beginning to abuse, the patient. We also expressly note that, although rely, or the factors they may consider, in Commenters also suggested that the the ‘‘substantial harm’’ standard applied exercising their professional judgment exception should recognize that broader by § 171.201(d)(1) through cross- to make individualized determinations restrictions of EHI access than reference to § 164.524(a)(3)(iii) is not of risk of harm consistent with illustrated by examples in the Proposed precisely the same as the requirement in § 171.201(c)(1). Rule would in many cases be indicated § 164.502(g)(5)(i), we will interpret as Comments. A few commenters by available evidence, widely sufficient for purposes of § 171.201(c)(1) advocated for clinician discretion to recognized clinical practice guidelines, and (d)(1) a licensed health care determine whether a disclosure of or State laws applicable to instances of professional’s election not to treat a health information was in the patient’s known or suspected child, intimate person as the patient’s legal best interest. partner, elder, or other abuse. representative in accordance with Response. This exception applies to § 164.502(g)(5)(i). Moreover, having Response. We believe an individual practices the actor reasonably believes noted above the broad discretion clinician’s assessment of the patient’s will substantially reduce a risk of harm licensed health care professionals have best interest is a less objective standard determined on an individualized basis regarding what information to factor than one based on the exercise of in the exercise of professional judgment into their individualized determinations professional judgment paired with a by a licensed health care professional consistent with § 171.201(c)(1), we defined standard of cognizable harm. It with a clinician-patient relationship highlight that this broad discretion would thus render the exception more with the patient whose EHI is affected would allow them to consider any difficult to administer as well as more by the determination (finalized knowledge they might have of another susceptible to inappropriate use of the § 171.201(c)(1)). Moreover, and as we licensed health care professional, or exception. We are finalizing the noted in the Proposed Rule (84 FR other type of covered entity, having substance of this condition of the 7524), this exception would apply when elected in accordance with Preventing Harm Exception as an actor implements practices that are § 164.502(g)(5)(i) not to treat a person as proposed: To satisfy the conditions of likely to interfere with the access, the patient’s representative. the Preventing Harm Exception, an exchange, or use of a patient’s EHI Comments. Some comments implied individualized determination by a pursuant to electing to not treat a person concerns about the potential conflict licensed health care professional in the as a personal representative in between the documentation exercise of professional judgment must accordance with 45 CFR 164.502(g)(5). requirements of this exception and be that a risk of harm cognizable under We have finalized the substance of this those required under other applicable this exception is associated with feature of the exception as proposed, law. particular access, exchange, or use of though 45 CFR 164.502(g)(5) is not Response. Provided its conditions are the patient’s EHI. The harm cognizable expressly referenced in the final met, this exception is applicable in under this exception will be one that regulation text. circumstances where a licensed health would be recognized under The listed examples described in the care professional in the exercise of § 164.524(a)(3)(i) (at this time, danger to Proposed Rule were intended to be professional judgment has determined the life or physical safety of the patient illustrative, not exhaustive. There are that there is a risk of abuse beginning, or another person) where a practice many other situations where the as well as circumstances in which prior affects a patient’s access, exchange, or Preventing Harm Exception will apply or ongoing abuse is known or suspected. use of their EHI, per the finalized to an actor’s practices so long as the Actors have significant discretion and § 171.201(d)(3). Where § 171.201(d)(1) conditions of the exception are flexibility in determining how best to or § 171.201(d)(2) applies, the harm otherwise met. As another illustrative document determinations and the bases cognizable under this exception will be example, if a determination of risk of for their determinations. Where other one that would be recognized under harm consistent with § 171.201(c)(1) law or regulations—Federal, State, or § 164.524(a)(3)(iii) or § 164.524(a)(3)(ii), indicates that a broad withholding of tribal—require a specific form, manner, respectively. At this time, the harm the patient’s EHI from a known, or content of documentation in standard in both § 164.524(a)(3)(iii) and suspected, or potential abuser is circumstances that would serve as basis § 164.524(a)(3)(ii) is ‘‘substantial harm.’’ reasonably likely to substantially reduce for individualized determinations For all legally permissible access, a risk of harm to the patient or another consistent with the finalized exchange, or use of the patient’s EHI to person, then the exception will apply to § 171.201(c)(1), we would consider that which § 171.201(d)(1) through (3) do not those practices so long as its conditions documentation relevant to assessing the apply, the finalized § 171.201(d)(4) are met in full. Moreover, provided its applicability of this exception to those applies, by cross-reference, the same conditions are met in full, this practices. In order to avoid potentially § 164.524(a)(3)(i) harm standard of exception will also apply to practices duplicative or other unnecessary danger to the life or physical safety of that may be likely to, or do, interfere burdens on licensed health care the patient or another person that is with a legal representative’s access, professionals or other actors, we have applicable to practices interfering with exchange, or use of a patient’s EHI to a decided not to establish at this time a the patient’s access to their own EHI lesser degree than might an election not specific documentation condition and (that does not include PII of another). to recognize the representative as the have decided not to establish other

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00197 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25838 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

unique documentation requirements for commenter’s example as suggesting two reference in § 171.201(d)(1), finalized as this exception. considerations specific to access, the harm standard applicable to Comments. In reference to a specific exchange, and use of EHI. First, we practices interfering with a legal illustrative example in the Proposed believe the comment indicates we representative’s access to a patient’s EHI Rule, one commenter indicated that should expressly acknowledge that the same harm standard that would withholding or delaying availability of these types of situations are often legally apply to denying a personal only specific sensitive data elements as well as clinically complex. It is not representative’s access to an may not be sufficient in circumstances our intent that our policies individual’s PHI under such as those described in the Proposed unnecessarily add to this complexity. It § 164.524(a)(3)(iii). As Rule example, and that revoking a is also not our intent that our policies § 164.524(a)(3)(iii) stands at the time suspected abuser’s proxy access on the undermine the ability of a licensed this rule is finalized, it references whole may be more clinically health care professional, or other actor ‘‘substantial harm.’’ As discussed above, appropriate in such circumstances (84 relying on the professional’s this exception will also apply to FR 7525). determination, to take appropriate steps practices likely to interfere with a legal Response. In response to this to reduce abuse risks to which the representative’s access, exchange, or use comment, we first clarify the intent and professional’s patients would otherwise that are employed pursuant to an function of the example provided in the be exposed. Nothing in § 171.201, or in election not to treat that legal Proposed Rule. In the example, the the information blocking provisions representative as a personal licensed health care professional in the generally, requires an actor to disclose representative in accordance with exercise of professional judgment had their awareness or suspicion of abuse to § 164.502(g)(5)(i). For purposes of determined that only some information the patient’s legal representative in § 171.201, ‘‘substantial harm’’ is within the record would need to be order to satisfy the conditions of the interpreted as it is for purposes of withheld from the patient’s partner’s Preventing Harm Exception. Second, proxy access to her EHI (84 FR 7525). § 164.524(a)(3)(iii). Thus, for purposes our understanding of this comment of not recognizing a personal Although not specifically stated in the indicates that in some particular Proposed Rule, the example presumes a representative, or otherwise restricting individualized circumstances the patient EHI access, exchange, or use by mature technical capability to sequester licensed health care professional may a representative known or suspected to data from specific user(s) on an itemized determine in the exercise of professional be abusing the patient, we believe the basis. The example also presumes that judgment that to substantially reduce a harm standard applicable under this the licensed health care professional, in risk of harm it may be necessary to exception to practices affecting a legal their exercise of professional judgment, withhold some portions of a patient’s representative’s access, exchange, or use had not formed a reasonable belief that EHI from the patient’s own access of the patient’s EHI is sufficiently broad. ceasing to recognize the patient’s through an API or patient portal. We We interpret the discretion afforded to partner as her personal representative, can, for example, envision possible a licensed health care professional in and entirely revoking the partner’s circumstances where a licensed health making an individualized determination proxy access to her EHI, would care professional with a clinician- substantially reduce a risk of harm to patient relationship to the patient of risk of harm consistent with the the patient. We intended that the knows or has reason to believe that a finalized § 171.201(c)(1) (type of risk example illustrate that where the person suspected of abusing a patient condition) as allowing them to take into licensed health care professional routinely ‘‘looks over the shoulder’’ of consideration clinical practice determined a risk of harm would arise the patient while they access their EHI, guidelines and clinical expert groups’ from making a specific piece of or uses the patient’s own credentials to studied opinions relevant to abuse- information accessible to the patient’s access the patient’s EHI. In such related risks of substantial harm. Only proxy, the minimum interference circumstances, this exception would practices based on the potential for necessary to substantially reduce that apply to practices interfering with the harms that would not be recognized as risk of harm would be to withhold that patient’s own access to their EHI to the meeting the ‘‘substantial harm’’ specific piece of information from the extent the practices are not inconsistent standard, as it is interpreted by the HHS patient’s partner’s proxy access to her with the HIPAA Privacy Rule or the Office for Civil Rights for purposes of EHI. conditions in § 171.201. § 164.524(a)(3)(iii), would fail to satisfy Comments. A commenter indicated Comments. Several commenters the type of harm condition finalized in that if a clinician has a suspicion suggested that the Preventing Harm § 171.201(d)(1). We remind actors that (confirmed or not) that the patient is Exception should recognize more types any decision not to provide access, suffering intimate partner or elder of abuse, and a broader array of exchange, or use of EHI on the basis of abuse, it is considered clinically potential types of harm than danger to determination of risk of harm consistent important that notes or other data life or physical safety in the context of with the finalized § 171.201(c)(1) and elements indicating the suspicion not be interfering with access to a patient’s EHI § 171.201(d)(1), (2), (3), or (4) is subject released to the patient in the company by a legal representative suspected of to rights the individual patient whose of the suspected abuser. The commenter abusing the patient. One commenter EHI is affected may be afforded by stated that such disclosure could advocated that the Preventing Harm applicable regulations or law to have the undermine the clinician’s ability to help Exception should recognize all types of determination reviewed and potentially the patient because the patient would violence and abuse. The commenter reversed. (See the ‘‘patient right to likely be forced to switch clinicians. provided citations to professional request review of individualized The comment also indicated there may specialty expert committee opinions in determination of risk of harm’’ be a risk that an abuser could harm the support of their recommendation. condition finalized in § 171.201(e), for patient as a result of the disclosure of Response. As discussed above in which we also use ‘‘patient review the clinician’s suspicion. reference to comments that rights condition’’ as a short form of Response. Because information recommended aligning this rule’s harm reference for ease of discussion.) Where blocking policy is specific to the access, standards more closely to the HIPAA § 164.524(a)(3) applies in addition to exchange, and use of EHI, we read the Privacy Rule, we have, by cross- § 171.201, § 164.524(a)(4) specifically

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00198 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25839

provides for review of determinations sub-paragraphs as they were in the considered consistent with made by licensed health care Proposed Rule. § 171.201(c)(1); and, second, it is also professionals in the exercise of In subparagraph (a)(3) of the proposed clear that the condition for a clinician- professional judgment. In circumstances text of § 171.201 (84 FR 7602), we patient relationship is specific and where § 171.201 applies but § 164.524 expressed the additional condition that limited to determinations of risks of does not, § 171.201(e) requires that an practices based on individualized harm on an individualized basis in the actor’s practices be consistent with any determinations of risk of harm are exercise of professional judgment by a rights of review of individualized subject to any rights of review of the licensed health care professional determinations of risk of harm that the determination that the patient may be (§ 171.201(c)(1) as finalized). Please note patient may be afforded under afforded under applicable law. This that this requirement is specific to the applicable Federal, State, or tribal law patient review rights condition is individualized determination of risk of or regulations. However, for purposes of finalized in § 171.201(e). As finalized, harm, and does not limit application of § 171.201(c)(1) determinations, the type this condition requires that where a risk § 171.201 to practices implemented of harm must be consistent with: The of harm is determined on an directly by the licensed health care harm standard stated in individualized basis (consistent with professional making a determination of § 164.524(a)(3)(i) (interpreted as it is for § 171.201(c)(1) as finalized), the actor risk of harm consistent with purposes of § 164.524(a)(3)(i)) where must honor any rights the individual § 171.201(c)(1) as finalized. § 171.201(d)(3) or (4) apply; the harm patient whose EHI is affected may have Appropriately tailored practices applied standard stated in § 164.524(a)(3)(ii) under § 164.524(a)(4) or any Federal, because the actor has a reasonable belief (interpreted as it is for purposes of State, or tribal law applicable in the the practice will substantially reduce a § 164.524(a)(3)(ii)) where § 171.201(d)(2) circumstances to have the determination risk of harm that was determined on an applies; or the harm standard stated in reviewed and potentially reversed. We individualized basis consistent with § 164.524(a)(3)(iii) (interpreted as it is have stated the condition for providing § 171.201(c)(1) will, if all other for purposes of § 164.524(a)(3)(iii)) review rights afforded by law in the applicable conditions of § 171.201 are where § 171.201(d)(1) applies. separate paragraph (e) of § 171.201 met, be recognized under this exception instead of including it within whether the practices are undertaken by Finalized Policy for an Individualized subparagraph (c)(1) because in the Determination of Risk of Harm by a the licensed health care professional context of 171.201 the patient review making the determination or by another Licensed Health Care Professional in the rights condition functions as a condition Exercise of Professional Judgment actor (e.g., another licensed health care on how practices based on such belief professional, a hospital, or a HIN) We are finalizing the substance of this are implemented more than as a having custody or control of the aspect of the exception with required characteristic of the patient’s EHI and knowledge of the modifications to the way it is displayed § 171.201(c)(1) determination itself. individualized determination of risk of and phrased in the finalized regulation The finalized text of § 171.201(c)(1) harm associated with particular text in comparison to the Proposed also differs from the proposed access(es), exchange(s), or use(s) of that Rule. If its other conditions are also met, regulation text specific to EHI. the finalized Preventing Harm individualized determinations of risk in Exception will apply to a practice an explicitly stating the requirement that As finalized, § 171.201(d) differs from actor reasonably believes will the licensed health care professional the proposed policy in that it does not substantially reduce a risk of harm making the determination must have a uniformly require that the risk consistent with the sub-paragraph of current or prior clinician-patient determined on an individualized basis § 171.201(d), as finalized, that applies to relationship with the patient whose EHI be to life or physical safety of the the specific access, exchange, or use, is affected by the determination. For patient or another person in all where the risk of harm is determined on purposes of § 171.201—as we discussed circumstances. Instead, through an individualized basis in the exercise in the Proposed Rule’s preamble, and specified cross-references to the sub- of professional judgment by a licensed above in this preamble—we believe the paragraphs of § 164.524(a)(3), the health care professional who has a broad discretion afforded to licensed finalized § 171.201(d) type of harm current or prior clinician-patient health care professionals to make condition uses the same harm standards relationship with the patient whose EHI individualized determinations of risks for the circumstances where both the is affected by the determination. In of harm in the exercise of professional Preventing Harm Exception and comparison to the proposed text of judgment is appropriate in the context § 164.524(a)(3) apply. Also through § 171.201 (84 FR 7602), we have of the expectation that a licensed health cross-references, the type of harm reorganized the regulation text in care professional with a clinician- condition applies the § 164.524(a)(3) response to comments requesting our patient relationship to a patient has the harm standards in circumstances similar regulatory text, in general, be easier to opportunity to have knowledge of the to those in which § 164.524(a)(3) applies use for purposes such as understanding patient and their individual but where only § 171.201 actually how the conditions of the exception circumstances that is not generally applies. The finalized § 171.201(d) does relate to one another and how they available outside the context of a not cross-reference § 164.502(g)(5)(i), apply to practices used in particular clinician-patient relationship. We but it is constructed so that it does types of circumstances. We have left the believe that explicitly stating in apply to practices interfering with a potential sources of risk of harm in a § 171.201(c)(1) the requirement for a personal representative or other legal single paragraph (finalized § 171.201(c)), clinician-patient relationship representative’s access to a patient’s EHI but separated them from the reasonable accomplishes two purposes: First, it consistent with an actor declining to belief condition paragraph (finalized ensures that this is immediately clear on recognize such a representative on the § 171.201(a)). The sources of risk of the face of the finalized regulation text same bases as a HIPAA covered entity harm are also, as discussed above, that only determinations made by could elect not to recognize a person as presented in two sub-paragraphs in the licensed health care professionals who an individual’s personal representative finalized text of § 171.201(c) (type of have or have had a clinician-patient consistent with § 164.502(g)(5)(i). In harm) instead of being split across three relationship with the patient will be order to retain a clear, consistent set of

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00199 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25840 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

harm standards throughout the review rights in circumstances where will ‘‘directly and substantially’’ 160 § 171.201 type of harm condition, the individualized determination of risk reduce the likelihood of harm to a however, we note that where a HIPAA of harm is or includes a determination patient or another person. As discussed covered entity elects not to recognize an that recognizing that same person as the in the Proposed Rule and above, the individual’s personal representative patient’s representative, or providing type of risk and the potential harm must consistent with § 164.502(g)(5)(ii), the specific information to that same also be cognizable under this exception Preventing Harm Exception would not recognized representative, would pose a (84 FR 7525 and 7526). apply.159 risk of cognizable harm. In a Under § 171.201 as proposed, an actor Consistent with the HIPAA Privacy circumstance where the actor has a would be able to demonstrate having Rule, a decision not to provide access, reasonable belief that such disclosure satisfied the condition of reasonable exchange, or use of EHI on the basis could create or increase a risk of harm belief that a practice will reduce the finalized in § 171.201(c)(1) is subject to to the patient, this exception does not likelihood of harm (‘‘reasonable belief the rights the individual patient whose require the candid disclosure to a condition’’) through a qualifying EHI is affected may be afforded by known, suspected, or potential abuser of organizational policy (proposed applicable law to have the the rationale for use of particular § 171.201(b)) and/or a qualifying determination reviewed and potentially practices, or even the precise practices, individualized determination (proposed reversed. While any such determination interfering with that representative’s § 171.201(c)). We discuss below the reviews may be pending, application of access, exchange, or use of EHI. We details of our proposal, respond to practices interfering with the patient’s would, however, generally expect actors comments, and summarize finalized access, exchange, or use of their EHI to be as candid with the patient per se policy specific to each of these based on an individualized as is clinically appropriate and safely approaches to demonstrating the determination by a licensed health care practicable in their individualized required reasonable belief that a practice 161 professional (§ 171.201(c)) that are circumstances. will substantially reduce a risk of harm cognizable under this exception. otherwise compliant with the Where an actor lacks the technical conditions of § 171.201 as a whole will capability to sequester only that EHI the Practices Implemented Based on an be considered to be covered by the actor reasonably believes poses a risk of Organizational Policy exception. cognizable harm from other data for Upon becoming aware of a reversal of In the Proposed Rule (84 FR 7525), we which the actor does not pose such risk the determination on which the actor’s proposed that to qualify for this of harm, this lack of segmentation required reasonable belief was based, exception, an actor must have had a capability would not render § 171.201 whether as a result of a review reasonable belief that the practice or applicable to practices likely to, or that requested by the patient or other practices will directly and substantially do, interfere with access, exchange, or reduce the likelihood of harm to a processes, the actor’s continued use of the other data. Rather, where patient or another person and that the application of practices based on the such lack of segmentation capabilities type of risk must also be cognizable original determination would no longer renders the actor unable to support an under this exception. We proposed that be consistent with the conditions of otherwise legally permissible access, an actor could meet this condition in § 171.201. Likewise, upon becoming exchange, or use of EHI, the actor two ways: Through a ‘‘qualifying aware of a revision of the determination should reference the Content and organizational policy’’ (§ 171.201(b) as on which the actor’s required reasonable Manner Exception (§ 171.301) or the proposed) or through a ‘‘qualifying belief was originally based, whether the Infeasibility Exception (§ 171.204). individualized finding’’ (§ 171.201(c) as revision resulted from a review proposed). We stated in the Proposed requested by the patient or other Licensed health care professionals Rule that we anticipate that in most processes, practices applied to the have discretion to determine how to use instances where § 171.201 would apply, patient’s EHI after the revision is made their EHRs and/or other records kept in the actor would demonstrate that the will need to comply with the conditions their ordinary course of business to practices it engaged in were consistent of § 171.201 in light of the revised capture and preserve documentation of with an organizational policy that was determination in order for the practice and relevant to their individualized objectively reasonable and no broader to continue to be covered under determinations. Information relevant to than necessary for the type of patient § 171.201. determinations would include the facts safety risks at issue. We also noted in For the specific purposes of § 171.201, or circumstances that substantially the Proposed Rule that within any type the rights to obtain review or informed each determination, and any of actor defined in § 171.102, reconsideration of a provider’s other decision-making information that organizations may vary significantly in individualized determination of risk of the professional may otherwise have structure, size, and resources. Further, harm reside with the patient whose EHI difficulty recalling or reconstructing if even when an organizational policy is affected. The rights in many cases later asked to explain how or why they exists, it may not anticipate all of the may be exercised on the patient’s behalf reached their individualized potential risks of harm that could arise by the patient’s personal or other legal determination in a particular case. in real-world clinical or production representative. However, it may not be Practices Implemented Based on an appropriate, or feasible, for the patient’s Organizational Policy or on 160 As, and for the reasons, discussed earlier in representative to exercise the patient’s Determination Specific to the Facts and this section of this preamble, we have removed Circumstances ‘‘directly and’’ from the belief standard finalized in 159 Because § 164.502(g)(5)(ii) currently applies a § 171.201(a). standard not of harm but of determination by the 161 As, and for the reasons, discussed earlier in covered entity that recognizing a person as personal To qualify for the Preventing Harm this section of this preamble, the belief standard representative is not in the best interest of the Exception, we proposed that an actor finalized in § 171.201(a) requires the actor believe individual, we have determined it is more would be required to have, while the practice will ‘‘substantially reduce’’ a risk of appropriate to address these circumstances in engaging in the practice(s) for which harm to a patient or another natural person that context of the exception for practices promoting would otherwise arise from the access, exchange, or privacy of EHI, finalized in § 171.202 and discussed application of the exception is claimed, use of electronic health information affected by the in Section VIII.D.1.b of this final rule preamble. a reasonable belief that the practice(s) practice.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00200 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25841

environments of health IT. Thus, we a framework within which they can rulemaking process. We will continue proposed in § 171.201(c) (84 FR 7602) develop or refine their practices in working to engage with the stakeholder that in lieu of demonstrating that a assurance that practices meeting the communities to promote understanding practice conformed to a policy that met conditions in § 171.201 are excepted and foster compliance with the the conditions described in proposed from the definition of information information blocking provision amongst § 171.201(b) and the Proposed Rule blocking finalized in § 171.103. At the all actors within the definitions in preamble at 84 FR 7525, the actor could same time, implementing such an § 171.102. We also believe that in many justify the practice(s) directly by making exception without appropriate cases voluntary groups with relevant a finding in each case, based on the conditions could have the unintended expertise, such as professional societies particularized facts and circumstances. and undesirable effect of excusing and provider organizations, may be in We proposed that where the proposed conduct that would more appropriately the best position to develop resources § 171.201(b) (84 FR 7602) would apply, remain within the definition of tailored to the particular needs and an actor’s policy would need to be: information blocking. preferences of specific segments or • In writing; Therefore, in § 171.201, we have communities within any given type of • developed with meaningful input finalized conditions that strike a actor. from clinical, technical, and other practical balance between minimizing Comments. Some commenters stating appropriate staff or others who have burdens on actors and ensuring that the that developing new or revised expertise or insight relevant to the risk interests of patients in the access, organizational policies and training staff of harm that the policy addresses; exchange, and use of their EHI are in the policies requires time • implemented in a consistent and adequately protected. These conditions recommended that we establish a grace non-discriminatory manner; and are, in comparison to the Proposed Rule, period before organizations’ policies • no broader than necessary to more granularly and durably aligned and actual practices must fully comply mitigate the risk of harm. with relevant HIPAA right of access with § 171.201 conditions in order to be We stated that the proposed condition provisions (§ 164.526(a)(3)) and this recognized as reasonable and necessary would not be met if, for example, a alignment reduces complexity. under § 171.201. hospital imposed top-down information We have revised the way the Response. This concern is not unique sharing policies or workflows regulation text is presented and phrased to § 171.201. Commenters also raised established by the hospital’s EHR so that it is easier to understand what this concern in the context of developer and approved by hospital is required in order for a practice to be information blocking in general. As we administrators without meaningful excepted from the definition of stated in section VIII.B.3 of this input from the medical staff, IT information blocking under this preamble, we thank commenters for department, and front-line clinicians exception. Moreover, we have avoided their input. Comments related to the who are in the best position to gauge specifying particular or unique forms, overall timing of information blocking how effective it will be at mitigating methods, or content of documentation enforcement have been shared with patient safety risks. for purposes of this exception. We OIG. We emphasize that individuals and Comments. Commenters expressed believe the flexibility this offers actors entities subject to the information concern that information blocking to determine the most efficient approach blocking provision must comply with policy and its interaction with other to documenting their practices and the ONC final rule as of the compliance applicable laws and regulations, such as determinations relevant to this date of the information blocking section the HIPAA Rules, are complex and that exception enables them to achieve and of this final rule (45 CFR part 171). We there will be costs and other burden document satisfaction of the exception’s have finalized a compliance date for 45 associated with understanding how the condition with the lowest practicable CFR part 171 as a whole that is six policies affect an actor’s daily burden. months after the date this final rule is operations. Commenters also expressed Comments. A number of commenters published in the Federal Register. concern that it would be too noted that there will be burden OIG and ONC are coordinating timing burdensome to be required to associated with developing or revising of the compliance date of the demonstrate, in any of the ways we organizational policies and training staff information blocking section of this proposed, that they have a reasonable so they can use this exception in final rule (45 CFR part 171) and the start belief that practices would reduce a risk compliance with its conditions. Several of information blocking enforcement. of cognizable harm. of these commenters suggested we We are providing the following Response. We understand that provide additional guidance and information on timing for actors. complexity can increase difficulty in informational resources, in this final Enforcement of information blocking understanding and complying with any rule or otherwise, to help actors develop CMPs in section 3022(b)(2)(A) of the regulation. We also understand that the their policies and staff training. Some PHSA will not begin until established interaction between the HIPAA Rules commenters advocated that we develop by future notice and comment and the information blocking provision templates or models that actors could rulemaking by OIG. As a result, actors is inherently complex. However, use to more efficiently develop policies would not be subject to penalties until without an exception from the consistent with the conditions for CMP rules are final. At a minimum, the information blocking definition for applicability of this exception. timeframe for enforcement would not practices appropriately tailored to Response. We appreciate the feedback begin sooner than the compliance date reduce risks of harm, we believe actors and do recognize that developing or of the information blocking section of would be subject to the greater burden revising internal policies and this final rule (45 CFR part 171) and will of needing to craft practices that avoid procedures when compliance depend on when the CMP rules are violating the information blocking requirements change due to changes in final. Discretion will be exercised such provision without also making EHI law requires some effort. While that conduct that occurs before that time available for access, exchange, or use in recognizing the utility of the types of will not be subject to information circumstances where that puts patients resource materials suggested by blocking CMP. or other natural persons at risk of harm. commenters, we believe they are best Specific to § 171.201, as discussed This exception’s conditions give actors developed and provided outside the above in response to other comments

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00201 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25842 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

received specific to the Preventing Harm release of results in general, with an not prohibit making particular Exception, we have applied automatic release at the end of a time information available to a patient § 164.524(a)(3) harm standards under period determined by the organizational electronically before it has been § 171.201 to circumstances where both policy in place to ensure that patients conveyed in another way, deference sections of 45 CFR would apply, and to can consistently access their should generally be afforded to patients’ circumstances where only § 171.201 information within the timeframe right to choose whether to access their applies but that are similar in significant targeted by relevant measures under the data as soon as it is available or wait for respects to circumstances where CMS Promoting Interoperability the provider to contact them to discuss § 164.524(a)(3) applies. In substantial Programs. Commenters requested we their results. Only in specific part because of this alignment, we do clarify whether such practices would be circumstances do we believe delaying not believe there is a need to delay the recognized under § 171.201 or that we patients’ access to their health applicability of any of the conditions for recognize such current organizational information so that providers retain full a practice to be excepted under policies and practices as excepted from control over when and how it is § 171.201 from the definition of the definition of information blocking. communicated could be both necessary information blocking in § 171.103. Response. While we recognize the and reasonable for purposes of Actors who are also HIPAA covered importance of effective clinician-patient substantially reducing a risk of harm entities or business associates should relationships and patient cognizable under § 171.201(d) (as already have policies in place consistent communications, we are not persuaded finalized). Circumstances where with the HIPAA Privacy Rule, including that routinely time-delaying the § 171.201 would apply to such delay are but not limited to § 164.524(a)(3). These availability of broad classes of EHI those where a licensed health care actors and their staff members should be should be recognized as excepted from professional has made an individualized well versed in these policies and the information blocking definition determination of risk in the exercise of practices. Where § 164.524(a)(3) would under this exception. Consistent with professional judgment consistent with not apply but § 171.201(d)(3) or (4) § 171.201(d)(3) as finalized, the harm of § 171.201(c)(1), whether the actor would apply, we believe using the same, which a practice must reduce a risk implementing the practice is the familiar standard for the risk that the must, where the practice interferes with licensed health care professional acting actor must believe their practice would the patient’s access to their own EHI, be directly on their own determination or reduce as would apply to one that could justify denying the another actor implementing the delay in § 164.524(a)(3)(i) should facilitate patient’s right of access to PHI under reliance on that determination. An actor efficient updates to organizational § 164.524(a)(3). Currently, could choose to demonstrate the policies and streamline any staff § 164.524(a)(3)(i) requires that for a reasonable belief required by training that may be indicated specific covered entity to deny an individual § 171.201(a) through an organizational to § 171.201. We also note that the access to their PHI within the policy (§ 171.201(f)(1)) with which the finalized Preventing Harm Exception designated record set, the disclosure of practice is consistent, or based on a also provides, in § 171.201(f)(2), for that PHI must be reasonably likely to determination based on facts and coverage of practices implemented in endanger the life or physical safety of 162 circumstances known or reasonably absence of an applicable organizational the patient or another person. No believed by the actor at the time the policy or where existing organizational commenter cited evidence that routinely determination was made and while the policy does not address the particular delaying EHI availability to patients in practice remains in use (§ 171.201(f)(2)), practice in the particularized the interest of fostering clinician-patient to rely on a determination consistent circumstances. Moreover, although we relationships substantially reduces with § 171.201(c)(1). encourage actors to voluntarily conform danger to life or physical safety of their practices to the conditions of an patients or other persons that would Comments. Health care professionals exception suited to the practice and its otherwise routinely arise from patients’ commented that clinical experience purpose, an actor’s choice to do so choosing to access the information as indicates a systematic and substantial simply provides them an enhanced level soon as it is finalized. risk that releasing some patient data of assurance that the practices do not Moreover, we are independently through a patient portal or API without meet the definition of information aware, and some comment submissions first communicating the particular blocking. However, failure to meet an confirmed, that it is not uncommon to results or diagnosis with the patient in exception does not necessarily mean a automatically release lab and other a more interactive venue would pose practice meets the definition of findings to patients electronically risks of substantial harm to patients. information blocking. We reiterate, if regardless of whether a clinician has One example commenters specifically subject to an investigation by HHS, each seen the information or discussed it cited was genetic testing results practice that implicates the information with the patient before the patient can indicating a high risk of developing a blocking provision would be analyzed choose to access it electronically. We neurodegenerative disease for which on a case-by-case basis. presume these types of automatic there is no effective treatment or cure. Comments. Several commenters releases would not be the case if Commenters recommended that we indicated that providers’ current patients’ accessing their information on define this exception to allowing delay organizational policies call for practices a timeframe that is more of their own of the electronic release of such genetic that delay the release of laboratory choosing routinely posed a risk to the testing results, as a matter of results so that the patient’s clinician has life or physical safety of these patients organizational policy, to ensure patients an opportunity to review the results or other natural persons. Thus, we and their families are not exposed to before potentially needing to respond to believe that where applicable law does this information without appropriate patient questions, or has an opportunity counseling and context. One comment to communicate the results to the 162 Note that for purposes of § 164.524(a)(3)(i), indicated that delivery by the clinician patient in a way that builds the ‘‘individual’’ is defined in § 160.103, but for of the combined results, counseling, and purposes of § 171.201 an actor must reasonably clinician-patient relationship. Some believe a practice will substantially reduce a risk of context is clinically appropriate and commenters indicated their standard cognizable harm to patient(s) or other natural consistent with the conclusions of practice is to automatically time-delay person(s). relevant research.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00202 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25843

Response. To satisfy the conditions of have redesignated this paragraph from need to reasonably conclude, based on § 171.201, and actor would have to (b) to (f)(1), and redesignated its those particularized facts and demonstrate that they held a reasonable proposed sub-paragraphs from (1) circumstances and his/her expertise and belief that delaying availability of through (4) to (i) through (iv). We have best professional judgment, that the information until the information can be in comparison to the main paragraph practice was necessary, and no broader delivered in combination with language of the proposed § 171.201(b) than necessary, to mitigate the risk of appropriate counseling and context in modified the phrasing of the finalized harm to a patient or other persons. We an interactive venue will substantially paragraph (f) so that § 171.201 as further proposed that a licensed health reduce a risk of harm cognizable under finalized is more immediately clear on care professional’s independent and this exception. An actor could its face that what is finalized in individualized judgment about the accomplish such demonstration through § 171.201(f) is a condition for practices safety of the actor’s patients or other showing the practice is consistent with to meet the exception, and that persons would be entitled to substantial either an organizational policy meeting paragraph (f) can be satisfied by meeting deference under this proposed § 171.201(f)(1) or a determination based either subparagraph (1) or (2). exception. So long as the clinician on facts and circumstances known or Practices applied based on an reasonably believed by the actor at the organization policy to rely on considered the relevant facts and time the determination was made and individualized determinations of risk of determined that, under the particular while the practice remains in use harm consistent with § 171.201(c)(1) circumstances, the practice was meeting § 171.201(f)(2). However, for a would be covered under § 171.201 to the necessary to protect the safety of the practice likely to, or that does in fact, extent they otherwise meets its clinician’s patient or another natural interfere with the patient’s access to conditions. Neither an organizational person, we would not second-guess the their own EHI (§ 171.201(d)(3)), the policy (§ 171.201(f)(1)), nor a clinician’s professional judgment. To actor implementing these practices must determination based on facts and provide further clarity on this point, we demonstrate a reasonable belief that the circumstances known or reasonably provided an illustrative example in the practice will substantially reduce a risk believed by the actor at the time the preamble to the proposed rule (see 84 of harm to the life or physical safety of determination was made and while the FR 7525). the patient. The clinician who orders practice remains in use ((§ 171.201(f)(2)) Comments. Commenters requested testing of the sort referenced in the would be required to routinely evaluate that we clarify, provide guidance, or comment would, we presume, do so in or otherwise assess the licensed health establish specifications for the care professional’s exercise of the context of a clinician-patient documentation necessary to substantiate professional judgment in order for relationship. In the context of that applicability of the Preventing Harm relationship, a licensed health care practices implemented in reliance on the professional’s § 171.201(c)(1) Exception based on qualifying professional should be well positioned determinations particularized to specific to make determinations consistent with determination to be meet the conditions of § 171.201. facts and circumstances. Some § 171.201(c)(1) as to specifically when commenters indicated that such their patients, or other particular natural Practices Implemented Based on a specificity or guidance is needed to persons, would face a risk of harm Determination Specific to the Facts and avoid imposing on actors such as health cognizable under § 171.201(d)(3)—or Circumstances care providers and HINs/HIEs excess § 171.201(d)(1) or (2) if or as may be burden associated with documentation applicable—if the access, exchange, or As discussed in the Proposed Rule, in the absence of such guidance or use of a particular testing result or we recognize that some actors (such as small health care providers and small diagnosis were to be released specification. HINs/HIEs) may not have electronically before it could be Response. We appreciate these comprehensive and formal policies explained and contextualized by an commenters highlighting that the governing all aspects of EHI and patient appropriately skilled professional, such potential for uncertainty or confusion safety. Additionally, even if an as a clinician or a health educator, in about what is minimally necessary to organizational policy exists, it may not real time. demonstrate satisfaction of a new policy anticipate all of the potential risks of can often lead to capturing and retaining Summary of Finalized Policy: Practices harm that could arise in real-world a wide array of information just in case Implemented Based on an clinical or production environments of it may be needed or useful later. We Organizational Policy health IT. In these circumstances, in lieu of demonstrating that a practice have clarified the way in which all of We have finalized that to demonstrate the conditions in § 171.201 are stated the reasonable belief required by conformed to the actor’s policies and that the policies met the conditions and organized within the section. We § 171.201(a) based on an organizational also note here that an actor does not policy, the policy must: proposed in § 171.201(b), we proposed that the actor could justify its use of need to draft for each determination (i) Be in writing; consistent with § 171.201(f)(2) a (ii) Be based on relevant clinical, particular practices by making a finding comprehensive defense of their technical, and other appropriate in each case, based on the particularized findings. We believe the finalized expertise; facts and circumstances, that the (iii) Be implemented in a consistent practice is necessary and no broader statement of the condition, reinforced and non-discriminatory manner; than necessary to mitigate the risk of by this preamble discussion, provides (iv) Conform each practice to the harm. To do so, we proposed that the certainty that we do not intend or conditions in paragraphs (a) and (b) of actor would need to show that the expect actors to create new records this section, as well as the conditions of practices were approved on a case-by- systems or types, or to create or retain paragraphs (c) through (e) of this section case basis by an individual with direct duplicate information or documentation applicable to the practice and its use. knowledge of the relevant facts and across their current medical and other We have modified the regulation text circumstances and who had relevant business records. Ultimately, it is the finalized in § 171.201(f)(1) consistent clinical, technical, or other appropriate actor’s responsibility to demonstrate with other revisions to § 171.201. We expertise. Such an individual would they met the conditions of an exception.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00203 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25844 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

Summary of Finalized Policy: Practices We also revised in finalized proposed regulation text in § 171.202. Implemented Based on a Determination § 171.201(e), in comparison with the We noted that any interference practice Specific to the Facts and Circumstances proposed § 171.201(a)(3), the wording of that an actor is engaged in to protect the the condition finalized in § 171.201(e) privacy of an individual’s EHI must be We have finalized the substance of in comparison to the wording of this consistent with applicable laws and this condition as proposed, with condition as proposed in 171.201(a)(3) regulations related to health information modifications to the regulation text. We for two reasons. First, the wording has privacy, including the HIPAA Privacy have also reorganized § 171.201 so that been revised to fit its placement within Rule, the HITECH Act, 42 CFR part 2, it is easier to read and understand. We the finalized section. Second, the and State laws. We emphasized that this have redesignated this paragraph from wording has been revised to more exception to the information blocking (c) to (f), and broken it into clearly and completely state the sources provision does not alter an actor’s subparagraphs. We have in comparison of the review rights that must be obligation to comply with applicable to the main paragraph language of the afforded, if applicable. We note that laws (84 FR 7526). proposed § 171.201(c) modified the such review rights will be afforded by We noted that this exception is phrasing of the finalized paragraph (f) so § 164.524(a)(4) in the circumstances necessary to support basic trust and that § 171.201 as finalized is more where both § 164.524(a)(3) and confidence in health IT infrastructure. immediately clear on its face that what § 171.201 apply. However, rights that Without this exception, there would be is finalized in § 171.201(f)(2) is a means must be honored to meet the conditions a significant risk that actors would share to demonstrate a practice implemented of § 171.201 are not limited to those EHI in inappropriate circumstances, in absence of an applicable, or perhaps afforded by § 164.24(a)(4) or to such as when an individual has taken any, organizational policy nevertheless circumstances where § 164.524 applies affirmative steps to request that the EHI meets the conditions to be exempted in addition to § 171.201. Rights of not be shared under certain conditions under § 171.201 from the definition of review of an individualized or when an actor has been unable to information blocking in § 171.103. determination of risk of harm verify a requester’s identity before We have separated from both the (§ 171.201(c)(1)) might also be afforded sharing EHI. requirements applicable to by Federal, State, or tribal law We explained that this proposed individualized determinations of risk applicable in the particular exception was structured with discrete (finalized in the type of risk condition circumstances. ‘‘sub-exceptions.’’ An actor’s practice in § 171.201(c)(1)) and the requirements We do not believe it is necessary to must qualify for a sub-exception to be applicable to practices implemented expressly state in the regulation text that covered by the exception. We noted that based on organizational policy we interpret regulations promulgated the sub-exceptions were, to a large (§ 171.201(f)(1)) or to practices based on such laws, and that have the extent, crafted to closely mirror privacy- implemented pursuant to a force and effect of law on individuals protective practices that are recognized determination based on the facts and and entities they regulate, to be within under State and Federal privacy laws. In circumstances (§ 171.201(f)(2)) the the meaning of ‘‘law’’ for purposes of this way, the privacy sub-exceptions to patient review rights condition § 171.201(e). However, we expressly the information blocking provision expressed in subparagraph (a)(3) of the state this here in order to provide the recognize as reasonable and necessary those practices that are engaged in by proposed text of § 171.201 (84 FR 7602). type of assurance we believe many actors to be consistent with existing We have finalized the patient review commenters were seeking when stating laws, provided that certain conditions rights condition in § 171.201(e) instead in their comment submissions requests or recommendations for additional are met. of the finalized (f) because it applies We proposed four sub-exceptions that equally to practices implemented based guidance in the final rule. In order for the practice(s) to satisfy the condition in address the following privacy protective on an organizational policy and by practices: (1) Not providing access, practices implemented based on § 171.201(e), where otherwise applicable law affords a patient right(s) exchange, or use of EHI when a State or determinations based on facts and to request review of individualized Federal law requires that a precondition circumstances, in parallel to the other determinations of risk of harm be satisfied before an actor provides conditions for a practice to be excepted associated with the patient’s access, access, exchange, or use of EHI, and the under § 171.201 from the definition of exchange, or use of their EHI, the actor’s precondition is not satisfied (proposed information blocking in § 171.103. practice(s) be implemented in a manner in § 171.202(b)); (2) not providing In the finalized patient review rights consistent with those rights—regardless access, exchange, or use of EHI when condition (§ 171.201(e)), in comparison of which specific law(s) afford the rights the actor is a health IT developer of with proposed § 171.201(a)(3) (84 FR applicable in the particular certified health IT that is not covered by 7602), we have revised the wording in circumstances. the HIPAA Privacy Rule in respect to a which we state the condition for practice (proposed in § 171.202(c)); (3) a honoring any rights that applicable law b. Privacy Exception—When will an covered entity, or a business associate may afford patients to have these actor’s practice of not fulfilling a request on behalf of a covered entity, denying individualized determinations reviewed to access, exchange, or use electronic an individual’s request to access to their and potentially reversed. The condition health information in order to protect an electronic protected health information finalized in § 171.201(e) is that where individual’s privacy not be considered (ePHI) in the circumstances provided in the risk of harm is consistent with information blocking? 45 CFR 164.524(a)(1)(2) or (3) (proposed paragraph (c)(1) of this section, the actor We proposed to establish an in § 171.202(d)); and (4) not providing must implement its practices in a exception to the information blocking access, exchange, or use of EHI pursuant manner consistent with any rights the provision for practices that are to an individual’s request, in certain individual patient whose EHI is affected reasonable and necessary to protect the situations (proposed in § 171.202(e)) (84 may have under § 164.524(a)(4) of this privacy of an individual’s EHI, provided FR 7526). title, or any Federal, State, or tribal law, certain conditions are met (84 FR 7526). We proposed that an actor would to have the determination reviewed and The exception and corresponding need to satisfy at least one sub- potentially reversed. conditions were set forth in the exception with respect to a purportedly

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00204 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25845

privacy-protective practice that Finally, we noted that the term care decisions in emergency situations interferes with access, exchange, or use ‘‘individual’’ is defined by the HIPAA even if that family member may not be of EHI to not be subject to the Rules at 45 CFR 160.103. Separately, the ‘‘legal representative’’ or ‘‘personal information blocking provision. Each under the information blocking representative’’ of the patient. proposed sub-exception has conditions enforcement provision, we noted that We noted that we adopted this that must be met in order for an actor’s the term ‘‘individual’’ is used to refer to specialized usage to ensure that the practice to qualify for protection under actors that are health IT developers of Privacy Exception extends protection to the sub-exception (84 FR 7526). certified health IT, HINs, or HIEs (see information about, and respects the section 3022(b)(2)(A) of the PHSA). We privacy preferences of, all individuals, Modification clarified that for purposes of this not only those individuals whose EHI is We have changed the title of this exception (and only this exception), we protected as ePHI by HIPAA covered exception from ‘‘Exception—Promoting used neither of these definitions. entities and business associates (84 FR the privacy of electronic health Instead, the term ‘‘individual’’ 7526 and 7527). information’’ in the Proposed Rule (84 encompassed any or all of the following: Interaction Between Information FR 7602) to ‘‘Privacy Exception—When (1) An individual defined by 45 CFR Blocking, the Exception for Promoting will an actor’s practice of not fulfilling 160.103; (2) any other natural person the Privacy of EHI, and the HIPAA a request to access, exchange, or use who is the subject of EHI that is being Privacy Rule accessed, exchanged or used; (3) a electronic health information in order to We stated in the Proposed Rule that protect an individual’s privacy not be person who legally acts on behalf of a person described in (1) or (2), including we consulted extensively with the HHS considered information blocking?’’ Office for Civil Rights (OCR), which Throughout this final rule preamble, we as a personal representative, in accordance with 45 CFR 164.502(g); or enforces the HIPAA Privacy, Security use ‘‘Privacy Exception’’ as a short form and Breach Notification Rules, in of this title, for ease of reference. As (4) a person who is a legal representative of and can make health developing proposals to advance our stated in Section VIII.D of this final rule shared goals of preventing information preamble, we have changed the titles of care decisions on behalf of any person described in (1) or (2); or (5) an executor blocking for nefarious or self-interested all of the exceptions to questions to purposes while maintaining and improve clarity. We have edited the or administrator or other person having authority to act on behalf of the upholding existing privacy rights and wording of the introductory text in protections for individuals. We noted § 171.202 as finalized, in comparison to deceased person described in (1) or (2) or the individual’s estate under State or that the proposed exception for that proposed (84 FR 7602) so that it is promoting the privacy of EHI (also consistent with the finalized title of other law. We clarified that (2) varies from (1) referred to as the ‘‘privacy exception’’) § 171.202. We believe these conforming because there could be individuals who operates in a manner consistent with the changes in wording of the introductory could be the subject of EHI that is being framework of the HIPAA Privacy Rule. text also improve clarity in this section. accessed, exchanged, or used under (2), We explained that we designed the sub- Specific Terminology Used for the but who would not be the subject of PHI exceptions to ensure that individual Purposes of This Proposed Exception under (1). For example, an actor which privacy rights are not diminished as a is not a covered entity or business consequence of the information We noted that the proposed exception associate as defined under HIPAA such blocking provision, and to ensure that used certain terms that are defined by as a health IT developer of certified the information blocking provision does the HIPAA Rules 163 but that, for health IT may access, exchange or use not require the use or disclosure of EHI purposes of the exception, may have a a patient’s electronic health in a way that would not be permitted broader meaning in the context of the information; however this ‘‘health under the HIPAA Privacy Rule. We information blocking provision and its information’’ would not meet the emphasized that our intent was that the implementing regulations as set forth in definition of PHI, but nonetheless, information blocking provision would the Proposed Rule. We explained that, would be subject to this regulation. not conflict with the HIPAA Privacy in general, the terms ‘‘access,’’ We also clarified that (3) encompasses Rule. We noted that the sub-exception ‘‘exchange,’’ and ‘‘use’’ have the a person with legal authority to act on proposed in § 171.202(d) reflects a meaning in proposed § 171.102. behalf of the individual, which includes policy that an actor’s denial of access to However, we noted that in some a person who is a personal an individual consistent with the instances we referred to ‘‘use’’ in the representative as defined under the limited conditions for such denials that context of a disclosure or use of ePHI HIPAA Privacy Rule. We explained that are described in the HIPAA Privacy under the HIPAA Privacy Rule, in we included the component of legal Rule at 45 CFR 164.524(a)(1)(2) and (3), which case we explicitly stated that the authority to act in (3) because the is reasonable under the circumstances term ‘‘use’’ had the meaning defined in HIPAA Privacy Rule gives rights to (84 FR 7527). 45 CFR 160.103. Similarly, we referred parents or legal guardians in certain We also noted that the information in a few cases to an individual’s right of circumstances where they are not the blocking provision may operate to access under 45 CFR 164.524, in which ‘‘personal representative’’ for their require that actors provide access, case the term ‘‘access’’ should be child(ren). For instance, a non-custodial exchange, or use of EHI in situations understood in that HIPAA Privacy Rule parent who has requested a minor that the HIPAA Rules would not require context. We emphasized that, for child’s medical records under a court- access of similar information. This is purposes of section 3022 of the PHSA, ordered divorce decree may have legal because the HIPAA Privacy Rule however, the term ‘‘access’’ includes, authority to act on behalf of the child permits, but does not require, covered but is broader than, an individual’s even if he or she is not the child’s entities to disclose ePHI in most access to their PHI as provided for by ‘‘personal representative.’’ Further, we circumstances. We explained that the the HIPAA Privacy Rule (84 FR 7526). noted that in limited circumstances and information blocking provision, on the if permitted under State law, a family other hand, requires that an actor 163 45 CFR part 160 and subparts A, C, and E of member may have legal authority to act provide access to, exchange, or use of part 164. on behalf of a patient to make health EHI unless they are prohibited from

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00205 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25846 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

doing so under an existing law or are access, exchange, or use is required by privacy restrictions for the actor that covered by one of the exceptions. As an law (84 FR 7527). may define conditions or limits on what illustration, we noted that the HIPAA For these reasons, we proposed that the actor may do because of those Privacy Rule permits health care the sub-exception in § 171.202(e) would contractual restrictions. In addition, providers to exchange ePHI for generally permit an actor to give effect some commenters suggested that treatment purposes but does not require to individuals’ expressed privacy contractual restrictions should be them to do so. Under the information preferences, including their desire not treated similarly to State and Federal blocking provision, unless an exception to permit access, exchange, or use of privacy laws under the Privacy to information blocking applies, or the their EHI. At the same time, however, Exception. interference is required by law, a we emphasized that the Privacy Response. Please see section VIII.C.6.a primary care provider would be Exception must be tailored to ensure (Prevention, Material Discouragement, required to exchange ePHI with a that protection of an individual’s and Other Interference) above regarding specialist who requests it to treat an privacy is not used as a pretext for interference that discusses contracts individual who was a common patient information blocking. Accordingly, we including business associate agreements of the provider and the specialist, even proposed that this exception would be where this is discussed in depth. subject to strict conditions (84 FR 7527). if the primary care provider offered Definitions in This Exception patient care services in competition Privacy Practices Required by Law with the specialist’s practice, or would As noted above, we stated in the usually refer its patients to another We stated in the Proposed Rule that Proposed Rule that we consulted specialist due to an existing business because the information blocking extensively with the HHS Office for relationship (84 FR 7527). provision excludes from the definition Civil Rights (OCR), which enforces the of information blocking practices that HIPAA Privacy, Security and Breach Promoting Patient Privacy Rights are required by law (section 3022(a)(1) Notification Rules, in developing We stated that the information of the PHSA), privacy-protective proposals to advance our shared goals of blocking provision would not require practices that are required by law do not preventing information blocking for that actors provide access, exchange, or implicate the information blocking nefarious or self-interested purposes use of EHI in a manner that is not provision and do not require coverage while maintaining and upholding permitted under the HIPAA Privacy from an exception. We noted that existing privacy rights and protections Rule or other laws. As such, the privacy- practices that are ‘‘required by law’’ can for individuals (84 FR 7527). protective controls existing under the be distinguished from other practices This Privacy Exception operates in a HIPAA Rules would not be weakened that an actor engages in pursuant to a manner consistent with the framework by the information blocking provision. law, but which are not ‘‘required by of the HIPAA Rules. We have finalized Moreover, we described that we law.’’ Such laws are typically framed in the sub-exceptions to ensure that structured the Privacy Exception to a way that permit an access, exchange individual privacy rights are not ensure that actors can engage in or use of health information to be made diminished as a consequence of the reasonable and necessary practices that only if specific preconditions are information blocking provision, and to advance the privacy interests of satisfied but do not expressly require ensure that the information blocking individuals (84 FR 7527). that the actor engage in a practice that provision does not require the use or We explained that unless required by interferes with access, exchange, or use disclosure of EHI in a way that would law, actors should not be compelled to of EHI. For example, we noted that the not be permitted under the HIPAA share EHI against patients’ expectations HIPAA Privacy Rule provides that a Privacy Rule. We emphasize that our under applicable law or without covered entity may use or disclose PHI intent is that the information blocking adequate safeguards out of a concern in certain circumstances where the provision would not conflict with the that restricting the access, exchange, or individual concerned has authorized the HIPAA Rules. As such, we added in the use of the EHI would constitute disclosure.164 The effect of this definitions section of this exception the information blocking. We acknowledged condition is that the covered entity term ‘‘HIPAA Privacy Rule’’ to mean 45 that this could seriously undermine should not use or disclose the PHI in the CFR parts 160 and 164 to improve patients’ trust and confidence in the absence of an individual’s readability and support the policy goal privacy of their EHI and diminish the authorization. However, we noted that of alignment with the HIPAA Privacy willingness of patients, providers, and because the condition does not prohibit Rule. other entities to provide or maintain the actor from exchanging the EHI in all With regards to the definition of health information electronically. In circumstances, the actor would be at ‘‘individual,’’ we have finalized this addition, we noted that such outcomes risk of engaging in a practice that was definition as proposed with a minor would undermine and not advance the information blocking unless an clarification, and it is not contrary to the goals of the information blocking exception applied. For this reason, we HIPAA Rules. We note that the term provision and be inconsistent with the included a sub-exception, proposed in ‘‘individual’’ is defined by the HIPAA broader policy goal of the Cures Act to § 171.202(b), that provided that an actor Rules at 45 CFR 160.103. Separately, facilitate trusted exchange of EHI. We will not be engaging in information under the information blocking stated that trusted exchange requires not blocking if a State or Federal law enforcement provision, we noted that only that EHI be shared in accordance imposes a precondition to the provision the term ‘‘individual’’ is used to refer to with applicable law, but also that it be of access, exchange, or use, and that actors that are health IT developers of shared in a manner that effectuates precondition has not been satisfied (84 certified health IT, HINs, or HIEs (see individuals’ expressed privacy FR 7527 and 7528). section 3022(b)(2)(A) of the PHSA). We preferences. We noted that an Comments. Commenters finalized that for purposes of this individual’s expressed privacy recommended that we allow for EHI to exception (and only this exception), we preferences will not be controlling in all be withheld if there are contractual used neither of these definitions. cases. An actor will not be able to rely Instead, the term ‘‘individual’’ on an individual’s expressed privacy 164 45 CFR 164.508 (Uses and disclosures for encompassed any or all of the following: preference in circumstances where the which an authorization is required). (1) An individual defined by 45 CFR

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00206 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25847

160.103; (2) any other natural person We proposed to establish a sub- comment on our proposed approach to who is the subject of EHI that is being exception to the information blocking addressing variation in State laws accessed, exchanged or used; (3) a provision that recognizes that an actor throughout this proposed sub-exception person who legally acts on behalf of a will not be engaging in information (84 FR 7528). person described in (1) or (2), in making blocking if the actor does not provide We also recognized that some states decisions related to health care, as a access, exchange, or use of EHI because have enacted laws that more personal representative, in accordance a necessary precondition required by comprehensively identify the with 45 CFR 164.502(g); (4) a person law has not been satisfied. We circumstance in which an individual or who is a legal representative of and can explained that this exception would actor can and cannot provide access, make health care decisions on behalf of apply to all instances where an actor’s exchange, or use of EHI. We stated that any person described in paragraph (a)(1) ability to provide access, exchange, or we were considering to what extent or (2); or (5) an executor or use is ‘‘controlled’’ by a legal obligation health care providers that are not administrator or other person having required by law that a certain condition regulated by the HIPAA Privacy Rule, authority to act on behalf of a deceased (or multiple conditions) must be met and would rely instead on State laws for person described in (1) or (2) or the before access, exchange, or use of the this sub-exception, would be able to individual’s estate under State or other EHI may be provided. We emphasized benefit from this sub-exception when law. that to be covered by this exception, the engaging in practices that interfere with To clarify, we have finalized that actor must comply with certain access, exchange, or use of EHI for the § 171.202(a)(2)(iii) encompasses only a conditions, which are discussed below. purpose of promoting patient privacy. person who is a personal representative We noted that the nature of the We sought comment on any challenges as defined under the HIPAA Privacy preconditions that an actor must satisfy that may be encountered by health care Rule. We distinguish a ‘‘personal in order to provide access, exchange, or providers that are not regulated as representative’’ defined under the use of EHI will depend on the laws that covered entities under the HIPAA HIPAA Privacy Rule from all other regulate the actor. For example, an actor Privacy Rule when seeking to take natural persons who are legal that is regulated by a restrictive State advantage of this proposed sub- representatives and who can make law may need to satisfy more conditions exception. We also sought comment on health care decisions on behalf of the than an actor regulated by a less whether there exists a class of health individual, and thus those persons are restrictive State law before providing care provider that is not regulated by included in § 171.202(a)(2)(iv). We access, exchange, or use of EHI (84 FR any Federal or State law that prescribes misstated in the Proposed Rule that the 7527 and 7528). preconditions that must be satisfied in We requested comments generally on connection with the disclosure of EHI, HIPAA Privacy Rule gave rights to this proposed sub-exception. More and whether any such class of health parents or legal guardians in certain specifically, we sought comment on care provider would benefit from a sub- circumstances where they are not the how this proposed sub-exception would exception similar to that proposed in ‘‘personal representatives.’’ We clarify be exercised by actors in the context of § 171.202(c) for health IT developers of in this final rule that, in limited State laws. We noted our awareness that certified health IT (84 FR 7529). circumstances and if permitted under actors that operate across State lines or Comments. Several commenters State law, a family member may be the in multiple jurisdictions sometimes recommended that actors who operate legal representative to act on behalf of adopt organization-wide privacy across multiple states with different a patient to make health care decisions practices that conform with the most preconditions for disclosure under local in emergency situations even if that restrictive laws regulating their laws should be able to adopt uniform family member may not be the business. We stated that we were requirements across their organizations ‘‘personal representative’’ of the patient. considering the inclusion of an that satisfy the most stringent Comments. We received no comments accommodation in this sub-exception preconditions of those local laws for opposing this condition of the proposed that would recognize an actor’s purposes of this sub-exception. They definition of ‘‘individual’’ in the Privacy observance of a legal precondition that stated that this is appropriate because it Exception. the actor is required by law to satisfy in is often difficult for organizations Response. We finalized and clarified at least one State in which it operates. operating across State lines to develop that § 171.202(a)(2)(iii) refers to only We noted that, in the event that we did different workflows for each State. persons who meet the definition of a adopt such an accommodation, we However, other commenters requested personal representative under 45 CFR would also need to carefully consider that actors should be permitted to select 164.502(g), and § 171.202(a)(2)(iv) refers how to ensure that before the use of the which portions of a State law should be to all other persons who are legal most stringent restriction is applied in included in procedures implemented representatives of and can make health all jurisdictions, the actor has provided across all states rather than being care decisions on behalf of any person all privacy protections afforded by that required to provide all privacy that was proposed in § 171.202(a)(4). law across its entire business. This type protections afforded by that law across Sub-Exception 1: ‘‘Precondition Not of approach would ensure that an actor its entire business. Other commenters Satisfied’’ cannot take advantage of a more- believed that it should be left to the restrictive law for the benefit of this actor’s discretion to determine whether We stated in the Proposed Rule that exception while not also fulfilling the it is better to have a uniform approach State and Federal privacy laws that privacy-protective obligations of the law across all the jurisdictions it operates in permit the disclosure of PHI often being relied on. We requested comment or whether a State-by-State approach is impose conditions that must be satisfied on whether there is a need for ONC to more appropriate. They mentioned that prior to a disclosure being made. In the adopt such an accommodation for actors such flexibility also would align with final rule we are deleting the word operating in multiple states and the Department’s overall goal of ‘‘privacy’’ when it refers to laws in the encouraged commenters to identify any reducing administrative burden regulation text in § 171.202(b) in order additional conditions that should attach particularly on providers while ensuring to alleviate any ambiguity about what is to the provision of such an a high degree of privacy protection for meant as a ‘‘privacy law.’’ accommodation. We also requested patients.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00207 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25848 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

Response. We appreciate the various 164.524 for the individual’s EHI, the what is meant as a ‘‘privacy law.’’ The comments and recognize that it is actor must not impose preconditions in HIPAA Privacy Rule provides a Federal difficult for organizations operating its policies and procedures which floor of privacy protections for an across State lines to have different would affect the individual’s right to individual’s individually identifiable workflows for each State while assuring access under the HIPAA Rules even health information where that privacy, particularly the individual’s when it is operating in multiple states. information is held by a covered entity right under the HIPAA Rules to obtain We note that an actor may not or by a business associate of the covered their PHI. Additionally, it is important inappropriately seek to use State or entity. This sub-exception does not alter that any uniform policies and Federal laws as a shield against an actor’s ability to comply with procedures must in fact be implemented disclosing EHI. For example, we would applicable Federal or State laws. across an actor’s entire organization and expect that actors implement State- To illustrate this sub-exception, we not be applied selectively in ways mandated preconditions consistently provided the following examples. We which might be contrary to the and in a non-discriminatory manner note that this list of examples is not information blocking provision. when fulfilling requests to access, exhaustive and that preconditions Balancing these goals, this final rule exchange, or use EHI. Additionally, we required by law that control access, provides that, except for an individual’s caution actors who repeatedly change exchange, or use of EHI that are not access to their EHI as discussed below, their privacy policies depending on the listed below would still qualify under actors may meet this sub-exception if EHI requestor or the request that such this proposed sub-exception so long as they operate across multiple states and actions may be considered intended to all conditions are met. elect to adopt and implement uniform materially interfere with, prevent, or • Although the HIPAA Privacy Rule policies and procedures required by one discourage the access, exchange, or use does not have individual ‘‘consent’’ State that are more restrictive (i.e., of EHI. requirements for uses and disclosures of provide greater privacy protections) We note that we have modified the PHI for purposes such as treatment, than would otherwise be required by introductory text in § 171.202(b) for payment, and health care operations, another specific State or Federal law. To clarity and precision. The final certain Federal and State laws do be considered more restrictive in this introductory text reads as follows: ‘‘To require that a person provide consent context, a law might require more or qualify for the exception on the basis before their EHI can be accessed, different preconditions to the access, that one or more Federal or State exchanged, or used for specific exchange, or use of EHI than Federal preconditions for providing access, purposes. For example, some State laws law or the law of another State in which exchange, or use of electronic health require an individual’s consent for uses the actor operates. Alternatively, an information have not been satisfied, the and disclosures of EHI regarding some actor could comply with the following requirements must be met sensitive health conditions such as HIV/ preconditions of each State in which it . . .’’ The changes to the final AIDS, mental health, or genetic testing. operates on a State-by-State basis with introductory text from the proposed Additionally, actors that are under ‘‘Part respect to the EHI requested. These introductory text (see 84 FR 7602) are 2 programs,’’ which means federally alternatives provide multi-state actors not substantive and do not change the assisted programs (‘‘federally assisted’’ with significant flexibility without meaning of the introductory text. as defined in 42 CFR 2.12(b) and adversely impacting an individual’s We also note that we have added ‘‘and ‘‘program’’ as defined in 42 CFR 2.11), right to obtain EHI as described below. actions’’ in § 171.202(b)(3)—‘‘For generally are required to obtain an An actor that operates in multiple purposes of determining whether the individual’s consent to disclose or re- states could either comply with the laws actor’s privacy policies and procedures disclose patient-identifying information of each State in which it operates or and actions satisfy the requirements of related to the individual’s substance use comply with the most restrictive State subsections (b)(1)(i) and (b)(2) above disorder, such as treatment for laws in which it operates and where when the actor’s operations are subject addiction. The sub-exception would applicable, comply with Federal law to multiple laws which have operate to clarify an actor’s compliance requirements. The actor will need to inconsistent preconditions, they shall be obligations in these situations. In such document either approach in its policies deemed to satisfy the requirements of scenarios, it would not be considered and procedures in which the actor has the subsections if the actor has adopted information blocking to refuse to adopted and implemented in order to uniform privacy policies and provide access, exchange, or use of EHI meet the conditions of § 171.202(b)(1)(i) procedures to address the more if the actor has not received the because the uniform approach will not restrictive preconditions.’’ We added individual’s consent, subject to be available to actors that operate on a this language for accuracy and clarity. requirements discussed herein. case by case basis without policies and Comments. A commenter requested • If an actor is required by law to procedures as contemplated by that we provide clarification on all the obtain an individual’s HIPAA subsection § 171.202(b)(1)(ii). Those Federal and State privacy laws authorization before providing access, actors without uniform policies and considered when developing the exchange, or use of the individual’s EHI, procedures will need to comply with ‘‘applicable State and Federal privacy then the individual’s refusal to provide each of the applicable State and Federal laws’’ threshold condition of this sub- an authorization would justify the laws. exception. They requested that the final actor’s refusal to provide access, As noted above, the uniform policy rule make clear that those State privacy exchange, or use of EHI. The actor’s and procedure approach to individual laws that are more restrictive than refusal would, subject to conditions access requests for EHI must assure Federal privacy laws (e.g., 42 CFR part discussed herein, be protected under alignment with the HIPAA Privacy Rule 2 and HIPAA) take precedence over the this sub-exception. and individual access implementation less stringent Federal privacy laws. • The HIPAA Privacy Rule, and many specifications to help assure that the Response. As mentioned above, for State laws, permit the disclosure of PHI broader policy goals for individual clarity purposes, we have not included in certain circumstances only once the access to EHI are met. Specifically, the word ‘‘privacy’’ in the final identity and authority of the person when an actor receives a request by or regulation text in § 171.202(b) in order requesting the information has been on behalf of an individual under 45 CFR to alleviate any ambiguity regarding verified. We acknowledge that it is

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00208 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25849

reasonable and necessary that actors by implementing and conforming to We proposed that this condition take appropriate steps, consistent with organizational policies and procedures requires that the actor’s privacy- Federal and State laws, to ensure that that identify the criteria to be used by protective practices must be based on EHI is not disclosed to the wrong person the actor and, as applicable, the steps objective criteria that apply uniformly or to a person who is not authorized to that the actor will take, in order to for all substantially similar privacy receive it. Where an actor cannot verify satisfy the precondition. risks. We explained that an actor could the identity or authority of a person We noted that most actors are covered not, for example, implement an requesting access to EHI, and such entities or business associates for the organizational privacy policy that verification is required by law before the purposes of the HIPAA Privacy Rule, imposed unreasonably onerous actor can provide access, exchange, or and are already required to have requirements on a certain class of use of the EHI, the actor’s refusal to policies, procedures, and training individuals or entities without a provide access, exchange, or use of the programs in place that address how legitimate justification for doing so. We EHI will, subject to the conditions ePHI (as defined in 45 CFR 160.103) is explained that this condition provides discussed herein, will not be used and disclosed. As such, we basic assurance that the purported information blocking. expected that the overwhelming privacy-protective practice is not being • Under the HIPAA Privacy Rule, a majority of actors will already be in a used to interfere with access, exchange, health care provider may share position to meet this condition or would or use of EHI for other purposes to information with another health care be able to meet this condition with which this proposed exception does not provider for a quality improvement modest additional effort. However, we apply (84 FR 7532). project if it has verified that the acknowledged that some actors may not, We requested comment on this requesting entity has a relationship with for whatever reason, have privacy proposed condition. Comments. Commenters agreed that the person whose information is being policies and practices in place, or may having an organizational policy which requested. Where the actor could not have implemented privacy policies and outlines patient preference categories establish if the relationship existed, it practices that do not sufficiently address and restrictions should be created and would not be information blocking for the criteria to be used, and steps to be utilized in a consistent and non- the actor to refuse to provide access, taken, to satisfy a precondition relied on discriminatory manner for all patient exchange, or use, subject to the by the actor. As such, we proposed to requests. conditions discussed herein. provide an alternative basis on which to Comments. We received comments on Response. We agree with the qualify, in part, for this sub-exception. the Privacy Exception expressing commenters, and for clarity, we moved We proposed to permit actors to instead concern about whether a business this proposed section to finalize in document, on a case-by-case basis, the associate (as defined under the HIPAA § 171.202(b)(1), in order to address criteria used by the actor to determine Privacy Rule) would be liable for when an actor has conformed to its when the precondition will be satisfied, information blocking practices for not organizational policies and procedures any criteria that were not met, and the providing access, exchange, or use of and when an actor documents on a case- reason why the criteria were not met (84 EHI because doing so would violate its by-case basis when a precondition has FR 7529). business associate agreement. been satisfied. In both cases, the actor’s Response. Please see section Separately, we proposed that if the practice must be implemented in a VIII.C.6.a. (Prevention, Material precondition that an actor purportedly consistent and non-discriminatory Discouragement and Other Interference) needs to satisfy relies on the provision manner. We provide the following above regarding interference that of a consent or authorization from an example to illustrate the requirement discusses contracts including business individual, it is a requirement for the that a practice must be implemented in associate agreements where this is condition(s) of this sub-exception that a consistent and non-discriminatory discussed in depth. the actor (i) did all things reasonably manner. necessary within its control to provide For example, we noted an actor that Sub-Exception 1: ‘‘Precondition Not the individual with a meaningful offered a patient-facing software Satisfied’’: Conditions To Be Met To opportunity to provide the consent or application (app) would not be able to Qualify for This Sub-Exception authorization and (ii) did not benefit from this exception if it refused We noted that in most circumstances, improperly encourage or induce the to exchange EHI with a competitor app an actor would be in a position to individual to not provide the consent or because the individual failed to meet influence whether a precondition is authorization (84 FR 7529). onerous authorization requirements that satisfied. For example, an actor could Sub-Exception 1: ‘‘Precondition Not applied only to the exchange of EHI deprive a person of the opportunity to Satisfied’’: Practice Must Be with the competitor app and did not take some step that is a prerequisite for Implemented in a Consistent and Non- apply to others that presented no greater the exchange of their EHI, could assume Discriminatory Manner privacy or security risk. the existence of a fact prejudicial to the In context of this condition of the granting of access without seeking to We proposed that in order for a Privacy Exception, and consistent with discover the actual facts, or could make practice to qualify for this sub- its interpretation for information a determination that a precondition was exception, the practice must be blocking exceptions defined in part 171 not satisfied without properly implemented in a consistent and non- subpart B in general, ‘‘consistent and considering or seeking all relevant discriminatory manner (proposed non-discriminatory’’ should be information. As such, we proposed that § 171.202(b)(3)(ii)). This condition understood to mean that similarly this exception would be subject to would provide basic assurance that the situated actors whose interactions pose conditions that ensure that the purported privacy practice is directly the same level of privacy risk should be protection of an individual’s privacy is related to a specific privacy risk and is treated consistently with one another not used as a pretext for information not being used to interfere with access, under the actor’s privacy practices. blocking (84 FR 7529). exchange, or use of EHI for other Inconsistent treatment across similarly We proposed that an actor can purposes to which this exception does situated actors whose interactions pose qualify, in part, for this sub-exception not apply. the same level of privacy risk based on

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00209 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25850 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

extraneous factors, such as whether they applicable legal requirement and not be apply the policies and procedures (84 are a competitor of the actor tied only to a privacy risk or interest. To FR 7529 and 7530). implementing the privacy practices, require that an actor’s practice be We requested comment on the would not be considered appropriate. tailored to the specific privacy risk or proposed condition generally, and interest without a legally imposed specifically, on whether an actor’s Sub-Exception 1: ‘‘Precondition Not requirement could lead to overly strict organizational policies and procedures Satisfied’’: Practice Must Be Tailored to provide a sufficiently robust and the Applicable Precondition as well as an ambiguous requirement. As such, we believe that it is an reliable basis for evaluating the bona We proposed that for actors who seek important policy interest that an actor fides, reasonableness, and necessity of to qualify for this sub-exception, an carefully evaluate the State or Federal practices engaged in to satisfy actor’s privacy-protective practice law requirements imposed upon an preconditions required by State or (proposed (§ 171.202(b)(3)(i)) must be actor, and that the actor develop a Federal privacy laws (84 FR 7529 and tailored to the specific privacy risks that response that is tailored to the legal 7530). the practice actually addresses. This precondition which protect and Comments. Some commenters condition necessarily presupposes that promote the privacy of EHI. We provide recommended that actors should be able an actor has carefully evaluated the the following use case to provide a to have written organization-specific privacy requirements imposed on the greater understanding of how this policies that may be more restrictive actor, the privacy interests to be element of the sub-exception can be than State or Federal law and that managed by the actor, and has met. health information networks and developed a considered response that is • To meet a legal precondition exchanges should be given an tailored to protecting and promoting the whereby an actor must identify a patient exemption based on their existing privacy of EHI. For example, we noted before accessing, exchanging or using written governance policies. Other that the HIPAA Privacy Rule at 45 CFR EHI, an actor’s policy that a driver’s commenters recommended adding 164.514(h) requires that, in certain language indicating that organizational license was the only accepted circumstances, the disclosure of PHI is policies must comply with Federal, government-issued form of only authorized once the identity and State, and local laws or that the final identification (as opposed to other types authority of the person requesting the rule should specify that organizations of legally acceptable forms of information has been verified. The should implement policies which identification such as a valid passport) privacy issue to be addressed in this conform to the specific State laws in would not be a practice that is tailored instance is the risk that PHI will be which the information originates. to the applicable precondition legal disclosed to the wrong individual or an Response. As noted above, this final unauthorized person. We proposed that requirement because the provider’s rule includes a limited exception that if an actor chooses not to provide preference for one form of government- permits an actor that operates in more access, exchange, or use of EHI on the issued identification over another does than one State to adopt uniform policies basis that the actor’s identity not meaningfully address this legal and procedures based on more verification requirements have not been precondition. restrictive provisions of State and satisfied, the actor’s practice must be We have finalized that to qualify for Federal law, subject to certain tailored to the specific privacy risks at this sub-exception on the basis that conditions. ONC reiterates that an issue. We noted that this would require State or Federal law requires one or actor’s organizational policies and that the actor ensure that it does not more preconditions to be met before procedures should not be used as a impose identity verification providing access, exchange, or use of pretext for information blocking. For requirements that are unreasonably EHI the precondition should be based example, information blocking may onerous under the circumstances (84 FR upon the applicable legal requirements. exist if an actor’s policies and 7531). Sub-Exception 1: ‘‘Precondition Not procedures impose onerous additional For the purposes of this sub- Satisfied’’: Organizational Policies and privacy requirements for access, exception, we proposed that engaging in Procedures or Case-by-Case Basis exchange or use of EHI beyond what is an interference on the basis that a required by law, or where an actor precondition has not been satisfied We proposed that if an actor seeks to repeatedly changes its privacy policies would be a practice that addresses a qualify for this sub-exception, in part, and procedures to circumvent this privacy risk or interest, and so tailoring by implementing and conforming to exception. Further, the actor’s policies that interference to satisfy a organizational policies and procedures, and procedures must be tailored and precondition could satisfy this such policies and procedures must be in must be implemented in a consistent requirement if all of the elements are writing, and specify the criteria to be and non-discriminatory manner. met. used by the actor, and, if applicable, the We do not agree that health We requested comment on this steps that the actor will take, in order to information exchanges or networks proposed condition. satisfy the precondition relied on by the should be given a blanket exemption Comments. Commenters expressed a actor not to provide access, exchange, or based on their existing written belief that a requirement that a ‘‘practice use of EHI. We emphasized that it governance policies because that could must be tailored to the specific privacy would not be sufficient for an actor to lead to a situation involving information risk or interest being addressed’’ could simply identify the existence of the blocking if those policies imposed lead to unnecessary complexity, and precondition in their organizational conditions that conflict with the that such a policy could be overly policies and procedures. information blocking provision. prescriptive. In addition, commenters We proposed that an actor would only Secondly, we expect that an actor’s expressed that we should provide more be eligible to benefit from this sub- organizational policies will conform use cases to help providers and others exception if it has implemented and with applicable laws, including the better understand how this element of followed its processes and policies. This information blocking provision, so it is the sub-exception could be met. would include taking reasonable steps not necessary to further require actors to Response. We agree. We believe that to ensure that its workforce members implement policies which conform to a precondition should be tailored to the and agents understand and consistently the specific laws, including the law of

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00210 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25851

the State in which the information what type of documentation would believe this documentation requirement originated. suffice to demonstrate that an actor met would be onerous. this sub-exception. Commenters were Therefore, we have finalized the Documenting Criteria and Rationale concerned that these were stringent following requirements for this sub- If an actor’s practice does not conform documentation requirements and that exception. An actor must document its to an actor’s organizational policies and provider practices may inadvertently organizational policies and procedures procedures as required by trigger a violation of information and specify the criteria used by the actor § 171.202(b)(1)(i), we proposed that an blocking. Other commenters suggested and as applicable, the steps that the actor can seek to qualify for this sub- that we should remove or consider actor will take to satisfy the exception, in part, by documenting how reducing onerous requirements for precondition. Such steps may include it reached its decision that it would not documentation for qualifying for the providing the actor’s workforce provide access, use, or exchange of EHI privacy sub-exceptions, and other members with training on those policies on the basis that a precondition had not commenters requested specification on and procedures. Alternatively, we have been satisfied. We proposed that such what form the documentation must be finalized a requirement an actor must documentation must be created on a and to specify whether existing document on a case-by-case basis how case-by-case basis proposed in documentation required by the HIPAA it reached its decision that it would not § 171.202(b)(1)(ii). We noted that an Rules (e.g., patient informed consent provide access, use, or exchange of EHI actor will not satisfy this condition if, and authorization forms, Notice of on the basis that a precondition had not for instance, it sought to document a Privacy Practices, Security Risk been satisfied, including the criteria it general practice that it had applied to all Analysis, etc.) would satisfy the used to determine when the instances where the precondition had documentation requirements under this precondition is satisfied. That is, an not been satisfied. Rather, we stated that Privacy Exception. actor can provide documentation that the record created by the actor must Response. The documentation identifies the objective criteria that the address the specific circumstances of requirements are for the actor to comply actor applied in order to determine the specific practice (or interference) at with applicable State and Federal laws whether the precondition had been issue. and to assure that after the fact satisfied. Additionally, the actor must We proposed that the record created rationalizations are not used to justify provide documentation that the practice by the actor must identify the objective practices that have already occurred, is tailored to those criteria that are criteria used by the actor to determine consistent with the policy objectives of directly relevant to satisfying the when the precondition is satisfied. the information blocking provision. precondition. Consistent with the condition to this To finalize the documentation sub-exception that the practice must be requirements we looked to OIG, which Sub-Exception 1: ‘‘Precondition Not tailored to the privacy interest at issue, has authority under section 3022(b) of Satisfied’’: Precondition Relies on a those criteria would need to be directly the PHSA to investigate any claim that Consent or Authorization relevant to satisfying the requirement. an actor engaged in information We proposed that if the precondition For example, we explained that if the blocking. OIG regulations in other that an actor purports to rely upon requirement at issue was the provision contexts include a writing requirement. requires the provision of a consent or of a valid HIPAA authorization, the For example, OIG has promulgated the authorization from an individual, it is a actor’s documented record should ‘‘safe harbors’’ provisions at 42 CFR condition of this sub-exception that the reflect, at minimum, that the 1001.952, specifying various payment actor must have done all things authorization would need to meet each and business practices that would not reasonably necessary within its control of the requirements specified for a valid be subject to sanctions under the Anti- to provide the individual with a authorization at 45 CFR 164.508(c). The Kickback Statute. Several of these safe meaningful opportunity to provide that record would then need to document harbors include a writing requirement to consent or authorization. We noted that the criteria that had not been met, and document in writing an agreement, this requirement will be relevant when, the reason why it was not met. We lease, or other transaction. These for example, a State privacy law or the noted that the actor could record that documentation requirements do not HIPAA Privacy Rule requires an the authorization did not contain the often get into specific terms or individual to provide consent and/or a name or other specific identification of requirements, but rather tend to be more HIPAA authorization before identifiable the person making the request because general in nature. However, the information can be accessed, exchanged, the authorization only disclosed the documentation requirements do provide or used for specific purposes. person’s first initial rather than a first indicia of evidence that an entity has We stated that we were considering name, and the actor had records about met the requirements of the safe harbor addressing this condition in further multiple people with that same initial provisions. detail, whether by way of additional and last name. In addition, we considered the guidance or in regulation text. To this We noted that this condition would documentation requirements in the end, we requested comments regarding provide the transparency necessary to HIPAA Rules. The HIPAA Privacy Rule what actions an actor should take, demonstrate whether the actor has at 45 C.F.R 164.530 (j) requires a within the actor’s control, to provide an satisfied the conditions applicable to covered entity to maintain its policies individual with a meaningful this exception. Moreover, we noted that and procedures in written or electronic opportunity to provide a required it will help ensure that a decision to not form for six years from the date of its consent or HIPAA authorization, and provide access, exchange, or use of EHI creation or the date when it last was in whether different expectations should is considered and deliberate, and effect, whichever is later. In our review arise in the context of a consent versus therefore reasonable and necessary (84 of the OIG and HIPAA regulations, we a HIPAA authorization. Separately, we FR 7530). believe that the documentation proposed that to qualify for this sub- We requested comment on this requirement for this sub-exception is exception, to the extent that the proposed condition. consistent with the safe harbor and precondition at issue was the provision Comments. Commenters requested HIPAA Privacy Rule documentation of a consent or HIPAA authorization by that we should provide specificity on requirements. Further, we do not an individual, the actor must not have

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00211 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25852 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

improperly encouraged or induced the this often acknowledged that modifying captured in the information blocking individual to not provide the consent or our proposal to fit their suggestion provision that is the subject of this final HIPAA authorization. We clarified that would require an actor to receive rule. this does not mean that the actor cannot assurances that consents are legitimate We recognize that actors must inform an individual about the and in their possession before sharing accommodate variations in laws across advantages and disadvantages of any data. These commenters often noted the states in which they operate. As exchanging EHI and any associated that it was not clear how recipients of discussed above, this final rule provides risks, so long as the information health care data subject to flexibility to multi-state providers with communicated is accurate and authorizations and consent would be respect to how they may structure legitimate. However, we noted that an expected to provide individuals with a uniform policies and procedures actor would not meet this condition in meaningful opportunity to consent if regarding consents and authorizations the event that it misled an individual they do not have an existing provided that they do in fact apply about the nature of the consent to be relationship with that individual or them. We also recognize that some types provided, dissuaded individuals from means to contact that individual. A few of actors will not have the necessary providing consent in respect of commenters recommended modifying legal rights or the technical access to disclosures to the actor’s competitors, or this condition so that an actor that does detailed patient information to imposed onerous requirements to not have a direct relationship with determine if a consent or authorization effectuate consent that were patients is not required to obtain patient is required as a precondition. unnecessary and not required by law. consent or authorization. We intend that each actor must do We requested comment on whether Response. We agree with the what is reasonable and what is within the proposed condition requiring the commenters and have attempted to its control. This applies to actors who provision of a meaningful opportunity address concerns about vagueness and are providers that have a direct patient and prohibiting improper consistency with industry practices and relationship and to actors that are encouragement or inducement should relationships. This finalized sub- supporting a health care provider with apply to preconditions beyond the exception requires the actor to have respect to an insufficient consent or precondition that an individual provide used reasonable efforts within its authorization that must also use consent or authorization. We requested control if the actor has already received reasonable efforts to avoid possible comment on whether the conditions a form of required consent or information blocking. specified for this sub-exception, when authorization that does not meet all A health information network that taken in total, are sufficiently applicable requirements. Specifically, receives an insufficient consent or particularized and sufficiently strict to the actor must have used reasonable authorization might find that this sub- ensure that actors that are in a position efforts within its control to provide the exception helpful if it does not have to influence whether a precondition is individual with a consent or lawful access to the individual’s satisfied will not be able to take authorization form that satisfies all information to determine what consent advantage of this sub-exception and applicable requirements or have might be required under State or Federal seek protection for practices that do not provided other reasonable assistance confidentiality laws that apply to promote the privacy of EHI. We also with respect to the deficiencies. In information about mental health, requested comment on whether we effect, this places more of an obligation substance abuse, HIV status or other should adopt a more tailored approach on the party requesting the EHI and the highly confidential diseases or to conditioning the availability of this individual to attempt to satisfy the conditions. We also note that if a exception. For example, we noted that precondition by providing a consent or network is not able to review such we were considering whether different authorization. This final rule does not information under applicable law, conditions should apply depending on: require the actor that receives the providing a corrected consent would not (i) The nature of the EHI at issue; (ii) the request to obtain a patient’s consent or be within its control. circumstances in which the EHI is being authorization to do all things reasonably Comments. Many commenters were access, exchanged, or used; (iii) the necessary within its control to provide concerned that our definition of interest being protected by the the individual with a meaningful ‘‘meaningful opportunity’’ was too precondition; or (iv) the nature of the opportunity to provide the consent or broad. These few commenters suggested precondition to be satisfied. We authorization. Rather, the final rule that, as proposed, our definition of encouraged commenters to identify requires that the actor is obligated to ‘‘meaningful opportunity’’ could place a scenarios in which the application of take reasonable steps to provide a significant burden on providers. the conditions applicable to this sub- sufficient consent or authorization form Specifically, these commenters exception, as proposed, give rise to or other reasonable assistance. suggested that adding a ‘‘meaningful’’ unnecessary burden, or would require Providing other reasonable assistance opportunity to consent to the patient, activities that do not advance the dual does not mean that the actor needs to with its requisite new forms and policy interests of preventing ‘‘chase’’ the individual to obtain a procedures, would add new burdens on information blocking and promoting sufficient consent or authorization. actors without appearing to solve any privacy and security (84 FR 7530 and Such other reasonable assistance might existing problems. 7531). include notifying the individual of One commenter recommended that Comments. Some commenters noted elements that are missing in the consent we modify this requirement to include that the entire condition was too vague or authorization initially provided, such a reasonable opportunity for the and generally inconsistent with current as a witness or an expiration date if provider to obtain the individual’s standard industry relationships and legally required. consent the next time the patient visits practices. Several commenters suggested We believe that setting the standard the office if the patient is not present in that the burden to obtain the consent for an actor’s actions with respect to an the office to provide consent. should be on the organization insufficient consent or authorization at Response. We appreciate the requesting the data rather than on the reasonable efforts is an appropriate comments that we have received on the organization that holds the data. standard to use because it aligns with meaningful opportunity provision. After However, commenters who suggested the case-by-case approach that is considering the comments, we

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00212 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25853

eliminated the ‘‘meaningful patient relationship would have a modification does not change the opportunity’’ provision in this final higher standard of reasonable efforts meaning of § 171.202(b)(2)(i). rule. However, this sub-exception still than those actors such as HINs which do Comments. A commenter expressed requires the actor to use reasonable not have a direct relationship with a concern to modify this exception to efforts within its control and to provide patient and are acting on behalf of a make it clear that a hospital or health reasonable assistance, which might health care provider. However, even system may claim the exception when include explaining the required actors that do not have a direct an entity requesting patient data does elements of a consent or authorization, relationship with an individual, should not communicate that it has obtained or providing a witness if required by use their reasonable efforts for the consent. law and requested by the patient at an activities under their control as it relates Response. As noted above, this office visit with the actor. to supporting the providing or obtaining condition of the sub-exception applies However, the requirement of of a consent or authorization. only after an insufficient consent or reasonable efforts is based on an Comments. Commenters expressed authorization is received. This assumption that actors may not use the concerns that actors would be required condition of the sub-exception in the protection of an individual’s privacy as to create new policies beyond HIPAA final rule does not apply when the actor pretext for information blocking. If a aimed at offering patients a has not received anything regarding the requestor provides or obtains some form ‘‘meaningful’’ opportunity to consent, individual’s consent or authorization. In of patient documented consent or and as a result, more challenges than such cases, the actor would not be authorization that requires the actor’s solutions would result from this policy. required to communicate to the entity assistance to satisfy elements that are Commenters noted unnecessary requesting the EHI that the actor has not not required by law and the actor does administrative burdens, confusion with obtained the individual’s consent or not provide such assistance, the actor HIPAA requirements, and complexity authorization in order to meet this sub- may be engaged in information for actors as some of the possible exception. blocking. challenges. We recognize that meeting certain Comments. A commenter argued that Response. As noted above, the preconditions may be outside the direct actors should provide the individual ‘‘meaningful opportunity’’ requirement control of the provider. For example, the with a ‘‘reasonably convenient was not included in this final rule. actor may have a pre-existing consent opportunity’’ to provide the consent or form from the individual that needs to Comments. Many commenters authorization, rather than requiring ‘‘all be modified due to a change in expressed the opinion that actors things reasonably necessary within its applicable law. The actor may have a meeting certain preconditions may be control’’ to provide consent or very difficult time tracking down a outside the direct control of the actor authorization. The commenter noted former patient to provide the updated and recommended that examples should that where entities make the request on consent form. In most cases, it would be be provided about what actions are behalf of the individual, the actor reasonable to mail or email the updated sufficient to meet the ‘‘reasonably making the request should facilitate the form to the patient’s last address on the necessary’’ standard. Another gathering of the consent or actor’s records or present it to the commenter argued that the reasonably authorization. patient at visit scheduled in the near necessary standard for the meaningful Response. As noted above, both the future. If the patient cancels the visit, it opportunity requirement only stands to ‘‘reasonable opportunity’’ and the ‘‘all may be reasonable for the actor to wait further aggravate the burdensome nature things reasonably necessary’’ language to obtain the consent until the next time of more stringent privacy laws. Other are not included in this final rule, but the patient visits the physical location commenters were concerned that the the actor must satisfy the reasonable of the actor’s office, so long as the actor requirement that the actor ‘‘did all efforts standard when an insufficient explains the insufficiency and provides things reasonably necessary within its consent or authorization has been a sufficient consent form at the next control to provide the individual with a received. This might include providing visit. meaningful opportunity to provide the a correct form or reasonable assistance Comments. Commenters have consent or authorization’’ was too rigid to the individual to solve any consent or mentioned that a health information a requirement and that even if one authorization documentation problems network (HIN) does not have possible action was not done, the necessary to address the insufficiency. operational control over or visibility exception would not apply. Other commenters argued that this standard Sub-Exception 1: Precondition Not into the detailed decision-making of an Satisfied: Did Not Improperly Encourage individual’s consent or authorization of was an extremely onerous requirement and contradicts the stated intent of or Induce the Individual To Withhold its participants, and they argue that an the Consent or Authorization actor such as a HIN should not be reducing the overall administrative obligated to review or confirm the burden on health care practices. We proposed that to qualify for this individuals’ consent or authorization, Response. As noted above, the sub-exception, to the extent that the and that such confirmation is a standard is now based on reasonable precondition at issue was the provision requirement of the health care provider efforts within the actor’s control, and it of a consent or authorization by an because health care provider has a applies only after the actor receives a individual, the actor must not have direct relationship with the patient. consent or authorization form that does improperly encouraged or induced the Response. We believe that actors such not satisfy all applicable conditions. We individual to not provide the consent or as a HIN do have the obligation to believe that this change addresses the authorization. As proposed, an actor comply with the conditions of this sub- comments noted above. We note that we would not meet this condition in the exception. We have taken the approach have slightly modified the terminology event that it misled an individual about that each actor must use its ‘‘reasonable used in § 171.202(b)(2)(i). We proposed the nature of the consent to be provided, efforts’’ and focus on what reasonable ‘‘a form of consent or authorization’’ (84 dissuaded individuals from providing steps they can take to provide their FR 7602) and have change that language consent in respect of disclosures to the reasonable efforts. We do not, however, in the final rule to ‘‘a consent or actor’s competitors, or imposed onerous believe that actors who have a direct authorization form’’ for clarity. This requirements to effectuate consent that

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00213 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25854 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

were unnecessary and not required by that the HIPAA Privacy Rule (or Practice Must Implement Privacy Policy law. applicable State law) imposes We proposed that in order to qualify We sought comment on whether the preconditions to the provision of access, for this sub-exception, the practice proposed condition requiring the exchange, or use of EHI. However, we engaged in by the non-covered actor— provision of prohibiting improper recognized that direct-to-consumer the interference with access, exchange, encouragement or inducement should health IT products and services are a or use of EHI—must also implement a apply to preconditions beyond the growing sector of the health IT market. process described in the actor’s precondition that an individual provide The privacy practices of consumer- organizational privacy policy. This consent or authorization. We sought facing health IT products and services requires that a non-covered actor must comment on whether the conditions are typically regulated by the Federal have documented in detail in its specified for this sub-exception, when Trade Commission Act (FTC Act). organizational privacy policy the taken in total, are sufficiently However, while the FTC Act prohibits processes and procedures that the actor particularized and sufficiently strict to unfair or deceptive acts or practices in will use to determine when the actor ensure that actors that are in a position or affecting commerce (15 U.S.C. will not provide access, exchange, or to influence whether a precondition is 45(a)(1)), it does not prescribe specific use of EHI. For example, we explained satisfied will not be able to take privacy requirements.165 that a non-covered actor that proposed advantage of this sub-exception and We proposed that where a health IT to require the provision of written seek protection for practices that do not developer of certified health IT offers a consent for the use or disclosure of EHI promote the privacy of EHI. We also health IT product or service not would need to describe in its sought comment on whether we should regulated by the HIPAA Privacy Rule, organizational privacy policy the adopt a more tailored approach to such product or service is still subject processes and procedures to be utilized conditioning the availability of this sub- to the information blocking provision. by the actor to implement that privacy- exception (84 FR 7531). We wanted to ensure that such non- protective practice so that the practice Comments. We received no comments covered actors under the information be considered reasonable and necessary opposing this condition applicable to blocking provisions are able to avail and qualify for this sub-exception. We practices that implement the provision themselves of the Privacy Exception. As noted that compliance with this of a consent or authorization from an such, we proposed that an entity that is condition ensures that the sub- individual to an actor. not covered by HIPAA will not engage exception recognizes only legitimate Response. Within the sub-exception in information blocking if the actor practices that have been tailored to the (§ 171.202(b)) applicable to practices declines to provide access, exchange, or privacy needs of the individuals that that implement a consent or use of EHI where the practice use the non-covered actor’s health IT, authorization, we are finalizing in implements a process that is described and does not recognize practices that are § 171.202(b)(2)(ii) as proposed. in the actor’s organizational privacy a pretext or after-the-fact rationalization Sub-Exception 2: Sub-Exception: Health policy and has been disclosed to any for actions that interfere with access, IT Developer of Certified Health IT Not individual or entity that uses the actor’s exchange, or use of EHI. Covered by HIPAA health IT. We proposed this sub- We also proposed that the non- The sub-exception we proposed in exception in § 171.202(c) which sets covered actor’s practice must implement § 171.202(b) recognized as reasonable forth additional detail (84 FR 7532). its documented organizational privacy and necessary the activities engaged in In the final rule, we have finalized policy. We noted that practices that by actors consistent with the controls that when engaging in a practice that diverge from an actor’s documented placed on access, exchange, or use of promotes the privacy interests of an policies, or which are not addressed in EHI by Federal and State laws. We individual, the non-covered actor must an actor’s organizational privacy policy, noted that the sub-exception was implement the practice according to a would not qualify for this proposed sub- limited to actors that are subject to those process described in the organizational exception (84 FR 7532). Federal and State laws; an actor that is privacy policies, disclosed those Policies Must Have Been Disclosed to not regulated by HIPAA cannot benefit organizational privacy policies to the Users from the exception proposed in individuals and entities that use the actor’s product or service before they We proposed that a non-covered actor § 171.202(b). that seeks to benefit from the sub- We proposed to establish a sub- agreed to use them, and the non-covered exception must also ensure that it has exception to the information blocking actor’s organizational privacy policies previously disclosed the privacy- provision that would apply to actors must: (1) Comply with applicable State protective practice to the individuals that are health IT developers of certified or Federal laws; (2) be tailored to the and entities that use, or will use, the health IT but not regulated by the specific privacy risk or interest being health IT. These users are affected by HIPAA Privacy Rule in respect to the addressed; and (3) be implemented in a the practices engaged in by a non- operation of the actor’s health IT consistent and non-discriminatory covered actor but may otherwise have product or service (referred to as ‘‘non- manner. Public comments on specific no visibility of the non-covered actor’s covered actors’’ for this sub-exception). conditions are summarized below, in approach to protecting the privacy of We noted that we expect that the class context of each condition proposed. We EHI. We noted that we expect that non- of actors to which this proposed sub- believe our responses to these covered actors will seek to satisfy this exception applies will be very small. We comments furnish the clarity non- condition by using a privacy notice.166 explained that the vast majority of covered actors need to understand the conditions of the sub-exception health IT developers of certified health 166 ONC has provided a Model Privacy Notice IT operate as business associates to finalized in § 171.202(c). (MPN) that is a voluntary, openly available resource covered entities under HIPAA. As designed to help developers clearly convey business associates, they are regulated 165 See HHS, Examining Oversight of the Privacy information about their privacy and security & Security of Health Data Collected by Entities Not policies to their users. The MPN provides a by the HIPAA Privacy Rule, and may be Regulated by HIPAA, https://www.healthit.gov/ snapshot of a company’s existing privacy practices able to benefit from the exception sites/default/files/non-covered_entities_report_ encouraging transparency and helping consumers proposed in § 171.202(b) to the extent june_17_2016.pdf. make informed choices when selecting products.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00214 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25855

We emphasized that the disclosure must Practice Must Be Tailored to Privacy determine the most appropriate way to be meaningful. In assessing whether a Risk and Implemented in a Non- communicate their privacy policies to non-covered actor’s disclosure was Discriminatory Manner individuals and users. As stated above meaningful, we explained that regard Finally, we proposed that in order for and in the Proposed Rule (84 FR 7533), will be paid to whether the disclosure a practice to qualify for this sub- it would be reasonable for non-covered was in plain language and conspicuous, exception, an actor’s practice must be actors to, at a minimum, post their including whether the disclosure was tailored to the specific privacy risks that privacy notices, or otherwise describe located in a place, and presented in a the practice actually addresses and must their privacy-protective practices, on manner, that is accessible and obvious be implemented in a consistent and their websites. to the individuals and entities that use, non-discriminatory manner. Comments. A few commenters stated or will use, the health IT. We requested comment on this that it is unclear whether application We proposed that to qualify for this proposed sub-exception generally. developers are subject to HIPAA if they sub-exception, a non-covered actor Specifically, we requested comment on are not business associates or covered would not be required to disclose its whether HIEs or HINs would benefit entities. organizational privacy policy to its from a similar sub-exception. We also Response. We appreciate the customers or to the public generally. requested comment on whether the feedback. Where application developers conditions applicable to this sub- Rather, the non-covered actor need only are not defined as a covered entity or exception are sufficient to ensure that describe, with sufficient detail and business associate as defined under 45 non-covered actors cannot take precision to be readily understood by CFR 160.103, then the application advantage of the exception by engaging users of the non-covered actor’s health developer is not covered under the in practices that are inconsistent with IT, the privacy-protective practices that HIPAA Privacy Rule or HIPAA Security the promotion of individual privacy. We the non-covered actor has adopted and Rule. also requested comment on the level of will observe. We explained that this is detail that non-covered actors should be Comments. Some commenters necessary because a non-covered actor required to use when describing their expressed concern that data will be that is not subject to prescribed privacy privacy practices and processes to user made available to third-party standards in connection with the of health IT (84 FR 7533). application suppliers, commercial provision of health IT will have Comments. Some commenters analytics companies, and/or entities that significant flexibility in the privacy- believed that this sub-exception could are not governed by HIPAA and that protective practices that it adopts. If a be helpful for those developing their such availability of data would not serve non-covered actor is not required to own health IT tools, which are outside patients’ best interests and could result inform the individuals and entities that of the electronic health record. in potential misuse of patient data. use, or will use, the health IT, about the Response. We agree that this sub- Response. We appreciate the feedback privacy-protective practices that it will exception would be helpful for those and agree that an actor who is a health implement in its product, or when developing their own health IT tools. IT developer of certified health IT that providing its service, we noted that The sub-exception address those is not required to comply with the there is a risk that the sub-exception certified Health IT products not covered HIPAA Privacy Rule must comply with will give deference to policies and by HIPAA and would have in place an all applicable State and Federal laws, processes that are post hoc organizational privacy policy which is including the FTC Act. Further, such rationalizations used to justify improper tailored to a specific privacy risk or actors must have an organizational practices. We stated that this condition interest. privacy policy that is tailored to the also serves as a check on the nature of Comments. Commenters noted that privacy risk or interest being addressed the interferences that a non-covered regarding the sub-exception proposed in order to meet this sub-exception. We actor writes into its organizational for ‘‘non-covered actors’’ that develop emphasize that where a health IT privacy policies; transparency will help patient-facing health IT, they urged the developer of certified health IT offers a to ensure that a non-covered actor takes need to balance the conditions of this health IT product or service not a balanced approach to protecting sub-exception with the requirements regulated by the HIPAA Privacy Rule, privacy interests on one hand, and placed on actors who institute such product or service is subject to the pursuing business interests that might organizational privacy policies. information blocking provision. Our be inconsistent with the information Response. We appreciate the goal is to ensure that non-covered actors blocking provision, on the other hand comment. In order to meet this sub- that engage in reasonable and necessary (84 FR 7533). exception, the organizational privacy privacy-protective practices that policies of a non-covered actor would We proposed that it will be a matter interfere with the access, exchange, or need to comply with other applicable for non-covered actors to determine the use of EHI could seek coverage under State and Federal laws. Further, we the sub-exception. most appropriate way to communicate have finalized that non-covered actors its privacy practices to users. We noted that seek to benefit from this sub- Comments. Some commenters stated that it would be reasonable that non- exception must also ensure that their that actors that are not covered by covered actors would, at a minimum, organizational privacy policies are HIPAA should make their privacy post their privacy notices, or otherwise disclosed to the individuals and entities policies publicly available. Other describe their privacy-protective that use their product or service before commenters did not believe that the practices, on their websites (84 FR the individuals and entities agree to use Proposed Rule fully addressed patient 7533). them. The organizational privacy and consumer privacy protections. policies are important for transparency Response. We appreciate the The MPN does not mandate specific policies or for users of the certified technologies comments. We believe that it is substitute for more comprehensive or detailed and to demonstrate compliance with important that users know what to privacy policies. See https://www.healthit.gov/ topic/privacy-security-and-hipaa/model-privacy- applicable State and Federal laws. Non- expect when electing to use a non- notice-mpn. covered actors have the discretion to covered actor’s product or service.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00215 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25856 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

Sub-Exception 3: Denial of an safety of the individual or another words, the ‘‘reviewable grounds’’ of Individual’s Request for Their person. In addition, we noted that if access as described in 45 CFR Electronic Protected Health Information access is denied, then the individual has 164.524(a)(3), provides that a covered in the Circumstances Provided in 45 the right to have the denial reviewed by entity may deny access provided that CFR 164.524(a)(1) and (2) a licensed health professional who is to the individual is given a right to have act as a reviewing official and did not We proposed a limited sub-exception such denials reviewed when a licensed participate in the original decision to to the information blocking provision health care professional, in the exercise deny access (see generally 45 CFR that would permit a covered entity or of professional judgment, determines 164.524(a)(3)) (84 FR 7533 and 7534). that the access requested is reasonably business associate to deny an As mentioned above with regards to individual’s request for access to their likely to endanger the life or physical the harm exception (§ 171.201) our safety of the individual or another PHI in the circumstances provided purpose is to avoid unnecessary under 45 CFR 164.524(a)(1) (2) and (3). person. In addition, we noted that if complexity. By including the access is denied, then the individual has We noted that this exception would ‘‘reviewable grounds’’ of 45 CFR avoid a potential conflict between the the right to have the denial reviewed by 164.524(a)(3) in the harm exception at a licensed health professional who is to HIPAA Privacy Rule and the § 171.201, we align these regulations in information blocking provision. act as a reviewing official and did not a way that streamlines compliance for participate in the original decision to Specifically, the HIPAA Privacy Rule actors subject to the HIPAA Privacy contemplates circumstances under deny access and the risk to be reduced Rule and this regulation. We removed must be one that would otherwise arise which covered entities, and in some the 45 CFR 164.524(a)(3) reference in instances business associates, may deny from the specific access, use, or the privacy sub-exception in exchange of EHI affected by the practice. an individual access to PHI and § 171.202(d) and moved it to the harm We proposed that if an actor who is distinguishes those grounds for denial exception in § 171.201 in order to a covered entity or its business associate which are reviewable from those which promote clarity and alignment with the are not. We proposed that this exception inter-relationship between this final rule denies an individual’s request for access applies to both the ‘‘unreviewable and the HIPAA Privacy Rule. to their PHI on the basis of these grounds’’ and ‘‘reviewable grounds’’ of In restricting this privacy sub- unreviewable grounds, and provided access. We noted that the ‘‘unreviewable exception to only ‘‘unreviewable that the denial of access complies with grounds’’ for denial for individuals grounds’’ in 45 CFR 164.524(a)(1) and the requirements of the HIPAA Privacy include situations involving: (1) Certain (2), we clarify the regulation text so that Rule in each case, then the actor would requests that are made by inmates of it is immediately clear that actors who qualify for this exception and these correctional institutions; (2) information are covered entities, and in some practices would not constitute created or obtained during research that instances business associates, may deny information blocking (84 FR 7534). includes treatment, if certain conditions an individual access to EHI of the We requested comment on this are met; (3) denials permitted by the individual and such denials would not proposed sub-exception. Privacy Act; and (4) information provide an opportunity for review of the Comments. Commenters were obtained from non-health care providers denial under certain circumstances. We concerned that HINs that are business pursuant to promises of confidentiality. clarify in the final rule that if an associates may not be authorized to In addition, we noted that two individual requests EHI under the right provide individual access on the behalf categories of information are expressly of access provision under 45 CFR of covered entity. Further, commenters excluded from the HIPAA Privacy Rule 164.524(a)(1) from an actor that must sought clarification that this sub- individual right of access: (1) comply with 45 CFR 164.524(a)(1), the exception would also apply in Psychotherapy notes, which are the actor’s practice must be consistent with circumstances where as a business notes recorded by a health care provider 45 CFR 164.524(a)(2). These associate, the HIN would deny the who is a mental health professional ‘‘unreviewable grounds’’ are related to individual’s request for access because documenting or analyzing the contents specific privacy risks or interests and of its obligations as a business associate. of a conversation during a private have been established for important counseling session and that are public policy purposes, such as when a Response. We share this concern. To maintained separate from the rest of the health care provider is providing meet this privacy sub-exception, if an patient’s medical record; and (2) treatment in the course of medical individual requests their ePHI under 45 information compiled in reasonable research or when a health care provider CFR 164.524(a)(1), the actor may deny anticipation of, or for use in, a civil, is acting under the direction of a the request in the circumstances criminal, or administrative action or correctional institution. provided in 45 CFR 164.524(a)(1) or (2). proceeding.167 Unlike the ‘‘unreviewable grounds,’’ That is, an actor that is a covered entity We noted the ‘‘reviewable grounds’’ of the ‘‘reviewable grounds’’ that are may deny an individual’s request for access as described in § 164.524(a)(3), finalized § 171.201 are directly related access to all or a portion of the PHI and which provides that a covered entity to the likelihood of harm to a patient or must meet its requirements under the may deny access provided that the another person and requires that actors HIPAA Privacy Rule. As we discussed individual is given a right to have such seeking to avail themselves of this earlier, an individual’s right under the denials reviewed under certain exception must have a reasonable belief HIPAA Privacy Rule to access PHI about circumstances. We explained that one that the practice will substantially themselves includes PHI in a designated such circumstance is when a licensed reduce a risk of harm that would record set maintained by a business health care professional, in the exercise otherwise arise from the specific access, associate on behalf of a covered entity. of professional judgment, determines use, or exchange of EHI affected by the However, if the same PHI that is the that the access requested is reasonably practice, and the harm must be one that subject of an access request is likely to endanger the life or physical would be cognizable under 45 CFR maintained in both the designated 164.524(a)(3) as a basis for denying an record set of the covered entity and the 167 See 45 CFR 164.501; 45 CFR 164.524 (a)(1)(i) individual’s right of access to their PHI designated record set of the business and (ii). in analogous circumstances. In other associate, the PHI need only be

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00216 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25857

produced once in response to the certain circumstances. As a matter of regarding whether this approach is too request for access.168 public policy, we explained that these permissive and could result in Comments. Commenters requested privacy concerns, if expressed by an unintended consequences. We also clarification that covered entities and individual and agreed to by an actor, sought comment on this proposed sub- business associates could meet this sub- would be reasonable and necessary, and exception generally, including on exception when conducting clinical an actor’s conduct in abiding by its effective ways for an individual to research with a blinded or masked agreement would, if all conditions are revoke their privacy request for designed. The EHI is typically ‘tagged’ met, be an exception to the information purposes of this sub-exception. as part of a blinded or masked research blocking provision (84 FR 7534). We also proposed that in order for a during a research study. We proposed that this proposed sub- practice to qualify for this sub- Response. To meet this privacy sub- exception would not apply under exception, an actor’s practice must be exception, if an individual requests circumstances where an actor interferes implemented in a consistent and non- their ePHI under 45 CFR 164.524(a)(1), with a use or disclosure of EHI that is discriminatory manner. This condition the actor may deny the request in the required by law, including when EHI is would provide basic assurance that the circumstances provided in 45 CFR required by the Secretary to enforce purported privacy practice is directly 164.524(a)(1) or (2). Under certain HIPAA under 45 CFR 164.502(a)(2)(ii) related to the risk of disclosing EHI limited circumstances under the Privacy and 45 CFR 164.502(a)(4)(i). Stated contrary to the wishes of an individual, Rule, a covered entity may deny an differently, this sub-exception would and is not being used to interfere with individual’s request for access to all or not operate to permit an actor to refuse access, exchange, or use of EHI for other a portion of the PHI requested. In some to provide access, exchange, or use of purposes to which this exception does of these circumstances, an individual EHI when that access, exchange, or use not apply. We noted that this condition does not a right to have the denial is required by law. We noted that this requires that the actor’s privacy- reviewed by a licensed health care sub-exception recognizes and supports protective practice must be based on professional. It is known as the public policy objective of the HIPAA objective criteria that apply uniformly ‘‘unreviewable grounds’’ for denial.169 Privacy Rule, which identifies uses and for all substantially similar privacy risks One of the ‘‘unreviewable grounds’’ disclosures of EHI for which the public (84 FR 7534 and 7535). involves individual access to ePHI in a interest in the disclosure of the We noted that under the HIPAA research study. An actor may deny individual’s information outweighs the Privacy Rule, individuals have the right access to an individual provided that individual’s interests in controlling the to request restrictions on how a covered the requested PHI is in a designated information. entity will use (as that term is defined record set that is part of a research study We proposed that this sub-exception in 45 CFR 160.103) and disclose PHI that includes treatment (e.g., clinical would permit an actor not to share EHI about them for treatment, payment, and trial) and is still in progress, provided if the following conditions are met: (1) health care operations pursuant to 45 the individual agreed to the temporary The individual made the request to the CFR 164.522(a)(1). Under 45 CFR suspension of access when consenting actor not to have their EHI accessed, 164.522(a), a covered entity is not to participate in the research. The exchanged, or used; (2) the individual’s required to agree to an individual’s individual’s right of access can be request was initiated by the individual request for a restriction (other than in reinstated upon completion of the without any improper encouragement or the case of a disclosure to a health plan research study. inducement by the actor; and (3) the under 45 CFR 164.522(a)(1)(vi)), but is actor or its agent documents the request bound by any restrictions to which it Sub-Exception 4: Sub-Exception: within a reasonable time period. agrees (84 FR 7534). Respecting an Individual’s Request Not We described that to qualify for this We proposed that if an individual To Share Information sub-exception, the request that the submitted a request to an actor not to We proposed to establish an individual’s EHI not be accessed, disclose her EHI, and the actor agreed exception to the information blocking exchanged, or used must come from the with and documents the request, the provision that would, in certain individual. Moreover, the individual request would be valid for the purposes circumstances, permit an actor not to must have made the request of this sub-exception unless and until it provide access, exchange, or use of EHI independently and without any was subsequently revoked by the if an individual has specifically improper encouragement or inducement individual. We believed that this requested that the actor not do so. This by the actor. approach would minimize compliance sub-exception was proposed in We proposed that if an individual burdens for actors while also respecting § 171.202(e). We noted that this sub- submits a request to an actor not to individuals’ requests. We sought exception is necessary to ensure that disclose her EHI, and the actor agrees comment on this proposed sub- actors are confident that they can with and documents the request, the exception generally, including on respect individuals’ privacy choices request would be valid for purposes of effective ways for individuals to revoke without engaging in information this sub-exception unless and until it is their privacy request for purposes of this blocking, and to promote public subsequently revoked by the individual. sub-exception (84 FR 7534). In the final confidence in the health IT We proposed that once the individual rule, we align with the HIPAA Privacy infrastructure by effectuating patients’ makes the request, she should not, Rule, specifically, 45 CFR 164.522(a)(2) preference about how and under what subject to the requirements of applicable which includes specific requirements circumstances their EHI will be Federal or State laws and regulations, with respect to the termination of an accessed, exchanged, and used. We have to continually reiterate her privacy individual’s restriction. Similar to the recognized in the Proposed Rule that preferences, such as having to re-submit HIPAA Privacy Rule, we include individuals may have concerns about a request every year. Likewise, we § 171.202(e)(4) to address situations permitting their EHI to be accessed, proposed that once the actor has where the individual terminates its exchanged, or used electronically under documented an individual’s request, the individual’s restriction. actor should not have to repeatedly An actor may terminate a restriction 168 45 CFR 164.524(c)(1). reconfirm and re-document the request. with the individual’s written or oral 169 45 CFR 164.524(a)(2). We requested comment, however, agreement. If the individual’s agreement

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00217 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25858 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

is obtained orally, the actor must conduct of public health surveillance health-IT market may well have document that agreement. A note in the and health care research (84 FR 7534 changed and that the individual has a certified EHR or similar notation is and 7535). right to have those changes disclosed to sufficient documentation. If the Comments. Commenters make an informed decision. Another individual agrees to terminate the recommended that we provide guidance commenter expressed a belief that not restriction, the actor may use and regarding what could be considered a asking the individual to reconfirm their disclose EHI as otherwise permitted ‘‘reasonable time period’’ under preference is too permissive. under this final rule. An actor may only § 171.202(e)(3) and to provide clarity to Response. We agree that once the access, exchange or use EHI after it health information professionals that individual makes the request to an informs the individual of the will be tasked with documenting the actor, she should not, subject to the termination. The restriction continues to individual’s privacy preferences in requirements of applicable Federal or apply to EHI accessed, exchanged or accordance with this regulation. State laws and regulations, have to used prior to informing the individual Response. In order to align with continually reiterate her privacy of the termination. That is, any EHI that HIPAA, we looked to the HIPAA preferences, such as having to re-submit had been collected before the Privacy Rule at 45 CFR 164.522 for a request every year. Likewise, we termination may not be accessed, guidance on this issue. The HIPAA finalized that once the actor has exchanged or used in a way that is Privacy Rule requires a covered entity to documented an individual’s request inconsistent with the restriction, but document a restriction of PHI, but gives within a reasonable period of time, then any information that is collected after covered entities the discretion to the actor is not required to repeatedly informing the individual of the determine the exact timing of the reconfirm and re-document the request. termination of the restriction may be documentation. The documentation Comments. A commenter used or disclosed as otherwise requirement is consistent with the recommended that the request needs to permitted under the final rule. In HIPAA Privacy Rule, which is already be in writing, and suggested that we § 171.201(e)(4), we clarify that an actor being observed by covered entities and provide guidance regarding how the must document a restriction to which it business associates. individual’s request could be has agreed. We do not require a specific Under the HIPAA Privacy Rule, a documented. Another commenter form of documentation; a note in the covered entity may voluntarily choose, requested that we develop a template certified EHR or similar notation is but is not required, to obtain the consent form whereby patients could sufficient. individual’s consent for it to use and indicate if they would like to have their A restriction is only binding on the disclose information about him or her health information disclosed to third actor that agreed to the restriction. We for treatment, payment, and health care parties and to ensure that the content of encourage actors to inform others of the operations.170 A ‘‘consent’’ document is this form would be absent of any existence of a restriction when it is not a valid permission to use or disclose ‘‘improper encouragement or appropriate to do so. If a restriction does PHI for a purpose that requires an inducement’’ and that we should work not permit an actor to disclose EHI to a ‘‘authorization’’ under the HIPAA in consultation with OCR to develop the particular person, the actor must Privacy Rule (see 45 CFR 164.508), or recommended language for a model carefully consider whether disclosing where other requirements or conditions consent form. the existence of the restriction to that exist under the HIPAA Privacy Rule for Response. We agree that an person would also violate the the use or disclosure of PHI. individual’s request and an individual’s restriction. Similarly, we believe that actors request for revocation should be in We clarified that for the purposes of should be given the discretion to writing assuming such a request is not this proposed sub-exception, the actor document an individual’s request and required or prohibited by law. may give effect to an individual’s such documentation should be within a Alternatively, an actor could document request not to have an actor disclose EHI reasonable period of time after making a conversation with an individual. Such even if State or Federal laws would such a request. Although we do not documentation could be documented in allow the actor not to follow the require the request form to be dated at a certified EHR in some manner, and if individual’s request. We explained that the time it is signed, we would the individual was provided a specific this is consistent with our position that, recommend that it be dated so that request form, the form could be absent improper encouragement or actors and others can document that the included in a certified EHR. We believe inducement, and subject to appropriate request was obtained prior to an actor’s that an individual should have conditions, it should not be considered agreement for the restriction of the sufficient opportunity to consider information blocking to give effect to individual’s access, exchange or use of whether to provide a request and that an patients’ individual preferences about EHI. What would be deemed as an actor should minimize the possibility of how their EHI will be shared or how unreasonable period of time would be coercion or undue influence and refrain their EHI will not be shared. the unreasonable delay in performance from any improper encouragement or We requested comments on this sub- and in documentation by the actor as inducement. Any form provided by the exception generally. Specifically, we well as whether there were any actor should have information provided sought comment on what would be objective manifestations of expectation in plain language that is understandable considered a reasonable time frame for expressed between the individual and to the individual. documentation. In addition, we also the actor. For example, we noted that it would sought comment on how this sub- Comments. A commenter be improper to discourage individuals exception would affect public health recommended that a reasonable time from sharing information with disclosures and health care research, if frame should balance and not burden an unaffiliated providers on the basis of an actor did not share a patient’s EHI individual or organization such as generalized or speculative risks of due to a privacy preference, including reviewing preferences with the unauthorized disclosure. On the other any effects on preventing or controlling individual each year and that the risk/ hand, we noted that if the actor was diseases, injury, or disability, and the benefit profile in the fast-changing aware of a specific privacy or security reporting of disease, injury, and vital risk, it would be proper to inform events such as births or deaths, and the 170 See 45 CFR 164.506(b). individuals of that risk. Likewise, an

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00218 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25859

actor would be permitted to provide an an individual is unavailable to provide We emphasized (84 FR 7535) that, individual with general information a revocation. The commenter was while the importance of security about her privacy rights and options, concerned that if the EHI was not practices cannot be overstated, the including for example, the option to not disclosed to health care provider in an proposed exception would not apply to provide consent, provided the emergency, the individual could be all practices that purport to secure EHI. information is presented accurately, subject to imminent harm or death. Rather, we stated that the exception does not omit important information, Response. In the Proposed Rule would only be available when the and is not presented in a way that is (proposed § 171.202(e)), we did not actor’s security-based practice satisfies likely to improperly influence the provide how an individual could revoke the conditions applicable to this individual’s decision about how to her privacy agreement with the actor. In exception.171 We noted that it would exercise their rights. response, we included in the final rule not be appropriate to prescribe a It is important to note that the sub- in § 171.202(e)(4) to specifically address ‘‘maximum’’ level of security or to exception conditions in the regulation the termination of an individual’s dictate a one-size-fits-all approach for are not intended to preempt any request. In order to address these all actors as that may not be appropriate applicable Federal, State, or local laws specific circumstances and align with in all circumstances and may not that may require additional information the HIPAA Privacy Rule, we agree that accommodate new threats, to be disclosed for an agreement to be an individual’s restriction may need to countermeasures, and best practices in a legally effective. We will continue to be compromised in emergency rapidly changing security landscape. We work in consultation with OCR to treatment situations, and we have further noted that we did not intend for develop resources as necessary to finalized that an actor may terminate an the proposed exception to dictate a support actors’ compliance with the individual’s request for a restriction to specific security approach. Moreover, conditions of this Privacy Exception. not provide access, exchange or use of we emphasized that effective security Comments. Commenters requested EHI under limited circumstances. best practices focus on the mitigation greater clarity on how this regulation c. Security Exception—When will an and remediation of risks to a reasonable would affect public health disclosures actor’s practice that is likely to interfere and acceptable level. and health care research, if an actor did with the access, exchange, or use of With consideration of the above (84 not share a patient’s EHI due to a electronic health information in order to FR 7535), we proposed that actors privacy preference, including any protect the security of electronic health would be able to satisfy the exception effects on preventing or controlling information not be considered through practices that implement either diseases, injury, or disability, and the security policies and practices information blocking? reporting of disease, injury, and vital developed by the actor, or case-by-case We proposed in the Proposed Rule (84 events such as births or deaths, and the determinations made by the actor. We FR 7535 through 7538) to establish an conduct of public health surveillance proposed that whether a security- exception to the information blocking and health care research. motivated practice meets this exception Response. With regard to public provision that would permit actors to would be determined on a case-by-case health disclosures, to the extent that engage in practices that are reasonable basis using a fact-based analysis of the such disclosures are required by law, and necessary to promote the security of conditions set forth in the Proposed the actor would not be in a position to EHI, subject to certain conditions. We Rule. grant the patient’s request for explained that, without this exception, We emphasized (84 FR 7535) that the restriction. With regard to EHI used for actors may be reluctant to implement practices implemented by a single research, the unavailability of the security measures or engage in other physician office with limited technology individual’s information resulting from activities that are reasonable and resources, for example, will be different a restriction would be consistent with necessary for safeguarding the to those implemented by a large health the patient’s right to withhold confidentiality, integrity, and system, and that this difference does not authorization for research uses and availability of EHI. This could affect an actor’s ability to qualify for this disclosures. However, an Institutional undermine the ultimate goals of the exception. The fact-based approach that Review Board may approve a consent information blocking provision by we proposed would allow each actor to procedure that alters some or all of the discouraging best practice security implement policies, procedures, and elements of informed consent, or waive protocols and diminishing the reliability technologies that are appropriate for its the requirement to obtain informed of the health IT ecosystem. particular size, organizational structure, consent under HHS regulations at 45 We noted (84 FR 7535) that robust and risks to individuals’ EHI. We noted CFR 46.116(c), and to the extent that the security protections are critical to that a fact-based analysis also aligns researcher has obtained a waiver of promoting patients’ and other with the HIPAA Security Rule 172 informed consent, research could be stakeholders’ trust and confidence that concerning the security of ePHI. The compromised by the unavailability of EHI will be collected, used, and shared HIPAA Security Rule requires HIPAA certain EHI. One possible way to resolve in a manner that protects individuals’ covered entities or business associates this issue would be the establishment of privacy and complies with applicable to develop security practices and a field that actors covered could check legal requirements. We also noted that implement administrative, physical, and in a certified EHR that would indicate public confidence in the security of that restrictions have been applied to their EHI has been challenged by the 171 In the Proposed Rule (84 FR 7535), we used the individual’s EHI (without providing growing incidence of cyber-attacks in the phrase ‘‘conditions applicable to this detail of the nature of such restriction). the health care sector. More than ever, exception’’ to mean the conditions (inclusive of requirements within specific conditions) of the In this case, actors could exclude the we explained, health care providers, exception applicable to a particular practice in a individual’s EHI from research. health IT developers, HIEs and HINs particular circumstance. Where we are not Comments. A commenter suggested must be vigilant to mitigate security summarizing what we stated in the proposed rule, that EHI should be accessed, exchanged risks and implement appropriate in this preamble we have generally used plainer- language phrasings, such as ‘‘the conditions of the or used despite a patient’s privacy safeguards to secure the EHI they exception that are applicable to a practice [in the agreement with an actor in emergency collect, maintain, access, use, and particular circumstances].’’ treatment situations particularly when exchange. 172 45 CFR 164.306, 308, 310, and 312.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00219 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25860 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

technical safeguards that take into security may present novel and practices meet the conditions in account: The entity’s size, complexity, unexpected threats that even a best- § 171.203 to qualify for the exception. and capabilities; technical, hardware, practice risk assessment and security Response. We appreciate commenters’ and software infrastructure; the costs of policy cannot anticipate. We stated that feedback. We have finalized the security measures; and the likelihood if a practice that does not implement an exception in § 171.203, with some and possible impact of potential risks to organizational security policy is to modification to the regulation text. We ePHI.173 We noted (84 FR 7535 and qualify for this exception; however, it have changed the title of the exception 7536), however, that while our proposed must meet certain conditions. The from ‘‘Exception—Promoting the approach would be consistent with the public comments received, our security of electronic health regulation of security practices under responses to these comments, and the information’’ in the Proposed Rule (84 the HIPAA Security Rule, the fact that conditions as finalized in § 171.203 are FR 7603) to ‘‘Security Exception—When a practice complies with the HIPAA discussed below in this section of this will a practice likely to interfere with Security Rule would not establish that final rule preamble. access, exchange, or use of electronic it meets the conditions of the exception We encouraged comment on these health information in order to protect to the information blocking provision. conditions (84 FR 7538), and our overall the security of electronic health We emphasized (84 FR 7536) that the approach to the proposed exception, information not be considered HIPAA Security Rule and the proposed including whether our proposal information blocking?’’ Throughout this exception have different foci. The provided adequate flexibility for actors final rule preamble, we use ‘‘Security HIPAA Security Rule establishes a to implement measures that are Exception’’ as a short form of this title, baseline by requiring certain entities to commensurate to the threats they face, for ease of reference. As stated in ensure the confidentiality, integrity, and the technology infrastructure they Section VIII.D of this final rule availability of ePHI by implementing possess, and their overall security preamble, we have changed the titles of security measures, among other profiles and, equally important, whether all of the exceptions to questions to safeguards, that the entities determine this exception adequately mitigates the improve clarity. We have edited the are sufficient to reduce risks and risk that actors will adopt security wording of the introductory text of vulnerabilities to a reasonable and policies that are unnecessarily § 171.203 as finalized, in comparison to appropriate level. In contrast, we restrictive or engage in practices that that proposed (84 FR 7603) so that it is explained that the purpose of the unreasonably interfere with access, consistent with the finalized title of exception to the information blocking exchange, or use of EHI. Commenters § 171.203. We believe these conforming provision is to provide flexibility for were encouraged to propose additional changes in wording of the introductory reasonable and necessary security conditions that may be necessary to text also improve clarity of expression practices without excepting from the ensure that the exception is tailored and in this section. definition of information blocking in does not extend protection to practices Comments on specific conditions are § 171.103 practices that purport to that are not reasonable and necessary to summarized below, in context of each promote the security of EHI but that are promote the security of EHI and that condition proposed. We believe our unreasonably broad and onerous on could present information blocking responses to these comments furnish the those seeking access to EHI, not applied concerns. We also requested comment clarity actors need to understand the consistently across or within an on whether the use of consensus-based conditions and of the exception organization, or otherwise may standards and guidance provides an finalized in § 171.203 for practices unreasonably interfere with access, appropriate reference point for the likely to interfere with access, exchange, exchange, or use of EHI. development of security policies. or use of EHI in order to protect the To qualify for this exception, we Finally, we asked commenters to offer security of EHI to be considered proposed that an actor’s conduct must an alternative basis for identifying excepted from the definition of satisfy threshold conditions. As practices that do not offer a security information blocking in § 171.103. discussed in detail in the Proposed Rule benefit (compared with available Condition: The Practice Must Be (84 FR 7535 through 7538), the alternatives) but that cause an Directly Related to Safeguarding the particular security-related practice must information blocking harm by Confidentiality, Integrity, and be directly related to safeguarding the interfering with access, exchange, or use Availability of Electronic Health confidentiality, integrity, and of EHI (84 FR 7538). Information availability of EHI, implemented Comments. We received several consistently and in a non- comments supporting, and did not We proposed that, as a threshold discriminatory manner, and tailored to receive any comments opposed to, the condition, the exception would not identified security risks (84 FR 7535). establishment of the Security Exception. apply to practices that are not directly We also proposed (84 FR 7537) that We also received no comments offering related (84 FR 7536) to safeguarding the where an actor has documented security an alternative basis for identifying security of EHI. We explained that, in policies that align with applicable practices that do not offer a security assessing the practice, we would consensus-based standards, and where benefit (compared with other available consider whether and to what extent the the policies are implemented in a alternatives) but that cause an practice directly addressed specific consistent and non-discriminatory information blocking harm by security risks or concerns. We noted manner, a practice’s conformity with interfering with access, exchange, or use that we would also consider whether such policies would provide a degree of of EHI to a greater degree than the practice served any other purposes assurance that the practice was necessary. We received a number of and, if so, whether those purposes were reasonable and necessary to address comments requesting additional merely incidental to the overriding specific security risks and thus should guidance about how the exception’s security purpose or provided an not constitute information blocking. We conditions can be met in practice. objectively distinct, non-security-related also stated in the Proposed Rule (84 FR Commenters asked questions about, or rationale for engaging in the practice. 7537) that we recognize that EHI recommended that we furnish We noted (84 FR 7536) that it should additional guidance on how an actor not be particularly difficult or onerous 173 45 CFR 164.306(b) might determine which a security for an actor to demonstrate that its

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00220 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25861

practice was directly related to a context of the requirement to meet all availability, also known as the CIA specific security risk or concern. For conditions at all relevant times. triad, is a model designed to guide example, we explained that the actor Response. While fact-based analysis policies for information security may show that the practice was a direct may not be as simple as determining if practices within an organization. The response to a known security incident a particular security practice does or elements of the triad are considered the or threat; or that the practice directly does not conform to a pre-specified three most crucial components of related to the need to verify a person’s approach, we believe that it is the most information security practices.175 In identity before granting access to EHI; or practical approach given the inherent assessing whether a practice meets the that the practice was directly related to complexity of the regulatory and threat condition finalized in § 171.203(a), the ensuring the integrity of EHI. landscapes relevant to an actor’s information that we would expect to We emphasized (84 FR 7536) that the cybersecurity practices. This landscape consider includes, but is not necessarily salient issue under this condition, complexity contributes substantially to limited to, the actor’s purported basis therefore, would be whether the security our belief that a one-size-fits-all detailed for adopting the particular security practice was actually necessary and definition or test for security measures practice, which could be evidenced by directly related to the specific security or methods to be deemed ‘‘directly the actor’s organizational security risk being addressed. To that end, we related’’ to safeguarding the policy, risks assessments the actor had noted that we would consider the confidentiality, integrity, and performed that informed the actor’s actor’s purported basis for adopting the availability of EHI would not be the security-based practice(s), and other particular security practice, which optimal approach at this time. We have relevant documentation that an actor could be evidenced by the actor’s not established a specific, regulatory maintains. We also reiterate our organizational security policy, risk definition for ‘‘directly related’’ as we observation that many actors are also assessments, and other relevant are using both ‘‘directly’’ and ‘‘related’’ HIPAA covered entities or business documentation, which most actors are in their ordinary meanings.174 associates. For that reason, many actors already required to develop pursuant to With respect to the condition that a are likely to have, pursuant to their requirements under the HIPAA Rules. practice meet all conditions in § 171.203 meeting the requirements of the HIPAA However, we proposed that the at all relevant times in order to satisfy Security Rule, documentation relevant documentation of an actor’s decision the exception, we do not believe it to showing their security-based making would not necessarily be would be particularly difficult, in practice(s) satisfy the Security dispositive. For example, we noted that context of a fact-specific analysis, for an Exception condition that is finalized in if the practice had the practical effect of actor to demonstrate that its practice § 171.203(a).176 disadvantaging competitors or steering was directly related to a specific referrals, this could be evidence that the security risk or concern. For example, Condition: The Practice Must Be practice was not directly related and the actor may show that the practice Tailored to the Specific Security Risk tailored to the specific security risk. We was a direct response to a known Being Addressed proposed that such an inference would security incident or threat, or that the To meet the exception, we proposed also not be warranted where the actor practice was directly related to the need (84 FR 7536) that an actor’s security- has not met the other conditions of this to verify a person’s identity before related practice must be tailored to exception, as where the actor’s policies granting access to EHI. We also note specific security risks that the practice were not developed or implemented in that, although we encourage actors to actually addressed. We explained that a reasonable manner; its security voluntarily conform their practices to this condition necessarily presupposes policies or practices were not tailored to the conditions of an exception suited to that an actor has carefully evaluated the specific risks; or it applied its security the practice and its purpose, an actor’s risk posed by the security threat and policies or practices in an inconsistent choice to do so simply provides it an developed a considered response that is or discriminatory manner. enhanced level of assurance that the tailored to mitigating the vulnerabilities Comments. We received a number of practices do not meet the definition of of the actor’s health IT or other related comments supporting the applicability information blocking. Failure to meet an systems. of this exception to practices directly exception does not necessarily mean a Comments. Commenters expressed related to safeguarding the practice meets the definition of concerns with what commenters confidentiality, integrity, and information blocking. If subject to an described as the complexity of fact- availability of EHI and that are investigation by HHS, each practice that based analysis and use of terms such as consistent with the HIPAA Security implicates the information blocking ‘‘tailored.’’ Commenters stated that Rule. We received no comments provision and that does not meet any analyzing their policies and practices recommending that this exception not exception would be analyzed on a case- against such standards could be be applicable to such practices. by-case basis. burdensome, especially in context of the Response. We have finalized this The overarching purpose of the requirement to meet all conditions at all condition as proposed. In order to meet Security Exception is to provide relevant times. this specific condition (finalized in flexibility for reasonable and necessary Response. While fact-specific analysis § 171.203(a)), a practice must be directly security practices while screening out may not be as simple as determining if related to safeguarding the practices that purport to promote the a particular security practice does or confidentiality, integrity, and security of EHI but that otherwise does not conform to a pre-specified availability of EHI. unreasonably and/or unnecessarily approach, we believe that it is the most Comments. Commenters expressed interfere with access, exchange, and use practical approach given the inherent concerns with what commenters of EHI. Confidentiality, integrity and complexity of the regulatory and threat described as the complexity of fact- landscapes relevant to an actor’s based analysis and use of terms such as 174 Ordinary meanings of the adverb ‘‘directly’’ cybersecurity practices. This landscape ‘‘directly related.’’ Commenters stated and the adjective ‘‘related’’ in American usage can be found in widely published dictionaries, such as that analyzing their policies and The American Heritage Dictionary of the English 175 See NIST Special Publication 800–12, revision practices against such standards could Language, Dictionary.com, or Merriam- 1, An Introduction to Information Security. be burdensome, especially in the Webster.com. 176 45 CFR 164.316

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00221 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25862 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

complexity contributes substantially to to the need to verify a person’s identity security requirements must be imposed our belief that a one-size-fits-all before granting access to EHI, it would in a non-discriminatory manner. We definition or test for security measures be logical to expect the practice would noted that this would mean, for or methods to be deemed conformant also be tailored to address that need. example, that if a developer imposed a with the condition finalized in Comments. Commenters requirement that third-party apps § 171.203(b) would not be the optimal recommended that actors should be include two-factor authentication for approach at this time. Instead, we have permitted to develop and implement patient access, the developer would finalized the condition proposed in security policies that exceed the need to ensure that the same § 171.201(b) as proposed. We believe minimum requirements of HIPAA with requirement was imposed on, and met requiring that the actor’s policies and the intent to promote data security or to by, all other apps, including any apps practices be tailored to the risk being comply with State law or policies. made available by the developer itself. addressed is currently the most Response. If its conditions are We also noted that such a developer appropriate and practical approach. We otherwise met, this exception would requirement must also meet the other intend for this exception to be apply to security-based practices that conditions of the exception (e.g., the applicable to a wide array of practices exceed the minimum conditions of the condition that the practice be tailored to that are reasonable and necessary to HIPAA Security Rule. As would be the the specific security risk being protect the security of EHI in various case with a practice implemented to addressed). actors’ specific operational contexts. In comply with the HIPAA Security Rule Comments. We received no comments assessing whether a practice meets the requirements, the fact that a practice opposed to the condition that practices condition finalized in § 171.203(b), we was implemented to meet another must be implemented in a consistent would consider whether and to what applicable legal mandate would be and non-discriminatory manner. We did extent the practice directly addresses considered in assessing whether a receive one comment recommending specific security risks or concerns and practice meets this exception. However, that we recognize under this exception whether it was tailored to those risks. a practice that is consistent with a law risk-based cybersecurity practices that We would also consider whether the or regulation setting a minimum may result in applying different security practice served any other purposes and requirement for protecting requirements to different exchange if so, whether those purposes were confidentiality, integrity, and partners based on risk posed. merely incidental to an overriding availability of EHI might not meet this Response. We intend this exception, security purpose or provided an exception. For example, a practice that including but not limited to this specific objectively distinct, non-security related is consistent with a minimum legal condition, to allow for recognition of rationale for engaging in the practice. condition related to the security of EHI risk-based security practices. We also believe the ordinary meaning of might not meet this exception if it is not Assessment of whether practices satisfy ‘‘tailored’’ 177 provides sufficient clarity also tailored to avoid interfering with the conditions of this exception will be that we expect the practices to be made the access, exchange, or use of EHI to a fact-based. We also recognize that or adapted to serve the particular greater extent than reasonable and objectively reasonable practices applied purpose or need for which they are necessary to appropriately mitigate the on the basis of the cybersecurity risks deployed. With respect to the risk it addresses. posed by particular system connections requirement that a practice meet all We have finalized this condition in or data exchanges may result in conditions in § 171.203 at all relevant § 171.203(b) without modification to the practices that are tailored to this risk times in order to satisfy the exception, text of this condition as proposed (84 FR and thus not necessarily identical across we do not believe it would be 7603). all connections, interchanges, and therefore all individuals or entities with particularly difficult, in context of a Condition: The Practice Must Be whom an actor engages. In context of fact-specific analysis, for an actor to Implemented in a Consistent and Non- this condition of the Security Exception, demonstrate that each practice was Discriminatory Manner ‘‘consistent and non-discriminatory’’ made or adapted to serve the particular We proposed (84 FR 7536 and 7537) purpose or need for which is was should be understood to mean that that in order for a practice to qualify for similarly situated actors whose deployed. For example, where a practice this exception, the actor’s practice must meets the condition finalized in interactions pose the same level of have been implemented in a consistent security risk should be treated § 171.203(a) by being a direct response and non-discriminatory manner. We to a known security incident or threat, consistently with one another under the explained that this condition would actor’s security practices. Inconsistent it logically follows that the practice provide basic assurance that the should also be made or adapted to the treatment across similarly situated purported security practice is directly actors whose interactions pose the same purpose of responding to such incident related to a specific security risk and is or threat. In which case, the practice’s level of security risk based on not being used to interfere with access, extraneous factors, such as whether they inherent characteristics would support exchange, or use of EHI for other the actor’s ability to show that it meets are a competitor of the actor purposes to which this exception does implementing the security practices, the condition finalized in § 171.203(b). not apply. Similarly, where an identity-proofing would not be considered appropriate. As an illustration solely of the non- We have finalized this condition as practice satisfies the condition finalized discriminatory manner condition (84 FR proposed. It is codified in § 171.203(c). in § 171.203(b) by being directly related 7536 and 7537), we discussed a hypothetical example of a health IT Condition Applicable to Practices That 177 See, e.g., sense 1.b. of the entry for the verb developer of certified health IT that Implement an Organizational Security ‘‘tailor’’ in the Merriam-Webster dictionary: ‘‘to Policy make or adapt to suit a special need or purpose’’ offers apps to its customers via an app (https://merriam-webster.com/dictionary/tailor, last marketplace. We stated that if the We discussed in the Proposed Rule accessed Feb. 6, 2020). See also, e.g., sense 3 of the developer requires that third-party apps (84 FR 7537) that an actor’s approach to entry for the verb ‘‘tailor’’ in The American Heritage information security management Dictionary of the English Language: ‘‘to make, alter, sold (or made available) via the or adapt for a particular end or purpose’’ (https:// developer’s app marketplace meet would reflect the actor’s particular size, ahdictionary.com, last accessed Feb 6, 2020). certain security requirements, those organizational structure, and risk

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00222 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25863

posture. Because of this, we emphasized the condition applicable to practices § 171.203(d)(2) with a revision to the that actors should develop and that implement an organizational wording of the regulation text in implement organizational policies that security policy (§ 171.203(d)) in more comparison with that proposed (84 FR secure EHI. We proposed that, where an detail below. 7603). Specifically, we have replaced actor has documented security policies Paragraph (d)(1): Security Policy in ‘‘and respond directly to’’ that appeared that align with applicable consensus- Writing in the regulation text with ‘‘and be based standards, and where the policies directly responsive to’’ in the text are implemented in a consistent and We proposed that the actor’s security finalized in § 171.203(d)(2). Thus, the non-discriminatory manner, a practice’s policy must be in writing (84 FR 7537). finalized text in § 171.203(d)(2) reads: conformity with such policies would This requirement is applicable to ‘‘have been prepared on the basis of, provide a degree of assurance that the practices that implement an and be directly responsive to, security practice was reasonable and necessary organizational security policy and is risks identified and assessed by or on to address specific security risks and consistent with the HIPAA Security behalf of the actor.’’ 178 thus should not constitute information Rule. The importance of written We made this editorial revision blocking. security policies is also consistent with because we believe it makes the We stated (84 FR 7537) that a practice consensus-based standard and best 179 resulting regulation text easier to read. that went beyond an actor’s established practice guidance. Although actors may have obligations Comments. We received no comments policies or procedures by imposing under other existing law or regulations, opposed to this condition proposed in security controls that were not such as the HIPAA Security Rule, to documented would not qualify for this § 171.203(d). Response. Within the condition conduct security risk assessments, this exception under this condition condition, which is applicable to (although the actor may be able to (§ 171.203(d)) applicable to practices that implement an organizational security-based practices that implement qualify under the alternative basis for an organizational security policy, does practices that do not implement a security policy, we have finalized in § 171.203(d)(1) the requirement that the not establish a set threshold for an security policy). We further stated that actor’s proficiency in identifying, such practices would be suspect under policy must be in writing. We have finalized this condition as proposed. assessing, and responding to security the information blocking provision if risks. If any actor believes it may lack there were indications that the actor’s Paragraph (d)(2): Security Risks the technical or other expertise security-related justification was a Identified and Assessed necessary to conduct a risk assessment pretext or after-the-fact rationalization appropriate to its operations and the for its conduct or was otherwise We proposed (84 FR 7537) that the actor’s security policy must be informed EHI for which it is responsible, we unreasonable under the circumstances. would encourage that actor to seek We reiterated (84 FR 7537) that, to the by an assessment of the security risks additional information, training, or extent that an actor seeks to justify a facing the actor. While we did not support from an individual or entity practice on the basis of its propose any requirements as to a risk with the required expertise. As finalized organizational security policies, such assessment, we noted that a good risk in § 171.203(d)(2), the requirement that policies must be in writing and assessment would use an approach 180 risks have been identified and assessed implemented in a consistent and non- consistent with industry standards, expressly provides for this to have been discriminatory manner. We emphasized and would incorporate elements such as done either by the actor or on the actor’s that what a policy requires will depend threat and vulnerability analysis, data behalf. We are sensitive to the on the facts and circumstances. collection, assessment of current possibility that some actors, including However, we proposed that to support security measures, likelihood of but not limited to small clinician a presumption that a practice conducted occurrence, impact, level of risk, and 181 practices, may not be in a position to pursuant to the actor’s security policy final reporting. meet the condition finalized in was reasonable, the policy would have Comments. We received no comments paragraph (d) of § 171.203 immediately to meet conditions stated and discussed opposed to requiring a linkage between or for all of their security-based in Section VIII.D.3 of the Proposed Rule an organization’s security policy and a practices, and we therefore reiterate that (84 FR 7537). The details within risk assessment. We did receive a we have finalized in § 171.203(e) an paragraph (d) of § 171.203 were couple of comments expressing a alternative condition that an actor may proposed in regulation text (84 FR concern that not all actors may yet be choose to meet in circumstances where 7603). The detailed requirements of the proficient in identifying and assessing it may not be practical for them to meet condition as proposed in § 171.203(d) the risks associated with specific health the condition finalized in § 171.203(d). were: If the practice implements an IT functionalities, such as standards- organizational security policy the policy based APIs. We also reiterate that, while we do must— Response. Within the condition encourage actors to voluntarily conform • Be in writing; (§ 171.203(d)) applicable to practices their practices to the conditions of an • Have been prepared on the basis of, that implement an organizational exception suited to the practice and its and directly respond to, security risks security policy, we have finalized purpose, an actor’s choice to do so identified and assessed by or on behalf simply provides them an enhanced level of the actor; 178 45 CFR 164.316 of assurance that the practices do not • Align with one or more applicable 179 See SP 800–53 Rev. 5 Security and Privacy meet the definition of information Controls for Information Systems and consensus-based standards or best Organizations. blocking. Failure to meet an exception practice guidance; and 180 See OCR, Guidance on Risk Analysis, https:// does not necessarily mean a practice • Provide objective timeframes and www.hhs.gov/hipaa/for-professionals/security/ meets the definition of information other parameters for identifying, guidance/guidance-risk-analysis/ blocking. If subject to an investigation responding to, and addressing security index.html?language=es. by HHS, each practice that implicates 181 ONC and OCR have jointly launched the HHS incidents. HIPAA Security Risk Assessment (SRA) Tool, the information blocking provision and We discuss each of these https://www.healthit.gov/providers-professionals/ that does not meet any exception would requirements (subparagraphs) within security-risk-assessment-tool. be analyzed on a case-by-case basis.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00223 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25864 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

Paragraph (d)(3): Consensus-Based promoting the security of EHI rather align with one or more consensus-based Standards or Best Practice Guidance than taking a reactive stance. standards or best practice guidance We proposed (84 FR 7537) that the Commenters contended that for novel documents. An actor’s written security actor’s policy must align with one or threats, consensus-based standards and policies should be based on consensus- more applicable consensus-based best practice guidance may not exist, based standards or best practice standards or best practice guidance. We making it impossible for an actor to guidance documents which specifically noted that at present, examples of meet the condition that the address security risks and threats. A relevant best practices for development organizational security policy align with security policy should be clearly written of security policies include, but are not such standards. and observed and refers to clear, Response. With cybersecurity risk limited to: NIST–800–53 Rev. 5; the comprehensive, and well-defined plans, continuously evolving and the large rules, and practices that regulate access NIST Cybersecurity Framework; and number of threat sources active in the to an actor’s information systems and NIST SP 800–100, SP 800–37 Rev. 2, SP modern cybersecurity landscape, we the EHI included in it. We believe a 800–39, as updated and as interpreted recognize that actors must continuously good policy serves as a prominent through formal guidance. We noted that monitor, assess, and respond to security statement to the outside world about the best practice guidance on security risks that can themselves represent an actor’s commitment to security, and that policies is also developed by consensus impediment to EHI access, exchange, such a policy should be based on standards bodies such as ISO, IETF, or and use. Thus, this exception allows objective consensus-based standards IEC. We stated that HIPAA covered actors flexibility in selecting and and should not be ad hoc or arbitrary. entities and business associates may be tailoring their practices to mitigate We do agree that there are emerging able to leverage their HIPAA Security specific security risks, provided each and novel security threats that occur, Rule compliance activities and can, if such practice otherwise meets the and in those situations which are not they choose, align their security policy conditions of this exception, notably specifically addressed by an actor’s with those parts of the NIST including that it be directly related and security policies, we included in the Cybersecurity Framework that are tailored to the specific security risk exception as proposed an alternative referenced in the HIPAA Security Rule being addressed and be implemented in condition (proposed in § 171.203(e)) to Crosswalk to NIST Cybersecurity a consistent and non-discriminatory address those situations in which those Framework to satisfy this condition. We manner. We also note that best security security risks can be addressed based on noted that relevant consensus-based practices in security mitigation can take particularized facts and circumstances. standards and frameworks provide a proactive as well as a reactive Within the condition (§ 171.203(d)) actors of varying sizes and resources approach. A documented policy that applicable to practices that implement with the flexibility needed to apply the provides explicit references to an organizational security policy, the right security controls to the right consensus-based standards and best actor’s policy must align with one or information systems at the right time to practice guidance (such as the NIST more applicable consensus-based adequately address risk. Cybersecurity Framework) offers an standards or best practice guidance. The Comments. One commenter expressed objective and robust means by which we finalized condition is codified in a concern that a small independent can evaluate the reasonableness of a § 171.203(d)(3). clinician practice that conducts a risk particular security control for the analysis consistent with its obligation Paragraph (d)(4): Objective Timeframes purpose of the exception. We also and Other Parameters under the HIPAA Security Rule may recognize that, as a practical matter, lack the technical expertise or other some actors (such as small health care We proposed that the actor’s security organizational capabilities needed to providers or those with limited policy must provide objective develop a customized security policy resources) may have organizational timeframes and common terminology that appropriately applies consensus- security policies that are less robust or used for identifying, responding to, and based standards to each risk identified. that otherwise fall short of the minimum addressing security incidents. We noted This commenter recommended that we conditions proposed. In such examples of acceptable sources for incorporate in § 171.203(d) regulation circumstances an actor can still benefit development of a security response plan text a statement that these conditions from this exception by demonstrating include: NIST Incident Response apply ‘‘subject to the actor’s that the practice met the conditions of Procedure (https://csrc.nist.gov/ sophistication and technical this exception for circumstances where publications/detail/sp/800-61/rev-2/ capabilities.’’ no formal (organizational) security final), US–CERT for interactions with Response. We appreciate the point policy was implemented (see our government systems (https://www.us- highlighted by the commenter that, even discussion under ‘‘conditions applicable cert.gov/government-users/reporting- within a given type of actor, specific to practices that do not implement an requirements), and ISC–CERT for individuals or organizations may have organizational security policy’’ header, critical infrastructure (https://ics- different operational contexts that below within this section of this final cert.us-cert.gov/) (84 FR 7537). include variations in their technical rule preamble). As a point of clarification, we noted capabilities, expertise, and other Comments. A commenter noted that it that an actor’s compliance with the resources. We do not, however, believe could be a difficult for an actor to meet HIPAA Security Rule (if applicable to it is necessary to revise the regulation the standard to that the actor’s the actor) would be relevant to, but not text as recommended in order to allow organizational policy on security must dispositive of, whether the actor’s for assessment of whether the actor’s align with one or more consensus-based policies and procedures were practices, such as its organizational standards or best practice guidance objectively reasonable for the purpose of security policy, were objectively because there are many emerging the exception. We explained that an reasonable in the circumstances in security threats that occur that are new actor’s documentation of its security which they were implemented. and unexpected. policies and procedures for compliance Comments. A number of commenters Response. We do not believe that it with the HIPAA Security Rule may not requested that this exception allow would be difficult for an actor’s offer a sufficient basis to evaluate providers to be proactive when organizational policy on security to whether the actor’s security practices

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00224 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25865

unnecessarily interfere with access, interfere with access, exchange or use of whether there were reasonable and exchange, or use of EHI. We further EHI. appropriate alternatives that were less noted that a documented policy that We noted (84 FR 7538) that an actor’s likely to interfere with access, exchange, provides explicit references to consideration of reasonable and or use of EHI, but where the initial- consensus-based standards and best appropriate alternatives will depend on response practice may be in place for practice guidance (such as the NIST the urgency and nature of the security only a short while. Presumably, such Cybersecurity Framework) would offer threat in question. We further noted that initial-response practices are in place an objective and robust means by which we anticipate that an actor’s for only a short time precisely because, to evaluate the reasonableness of a qualification for the exception would upon more fully identifying and particular security control for the accommodate exigent circumstances. assessing current risks in context or as purpose of the exception (84 FR 7537). For example, we stated that we would follow-up to the exigent circumstances, Comments. We received no comments not expect an actor to delay the the actor will have concluded it carried opposing this requirement of the implementation of a security practice in a greater than necessary burden— condition applicable to practices that response to an emergency on the basis including the burden of interference implement an organizational security that it has not yet been able to initiate with access, exchange or use of EHI— policy. a fully realized risk assessment process. and consequently modified or replaced Response. Within the condition However, we also stated that we would its initial-response practice with a less (§ 171.203(d)) applicable to practices expect that in these exigent onerous alternative that was reasonable circumstances, where the actor has that implement an organizational and appropriately tailored to the implemented a security practice without security policy, we have finalized in specific risk addressed. first considering whether there were Comments. A commenter agreed that § 171.203(d)(4) the condition that the reasonable and appropriate alternatives this exception allows for an actor to actor’s organizational security policy that were less likely to interfere with maintain flexibility in its approach to ‘‘provide objective timeframes and other access, exchange or use of EHI, the actor address security incidents or threats. parameters for identifying, responding would expeditiously make any Response. We agree that this to, and addressing security incidents.’’ necessary changes to the practice based exception provides an actor the We have finalized this condition as on the actor’s re-consideration of flexibility to address security incidents proposed. reasonable and appropriate alternatives or threats based on particularized facts Condition Applicable to Practices That that are less likely to interfere with and circumstances which are necessary Do Not Implement an Organizational access, exchange or use of EHI. We to mitigate the security risk to EHI, Security Policy proposed that the exception would provided that there are no reasonable apply in these instances so long as an and appropriate alternatives to the In the Proposed Rule (84 FR 7537), we actor takes these steps and complies practice that address the security risk recognized that, as a practical matter, with all other applicable conditions. that are less likely to interfere with, some actors (such as small health care Comments. Commenters stated that prevent, or materially discourage access, providers or those with limited the absence of a policy means that one exchange or use of EHI. resources) may have organizational is dealing with an unexpected and We have finalized as proposed, in security policies that are less robust or evolving situation as best one can (e.g., § 171.203(e), the requirements that otherwise fall short of the minimum a sustained and sophisticated attack). applicable to practices that meet the conditions proposed. We proposed that Commenters suggested we create a threshold conditions established in in these circumstances an actor could further ‘‘safety valve’’ for short-lived §§ 171.203(a), (b) and (c) and that do not still benefit from the exception by actions that are taken in good faith implement an organizational security demonstrating that the practice at issue while a situation is being evaluated and policy. was objectively reasonable under the understood and that we should d. Infeasibility Exception—When will circumstances, without regard to a recognize the valid need to allow for an actor’s practice of not fulfilling a formal policy. While we noted in the due diligence as distinct from simply request to access, exchange, or use Proposed Rule (84 FR 7537) that we delaying access and such due diligence electronic health information due to the expect that most security practices should not need the Security Exception infeasibility of the request not be engaged in by an actor will implement to avoid implicating or being judged as considered information blocking? an organizational policy, we recognized engaged in information blocking. We proposed in the Proposed Rule in that EHI security may present novel and Commenters stated this is a core need § 171.205 (84 FR 7542 and 7603) to unexpected threats that even a best- for small medical practices with limited establish an exception to the practice risk assessment and security resources. information blocking provision that policy cannot anticipate. We noted that Response. We anticipate that the would permit an actor to decline to if a practice that does not implement an exception’s conditions as proposed and provide access, exchange, or use of EHI organizational policy is to qualify for finalized would accommodate exigent in a manner that is infeasible, provided this exception, however, it must meet circumstances. For example, we would certain conditions are met. We proposed certain conditions. We stated that the not expect an actor to delay the that in certain circumstances legitimate actor’s practice must, based on the implementation of a security measure in practical challenges beyond an actor’s particularized facts and circumstances, response to an emergency such as a control may limit its ability to comply be necessary to mitigate the security cyberattack simply because it has not with requests for access, exchange, or risk. Importantly, we proposed that the yet been able to implement a fully use of EHI. In some cases, the actor may actor would have to demonstrate that it realized risk assessment process. We not have—and may be unable to considered reasonable and appropriate believe the exception as posed does obtain—the requisite technological alternatives that could have reduced the provide a ‘‘safety valve’’ for situations capabilities, legal rights, financial likelihood of interference with access, where an actor in direct response to resources, or other means necessary to exchange, or use of EHI and that there exigent circumstances may have provide a particular form of access, were no reasonable and appropriate implemented in good faith a security exchange, or use. In other cases, the alternatives that were less likely to practice without first considering actor may be able to comply with the

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00225 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25866 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

request, but only by incurring costs or proposed that the actor would need to for demonstrating that practices meet all other burdens that are clearly show that complying with the particular the conditions of a proposed exception, unreasonable under the circumstances request in the manner requested would the actor would need to produce (84 FR 7542). impose a substantial burden on the evidence and ultimately prove that We proposed that the exception actor. Second, we proposed that the complying with the request for access, would permit an actor to decline a actor must also demonstrate that exchange, or use of EHI in the manner request in certain narrowly-defined requiring it to comply with the requested would have imposed a clearly circumstances when doing so would be request—and thus to assume the unreasonable burden on the actor under infeasible (or impossible) and when the substantial burden demonstrated under the circumstances (84 FR 7543 and actor otherwise did all that it reasonably the first part of the test—would have 7544). could do under the circumstances to been plainly unreasonable under the We stated that certain circumstances facilitate alternative means of accessing, circumstances (84 FR 7542 and 7543). would not constitute a burden to the exchanging, and using the EHI. We We proposed that whether it would actor for purposes of this exception and proposed a structured, fact-based have been plainly unreasonable for the would not be considered in determining approach for determining whether a actor to assume the burden of providing whether complying with a request request was ‘‘infeasible’’ within the access, exchange, or use will be highly would have been infeasible. We meaning of the exception. We noted that dependent on the particular facts and proposed that it would not be this approach would be limited to a circumstances. We proposed to rely considered a burden if providing the consideration of factors specifically primarily on the following key factors requested access, exchange, or use of delineated in the exception and that the enumerated in proposed § 171.205(a)(1): EHI in the manner requested would infeasibility inquiry would focus on the • The type of EHI and the purposes have (1) facilitated competition with the immediate and direct financial and for which it may be needed; actor; or (2) prevented the actor from operational challenges of facilitating • The cost to the actor of complying charging a fee (84 FR 7544). access, exchange, and use, as with the request in the manner We requested comment on the distinguished from more remote, requested; proposed approach for determining indirect, or speculative types of injuries • The financial, technical, and other whether a request is ‘‘infeasible’’ within (84 FR 7542). resources available to the actor; the meaning of the exception. We We encouraged comment on these • Whether the actor provides encouraged comment on, among other and other aspects of this proposal (84 comparable access, exchange, or use to issues, whether the factors we FR 7542). itself or to its customers, suppliers, specifically delineated properly focus Comments. We received several partners, and other persons with whom the infeasibility inquiry; whether our comments in general support of the it has a business relationship; approach to weighing these factors is proposed exception. • Whether the actor owns or has appropriate; and whether there are Response. We thank commenters for control over a predominant technology, additional burdens, distinct from the their support of our proposal. We note platform, health information exchange, immediate and direct financial and that we have changed the title of this or health information network through operational challenges, that are exception from ‘‘Exception— which EHI is accessed or exchanged; similarly concrete and should be Responding to requests that are • Whether the actor maintains ePHI considered under the fact-based rubric infeasible’’ (84 FR 7603) to ‘‘When will on behalf of a covered entity, as defined of the exception (84 FR 7544). an actor’s practice of not fulfilling a in 45 CFR 160.103, or maintains EHI on Comments. We received several request to access, exchange, or use behalf of the requestor or another person comments in support of our proposed electronic health information due to the whose access, exchange, or use of EHI approach for determining whether a infeasibility of the request not be will be enabled or facilitated by the request was ‘‘infeasible.’’ We also considered information blocking?’’ actor’s compliance with the request; received several comments that Throughout this final rule preamble, we • Whether the requestor and other expressed various concerns and use ‘‘Infeasibility Exception’’ as a short relevant persons can reasonably access, suggestions for improvement regarding form of this title, for ease of reference. exchange, or use the information from our proposals. Several commenters As stated in Section VIII.D of this final other sources or through other means; expressed concern that the language in rule preamble, we have changed the and the proposed exception, particularly titles of all of the exceptions to • The additional cost and burden to regarding the ‘‘infeasibility’’ of a questions to improve clarity. We have the requestor and other relevant persons request, was too vague or ambiguous also edited the wording of the of relying on alternative means of and that the inclusion of undefined introductory text in § 171.204 as access, exchange, or use (84 FR 7543). terms could create uncertainty for actors finalized, in comparison to that We acknowledged in the Proposed regarding whether they meet the proposed (84 FR 7603 and 7604), so that Rule that there may be situations when conditions under the exception. it is consistent with the finalized title of complying with a request for access, Commenters noted that such § 171.204. We believe these conforming exchange, or use of EHI would be uncertainty could dissuade actors from changes in wording of the introductory considered infeasible because an actor is taking advantage of the exception. text also improve clarity in this section. unable to provide such access, Commenters requested additional exchange, or use due to unforeseeable or examples and guidance to clarify the i. Infeasibility of the Request unavoidable circumstances that are conditions under the exception. To qualify for the exception, we outside the actor’s control. As examples, A few commenters questioned proposed that compliance with the we stated that an actor could seek whether it would be considered request for access, exchange, or use of coverage under this exception if it is information blocking if they could not EHI must be infeasible. We proposed a unable to provide access, exchange, or segment EHI to respond to a request for two-step test that an actor would need use of EHI due to a natural disaster a patient’s EHI (e.g., when patient to meet in order to demonstrate that a (such as a hurricane, tornado or consent to share EHI subject to 42 CFR request was infeasible. Under the first earthquake) or war. We emphasized part 2 or a State privacy law has not step of the infeasibility test, we that, consistent with the requirements been provided). These commenters

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00226 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25867

expressed concern about the ability of events are all that are necessary to meet explanation of the reasons why the actor their technology to segment a patient’s this exception and no consideration of cannot accommodate the request (84 FR EHI. factors must be demonstrated and 7544). The difference in the final Response. We thank commenters for proven. language is that we have not specified their support of our proposed approach The second new condition is that the the level of detail required in the for determining whether a request is actor is not required to fulfill a request written record or other documentation, ‘‘infeasible,’’ as well as the constructive for access, exchange, or use of EHI if the and have clarified that such a written feedback. We agree with commenters actor cannot unambiguously segment record or other documentation must be that each exception should clearly the requested EHI from other EHI: (1) contemporaneous so that an actor explain the conduct that would and Because of a patient’s preference or cannot use a post hoc rationalization for would not be covered by each because the EHI cannot be made claiming the request was infeasible exception. We also reiterate that failure available by law; or (2) because the EHI under circumstances that were not to meet the exception does not mean is withheld in accordance with the considered at the time the request was that an actor’s practice related to Harm Exception in § 171.201 received. infeasible requests necessarily meets the (§ 171.204(a)(2)). For instance, an actor We proposed in the Proposed Rule (84 information blocking definition. will be covered under this condition if FR 7544) and have finalized in this final However, as we noted in the Proposed the actor could not fulfill a request to rule in § 171.204(a)(3)(ii) the following Rule, the broad definition of access, exchange, or use EHI because the factors that may not be considered in information blocking in the Cures Act requested EHI could not be the determination: (1) Whether the means that any practice that is likely to unambiguously segmented from patient manner requested would have interfere with the access, exchange, or records created by federally assisted facilitated competition with the actor; use of EHI implicates the information programs (i.e., Part 2 Programs) for the and (2) whether the manner requested blocking provision. As a result, treatment of substance use disorder (and prevented the actor from charging a fee practices that do not meet the exception covered by 42 CFR part 2) or from or resulted in a reduced fee. We note will have to be assessed on a case-by- records that the patient has expressed a that we have clarified in the final rule case basis to determine, for example, the preference not to disclose. that charging ‘‘a’’ fee includes a reduced actor’s intent and whether the practice The revised condition in fee as well. Our rationale for carving out rises to the level of an interference. § 171.204(a)(3)(i) specifically aligns with these considerations is that the purpose We have restructured this exception our proposal (84 FR 7543) in that an of the Infeasibility Exception is to to provide further clarity. Toward that actor would not be required to fulfill a provide coverage to actors who face end, we have eliminated the proposed request for access, exchange, or use of legitimate practical challenges beyond two-step test that an actor would need EHI if the actor demonstrates, through their control that limit their ability to to meet in order to demonstrate that a contemporaneous written record or comply with requests to access, request is infeasible (84 FR 7542 and other documentation, its consideration exchange, or use EHI. We do not believe 7543). Instead, we have finalized a of the following factors in a consistent that whether the manner requested revised framework for this exception and non-discriminatory manner, prior to would have facilitated competition with that provides two new conditions that responding to the request pursuant to the actor or prevented the actor from must be met in order for an actor to be paragraph (b) of this section, that led to charging a fee or resulted in a reduced covered by the exception and a revised its determination that complying with fee qualify as the type of legitimate condition that provides an exception for the request would be infeasible under practical challenges beyond the actor’s those actors unable to meet the new the circumstances: control that should be covered by the Content and Manner Exception. When • The type of EHI and the purposes exception. Regarding the consideration the practice by an actor meets one of the for which it may be needed; of fees, the actor is able to charge fees conditions in § 171.204(a) and the actor • The cost to the actor of complying for costs reasonably incurred, with a meets the requirements for responding with the request in the manner reasonable profit margin, for accessing, to requests in § 171.204(b) (which are requested; exchanging, or using EHI under the Fees discussed in more detail below), the • The financial and technical Exception in § 171.302. actor is not required to fulfill a request resources available to the actor; We have finalized in for access, exchange, or use of EHI due • Whether the actor’s practice is non- § 171.204(a)(3)(i)(F) the criterion that to the infeasibility of the request. discriminatory and the actor provides considers an actor’s ability to provide The first new condition is that the the same access, exchange, or use of EHI access, exchange, and use of EHI actor cannot fulfill the request for to its companies or to its customers, consistent with the Content and Manner access, exchange, or use of EHI due to suppliers, partners, and other persons Exception in § 171.301 in order to events beyond the actor’s control, with whom it has a business assure alignment of this exception with namely a natural or human-made relationship; the Content and Manner Exception. We disaster, public health emergency, • Whether the actor owns or has further discuss the Content and Manner public safety incident, war, terrorist control over a predominant technology, Exception in section VIII.D.2.a of this attack, civil insurrection, strike or other platform, health information exchange, final rule. labor unrest, telecommunication or or health information network through We did not finalize three factors that internet service interruption, or act of which electronic health information is were proposed in the context of the military, civil or regulatory authority accessed or exchanged; and infeasibility analysis: (1) Whether the (§ 171.204(a)(1)). This is consistent with • Why the actor was unable to actor maintains electronic protected our statements in the Proposed Rule provide access, exchange, or use of EHI health information on behalf of a describing events that an actor could consistent with the Content and Manner covered entity, as defined in 45 CFR seek coverage for under this exception Exception in § 171.301. 160.103, or maintains electronic health if it is was unable to provide access, We note that the above provisions information on behalf of the requestor or exchange, or use of EHI due to events align with our proposal in the Proposed another person whose access, exchange, beyond its control (84 FR 7543). This Rule that the actor must provide the or use of electronic health information new condition makes clear that such requestor with a detailed written will be enabled or facilitated by the

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00227 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25868 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

actor’s compliance with the request; (2) license terms from competitors or other (BAAs), and subsequent requests for whether the requestor and other persons who are technologically access, exchange, and use of EHI that relevant persons can reasonably access, dependent on the use of those are inconsistent with those contracts. exchange, or use the electronic health interoperability elements would also be Commenters urged ONC to specify information from other sources or subject to the information blocking whether an actor can refuse a request to through other means; and (3) the provision, unless they meet all access, exchange, or use EHI as being additional cost and burden to the conditions of the Licensing Exception infeasible due to such contractual requestor and other relevant persons of (§ 171.303). restrictions and obligations. relying on alternative means of access, We note, however, that actors may Response. We appreciate these exchange, or use (see the proposed seek coverage under the Infeasibility comments. We reiterate, as we factors at 84 FR 7543). We removed the Exception (§ 171.204) or Content and explained in the Proposed Rule, that first factor because it was confusing and Manner Exception (§ 171.301) for one means by which actors restrict was not a strong indicator of whether a certain issues related to IP. For instance, access, exchange, or use of EHI is request was infeasible. We removed the an actor may claim to be unable to fulfill through formal restrictions, such as second and third factors because we a request to access, exchange, or use EHI contract or license terms, EHI sharing proposed them with the intention that because the actor is not the owner of the policies, organizational policies or they would be indicators of whether the IP rights and lacks requisite authority to procedures, or other instruments or relative burden on the requestor was provide the requested access, exchange, documents that set forth requirements greater than that on the actor. However, or use of EHI. In such a situation, the related to EHI or health IT (84 FR 7518). we have shifted away from this relative actor could claim that the request is We emphasize that such restrictions are burden analysis in the final rule. To infeasible under the circumstances (see one of the forms of information blocking illustrate, consideration does not have § 171.204(a)(3)). Under the Cures Act and our final rule seek to to be given as to whether other means § 171.204(a)(3)(i)(E), one factor that can address. We refer readers to the are available for access, exchange, or use be considered when determining discussion of ‘‘Practices that May of EHI or the cost to the requestor for whether a practice is infeasible under Implicate the Information Blocking that alternative means because of the the circumstances is whether the actor Provision’’ in section VIII.C.6 of this new Content and Manner Exception owns or has control over a predominant final rule for a more detailed discussion (§ 171.301) and its relationship to this technology, platform, HIE, or HIN of when contracts and agreements will exception. through which EHI is accessed or be considered an ‘‘interference’’ with Comments. One commenter exchanged. The actor could also seek access, exchange, or use of EHI. recommended that claims of coverage under the Content and Manner Comments. A few commenters infeasibility based on the classification Exception. Under § 171.301(b)(2), an encouraged ONC to add a provision to of EHI as proprietary and claims of actor may provide the EHI requested in the exception that would enable entities infeasibility rooted in discriminatory an alternative manner if responding to who have joined Trusted Exchange practices should not be included in the the request in the manner requested Framework and Common Agreement exception, as they do not support ONC’s would require the actor to license IP. As (TEFCA) to claim the Infeasibility policy goals of promoting competition we have explained throughout this final Exception if a requestor or third party and innovation in health IT and rule, each information blocking case, refused to join the TEFCA and instead ultimately disadvantage customers and and whether the actor’s practice would demanded a one-off interface. patients. meet all conditions of an exception, will Response. We appreciate these Response. We agree with the depend on its own unique facts and comments, but have decided not to commenter that claiming the EHI itself circumstances. We refer readers to the adopt this suggested addition at this as proprietary is not a justification for detailed discussions regarding the time. The TEFCA is still new, the claiming this exception. As discussed in Content and Manner Exception Common Agreement is not yet finalized, more detail in the Fees Exception, we (VIII.D.2.a) and Licensing Exception and it would be premature to establish emphasize that almost all of the patient (VIII.D.2.c) in this preamble. special treatment for entities that join EHI found in the U.S. health care system We also agree with the commenter the TEFCA. We may reconsider this has been generated and paid for with that infeasibility rooted in suggestion at a later date. We note that either public dollars through Federal discriminatory practices should not be a this does not necessarily mean that programs, including Medicare and justification for claiming this exception. actors in these situations will not be Medicaid, or directly subsidized It was never our intention to allow such covered by the exception, as they could through the tax preferences for conduct to be covered by this exception. still show that a request for a one-off employer-based insurance. In response to this comment, we have interface is infeasible under the We explained in the Proposed Rule clarified the factor in circumstances (see § 171.204(a)(3)). how use of IP rights for interoperability § 171.204(a)(3)(i)(D) to explicitly state However, not joining TEFCA is not de elements can serve to interfere with that one consideration for determining facto proof of infeasibility. We note that access, exchange, and use of EHI. We whether a request is infeasible under the in addition to seeking coverage for also explained in the Proposed Rule that circumstances is whether the actor’s infeasibility under the circumstances, the mere fact that EHI is stored in a practice is non-discriminatory and the the actor could also seek coverage from: proprietary format or has been actor provides the same access, (1) The Content and Manner Exception combined with confidential or exchange, or use to its companies or to if the actor could not fulfill request to proprietary information does not alter its customers, suppliers, partners, and access, exchange, or use EHI in the the actor’s obligations under the other persons with whom it has a manner requested (via a one-off information blocking provision to business relationship. interface), but could fulfill the request facilitate access, exchange, and use of Comments. Some commenters through an acceptable alternative the EHI in response to a request (84 FR expressed concern that this exception manner (see § 171.301(b)); or (2) the 7517). We emphasize that actors who does not fully consider potential Fees Exception or Licensing Exception control proprietary interoperability conflicts between valid contracts, such if the actor chooses to provide the one- elements and demand royalties or as business associate agreements off interface as requested, but charges

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00228 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25869

fees/royalties related to developing or to requests (§ 171.204(b)). We removed Reasonable Alternative licensing the one-off interface, which the use of the term ‘‘timely’’ and could include fees or royalties that restructured the provision to more We proposed that, if the actor could result in a reasonable profit margin (see clearly explain ONC’s expectations for not meet the request for EHI, the actor § 171.302 and 303). responding to requests. Under the must work with the requesting party in response condition, if an actor does not a timely manner to identify and provide ii. Responding to Requests—Timely and a reasonable alternative means of Written Responses fulfill a request for access, exchange, or use of EHI for any of the reasons in accessing, exchanging, or using the EHI, We proposed, in addition to § 171.204(a), the actor must, within ten as applicable (84 FR 7544). demonstrating that a particular request business days of receipt of the request, Comments. Commenters, primarily was infeasible, that an actor would have provide to the requestor in writing the provider organizations, were supportive to show that it satisfied additional reason why meeting the request was of the proposed requirement to provide conditions. Specifically, we proposed infeasible. Our decision to finalize a 10- a reasonable alternative. We also that to qualify for the exception, the business day response timeframe was received a range of comments related to actor must have timely responded to all informed by our knowledge of the improving ONC’s proposals regarding requests relating to access, exchange, industry, stakeholder commenters, and the provision of a reasonable alternative, and use of EHI. Further, we proposed a desire to create consistent timeframes including comments requesting more that for any request that the actor claims across exceptions, such as alignment examples and guidance as to what was infeasible, the actor must have with the 10-business day response would be considered a ‘‘reasonable provided the requestor with a detailed timeframe in the Licensing Exception alternative.’’ Another commenter written explanation of the reasons why (see § 171.303(a)(1)). requested that ONC provide greater the actor could not accommodate the In instances when an actor is unable deference to the actor to determine the request. We proposed that the actor’s to respond within 10 business days, the appropriate format/functionality for failure to meet any of these conditions actor may be unable to avail themselves sharing the requested EHI when a would disqualify the actor from the of the requirements of the exception. As comparable functionality, distinct from exception and could also be evidence part of an information blocking the format/functionality requested, is that the actor knew that it was engaging investigation, ONC and OIG may made available and enables access, in practices that contravened the consider documentation or other exchange, or use of EHI on equivalent information blocking provision (84 FR writings maintained by the actor around terms. One commenter requested ONC 7544). place guardrails around requests for We proposed that the duty to timely the time of the request that provide information sharing, such that if an respond and provide reasonable evidence of the actor’s intent. actor is able to share data in an cooperation would necessarily be Additional documentation would not industry-accepted format, the requesting assessed from the standpoint of what is permit the actor to avail themselves of organization cannot make an objectively reasonable for an individual this exception, but ONC or OIG could information blocking claim if that or entity in the actor’s position. We examine the actor’s intent using this format does not meet their preferred, emphasized that we will look at the documentation when assessing the specific data transmission standard. specific facts and circumstances of each information blocking claim. case to determine whether the practice We have decided not to specify the A few commenters requested that is objectively reasonable (84 FR 7544). level of detail or specific type of ONC remove the requirement that an We encouraged comment on these information (such as technical actor both ‘‘identify’’ and ‘‘provide’’ a conditions and related considerations. information) that must be contained in reasonable alternative means of Specifically, we requested comment a written response. We believe it would accessing EHI, and instead require only regarding potential obstacles to be imprudent to create such boundaries that an actor ‘‘identify’’ a reasonable satisfying these conditions and for the written response given that the alternative. One commenter requested improvements we could make to the facts and circumstances will vary that ONC clarify that the proposed proposed process (84 FR 7544). significantly from case to case. Instead, requirement to identify a reasonable Comments. Many commenters, the finalized provision allows actors to alternative means of accessing, primarily provider organizations, determine what content is necessary to exchanging, or using EHI is only expressed concern that the proposed include in the written response in order necessary where any such alternative response requirements could create to explain the reason the request is exists. The commenter noted that there burden on providers, hospitals, and infeasible. We note that we have revised could be instances in which no clinical data registries. Commenters the requirement for the written response reasonable alternative exists, and the explained that each time a requester from the Proposed Rule. In the Proposed request is in effect impossible to comply makes a request that an actor deems Rule an actor was required to provide a with. One commenter requested that infeasible, the actor would be required ‘‘detailed written explanation of the ONC clarify that, regarding the to timely respond and provide a reasons why the actor cannot provision of a reasonable alternative, an detailed written explanation of its accommodate the request’’ (84 FR 7544) actor must only work with the requestor reasons for denial. A commenter also whereas we have finalized the in a timely manner to identify and recommended that, in the event a requirement that the actor must provide provide a reasonable alternative means request is infeasible and a written ‘‘in writing the reason(s) why the of accessing, exchanging, or using the explanation is necessary, that such request is infeasible’’ (§ 171.204(b)). We EHI as applicable. One commenter explanation need not contain detailed believe this revised requirement will expressed concern that this exception technical information. alleviate burden on actors by providing could be used to send patients to other Response. We appreciate these them discretion to decide the sources to get their health information comments and have revised the appropriate level of detail to include in because that approach would be less response condition in this exception to their written responses. It also places a burdensome than providing the address commenters’ concerns and greater emphasis on establishing that information to the patient directly. The establish a set timeframe for responding the request was infeasible to meet. commenter recommended that ONC

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00229 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25870 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

preclude the use of this exception for exception and demonstrate that the (§ 171.205 as finalized). For ease of patient access requests. request was infeasible under the reference and discussion, we use Some provider, hospital, and clinical circumstances. ‘‘Health IT Performance Exception’’ as a data registry commenters expressed short title for the finalized exception e. Health IT Performance Exception— concern regarding the potential burden throughout this preamble. Unless we are When will an actor’s practice that is on the actor related to identifying and directly quoting the Proposed Rule or implemented to maintain or improve providing a reasonable alternative accurate re-statement of Proposed Rule health IT performance and that is likely means of accessing, exchanging or using content requires otherwise, we use to interfere with the access, exchange, or the EHI. Other commenters, primarily ‘‘Health IT Performance Exception’’ in use of electronic health information not health IT developers, expressed concern this section of this preamble when be considered information blocking? regarding the potential impact and discussing this exception as proposed as burden on health IT developers, HINs, We proposed to establish an well as the finalized exception. As and HIEs of complying with a request to exception to the information blocking stated in section VIII.D of this preamble access, exchange, or use EHI, especially provision for certain practices that are (under the heading ‘‘modifications’’), we when the request requires custom reasonable and necessary to maintain changed the titles of all of the development. Commenters explained and improve the overall performance of information blocking exceptions to that if a system, even a large system, health IT, provided certain conditions questions for additional clarity. We were required to comply with many are met (84 FR 7550). We stated in the revised the wording of the finalized custom forms of integration, collectively Proposed Rule that this exception § 171.205 introductory text in they would cause a significant burden to would apply to the unavailability of comparison with that proposed in both business and budget. Some health IT occasioned by both planned § 171.207 so that it is consistent with commenters also noted that the and unplanned maintenance and the finalized title of the exception (and proposed exception seems imbalanced, improvement. We noted that planned § 171.205). Consistent with the favoring the requester of the EHI over maintenance or improvements are often restructuring of part 171 that is also the actor providing the EHI. carried out at regular intervals and described in section VIII.D of this Response. We appreciate the support address routine repairs, updates, or new preamble (under the heading for our proposal, as well as the array of releases while unplanned maintenance ‘‘modifications’’), this exception has constructive comments. We first note or improvements typically respond to been redesignated from § 171.207 in the that, in many instances, the exceptions, urgent or time-sensitive issues. We Proposed Rule (84 FR 7605) to § 171.205 including the finalized third condition proposed to codify the exception’s as finalized. Commenters’ requests for of this exception (§ 171.204(a)(3)), favor regulation text in § 171.207 (84 FR clarification and suggested revisions on the request for EHI because the overall 7605). specific points are discussed below. information blocking paradigm is to To ensure that the actor’s practice of Other revisions we have made to the eliminate interference with access, making health IT, and in turn EHI, regulation text finalized in § 171.205 in exchange, and use of EHI. We have unavailable for the purpose of carrying comparison to that proposed in removed the ‘‘reasonable alternative’’ out maintenance or improvements is § 171.207 are also discussed below. requirement from this exception and reasonable and necessary, we proposed instead have finalized the new Content conditions that would need to be Unavailability of Health IT Must Be for and Manner Exception in § 171.301 that satisfied at all relevant times a practice No Longer Than Necessary To Achieve establishes the content (i.e., the EHI) to be recognized as excepted from the the Maintenance or Improvements for required in the response and the manner definition of information blocking under Which the Health IT Was Made in which the actor may respond to the this proposed exception. Unavailable request for access, exchange, or use of Comments. We received numerous We proposed that any unavailability EHI. This new exception improves on comments supporting the establishment of health IT must be for a period of time the ‘‘reasonable alternative’’ of this exception. We did not receive no longer than necessary to achieve the requirement in the Proposed Rule by comments opposing the establishment maintenance or improvement purpose clarifying actors’ obligations for of this exception. Many of the for which the health IT is made providing access, exchange, or use of comments received requested unavailable or its performance degraded EHI in all situations and creating clarification or recommended revisions (84 FR 7550 and 7551). We provided as actionable technical procedures. to specific points within the proposed an illustrative example that a health IT We believe the Content and Manner exception. The comments requesting developer of certified health IT that has Exception in § 171.301 is responsive to clarification or making the right under its contract with a large the above comments, will reduce recommendations are summarized health system to take its system offline burden on actors, and is principled and below. for four hours each month to conduct tailored in a manner that will promote Response. We appreciate the routine maintenance would not qualify basic fairness and encourage parties to feedback. We have established the for this exception if an information work cooperatively to implement proposed exception with modifications blocking claim was made about a period efficient solutions to interoperability from the regulation text proposed in the of unavailability during which no challenges. We refer readers to the Proposed Rule. We have retitled the maintenance was performed. Content and Manner Exception and the exception from ‘‘Exception— Comments. We received comments discussion of such exception in this Maintaining and improving health IT from a variety of stakeholders on the preamble in sections VIII.C and performance’’ (proposed § 171.207, at 84 proposed requirement that any VIII.D.2.a. With regard to the comment FR 7605) to ‘‘Health IT Performance unavailability of health IT would need suggesting that no reasonable alternative Exception—When will a practice that is to be for a period of time no longer than may exist, we believe that the new implemented to maintain or improve necessary to achieve the maintenance or exception will address this concern. health IT performance and that is likely improvements for which the health IT However, if the actor still could not to interfere with the access, exchange, or was made unavailable. Some meet the new exception, the actor could use of electronic health information not commenters agreed that temporary avail itself of the third condition in this be considered information blocking?’’ unavailability of health IT ‘‘for a period

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00230 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25871

of time no longer than necessary’’ practices such as procedures that as it is intended to operate or without created an appropriate standard for both phased restoration of full functionality adversely affecting other functions of planned and unplanned downtimes. across a complex system, to manage the system. Other commenters indicated they did system loads or confirm the original Response. We interpret ‘‘minimum not support this standard, stating failure is fully resolved, and asked if we time necessary’’ to complete a concerns that the requirement that the would interpret this exception’s maintenance or improvement purpose, health IT be made unavailable ‘‘for a proposed conditions as excluding such objective, or activity to include period of time no longer than procedures. Some comments from reasonable and necessary practices, necessary’’ would be too difficult to members of the developer community such as confirmatory testing and phased assess without more specific criteria suggested that we modify our proposed restart protocols, to ensure that a newly such as defined time periods. Some language from ‘‘for a period of time no deployed or newly updated application commenters suggested we modify our longer than necessary’’ to ‘‘a reasonable functions in a particular production language to allow for greater flexibility period of time.’’ environment as it is intended to perform in maintenance downtime situations. Response. The ‘‘no longer than and does not adversely affect system Response. We have finalized within necessary’’ standard provides actors stability or the performance of critical the condition for maintenance and substantial flexibility to address the functions or components of that system. improvements to health IT in particular circumstances of each case, In determining whether an actor’s § 171.205(a)(1) the requirement allowing for consideration of a variety of practice affected health IT’s availability proposed in § 171.201(a)(1), with factors including but not limited to the or performance for longer than was modifications to the regulation text that service level agreements in place for the necessary in the particular are described below (immediately specific health IT at issue, the type of circumstances, we reiterate that we preceding the preamble discussion of maintenance or improvements, the would consider a variety of factors such the next subparagraph of § 171.205(a)). technical resources available to the as (but not limited to) the service level When an actor choosing to conform its actor, or best practices or other industry agreements in place for the specific practice to the health IT performance benchmarks relevant to the particular health IT at issue, the type of exception implements a practice that maintenance or improvements. In maintenance or improvements, the makes health IT under that actor’s response to comments requesting we technical resources available to the control temporarily unavailable, or clarify how we interpret ‘‘as soon as actor, or best practices or other industry temporarily degrades the performance of possible’’ and how it would apply to benchmarks relevant to the particular health IT, in order to perform specific types of practices, we first ask maintenance or improvements. maintenance or improvements to the readers to note that in this final rule Comments. Some commenters health IT, the actor’s practice must be preamble for the Health IT Performance recommended that we recognize there (§ 171.205(a)(1)) implemented for a Exception we use the phrase ‘‘as soon as may be circumstances where an period of time no longer than necessary possible’’ only in summarizing and instance of downtime may exceed to complete the maintenance or responding to these comments. We see service level agreements but still be no improvements for which the health IT how this phrase could be read as longer than necessary to address the was made unavailable or the health IT’s implying that we might uniformly issue. These commenters suggested such performance degraded. We believe that expect restarts in a shorter time or more violations of service level agreements establishing specific timeframes abrupt manner than might be consistent and other provisions of contracts applicable to various maintenance and with best practices for ensuring the between the parties should remain to be improvement purposes would be affected component(s) or production resolved through contractual impractical at this time due to the wide environment are restored to stable, mechanisms and not automatically variety of system architectures and reliable operating status. We do not, considered information blocking on operational contexts in which health IT however, interpret the finalized basis of exceeding the terms of the to which part 171 is applicable is condition as uniformly mandating agreements. One commenter suggested currently, or may in the future be, immediate full restarts of any or every actors who make their health IT deployed. We have finalized the ‘‘no system. In determining whether an temporarily unavailable under this longer than necessary’’ requirement of actor’s practice made health IT under its exception be held to industry standards this condition, which we believe control unavailable, or degraded the for necessary timeframes to complete provides substantial flexibility to health IT’s performance, for longer than any maintenance or improvements. consider the particular circumstances of was necessary in the particular Response. For purposes of each case, and a variety of factors circumstances, we would consider a determining whether a period of health including but not limited to the service variety of factors such as (but not IT unavailability or performance level agreements in place for the limited to) the service level agreements degradation is (or was) no longer than specific health IT at issue, the type of in place for the specific health IT at necessary to accomplish its purpose, we maintenance or improvements, the issue, the type of maintenance or note that service level agreements and technical resources available to the improvements, the technical resources industry practices would be relevant actor, or best practices or other industry available to the actor, or best practices information to be considered but not benchmarks relevant to the particular or other industry benchmarks relevant necessarily dispositive. For example, a maintenance or improvements. to the particular maintenance or period of health IT unavailability or Comments. Noting our use of the improvements. performance degradation could be phrase ‘‘as soon as possible’’ in the Comments. Several commenters within the parameters of applicable Proposed Rule’s preamble discussion of recommended that this exception apply service level agreements but still be this condition (84 FR 7551), specifically to downtime necessary for testing longer than necessary to accomplish the in an example where an actor takes whether a maintenance or improvement maintenance or improvement purpose health IT offline in response to a activity, such as deploying a new or for the health IT was made unavailable software failure, some commenters updated application into a particular or its performance degraded. For a requested we clarify how we interpret production environment for the first contrasting example, a period of health that phrase. A commenter described time, will operate in that environment IT unavailability or performance

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00231 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25872 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

degradation could be outside the necessary’’ for any particular window for unavailability in exchange parameters of applicable service level maintenance or upgrade. for a reduced fee for system agreements—a contractual matter for the We believe ‘‘complete’’ less maintenance, which would not parties to resolve through other ambiguously expresses our intent that contravene this condition of this appropriate channels—without being this requirement of this condition exception. ‘‘longer than necessary’’ in the totality encompasses the minimum time Comments. Several commenters of applicable circumstances and, necessary, in the totality of the expressed support for requiring therefore, without necessarily particular circumstances, to fully constituting information blocking as complete the maintenance or practices be implemented in a non- defined in § 171.103. improvement activity, including any discriminatory manner to meet the conditions of the Health IT Performance Comments. Several commenters confirmatory testing or other protocols requested we clarify whether this necessary to ensure an orderly and Exception. One commenter supported exception would apply to practices that reliable restoration of normal operating the requirement but stated that they degrade some aspects of a health IT status. We have also revised the believed practices applied selectively system’s performance, without making wording of § 171.205(a) as finalized so against an actor or third-party it entirely unavailable, for purposes of that it is consistent with the title and application inappropriately accessing conducting maintenance and introductory text of § 171.205 as interoperability resources should be improvement of the health IT system or finalized.182 We made modifications to exempt from this condition. some of its components. the titles and introductory text of all of Response. We appreciate the Response. We appreciate the the finalized exceptions for reasons opportunity to clarify two points. First, feedback. We agree that there may be described in section VIII.D of this we want to reiterate that there is an circumstances where the minimum preamble (under the heading important distinction between conduct disruption of an overall health IT ‘‘modifications’’). As finalized, of individuals or entities (or the system’s availability needed to § 171.205(a)(1) requires, in order to meet behavior of applications) that poses a the condition in § 171.205(a), that when accomplish particular maintenance or security risk and conduct or behavior an actor implements a practice that improvement purposes may be less than that may merely adversely affect makes health IT under that actor’s total. We do not intend that this performance of a health IT system or its exception would apply only to complete control temporarily unavailable, or temporarily degrades the performance of core functions. If an actor or an unavailability of health IT. We intend application is making or attempting the exception to apply to reasonable and health IT, in order to perform unauthorized access to systems or to necessary practices that disrupt EHI maintenance or improvements to the EHI, the actor with control of the system access, exchange, or use not only for the health IT, the actor’s practice must be shortest time but also to the least extent implemented for a period of time no subject to that security risk should take practicable to accomplish their specific longer than necessary to complete the prompt action to address that risk. As maintenance or improvement purposes maintenance or improvements for stated in the finalized § 171.205(d), the under the particular circumstances. which the health IT was made Health IT Performance Exception Accordingly, we have modified the unavailable or the health IT’s expressly does not apply to security- language of § 171.205(a)(1) as finalized performance degraded. related practices. If the unavailability of health IT for maintenance or to expressly include temporary Unavailability of Health IT for performance degradation as well as Maintenance or Improvements Must Be improvements is initiated by an actor in temporary unavailability of health IT Implemented in a Consistent and Non- response to a security risk to electronic affected by maintenance and Discriminatory Manner health information, the actor does not improvement practices. need to satisfy the conditions of We proposed (in proposed § 171.205, but must comply with all Discussion of Finalized Text of § 171.207(a)(2)) that any unavailability § 171.205(a)(1) applicable conditions of § 171.203 at all of health IT occasioned by the conduct relevant times if they wish to seek the The regulation text finalized in of maintenance or improvements must added assurance of conforming their be implemented in a consistent and § 171.205(a)(1) has been modified in practices to an exception to the non-discriminatory manner (84 FR comparison to the regulation text information blocking provision. Second, 7551). We explained that this condition proposed in § 171.207(a)(1) in several we recognize there are circumstances ways. The finalized regulation text provides a basic assurance that when health IT is made unavailable for the where an application’s behavior does expressly includes ‘‘or the health IT’s not pose a security risk but does performance degraded,’’ for the reasons purpose of performing maintenance or improvements the unavailability is not adversely impact the performance of a stated in response to comments (above). health IT system’s overall or core In the text of this provision, finalized at abused by the actor that controls the functions performance. We decline to § 171.205(a)(1), we have also replaced health IT. However, we indicated that modify § 171.205(a)(2) in the manner the verb ‘‘to achieve’’ with the verb ‘‘to this condition would not require that the commenter recommended in order complete.’’ Reflecting on the comments actors conduct all planned maintenance received, we have reviewed the or improvements simultaneously, or to address adverse impacts on health IT dictionary definition of ‘‘achieve’’ and require that every health IT contract performance. Instead, in response to this now believe that our use of ‘‘achieve’’ in provide the same promises in regard to and other comments, we have finalized the regulation text proposed in in planned maintenance or improvements. in § 171.205(b) an alternative condition § 171.207(a)(1) may have contributed to We further noted that a recipient of that expressly provides for the finalized commenters’ concerns about whether health IT could agree to a longer Health IT Performance Exception to we would interpret time for apply to practices implemented to 182 As noted above in this section of this mitigate a third-party application’s confirmatory testing of system preamble, titles of all the finalized exceptions have performance or phased restart protocols been revised to be more clear and easy to negative impact on an actor’s health IT’s as falling within the ‘‘minimum time understand. performance.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00232 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25873

Unavailability of Health IT for scheduled, and executed within a and scope of planned downtimes Maintenance or Improvements Must Be predefined window of time. One expectations in order for maintenance Agreed commenter recommended that actors and improvement health IT downtimes In order to benefit from this create a public website that displays to meet the information blocking exception, we proposed that the planned and unplanned system exception for maintenance and unavailability of health IT due to downtime and allow other actors to improvement. Similarly, we have not maintenance or improvements initiated subscribe to notifications of these modified the exception in response to by a health IT developer of certified downtimes. One commenter suggested recommendations from some health IT, HIE, or HIN, must be agreed we explicitly prohibit an entity from commenters that we require display of to by the individual or entity to whom regularly scheduling extensive time planned and unplanned downtime on the health IT is supplied (84 FR 7551). periods where query and response publicly available websites. We are not We noted that the availability of health services are unavailable. Another persuaded such measures would IT is typically addressed in a written commenter suggested we make generally render benefits commensurate contract or other written agreements, allowances within the conditions of this with the time and effort that would be that puts the recipient of the health IT exception for an actor who may fall needed for actors to implement and on notice about the level of EHI and slightly out of compliance with terms maintain them. health IT unavailability that can be agreed to regarding downtime in a Comments. Two commenters expected for users of the health IT. By service level agreement if the impact is disagreed with our proposed such agreements, the recipient of the de minimis and the actor was acting in requirement that temporary health IT willfully agrees to that level of good faith. One commenter contended unavailability initiated by a health IT planned and unplanned unavailability that the information blocking provisions developer of certified health IT, HIE, or (typically referred to in health IT should not regulate the level of service HIN must be agreed to by the individual contracts as ‘‘downtime’’). We proposed provided by health IT developers to or entity to whom the health IT that in circumstances where health IT their customers. We also received developer of certified health IT, HIE, or needs to be taken offline for several comments from members of the HIN supplied the health IT. Both maintenance or improvements on an HIE and HIN community that commenters recommended removing urgent basis and in a way that is not recommended against any requirement the ‘‘agreed upon with user’’ provision expressly permitted under a health IT to include specific details such as dates we proposed and recommended that contract an actor could satisfy the and times for maintenance because such ONC eliminate the requirement for prior proposed condition so long as the a requirement could result in HIEs and agreement of planned downtime in maintenance or improvements are HINs having to undertake the process of order to meet the conditions of this agreed to by the recipient of the health amending thousands of legal exception. These commenters suggested IT. We proposed that this could be agreements. that we instead allow for unilateral achieved by way of an oral agreement Response. We do not believe it is notice to organizations at least 10 days such as reached between the parties by necessary to dictate the availability or prior to scheduled maintenance. telephone, but we noted that because an health IT or other contractually defined Response. We continue to believe that actor must demonstrate that it satisfies details of the business relationship unplanned downtime must be done the conditions of this exception, it between parties for the purposes of this with the agreement of the individual or would be best practice for an actor to exception. Parties to a health IT contract entity to which the health IT is ensure the agreement was in writing or, can determine and communicate their supplied. This condition protects health at minimum, contemporaneously respective service level needs and care providers and other uses or health documented. capabilities or commitments in legally IT under the specific circumstance of We proposed that this condition enforceable contracts. Contractual health IT being made temporarily would only apply when the provisions can establish specific details unavailable due to unplanned unavailability of health IT is caused by of service levels, planned downtime, maintenance or improvements. It also a health IT developer of certified health unplanned downtime, and reduces the potential for downtime IT, HIE, or HIN because it is the supplier communications regarding planned and purportedly for purposes of health IT of the health IT and thus controls if and unplanned downtime, that are practical maintenance or improvement to be a when health IT is intentionally taken and appropriate to the context of a pretext for information blocking and offline for maintenance or particular contract. In the event parties thus makes it less likely that this improvements. We proposed that this do not honor such contract provisions, exception will be abused. However, the condition would not apply when health remedies are available to the parties conditions of this exception finalized in IT is made unavailable for maintenance outside and independent of part 171. § 171.205 can be met by unplanned or improvements at the initiative of a We also agree with commenters’ downtime in the absence of recipient (or customer) of health IT, observations that any specific contemporaneous agreement so long as noting that when it is a customer of requirements, such as those it is consistent with an existing service health IT who initiates unavailability, recommended by some other level agreement. We also note that the unavailability would not need to be commenters, could require amending specific agreement by all users to the subject of an agreement with the contracts in ways that could create temporary unavailability is not required supplier of that health IT, nor anyone significant burden and costs for actors. in all instances of unplanned downtime else, in order for the customer of health Thus, we did not modify this exception not already covered by an existing IT to benefit from this exception. in response to commenters’ service level or other contractual Comments. Several commenters from recommendations that we require agreement, such as downtime resulting the provider community recommended service level or other contractual from events beyond the actor’s control advance notice of downtime. Several agreements between parties conform to that prevent it from meeting the commenters from the provider specific prescribed timeframes, requirement, and practices that are community suggested that planned scheduling (including specifically or consistent with the conditions of the downtimes should be documented, query and response services), notice, Preventing Harm Exception (§ 171.201),

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00233 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25874 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

Security Exception (§ 171.203), or requirements finalized in § 171.205(a), Health IT Performance Exception, but Infeasibility Exception (§ 171.204). the condition applicable to practices must comply with all conditions of Comments. Several commenters from that make health IT temporarily § 171.203 at all relevant times for such the developer community expressed unavailable, or its performance practices to be excepted from the appreciation for the opportunity to degraded, for purposes of maintenance definition of information blocking in comment on throttling, arguing that it is and improvement. § 171.103. We believe this paragraph of a reasonable approach to maintain To meet the Health IT Performance the finalized Health IT Maintenance access to functionality. Many of these Exception under the assured level of Exception’s regulation text (finalized in commenters stated that, when applied performance condition, an action § 171.205(d)) provides ample clarity that with the agreement of health IT users, against a third-party application this exception is not intended to apply strategies such as throttling or metering (§ 171.205(b)) must be: (1) For a period to unplanned downtime implemented certain health IT functions should not of time no longer than necessary to specifically in response to emergent be considered information blocking. resolve any negative impacts; (2) security threats. We have finalized this One commenter suggested that implemented in a consistent and non- approach to the relationship between throttling should not be considered discriminatory manner; and (3) the Health IT Performance Exception information blocking if the health IT consistent with existing service level and Security Exception as proposed, developer or health care provider is agreements, where applicable. For because we continue to believe it forced to throttle access so as not to example, if the service level agreement ensures that the Health IT Performance negatively impact hospital operations. stated how and to what extent negative Exception cannot be used to avoid The commenter recommended that impacts should be addressed (e.g., over- compliance with conditions applicable when requests for EHI from third-party capacity), then it is expected that such under the Security Exception when the applications created an unreasonable provisions of an existing service level practice leading to unplanned and significant burden on health IT and agreement would be followed unless downtime is implemented specifically the installed infrastructure, the two they violated one of the other in response to a risk to security of EHI. contracting parties could mutually agree requirements of the (§ 171.205(b)) Comments. We received several that the third-party application was assured level of performance condition comments from stakeholders in the poorly designed and could be throttled (e.g., resulted in discriminatory developer community that it would be or even denied access. Another application or lasted longer than impossible for certified health IT commenter suggested that the practice necessary to resolve the negative developers, HIEs, or HINs to meet the of throttling should only occur if that impacts). We believe this approach will conditions of this exception as proposed portion of the health IT affected by an help to address situations where actions in the event of downtime as a result of application is impacting highly critical such as throttling become necessary to something like a natural disaster functions such as inpatient or protect the overall performance of because those parties would be unable emergency department care delivery health IT. to secure agreement from entities and and documentation. The commenter individuals prior to uncontrollable Interaction With the Preventing Harm stated that it was important to downtime. and Security Exceptions distinguish between the practice of Response. The Infeasibility Exception throttling generally and the practice of We proposed that when health IT is finalized in § 171.204 has been revised, throttling as a response to impact on made unavailable for maintenance or in comparison to the proposed critical functions because the practice of improvements aimed at preventing regulation text in the Proposed Rule, to throttling generally could be applied too harm to a patient or other person, or expressly address uncontrollable events. broadly. securing EHI, an actor must comply In cases of natural or human-made Response. We appreciate commenters’ with the conditions specified in the disaster, public health emergency, input. We recognize that in some proposed Harm Exception or proposed public safety, incident war, terrorist circumstances it may be appropriate for Security Exception, respectively, in attack, civil insurrection, strike or other actors to take action (e.g., deny access, order for these particular practices to be labor unrest, telecommunication or throttle, or meter) to limit the negative excepted from the definition of internet service interruption, or act of impact on the performance of health IT information blocking in § 171.103. military, civil or regulatory authority, an that may result from the technical Comments. We received a few actor can avail itself of the Infeasibility design, features, or behavior of a third- comments that expressed concern that Exception. We determined these party application. This would include, our maintenance exception, as situations should be addressed in the but not be limited to, third-party proposed, did not address unplanned Infeasibility Exception rather than the applications that a patient might choose downtime without notice in the Health IT Performance Exception in part to use to access their EHI. The instance of a potential threat to security because the breadth of circumstances regulation text finalized in § 171.205 has of EHI. where access, exchange, or use of EHI been expanded, in comparison to the Response. Unplanned downtime or may be interfered with due to these text proposed in § 171.207 (84 FR 7605), other practices reasonable and necessary uncontrollable events is more consistent to include paragraph (b), which we have in response to exigent threats to EHI with the intent and function of the titled ‘‘assured level of performance.’’ security should be implemented Infeasibility Exception. Thus, we have As finalized, § 171.205(b) establishes a consistent with the conditions for the not modified the Health IT Maintenance condition expressly applicable to Security Exception as finalized in Exception (§ 171.205) to address actions taken against a third-party § 171.203. We expressly stated in the uncontrollable events of the type application that is negatively impacting proposed regulation text at § 171.207(c), expressly addressed by the finalized the health IT’s performance. The and have finalized in § 171.205(d), that Infeasibility Exception (§ 171.204). specific requirements for action against if the unavailability of health IT for We have finalized the substance of the a third-party application to meet the maintenance or improvements is relationship between the Health IT condition finalized in § 171.205(b) and initiated by an actor in response to a Maintenance Exception and the thus be excepted from the definition of security risk to EHI, the actor does not Preventing Harm and Security information blocking parallel the need to satisfy the conditions of the Exceptions as proposed. We have also

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00234 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25875

finalized as proposed the provisions of patient should be provided an exception in the Proposed Rule, it is the Health IT Maintenance Exception opportunity to access the EHI through related to our proposals and requests for specific to ‘‘practices that prevent another means, such as the patient comment in the Proposed Rule harm’’ and ’’security-related practices,’’ portal. regarding the proposed EHI definition but have redesignated them within the Response. The Health IT Performance (84 FR 7513) and the proposed structure of the Health IT Maintenance Exception is applicable to a variety of requirement to identify and provide a Exception as finalized in § 171.205 in specific practices making health IT reasonable alternative means for comparison to the structure proposed at unavailable. It does not recognize only accessing, exchanging, or using EHI as § 171.207 (84 FR 7605). Specifically, the downtime or performance degradation part of the proposed Infeasibility ‘‘practices that prevent harm’’ provision of an actor’s entire health IT system. An Exception (84 FR 7544). We discuss is finalized in paragraph (c) of the actor who takes down one means of EHI below the connection between these finalized Health IT Maintenance access to conduct health IT maintenance proposals and requests for comment in Exception in § 171.205 instead of or improvement could provide the Proposed Rule and the conditions in paragraph (b) as was the case in the alternative access to EHI, in the Content and Manner Exception. Proposed Rule (84 FR 7605). Likewise, circumstances where this may be We note that a failure to meet the the ‘‘security-related practices’’ practical, and remain in compliance Content and Manner Exception does not provision is finalized in paragraph (d) of with the requirements for their practices mean that an actor’s practice meets the the finalized Health IT Maintenance to be excepted under § 171.205 from the information blocking definition. Exception in § 171.205 instead of definition of information blocking in However, as we noted in the Proposed paragraph (c) as was the case in the § 171.103. However, we stress that an Rule, the broad definition of Proposed Rule (84 FR 7605). Both of actor conducting maintenance or information blocking in the Cures Act these provisions were moved down to improvement of health IT in the actor’s means that any practice that is likely to accommodate the addition of the control is not required to provide an interfere with the access, exchange, or ‘‘assured level of performance’’ alternative electronic health information use of EHI implicates the information condition as paragraph (b) of § 171.205 access mechanism during the downtime blocking provision (see 84 FR 7515). As as finalized. in order for the Health IT Performance a result, practices that do not meet the The paragraph of the Health IT Exception to apply to the actor’s Content and Manner Exception will Maintenance Exception finalized in maintenance or improvement practices. have to be assessed on a case-by-case § 171.205(c), specific to ‘‘practices that We are aware that actors’ operational basis to determine, for example, the prevent harm,’’ continues to provide contexts and existing health IT actor’s intent and whether the practice that if the unavailability of health IT for capabilities vary substantially rises to the level of an interference. We maintenance or improvements is throughout the health IT ecosystem. In discuss the comments received initiated by an actor in response to a a variety of circumstances where regarding the proposals related to the risk of harm to a patient or another downtime or performance degradation EHI definition (84 FR 7513) and the person, the actor does not need to may be reasonable and necessary to requirement to identify and provide a satisfy the requirements of this section, maintain or improve health IT reasonable alternative means for but must comply with all conditions of performance, an actor may not have the accessing, exchanging, or using EHI § 171.201 at all relevant times to qualify capability needed to meet a requirement under the Infeasibility Exception (84 FR for an exception. Likewise, the that EHI must always be immediately 7544) below. paragraph of the Health IT Maintenance available in response to every patient Comments. As discussed in more Exception finalized in § 171.205(d), request. For example, in some detail section VIII.C.3, we received specific to ‘‘security-related practices,’’ circumstances it may be impossible to many comments expressing concerns continues to provide that if the achieve a particular maintenance or regarding the breadth of the proposed unavailability of health IT for improvement purpose within a specific EHI definition and requesting flexibility maintenance or improvements is system without temporarily rendering in the implementation of the initiated by an actor in response to a all EHI in the system unavailable to all information blocking provision. Many security risk to electronic health functions, services, and other commenters stated that it would be information, the actor does not need to components of the system (such as APIs difficult for actors to provide the full satisfy the requirements of this section, and portals) through which EHI is scope of EHI as it was proposed to be but must comply with all conditions of ordinarily accessed, exchanged, or used. defined, particularly as soon as the final § 171.203 at all relevant times to qualify 2. Exceptions that involve procedures rule was published. Some commenters for an exception. for fulfilling requests to access, opined that we were trying to do too exchange, or use EHI much too fast. Commenters requested Request for Comment that we provide flexibility for actors to We requested comments on the a. Content and Manner Exception— adjust to the scope of the EHI definition, exception in general, and on whether When will an actor’s practice of limiting as well as the exceptions. Commenters the proposed conditions would impose the content of its response to or the asserted that such an approach would appropriate limitations on actor- manner in which it fulfills a request to permit them to adapt their processes, initiated health IT maintenance or access, exchange, or use electronic technologies, and systems to enable the improvement activities that lead to health information not be considered access, exchange, and use of EHI as temporary unavailability of EHI. information blocking? required by the Cures Act and this final Comments. We did not receive In this final rule, we have established rule. Some commenters suggested that comments generally opposed to the a new exception in § 171.301 (referred EHI under the information blocking establishment of this exception. One to as the Content and Manner provision should be limited to ePHI as commenter recommended that if a Exception) under section 3022(a)(3) of defined in 45 CFR 160.103, while others patient is affected by a practice that the PHSA as a means to identify requested that ONC consider could be recognized under this reasonable and necessary activities that constraining the EHI covered by the exception, such as unavailability of do not constitute information blocking. information blocking provision to only health IT for an app registration, the Although we did not propose this the data included in the USCDI.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00235 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25876 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

We also received a range of comments when the request requires custom by the data elements represented in the requesting clarification and concerning development. Some commenters also United States Core Data for improvements to our proposal in the noted that the proposed exception Interoperability (USCDI) standard Infeasibility Exception that, for any seems imbalanced, favoring the adopted in § 170.213. Section request that the actor claims is requester of the EHI over the actor 171.301(a)(2) states that on and after infeasible, the actor must work with the providing the EHI. May 2, 2022, an actor must respond to requesting party in a timely manner to Response. The Content and Manner a request to access, exchange, or use EHI identify and provide a reasonable Exception in § 171.301 addresses the with EHI as defined in § 171.102. alternative means of accessing, two groups of comments noted above: We explained in section VIII.C of this exchanging, or using the EHI, as (1) Comments expressing concerns final rule that we have finalized a new applicable (proposed in § 171.205(d), 84 regarding the breadth of the proposed paragraph in the information blocking FR 7604). Commenters, primarily EHI definition (proposed in § 171.102, definition in § 171.103 that aligns with provider organizations, were supportive 84 FR 7601) and requesting flexibility in the content condition described above. of the proposed condition. Some the implementation of the information That new paragraph, which is finalized commenters requested clarification and blocking provision; and (2) comments in § 171.103(b), states that, until May 2, additional examples about what manner requesting clarification concerning and 2022, EHI for purposes of part 171 is of response would constitute a improvement to our proposal in the limited to the EHI identified by the data ‘‘reasonable alternative’’ and when it Infeasibility Exception regarding the elements represented in the USCDI would be acceptable to enable provision of a reasonable alternative standard adopted in § 170.213. We have requestors to access, exchange, or use (proposed in § 171.205(d), 84 FR 7604). included a detailed discussion in EHI in an alternative manner. One In response to these comments, we have section VIII.C of our rationale for commenter requested that ONC place removed the reasonable alternative including the content condition in the guardrails around requests for provision from the Infeasibility Content and Manner Exception and for information sharing, such that if an Exception and we have finalized the including paragraph (b) in § 171.103. actor is able to share data in an Content and Manner Exception in That discussion includes an explanation industry-accepted format, the requesting § 171.301 which describes the content of how those provisions address the organization cannot make an (i.e., the EHI) required to be provided in commenters’ concerns detailed above. information blocking claim if that an actor’s response to a request to We refer readers to the discussion in format does not meet the organization’s access, exchange, or use EHI and the section VIII.C. manner in which an actor must fulfill preferred, specific data transmission Manner standard. One commenter requested that the request in order to satisfy the ONC clarify that the proposed exception. We believe this new The second condition of this requirement to identify a reasonable exception will address the broad range exception (‘‘manner condition’’) in alternative means of accessing, of comments we received about the § 171.301(b) establishes the manner in exchanging, or using EHI is only content of an actor’s response to and which an actor must fulfill a request to necessary where any such alternative manner for fulfilling a request to access, access, exchange, or use EHI in order to exists. The commenter noted that there exchange, or use EHI, and will provide meet this exception. This condition is could be instances in which no the clarity and transparency sought by similar to our proposal in the reasonable alternative exists, and the commenters. We also believe, as Infeasibility Exception in the Proposed request is in effect impossible to comply discussed in more detail below, that this Rule that, for any request the actor with. new exception provides market claims is infeasible, the actor must have A few commenters requested that participants the ability to reach and worked with the requesting party in a ONC remove the requirement that an maintain market negotiated terms for timely manner to identify and provide actor both ‘‘identify’’ and ‘‘provide’’ a the access, exchange, and use of EHI. a reasonable alternative means of reasonable alternative means of accessing, exchanging, or using the EHI, Content accessing EHI, and instead require only as applicable (see proposed that an actor ‘‘identify’’ a reasonable The first condition of this exception § 171.205(d), 84 FR 7604). We explained alternative. One commenter expressed (‘‘content condition’’) in § 171.301(a) in the Proposed Rule that this proposed concern that this exception could be establishes the content an actor must condition would minimize the risk that used to send patients to other sources to provide in response to a request to the Infeasibility Exception could protect get their health information because that access, exchange, or use EHI in order to improper refusals to enable access, approach would be less burdensome meet this exception. As discussed in exchange or use of EHI, including than providing the information to the section VIII.C.3 of this preamble, we discriminatory blanket refusals as well patient in the manner requested. The have focused the scope of the EHI as other practices, such as improper commenter recommended that ONC definition in this final rule to ePHI as delays for access or exchange that preclude the use of this exception for defined in 45 CFR 160.103 to the extent would present information blocking patient access requests. that it would be included in a concerns (84 FR 7544). Some provider, hospital, and clinical designated record set as defined in 45 After review of comments, further data registry commenters expressed CFR 164.501, with limited exception. consideration of proposed conditions, concern regarding the potential burden We also address commenter concerns and taking into account the revised on the actor related to identifying and regarding the scope of the EHI definition structure of the exceptions, we providing a reasonable alternative and the pace at which we are determined that the concept of means of accessing, exchanging or using implementing the information blocking providing a ‘‘reasonable alternative’’ fits the EHI. Other commenters, primarily provision through the Content and better in the Content and Manner health IT developers, expressed concern Manner Exception. Specifically, section Exception than in the Infeasibility regarding the potential impact and 171.301(a)(1) states that for up to May Exception. As such, we removed the burden on health IT developers, HINs, 2, 2022, an actor must respond to a ‘‘reasonable alternative’’ requirement and HIEs of complying with a request to request to access, exchange, or use EHI from the Infeasibility Exception and access, exchange, or use EHI, especially with, at a minimum, the EHI identified incorporated the general concept into

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00236 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25877

the Content and Manner Exception. We fulfilling the request must satisfy the efficient solutions to interoperability believe this approach improves on the Fees Exception in § 171.302. Similarly, challenges. ‘‘reasonable alternative’’ requirement in § 171.301(b)(2)(iii) requires that any Second, we establish that an actor is the Proposed Rule by clarifying actors’ license of interoperability elements not required to fulfill a request to obligations for providing access, granted by the actor in relation to access, exchange, or use EHI in the exchange, or use of EHI in all situations; fulfilling the request is required to manner requested if the actor cannot creating actionable technical satisfy the Licensing Exception in reach agreeable terms with the requestor procedures; and aligning the § 171.303. to fulfill the request (§ 171.301(b)(1)(i)). requirement for providing an alternative We chose this approach because we We also establish that if an actor fulfills with the Fees and Licensing Exceptions. believe actors should, first and foremost, a request to access, exchange, or use EHI Under § 171.301(b)(1), an actor must attempt to fulfill requests to access, in any manner requested, the fees or fulfill a request described in the content exchange, or use EHI in the manner licenses associated with fulfilling such condition (paragraph (a) of the requested. This principle is central to requests will not be limited by the exception) in any manner requested, our information blocking policies (e.g., conditions in the Fees Exception or unless the actor is technically unable to it was part of the proposed Infeasibility Licensing Exception. These provisions fulfill the request or cannot reach Exception) and will help ensure that will allow actors to first attempt to agreeable terms with the requestor to EHI is made available where and when negotiate agreements in any manner fulfill the request (§ 171.301(b)(1)(i)). If it is needed. Our approach requested with whatever terms the actor an actor fulfills a request described in acknowledges, however, that there may chooses and at the ‘‘market’’ rate— the content condition in any manner be instances when an actor should not which supports innovation and requested: (1) Any fees charged by the be required to respond in the manner competition. We then allow flexibility actor in relation to its response are not requested. for actors to still satisfy the exception by required to satisfy the Fees Exception in fulfilling the request in an alternative First, if an actor is technically unable § 171.302; and (2) any license of manner if the actor cannot reach to fulfill a request to access, exchange, interoperability elements granted by the agreeable terms with the requestor to or use EHI in the manner requested, the actor in relation to fulfilling the request fulfill the request. For instance, under actor is allowed to fulfill the request in is not required to satisfy the Licensing the exception, actors who cannot reach an alternative manner Exception in § 171.303 agreeable terms with the requestor to (§ 171.301(b)(1)(i)). We emphasize that (§ 171.301(b)(1)(ii)). fulfill the request are not required to Section 171.301(b)(2) provides we use ‘‘technically unable’’ in this license their IP to proprietary requirements for fulfilling a request to context to mean that actors cannot technology in order to satisfy the access, exchange, or use EHI in an fulfill a request to access, exchange, or exception. alternative manner than the manner use EHI due to technical limitation. For In contrast, § 171.301(b)(2)(ii) and (iii) requested. If an actor does not fulfill a example, if an individual requested require that any fees charged or licenses request described in the content their EHI via an API and the actor could granted by the actor in relation to condition of this exception in any not fulfill the request via the API, but fulfilling a request to access, exchange, manner requested because it is the individual then requested the EHI be or use EHI in an alternative manner technically unable to fulfill the request provided via email and the actor was must satisfy the Fees Exception in or cannot reach agreeable terms with the technically able to do so, we expect that § 171.302 and the Licensing Exception requestor to fulfill the request, the actor the actor would fulfill the request in in § 171.303. We recognize that it is must fulfill the request in an alternative that ‘‘manner requested.’’ This standard possible that responding in an manner in order to satisfy the exception. sets a very high bar, and would not be alternative manner may require Section 171.301(b)(2)(i) states that the met if the actor is technically able to licensing of interoperability elements. actor must fulfill the request without fulfill the request, but chooses not to However, we do not believe that, in unnecessary delay in the following fulfill the request in the manner most cases, licensing certified order of priority, starting with the first requested due to cost, burden, or similar technology (§ 171.301(b)(2)(i)(A)) or paragraph and only proceeding to the justifications. If, for instance, under the standards-based technology next consecutive paragraph if the actor alternative manner, fulfilling the request (§ 171.301(b)(2)(i)(B)) would involve the is technically unable to fulfill the would prove costly for the actor, the type of licensing of proprietary request in the manner identified in a actor would be able to charge a fee that interoperability elements that concerned paragraph. That order of priority is as results in a reasonable profit margin the majority of commenters because the follows: (1) Using technology certified under the Fees Exception in § 171.302 standards in § 171.301(b)(2)(i)(a) and (B) to standard(s) adopted in part 170 that or license any requisite interoperability are ‘‘open’’ standards. Therefore, it is is specified by the requestor elements and make reasonable royalties our understanding that a health IT (§ 171.301(b)(2)(i)(A)); (2) using content under the Licensing Exception in developer of certified health IT would and transport standards specified by the § 171.303. If the burden on the actor for not normally be required to license its requestor and published by the Federal fulfilling the request is so significant IP in order to meet the requirements for Government or a standards developing that the actor chooses not to fulfill the fulfilling a request to access, exchange, organization accredited by the American request at all, the actor could seek or use EHI in those alternative manners. National Standards Institute (ANSI) 183 coverage under the Infeasibility On the other hand, the technology/ (§ 171.301(b)(2)(i)(B)); and (3) using an Exception in § 171.204. We believe this software that the developer uses to alternative machine-readable format, framework for utilizing this exception, fulfill a request in any manner requested including the means to interpret the which works in harmony with the could constitute the developer’s IP, EHI, agreed upon with the requestor Infeasibility Exception (§ 171.204), Fees depending on the request. We (§ 171.301(b)(2)(i)(C)). Section Exception (§ 171.302), and Licensing emphasize that this exception does not 171.301(b)(2)(ii) requires that any fees Exception (§ 171.303), is principled and require developers to open-source their charged by the actor in relation to tailored in a manner that will promote technology/software. basic fairness and encourage parties to For instance, if a health IT developer 183 See https://www.ansi.org/. work cooperatively to implement of certified health IT enables access to

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00237 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25878 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

EHI using HL7 (which is an ANSI- Medicare & Medicaid Services (CMS), appropriate format and is universally accredited standards developing other Federal and State programs that understood. This standard includes the organization) FHIR Release 2 (R2) use certified health IT, and other structure (i.e., syntax) and terminology Standard, that means the developer will Federal Departments (Department of (i.e., semantics) of the EHI. Examples of provide EHI in the format specified in Defense and Veterans Affairs). In content standards include: US Fast FHIR R2. In this example, the actual addition, the certification criteria under Healthcare Interoperability Resources software code that is used by the the ONC Health IT Certification Program (FHIR) Core IG; Consolidated Clinical developer to convert the EHI from the (the Program) include robust oversight, Document Architecture (C–CDA 2.1); developer’s proprietary format to FHIR including technical and interoperability HL7 V2.5.1; HL7 v2.7 (which is a R2 is the developer’s IP and is not requirements, ONC-Authorized standard that is not part of certification required to be provided to the requestor. Certification Body (ONC–ACB) in-the- from an ANSI-accredited standards We also note that our experience and field surveillance expectations, and cost developing organization); and Argonaut knowledge of the health IT landscape transparency and other disclosure Data Query Implementation Guide. The indicate that the market is increasingly requirements. To illustrate how this transport standard is the method to moving toward open standards, and we would work, if the requestor only connect two or more parties without a believe this movement will further requests the EHI using the C–CDA 2.1 focus on the data that is transported decrease the need to license IP in the content standard, then the actor would from one party to another. Put another future. We believe this framework and not have to also use the Direct transport way, the transport standard is the approach are supportive of innovation standard to provide the EHI. However, method by which information moves and address commenter concerns if the requestor requests the EHI through from one point to another. Examples of regarding their ability to protect their IP. the use of both standards, then the actor transport standards include: Direct We included in § 171.301(b)(2)(i) that would be expected to respond in such Project Standard, ONC Applicability an actor must fulfill the request without a manner if the actor has certified health Statement for Secure Health Transport, unnecessary delay in order to make IT that supports both standards. clear that actors seeking coverage under If the actor is technically unable to Version 1.0 (incorporated by reference this exception by responding in an respond using technology certified to in § 170.299) (§ 170.202(a)); and Simple alternative manner will be held to same standards adopted in part 170 specified Object Access Protocol (SOAP) based unnecessary delay or ‘‘timeliness’’ by the requestor, then the actor may exchange specifications such as considerations as all actors are in respond using content and transport ‘‘Nationwide Health Information determining whether there is an standards specified by the requestor and Network Messaging Platform 184 interference under the information published by the Federal Government or Specification.’’ Under the manner blocking provision. The fact that an a standards developing organization condition, an actor could proceed to the actor responds in an alternative manner accredited by the ANSI next consecutive ‘‘manner’’ under does not entitle that actor to any (§ 171.301(b)(2)(i)(B)). We chose to § 171.301(b)(2)(i) if the actor was additional time to respond to a request specify that standards published by a technically unable to respond with to access, exchange, or use of EHI that standards developing organization either the content standard or the the actor would not be afforded if accredited by ANSI would qualify for transport standard requested. responding in any manner requested. As this manner of response because ANSI Last, if an actor is technically unable such, any unnecessary delays related to oversees the development of voluntary to fulfill a request for access, exchange, responding in an alternative manner consensus standards in the United or use of EHI using a content and could disqualify an actor from meeting States and it accredits standards that are transport standard specified by the the alternative manner condition in the developed by representatives of other requestor and published by the Federal same way that an unnecessary delay in standards organizations. ANSI Government or a standards developing responding to a request to access, accreditation signifies that the organization accredited by ANSI, only exchange, or use EHI in any manner procedures used by standards then can the actor respond using an requested could constitute an developing organizations meet the alternative machine-readable format, interference. We refer readers to the institute’s requirements for openness, including the means to interpret the discussion of ‘‘Limiting or Restricting balance, consensus, and due process. EHI, agreed to by the actor and requestor the Interoperability of Health IT’’ in Voluntary consensus standards (§ 171.301(b)(2)(i)(C)). This option to section VIII.C.6.c.ii. developed by an ANSI-accredited respond using an agreed upon Under § 171.301(b)(2)(i)(A), if an actor standards developing organization carry alternative machine-readable format is a does not fulfill a request described in a high degree of acceptance both in flexible option for actors who cannot the content condition of this exception United States and internationally. ANSI meet the ‘‘manner’’ requirements in in any manner requested because it is has broad membership across § 171.301(b)(2)(i)(A) and (B), but still technically unable to fulfill the request government agencies, industry, want to be responsive to the requestor or cannot reach agreeable terms with the academia, and international bodies and and seek coverage under this exception. requestor to fulfill the request, the actor is the official United States Examples of alternative machine must fulfill the request in an alternative representative to the International readable formats include CSV, public manner. Specifically, the actor must Organization of Standards (ISO). This attempt to fulfill the request using manner of response also advances domain standards, public advisory technology certified to standards interoperability through standards- adopted in part 170 specified by the based exchange, even if the standard is 184 See ONC, Connecting Health and Care for the Nation, A Shared Nationwide Interoperability requestor. This manner of response is not certified under the Program. Roadmap, FINAL Version 1.0, https:// given precedence because it advances a As noted above, the ‘‘manner’’ of www.healthit.gov/sites/default/files/hie- certified, standards-based approach that response specific in § 171.301(b)(2)(i)(B) interoperability/nationwide-interoperability- supports the Promoting Interoperability includes two distinct components: (1) roadmap-final-version-1.0.pdf; ONC, 2015 Interoperability Standards Advisory, https:// Programs (previously Medicare and Content standard; and (2) transport www.healthit.gov/isa/sites/default/files/2015 Medicaid EHR Incentive Programs) standard. The content standard deals interoperabilitystandardsadvisory01232015final_ administered by the Centers for with whether the information is in an for_public_comment.pdf.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00238 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25879

standards, and other community efforts conditions are met (84 FR 7538 through emerged that are equally concerning (84 used to represent the data. 7541). FR 7538). We emphasize two key components of We proposed that the exception As just one illustration, some EHR § 171.301(b)(2)(i)(C). First, the would be subject to strict conditions to developers have begun conditioning alternative machine-readable format prevent its potential abuse. Specifically, access or use of customer EHI on must include the means to interpret the we explained our concern that a broad revenue-sharing or royalty agreements EHI. The goal with this requirement is or insufficiently tailored exception for that bear no plausible relation to the to ensure that, if an actor fulfills a the recovery of costs could protect rent- costs incurred by the EHR developer to request for access, exchange, or use of seeking, opportunistic fees, and grant access to the EHI. We have also EHI using an alternative machine- exclusionary practices that interfere heard of discriminatory pricing policies readable format, the EHI provided with the access, exchange, and use of that have the obvious purpose and effect through that format will be usable by EHI. We explained that these practices of excluding competitors from the use of the requestor. As an example, the format fall within the definition of information interoperability elements. Many of the used for the EHI Export functionality blocking and reflect some of the most industry stakeholders who shared their (§ 170.315(b)(10)) discussed earlier in serious concerns that motivated its perspectives with us in listening this final rule could be used to fulfill enactment (see 84 FR 7538 and section sessions prior to the Proposed Rule, such a request. Second, the alternative VIII.B of this preamble). For example, in including several health IT developers machine-readable format must be agreed the Information Blocking Congressional of certified health IT, condemned these upon with the requestor. This condition Report,185 we cited evidence of wide practices and urged us to swiftly ensures that, even if the actor is variation in fees charged for health IT address them (84 FR 7538). technically unable to meet the products and services. While we In light of these concerns, we requirements in § 171.301(b)(2)(i)(A) cautioned that the issue of fees is proposed that this exception would and (B), the actor is still providing the nuanced, and that variations in fees apply only to the recovery of certain requestor the opportunity to access, could be attributable in part to different costs and only when the actor’s methods exchange, or use the EHI in a manner technology architectures, service for recovering such costs comply with that is amenable to the requestor. models, capabilities, service levels, and certain conditions at all relevant times. In general, these conditions would b. Fees Exception—When will an actor’s other factors, we concluded that these factors alone could not adequately require that the costs the actor recovered practice of charging fees for accessing, were reasonably incurred, did not exchanging, or using electronic health explain all of the variation in prices that we had observed. Based on these and reflect costs that are speculative or information not be considered subjective, were appropriately allocated, information blocking? other indications, we concluded that some actors were engaging in and based on objective and verifiable We proposed in the Proposed Rule to opportunistic pricing practices or, in criteria. Further, the exception would establish an exception at § 171.204 (84 some cases, charging prices designed to not apply to certain fees, such as those FR 7589) to the information blocking deter connectivity or exchange with based on the profit or revenue provision that would permit the competing technologies or services. In associated with the use of EHI (either recovery of certain costs reasonably the time since we published the being earned by the actor, or that could incurred for the access, exchange, or use Information Blocking Congressional be realized by another individual or of EHI. We interpreted the definition of Report, these practices have persisted entity) that exceed the actor’s reasonable information blocking to include any fee and, in certain respects, become more costs for providing access, exchange, or that is likely to interfere with the access, pronounced. In a national survey of HIE use of the EHI (84 FR 7539 through exchange, or use of EHI. We noted that executives published in 2017, 47 7541). this interpretation may be broader than percent of respondents reported that Finally, the exception would provide necessary to address genuine EHR developers ‘‘often/routinely’’ additional conditions applicable to fees information blocking concerns and charge high fees for exchange that are charged in connection with: (1) The could have unintended consequences unrelated to cost, and another 40 certified APIs described in § 170.404 (84 on innovation and competition. percent reported that they ‘‘sometimes’’ FR 7594); and (2) the EHI export Specifically, unless we establish an do.186 Meanwhile, we have continued to criterion proposed in § 170.315(b)(10) exception, actors may be unable to receive credible evidence of rent- (84 FR 7590) to support single patient recover costs that they reasonably incur seeking and other opportunistic EHI export and to support the export of to develop technologies and provide behaviors, such as fees for data export all EHI when a health care provider services that enhance interoperability. and data portability that are not chooses to migrate information to This could undermine the ultimate plausibly related to any time, materials, another health IT system. We goals of the information blocking or other costs that a developer would emphasized that access to EHI that is provision by diminishing incentives to reasonably incur to provide these provisioned by supplying some form of invest in, develop, and disseminate services. And, while some practices physical media, such as paper copies interoperable technologies and services described in the Information Blocking (where the EHI is printed out), or where that enable more robust access, Congressional Report have become less EHI is copied onto a CD or flash-drive, exchange, and use of EHI. Therefore, we prevalent (such as the charging of per- would not be a practice that implicated proposed to establish an exception that transaction fees), other practices have the information blocking provision would permit the recovery of certain provided that the fee(s) charged for that costs that we believe are unlikely to 185 ONC, Information Blocking Congressional access complied with the HIPAA present information blocking concerns Report (April 2015), https://www.healthit.gov/sites/ Privacy Rule (45 CFR 164.524(c)(4)) (84 and would generally promote default/files/reports/info_blocking_040915.pdf. FR 7539). innovation, competition, and consumer 186 Julia Adler-Milstein and Eric Pfeifer, welfare, provided certain conditions are Information Blocking: Is It Occurring And What Clarification Policy Strategies Can Address It?, 95 Milbank met. We emphasized that actors can Quarterly 117, 124–25 (Mar. 2017), available at We clarify that the Fees Exception we make a reasonable profit under this http://onlinelibrary.wiley.com/doi/10.1111/1468- have finalized in this rule in no way exception, provided that all applicable 0009.12247/full. supports or encourages the sale of EHI.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00239 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25880 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

We emphasize that this exception regarding the application of the broad definition of information blocking permits the recovery of certain costs exceptions should the need arise. in section 3022(a) of the PHSA to reasonably incurred for the access, However, we believe the final rule encompass any fee that is likely to exchange, or use of EHI. We note that clearly describes the conditions actors interfere with the access, exchange, or many individuals and entities who are must meet in order to be covered by use of EHI (84 FR 7521). Fees that do considered ‘‘actors’’ under the each exception, and informational not meet this exception may implicate information blocking provision are also materials are not necessary at this time. the information blocking provision and subject to the HIPAA Privacy Rule and will have to be assessed on a case-by- Requirement That Costs Be Reasonably therefore prohibited from selling PHI case basis to determine, for example, the Incurred unless certain conditions are met, and actor’s intent and whether the practice in particular, receiving remuneration for In the Proposed Rule, we stated that, rises to the level of an interference. a disclosure of PHI in accordance with regardless of the type of cost at issue, a Consistent with the conditions of this 45 CFR 164.502(a)(5)(ii). This exception basic condition of the proposed exception, an actor seeking the to the information blocking definition in exception was that any costs the actor significant protection afforded by this no way affects existing HIPAA Privacy seeks to recover must have been exception will have to assess the fees Rule compliance responsibilities of reasonably incurred to provide the they charge in light of the costs entities subject to the HIPAA Rules. relevant interoperability elements for incurred. Comments. We received many the access, exchange, or use of EHI. We emphasize that our intention with comments in general support of the Whether a cost was reasonably incurred this exception is not to set any proposed exception. Commenters will ultimately depend on the particular particular fees related to products or appreciated ONC’s goal of addressing facts and circumstances. We requested services for accessing, exchanging, or rent-seeking, opportunistic fees, and comment on considerations that may be using EHI, but rather to allow the exclusionary practices that interfere relevant to assessing the reasonableness market to define the appropriate price with the access, exchange, and use of of costs incurred for purposes of this for such products or services so long as EHI. Some commenters suggested that exception (84 FR 7539). certain methods are followed and ONC should take additional steps and Comments. Several commenters certain criteria are met. We believe this measures to ensure that the requested additional clarity in the final approach is appropriate for this requirements under this exception are rule regarding various terms and exception in light of the considerable clear. A couple of commenters concepts in the proposed exception. diversity in the types of costs actors recommended that fees and costs of Commenters noted that many terms and might incur and the range of factors that information exchange should be made concepts regarding the reasonableness could bear on the reasonableness of publicly available. Another commenter of fees, and which fees would or would those costs. For example, the costs of suggested that ONC develop a process not be considered ‘‘reasonably developing software may vary with the for actors to routinely report their use of incurred’’ under the exception, were purposes it is intended to serve, the this exception, including specific ambiguous and overly broad. Some settings in which it will be deployed, timeframes for actors to submit commenters were concerned that such the types and scope of capabilities information to ONC and for ONC to ambiguity and vagueness could included, and the extent to which these determine whether the exception can be undercut ONC’s overall intent to development efforts build on existing applied under specific circumstances. prevent rent-seeking and opportunistic development efforts and know-how. Response. We thank commenters for fees and could create a loophole that Additionally, the costs of providing their support of and feedback on this would enable actors to use the services, including the implementation exception. We appreciate the exception to continue to charge of technology in production suggestions for improved transparency unreasonably high fees. Some environments, may vary based on the under this exception. We believe actors commenters requested additional technology design or architecture, should have discretion to decide if they examples of ‘‘costs reasonably incurred’’ individual customer needs, local would like to enhance transparency by under the exception. One commenter implementation conditions, and other making fees and costs of information asked that ONC outline different cost factors. An analysis of the approach for exchange publicly available. We believe categories (such as development costs, recovering costs will also account for that choosing not to disclose fees, on its deployment costs, usage costs) and different distribution and service own, would not likely implicate the indicate which of those costs would or models under which the costs are information blocking provision. Further, would not fall under the exception. A calculated. For these reasons, we have while we wholeheartedly support the couple of commenters requested that decided not to specify cost categories, goal of enhanced transparency and ONC explicitly state that fees the actor such as development costs, deployment commend commenters’ desire to pays to a developer for ‘‘Release of costs, usage costs, or ROI services and enhance transparency in the final rule, Information’’ (ROI) services and technology costs. However, we note that we believe their suggestions could technology would be considered ‘‘costs if an actor meets all necessary create additional burden for actors and reasonably incurred.’’ conditions of the finalized exception, such burden could outweigh the Response. We appreciate these the actor could recover such categories benefits of the measures they suggest. comments. Actors may choose to satisfy of cost under the exception. We will continue to consider steps to the conditions of this exception to be We have taken a few distinct steps to further promote transparency regarding certain that the fees they charge for the clarify this exception and address the our information blocking policies in access, exchange, or use of EHI do not overall concern from commenters future rulemakings. implicate the information blocking regarding the clarity of this exception. We appreciate the comment that we provision. We reiterate that failure to First, we have restructured the should develop a process for letting meet the exception does not mean that exception for clarity. We have changed actors know whether this exception an actor’s practice related to charging the title of the exception from could be applied under certain fees meets the information blocking ‘‘Exception—Recovering costs circumstances. We may consider definition. However, as we explained in reasonably incurred’’ to ‘‘When will an developing materials in the future the Proposed Rule, we interpret the actor’s practice of charging fees for

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00240 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25881

accessing, exchanging, or using actor seeks to recover its costs must specific factors and methods for electronic health information not be meet certain conditions. We proposed assessing when profit will be considered information blocking?’’ that this would require that the actor reasonable. We requested comment on Throughout this final rule preamble, we base its recovery of costs on objective whether the pro-competitive or use ‘‘Fees Exception’’ as a short form of and verifiable criteria that are uniformly efficiency-adding aspect of an actor’s this title, for ease of reference. As stated applied for all substantially similar or approach to providing access, exchange, in Section VIII.D of this final rule similarly situated classes of persons and or use of EHI should be taken into preamble, we have changed the titles of requests. We proposed that any account when assessing the all of the exceptions to questions to differences in prices or price terms reasonableness of profits. We asked improve clarity. We have also edited the would have to be based on actual commenters to consider whether there wording of the introductory text in differences in the costs that the actor are specific use cases for which actors’ § 171.302, in comparison to that incurred or other reasonable and non- profits should be limited or prohibited proposed (84 FR 7603), so that it is discriminatory criteria. We further for purposes of meeting the exception consistent with the finalized title in proposed to require that the method by (84 FR 7539). § 171.302. We believe these conforming which the actor recovers its costs must We also asked commenters to changes in wording of the introductory be reasonably related to the actor’s costs consider alternate approaches to the text also improve clarity in this section. of providing the type of access, exception that would also achieve the We have also divided the exception exchange, or use to, or at the request of, goal of allowing actors to recover certain into three conditions in § 171.302—(a) the person or entity to whom the fee is types of costs that would promote Basis for fees condition; (b) Excluded charged (84 FR 7539). innovation, competition and consumer fees condition; and (c) Compliance with We also proposed that the costs must welfare and that are unlikely to present the Conditions of Certification be reasonably allocated among all information blocking concerns. In condition. We explain upfront in the customers to whom the technology or assessing other potential approaches to introductory sentence of the exception service is supplied, or for whom the this exception, we encouraged that, pursuant to these conditions, an technology is supported. A reasonable commenters to contemplate such actor may charge fees, including fees allocation of costs would require that considerations as enforceability, that result in a reasonable profit margin, the actor allocate its costs in accordance potential burden on the parties, and for the access, exchange, or use of EHI with criteria that are reasonable and overall effectiveness in meeting the without implicating the information between only those customers that above stated goals (84 FR 7539). blocking provision. We believe this either cause the costs to be incurred or Comments. We received several framework provides actors with a clear benefit from the associated supply or comments regarding our proposed roadmap for voluntarily satisfying the support of the technology (84 FR 7539). approach for cost recovery and profits. conditions of the exception. We discuss We proposed that the exception Some commenters supported our the substantive changes we have made would not apply if the method by which proposed approach. A couple of to these provisions in the discussion of the actor recovers its costs is based, in commenters recommended that we each condition later in this section of any part, on whether the requestor or prohibit all profits under the exception the preamble. other person is a competitor, potential to ensure that actors cannot continue We also note that we have further competitor, or will be using the EHI in rent-seeking and exclusionary pricing clarified the fees allowed under this a way that facilitates competition with practices. Several commenters requested exception by focusing the scope of the the actor. The use of such criteria would clarification regarding the profits that EHI definition (discussed in section be suspect because it suggests the fee would be allowed under the exception VIII.C.3 of this preamble) and adding the actor is charging is not based on its and expressed concern that the paragraph (b) to the information reasonable costs to provide the services regulation text does not clearly state that blocking definition in § 171.103 and may have the purpose or effect of profits are allowed under the exception. (discussed in section VIII.C of this excluding or creating impediments for Several other commenters, primarily preamble). By changing the definition of competitors, business rivals, or other health IT developers, disagreed with the EHI to electronic protected health persons engaged in developing or proposed cost recovery approach and information (ePHI) as defined in 45 CFR enabling the use of interoperable limits on profits, expressing concern 160.103 included in a designated record technologies and services (84 FR 7539). that ONC’s proposals will serve as a set as defined in 45 CFR 164.501, we Last, we stated that the method by barrier to innovation, competition, and have focused the scope of information which the actor recovers its costs must interoperability. Some commenters covered by the information blocking not be based on the sales, profit, stated that ONC’s proposals regarding provision. In addition, under the revenue, or other value that the fees and profits go beyond the finalized information blocking requestor or other persons derive or may congressional intent in the Cures Act definition, for up to 18 months after the derive from the access to, exchange of, and questioned whether ONC has six-month delayed compliance date of or use of EHI, including the secondary regulatory authority to regulate costs the information blocking section of this use of such information, that exceeds and profits. final rule (part 171) (a total of 24 months the actor’s reasonable costs for the We received some comments that after the publication date of this final access, exchange, or use of EHI (84 FR recommended we take a different rule), EHI for purposes of the 7539). approach for assessing whether an information blocking definition is We requested comment on the actor’s costs recovered are reasonable. limited to the EHI identified by the data proposed conditions and other issues Commenters recommended using an elements represented in the USCDI we should consider in assessing approach that distinguishes, as standard adopted in § 170.213 (see whether the methodology by which an appropriate, between: (1) Pure cost or (§ 171.103(b)). actor distributes costs and charges fees expense recovery, with no provision for should be considered reasonable and margin or profit; (2) ‘‘cost-based Basis for Fees Condition necessary for purposes of the exception. pricing’’ or ‘‘cost plus accounting,’’ To qualify for this exception, we In particular, we noted that we were where margin or profit is allowed; and proposed that the method by which the considering whether to introduce (3) ‘‘market-based pricing,’’ where there

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00241 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25882 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

are no restrictions on pricing. A couple emphasize that our intention with this certainty about their practices related to of commenters recommended that exception is not to set any particular charging fees only need to comply with where a cost-based pricing mechanism costs that would be considered this exception if their practices interfere is required, the method for assessing the ‘‘reasonably incurred,’’ but rather to with the access, exchange, and use of cost basis should be reasonably allow the market to define the EHI. We emphasize that we are not associated with the complexity or cost appropriate price so long as certain limiting the fees and/or profits related to of providing the capabilities. Such methods are followed and certain the access, exchange, or use of methods could include reasonable criteria are met as established by the information outside the scope of EHI. heuristics, estimates, or other commonly conditions. To be responsive to We refer readers to section VIII.C.3 of used methods. comments, we have added text in the this preamble for a detailed discussion Commenters recommended that we introductory sentence of this exception of focused scope of the EHI definition. distinguish ‘‘basic access’’ (with no that clarifies that fees that result in a Second, under the finalized profits or limited profits) from ‘‘value- reasonable profit margin will be covered information blocking definition, for up added’’ access, exchange, or use (which by this exception so long as they are in to 18 months after the six-month would allow for increased profits). A compliance with the conditions in the delayed compliance date of the couple of commenters recommended exception (§ 171.302). information blocking section of this that allowed fees for ‘‘basic access’’ be We also appreciate the comments that final rule (part 171) (a total of 24 months on a pure direct cost recovery basis encouraged us to prohibit all profits after the publication date of this final only. Those commenters recommended under this exception. We considered rule), EHI for purposes of part 171 is that the cost to develop and/or map to this approach, but believe that actors limited to the EHI identified by the data standards should not be part of the cost should be able to make a reasonable elements represented in the USCDI basis for fees for ‘‘basic access;’’ rather profit margin, subject to the conditions standard adopted in § 170.213 (see any such costs should be a part of the in this exception. The allowance of a (§ 171.103(b)). The fees an actor charges fees for the health IT. The commenters reasonable profit margin is necessary to during that time will only be limited recommended that when the outputs of incentivize innovation and allow pursuant to the conditions in this value-added services are incorporated innovators to earn returns on the exception for that subset of EHI. into, or from, an essential part of the investments they have made to develop, We note that we revised legal medical record, or are routinely maintain, and update innovations that § 171.302(a)(1)(i) for clarity by limiting used for decision making, they ultimately improve health care delivery the requirement to ‘‘objective and constitute part of the set to which basic and benefit patients. We believe the verifiable criteria that are uniformly access is required. The commenters also finalized approach strikes the applied for all similarly situated classes recommended that we distinguish appropriate balance of addressing the of persons and requests’’ instead of between intellectual property (IP) rights rent-seeking and exclusionary pricing ‘‘objective and verifiable criteria that are that are essential to access EHI and IP practices noted by the commenters uniformly applied for all substantially rights that allow for value-added while enabling and supporting similar or similarly situated classes of services. innovation. However, to be responsive persons and requests.’’ We believe the Response. We thank commenters for to these comments related to limiting final standard achieves the same goal as their support of our proposals and for profits, we added a provision in the proposed standard and provides a the thoughtful comments on this aspect § 171.302(a)(1)(iv) that the fees an actor clearer condition for the regulated of the exception. We appreciate that charges must be based on costs not community to follow. We updated commenters were concerned both about otherwise recovered for the same § 171.302(a)(2)(ii) by removing the the elimination of rent-seeking, instance of service to a provider and illustrative language regarding the opportunistic fees, and exclusionary third party. The intent of this provision ‘‘secondary use of such information’’ pricing practices that interfere with the is that the exception will not apply to and by removing the proposed language access, exchange, and use of EHI as well practices where an actor charges twice about exceeding the actor’s reasonable as the importance of finalizing policies for the same exact service. For example, costs for providing access, exchange, or that support and promote innovation. the exception likely would not apply use of EHI (see 84 FR 7539). The We have finalized the proposed where an actor charges a hospital for provision finalized in approach for determining whether the providing a third party that the hospital § 171.302(a)(1)(ii)—that an actor’s fees basis for fees charged is acceptable contracts with access to certain EHI, and must be reasonably related to the actor’s under this exception, with some then charges that same third party an costs of providing the type of access, clarifications and updates detailed additional fee for access to the same exchange, or use of EHI to, or at the below. EHI. This condition creates a necessary request of, the person or entity to whom As we discussed in the Proposed guardrail to address potential misuse of the fee is charged—achieves the same Rule, we believe our approach will this exception that could result in a purpose of limiting fees to those provide actors that seek to meet this windfall for certain actors who charge necessary to recover the costs exception certainty that charging fees to fees for the same services multiple reasonably incurred. recover certain costs reasonably times. We removed the ‘‘secondary use’’ incurred for the access, exchange, or use We have also modified other aspects language because it seemed superfluous of EHI will not implicate the of this final rule that address commenter to include in the regulation text; information blocking provision, concerns regarding this exception. First, however, we emphasize that we provided the actor’s practice meets the as discussed previously in this section maintain that the fees an actor charges conditions of the exception. We reiterate and in more detail in section VIII.C.3 of must not be based on the sales, profit, that an actor who seeks to comply with this preamble, we have focused the revenue or other value that the requestor the conditions of this exception will not scope of the EHI definition. This change or other persons derive or may derive be prevented from making a reasonable addresses commenters’ concerns from the subsequent use of EHI. Our profit in connection with the access, regarding potential ambiguity regarding policy on this point has not changed exchange, or use of EHI, provided that the types of information for which from the Proposed Rule. Practices that all applicable conditions are met. We profits could be realized. Actors seeking use this method to recover costs will not

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00242 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25883

benefit from this exception and may fees to only a subset of their clarity regarding what is necessary to implicate the information blocking participants. However, as proposed, the meet the exception. provision. Last, we note that we have condition that costs be reasonably Comments. We received many added ‘‘or entities’’ to follow ‘‘person’’ allocated among all customers could comments, primarily from providers to align with the language in undercut this ability. Commenters and provider organizations, regarding § 171.302(a)(1)(ii). emphasized that the ability to offer free the potential financial burden the We note, with regard to the ‘‘basis for services to smaller providers, proposed exception will place on actors. fees’’ and ‘‘excluded fees’’ conditions particularly as HIEs/HINs work to Commenters recommended that ONC (§ 171.302(a) and (b), respectively), that engage providers across the care carefully consider the downstream each provision under these conditions continuum, is an important flexibility financial impact of new requirements, was proposed in the Proposed Rule with for such organizations. Commenters especially that providers, including the exception of two new provisions: (1) requested that HIE/HIN membership/ providers without certified health IT The fees an actor charges must be based participation costs and subscription fees and who do not participate in CMS on costs not otherwise recovered for the not be considered restricted fees under programs, will bear the brunt of the same instance of service to a provider the information blocking provision. financial burden of these policies. More and third party (§ 171.302(a)(1)(iv)); and Response. We thank commenters for specifically, commenters expressed (2) the fees an actor charges must not be these thoughtful comments. We concern regarding potential based on any costs that led to the maintain that the condition regarding recordkeeping and administrative creation of IP, if the actor charged a reasonable allocation of costs in burden caused by this exception. royalty for that IP pursuant to § 171.303 § 171.302(a)(iii) is necessary to ensure Commenters explained that actors may and that royalty included the that actors do not allocate fees in an need to retain extensive records to development costs for the creation of arbitrary or anti-competitive manner. document all of the costs that the actor the intellectual property The final condition requires that an incurred so that it can prove that its fees (§ 171.302(a)(2)(vi)). We discuss each of actor allocate its costs in accordance only constitute those costs plus a these additions in the discussion below. with criteria that are reasonable and reasonable profit. Further, commenters Regarding the conditions that were between only those customers that stated that the administrative burden included in the proposed exception, we either cause the costs to be incurred or required to assess and monitor this note that some of the conditions were in benefit from the associated supply or exception would be significant and not different subsections of the proposed support of the technology. We have sustainable. Commenters explained that exception and/or have been updated for finalized this condition with a cost accounting is challenging for even clarity and consistency with other modification discussed below. very large and well-resourced sections of this final rule. We describe organizations and there is concern that We agree with commenters that there all the substantive changes to these the exception will result in unintended may be situations when it would be provisions in this preamble, but refer negative consequences for many actors. reasonable for an actor to allocate costs readers to the proposed exception to Response. We appreciate these review the full scope of structural differently for different classes of comments. We reiterate that actors may changes and clarifications we have customers. In response to these choose to satisfy the conditions of this made (see 84 FR 7603). comments, we have revised the exception to be certain that the fees they Comments. We received some condition in § 171.302(a)(1)(iii) so that charge for the access, exchange, or use comments regarding the scaling of fees the fees an actor charges must be of EHI do not implicate the information and the proposed condition that the reasonably allocated among all similarly blocking provision. We also reiterate method by which the actor recovers its situated customers to whom the that failure to meet the exception does costs must be reasonably allocated technology or service is supplied, or for not mean that an actor’s practice related among all customers to whom the whom the technology is supported. This to charging fees meets the information technology or service is supplied or for addition addresses commenters’ blocking definition. However, as we whom the technology is supported. concerns by providing actors with the explained in the Proposed Rule, we Some commenters stated that the notion discretion to allocate costs differently interpret the broad definition of that costs can be evenly divided among for different classes of customers, while information blocking in section 3022(a) clients is flawed. Commenters requested ensuring that any differences in cost of the PHSA to encompass any fee that that ONC allow a fee scale as opposed allocation are based on actual is likely to interfere with the access, to a blanket fee structure. Commenters differences in the class of customer. For exchange, or use of EHI (84 FR 7521). noted that a sliding scale structure instance, under this provision, fees must Fees that do not meet this exception would ensure that smaller entities be reasonably allocated among all may implicate the information blocking would not be limited by a restrictive similarly situated large hospital systems provision and will have to be assessed pricing application that threatens their (above a certain established size on a case-by-case basis to determine, for operating costs, which may exist on a threshold) to whom a technology or example, the actor’s intent and whether slim margin. A couple of commenters service is supplied, or for whom the the practice rises to the level of an requested that ONC recognize that for technology is supported. However, the interference. This exception, as well as many organizations, especially non- allocation of fees for the same the other finalized exceptions, strike a profits, it is common and appropriate technology or service could be quite balance by identifying, as the Cures Act for fees to scale with the size of a different for a small, non-profit, rural requires, activities that interfere with member/participant organization. health clinic. access, exchange, or use of EHI but Several HIEs and HINs expressed We also note that we have replaced which are reasonable and necessary. concern that the proposed condition ‘‘customers’’ with ‘‘persons or entities’’ We believe the overwhelming benefits regarding the reasonable allocation of in § 171.302(a)(1)(iii) in order to align of the information blocking provision costs could have the unintended effect the language with § 171.302(a)(1)(i) and and the exceptions to the information of prohibiting the fee structure of many (ii). We believe aligning the provisions blocking definition—which enable public HIEs/HINs. Commenters noted within § 171.302(a) will strengthen the patients to access, exchange, and use that many HIEs/HINs choose to charge exception and provide actor’s with their EHI where and when it is

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00243 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25884 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

needed—far outweigh the potential believe there should be a distinction commenter requested additional clarity burden on actors. We believe the made between these two exceptions, about what ‘‘non-standard’’ means. A revisions we have made to this and have therefore decided not to couple of commenters noted that exception, the addition of paragraph (b) combine the two exceptions. requestors may prefer information in a in the information blocking definition We agree with the commenter that non-standard manner to meet their (see § 171.103(b)) and the discussion in actors should not be able to recover the business purposes, due to their own section VIII.C of this preamble), the same costs twice and have added a constraints, or for other reasons. addition of the Content and Manner provision in § 171.302(a)(2)(vi) that the Response. We thank commenters for Exception, as well as the revisions we fees an actor charges must not be based their support of this proposal, as well as have made to the other exceptions and on any costs that led to the creation of the constructive feedback. We relevant terms will have the overall IP, if the actor charged a royalty for that emphasize that the problematic nature effect of reducing burden on actors. The IP pursuant to § 171.303 and that royalty of non-standard implementation choices fact the information blocking section of included the development costs for the was identified by Congress in the Cures this rule (part 171) has a 6-month creation of the intellectual property. Act. Section 3022(a)(2)(B) of the PHSA delayed compliance date from the states that information blocking may Excluded Fees Condition publication date of this final rule will include implementing health IT in non- also relieve the burden on actors and We proposed that certain costs should standard ways that are likely to give them time to prepare for be explicitly excluded from the substantially increase the complexity or administrative changes. exception regardless of the method for burden of accessing, exchanging, or Comments. We received comments recovering the costs (84 FR 7540). using EHI. Due to Congress’s clear about the interplay and potential Comments. We did not receive objective to restrict these practices, overlap between the proposed Fees comments regarding the overall along with our continued concern that Exception and Licensing Exception. proposed approach of excluding certain these practices will lead to unnecessary Some commenters suggested that we costs from this exception. complexity and burden related to the combine the two exceptions for clarity. Response. We have finalized the access, exchange, or use of EHI, we have Some commenters requested structure of this exception to exclude finalized the proposed provision clarification as to whether an actor may certain fees with the changes described regarding non-standard design and charge both a fee to recover reasonable in the discussions above and below. We implementation choices. We have costs associated with EHI services and note that we have substituted the ‘‘or’’ updated § 171.302(a)(2)(iii) to address a reasonable royalty for licensing that preceded the final excluded fee in comments indicating that requestors interoperability elements. One the proposed exception (see 84 FR 7603) may prefer information in a non- commenter expressed concern that the with an ‘‘and’’ in the final exception. standard manner to meet their business overlap between the two exceptions This is not a substantive change, as our purposes, due to their own constraints, creates the potential for actors to recover intent has always been that the or for other reasons. We agree with the same costs twice. The commenter exception does not apply to each of commenters that in those situations— explained that licensing of IP is ‘‘excluded fees.’’ This revision clarifies when the requestor requests access, intended to recoup the costs of that point. exchange or use of EHI in the non- development of that IP, so where the IP Costs Due to Non-Standard Design or standard way—the exception should is an interoperability element, the costs Implementation Choices allow the actor to charge fees for the reasonably incurred for its development reasonable costs associated with the should be incorporated into the royalty We proposed that this exception requested non-standard design or rate. The commenter recommended that would not permit the recovery of any implementation. We emphasize, we should be clearer that, in these cost that the actor incurred due to the however, and make clear in circumstances, only a single recovery is health IT being designed or § 171.302(a)(2)(iii), that such fees related permitted. implemented in non-standard ways that to non-standard design or Response. We thank commenters for unnecessarily increase the complexity, implementation are only covered by the the thoughtful feedback and agree that difficulty or burden of accessing, exception when the requestor agreed to the distinction between the Fees exchanging, or using EHI. To the extent the fee associated with the non-standard Exception and the Licensing Exception that such costs can be reasonably design or implementation to access, (§ 171.303) must be clear. We emphasize avoided, we stated that we believe that exchange, or use EHI. We note that this that both exceptions deal with the fees actors should internalize the costs of provision was proposed as an ‘‘excluded actors may charge regarding the access, such behaviors, which do not benefit cost’’ but has been finalized within the exchange, or use of EHI and under both consumers, and which create ‘‘Basis for fees condition’’ for clarity and exceptions actors use interoperability unnecessary impediments to access, to align with the revised structure of elements (as defined in § 171.102) to exchange, and use of EHI. We requested this exception. facilitate the access, exchange, or use of comments on the proposed exclusion of We also note that the new Content EHI. The exception for recovering costs these types of costs from the exception and Manner Exception in § 171.301 reasonably incurred enables actors to (84 FR 7540). further addresses commenter concerns recover their costs to develop Comments. We received several because it provides actors with clear technologies and provide services that comments regarding the proposed procedures regarding the manner in enhance interoperability. On the other exclusion of costs due to non-standard which they may provide access, hand, the exception for licensing design or implementation choices from exchange, or use of EHI if they are interoperability elements specifically this exception. A couple of commenters technically unable to respond in the addresses circumstances when it is expressed support for the proposal. A manner requested or the manner necessary for an actor to license couple of other commenters disagreed requested requires the actor to license interoperability elements in order fulfill with the proposal and recommended intellectual property and the actor a request to access exchange, or use EHI. that actors should be able to recover all cannot reach agreeable terms with the The Licensing Exception deals with the reasonable implementation costs requestor (discussed in section requisite licensing conditions. We independent of design decisions. One VIII.D.2.a of this preamble). If an actor

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00244 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25885

meets that exception, its practice would the exception would not permit the specific opportunity costs on which a not implicate the information blocking recovery of certain types of costs that fee must not be based are those provision. For instance, if a requestor are subjective or speculative. We noted unrelated to the access, exchange, or use requested that the actor provide EHI in two important examples of this of EHI instead of the proposed a non-standard manner, but the actor is limitation. First, we proposed that an qualifying language of ‘‘except for the technically unable to provide the EHI in actor would not be permitted to recover reasonable forward-looking cost of the manner requested, the actor’s any costs associated with intangible capital’’ (see 84 FR 7603). We believe response to the request would not assets (including depreciation or loss of this finalized language is clearer than implicate the information blocking value), other than the actual the proposed language. In addition, it is provision if it provides the EHI via an development or acquisition costs of more precise than the proposed alternative manner in accordance with such assets. For example, an actor could language because it creates a connection § 171.301(b). The actor could also not charge a customer a fee based on the to the information blocking definition. potentially seek coverage under the purported ‘‘cost’’ of allowing the We note that we proposed these Infeasibility Exception if the request is customer to use the actor’s patented provisions as ‘‘excluded costs’’ (see 84 infeasible and the actor meets all the technology, computer software, FR 7603) but have finalized them within conditions in § 171.204. databases, trade secrets, copyrighted the ‘‘Basis for fees condition’’ for clarity. Regarding the comment concerning works, and the like. We noted that the Fee Prohibited by 45 CFR 164.524(c)(4) additional clarity about what ‘‘non- customer’s use of the asset could be standard’’ means, we explained and considered a ‘‘cost’’ in the sense that, We also proposed that the exception provided examples in the Proposed Rule were it not for the information blocking would not apply to fees prohibited by of practices related to implementing provision, the actor could charge a 45 CFR 164.524(c)(4). We noted in the health IT in non-standard ways that royalty or other fee for the use of its Proposed Rule that the HIPAA Privacy substantially increase the complexity or intangible assets. For this reason we Rule permits a covered entity to impose burden of accessing, exchanging, or proposed to permit an actor to license a reasonable, cost-based fee if the using EHI, and therefore implicate the most interoperability elements on individual requests a copy of the PHI (or information blocking provision (84 FR reasonable and non-discriminatory agrees to receive a summary or 7521). In addition, the Cures Act terms, subject to certain conditions. For explanation of the information). The fee specifically describes information purposes of this more general exception, may include only the cost of: (1) Labor blocking practices to include however, we explained that it would be for copying the PHI requested by the implementing health IT in nonstandard inappropriate to permit an actor to individual, whether in paper or ways that are likely to substantially charge a fee based on these electronic form; (2) supplies for creating increase the complexity or burden of considerations, which are inherently the paper copy or electronic media (e.g., accessing, exchanging, or using subjective and could invite the kinds of CD or USB drive) if the individual electronic health information (see rent-seeking and opportunistic pricing requests that the electronic copy be section 3022(a)(2)(B) of the PHSA). practices that fall squarely within the provided on portable media; (3) postage, Therefore, the Proposed Rule discussion definition of information blocking. We when the individual requests that the regarding non-standard ways of proposed that an actor’s practices could copy, or the summary or explanation, be implementing health IT also applies for qualify for both this exception (Fees mailed; and (4) preparation of an purposes of the Fees Exception. As Exception) and the Licensing Exception explanation or summary of the PHI, if explained in the Proposed Rule, non- (finalized in § 171.303). In that case, the agreed to by the individual (45 CFR standard implementation of health IT actor could recover costs under both 164.524(c)(4)). The fee may not include may arise where an actor chooses not to exceptions (84 FR 7540). costs associated with verification; adopt, or to materially deviates from, Second we stated the exception documentation; searching for and relevant standards, implementation would not apply to ‘‘opportunity costs,’’ retrieving the PHI; maintaining systems; specifications, and certification criteria such as the revenues that an actor could recouping capital for data access, adopted by the Secretary under section have earned had it not provided the storage, or infrastructure; or other costs 3004 of the PHSA (84 FR 7521). Even interoperability elements. We clarified not listed above even if such costs are where no federally adopted or identified that the exclusion of opportunity costs authorized by State law (84 FR 7540). standard exists, if a particular would not preclude an actor from Comments. We received a couple of implementation approach has been recovering its reasonable forward- comments regarding copying fees broadly adopted in a relevant industry looking cost of capital (84 FR 7540). allowed under the HIPAA Privacy Rule. segment, deviations from that approach Comments. We did not receive any One commenter stated that reasonable, will be suspect unless strictly necessary comments on our proposals regarding cost-based fees for certain costs, to achieve substantial efficiencies. For subjective or speculative costs. consistent with the HIPAA Privacy Rule further discussion regarding our Response. We have finalized this individual access provisions, should not rationale for this provision, as well as provision as proposed with some be allowed under the exception. One specific, non-exhaustive examples of modifications for clarity. We have commenter requested that ONC conduct that would be likely to interfere modified the provision regarding harmonize the exception with the with the access, exchange, or use of EHI, intangible assets in § 171.301(a)(2)(iv) HIPAA Privacy Rule provisions that we refer readers to the Proposed Rule by removing the parenthetical that govern the charging of fees for electronic (84 FR 7521). noted that such costs include the copies of medical records. depreciation or loss of value. The Response. We appreciate these Subjective or Speculative Costs parenthetical was illustrative and was comments. We have decided to finalize We proposed to limit this exception to not necessary in the regulation text, as the provision as proposed, which the recovery of costs that an actor it is just one of the many types of harmonizes this part of the exception actually incurred to provide the relevant intangible assets on which a fee must (§ 171.302) with those provisions of the interoperability element or group of not be based. We have also modified the HIPAA Privacy Rule. The exception elements (which may comprise either provision regarding opportunity costs in does not apply to fees prohibited by 45 products or services). We proposed that § 171.301(a)(2)(v) by clarifying that the CFR 164.524(c)(4). Consistent with the

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00245 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25886 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

HIPAA Privacy Rule’s individual access fundamental right to access their data EHI. ONC’s implementation of the Cures fee implementation specification, an and should be able to access, exchange, Act is predicated on an understanding actor can charge a reasonable, cost- and use their EHI at no charge. that access to EHI should not be treated based fee related to certain costs Commenters emphasized that the EHI as a commodity that should be traded or (described above) if a patient requests a belongs to the patient, and neither sold. ONC takes this approach because copy of her records. health care providers, EHR developers, we view patients as having an nor payers should profit from the sale of Individual Electronic Access overwhelming interest in EHI about EHI, as that will only serve to limit data themselves, and because we understand We proposed that the exception transfer, increase health care costs, and that the true value of EHI can only be would not apply if the actor charged a adversely affect patient care. realized if it is available where and fee based in any part on the electronic Commenters strongly supported our when it is needed, including providing access by an individual or their personal proposal (within the API Condition of electronic access to patients. Patients representative, agent, or designee to the Certification) that API fees should not have already effectively paid for their individual’s EHI. We stated that such be a barrier in allowing patient access to health information, either directly or fees are distinguished from the cost- their EHI (see proposed § 170.404 and through their employers, health plans, based fees that a covered entity is 84 FR 7487 through 7491). They and other entities that negotiate and permitted to charge individuals for the stressed that neither individuals nor app purchase health care items and services provision of copies of ePHI under the developers (i.e., API Users) should be on their behalf. We have codified this HIPAA Privacy Rule access provisions charged a fee for API uses that are provision in § 170.302(b)(2) to not (45 CFR 164.524(c)(4)), and similar associated with the access, exchange, permit ‘‘[a] fee based in any part on the allowable costs under State privacy and use of EHI by patients or their electronic access of an individual’s EHI laws, which would not be excluded applications, technologies, or services. by the individual, their personal from the costs recoverable under the Several commenters supported our representative, or another person or exception. We clarified that access to efforts to bolster patient access, noting entity designated by the individual.’’ EHI that is provisioned by supplying that the capacity to offer a patient access For purposes of the Fees Exception, some form of physical media, such as to EHI, through an API, without cost, is we define electronic access to mean an paper copies (where the EHI is printed well-supported in the Proposed Rule. internet-based method that makes EHI out), or where EHI is copied onto a CD One commenter requested that we available at the time the EHI is or flash-drive, would not be a practice differentiate between an individual that implicated the information blocking electronically accessing EHI and third requested and where no manual effort is provision provided that the fee(s) parties, at the direction of the required to fulfill the request charged for that access complied with individual, electronically accessing EHI. (§ 171.302(d)). We discussed the the HIPAA Privacy Rule access Response. We thank commenters for meaning of ‘‘electronic access’’ in the provisions (45 CFR 164.524(c)(4)) (84 FR the support and have finalized this Proposed Rule (see 45 FR 7540). We 7540). provision as proposed with a slight have defined ‘‘electronic access’’ in We stated that a fee based on modification to the text in § 171.302(d) in this final rule consistent electronic access by an individual or § 171.302(b)(2) and clarification of the with the Proposed Rule, including their personal representative, agent, or meaning of electronic access, which we distinguishing it from the methods and designee to the individual’s EHI, in have codified in § 171.302(d). We have efforts we cited in the Proposed Rule contrast, would arise if an actor sought reordered the language for clarity and, that we did not consider electronic to impose on individuals, or their in order to clarify the terms ‘‘agent’’ and access and for which a fee could be personal representatives, agents, or ‘‘designee,’’ we have replaced them with charged (see 45 FR 7540). We have designees, a fee that operated as a toll ‘‘another person or entity designated by chosen ‘‘internet-based method’’ in lieu to electronically access, exchange, or the individual.’’ These other individuals of the proposed ‘‘web-based delivery’’ use EHI. For example, a health care or entities (e.g., a third-party app) because it more technically aligns with provider that charges individuals a fee receive access to EHI at the direction of the concept we were attempting to in order for the individuals to receive the individual and individuals control convey in the Proposed Rule. Such access to their EHI via the health care whether the third-party receives access methods would be, as described in part provider’s patient portal or another to the individual’s EHI. This in the Proposed Rule, access via an API, internet-based method, would not be modification is merely a clarification of patient portal, or other internet-based able to benefit from this exception. our proposal and is not a substantive means. To note, the 2015 Edition ‘‘view, Similarly, where an individual change as we clearly stated in the download, and transmit to 3rd party’’ authorizes (approves) a consumer-facing Proposed Rule that, as summarized certification criterion uses this same app to receive EHI on the individual’s above, this exception would not apply concept of ‘‘internet-based’’ to convey behalf, the exception would not apply to to practices where an actor charges the that ‘‘patients (and their authorized practices where an actor charges the app app or its developer a fee to access or representatives) must be able to use or its developer a fee to access or use use APIs that enable access to the internet-based technology to view, APIs that enable an individual’s access individual’s EHI. Fees can be a method download, and transmit. . . .’’ In terms to the individual’s EHI. We explained of interfering with the access, exchange, of fulfilling a request without manual that this would be true whether the and use of EHI, as we have emphasized effort, we clarify that it entails the actor is a supplier of the API technology in the Proposed Rule and this final rule. completion of the process where there is or an individual or entity that has When it comes to an individual’s no manual effort involved to meet the deployed the API technology, such as a electronic access to their EHI, we request at the time of the request. To health care provider (84 FR 7540). believe that any fee, whether direct or illustrate the inverse, we recognize that Comments. Commenters expressed indirectly passed on through a fee there are times that manual effort may overwhelming support for our proposal charged to a third-party app that the be involved in collating or assembling regarding individual electronic access. individual has chosen to facilitate EHI from various systems in response to Commenters from across stakeholder access to their EHI, could interfere with a request. In such instances, this groups emphasized that patients have a an individual’s access and use of their provision (§ 170.302(b)(2)) would not

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00246 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25887

apply to the costs of those efforts conversion or migration of data for these other conditions described above and in because the efforts would not fall under purposes. We emphasized that our proposed § 171.205(a). the definition of ‘‘electronic access.’’ concerns are compounded by the fact Second, we proposed that the We reaffirm that this exception would that EHR developers rarely disclose in exception would not apply to a fee to not apply to an actor that charges advance the fees they will charge for export or convert data from an EHR individuals a fee in order for the data export and data portability services technology unless such fee was agreed individuals to receive access to their (see 80 FR 62719; 80 FR 16880 and 81). to in writing at the time the technology EHI using an internet-based delivery For these reasons, we proposed that was acquired, meaning when the EHR method, including where an individual fees charged for the export, conversion, developer and the customer entered into uses consumer-directed technology (e.g., or migration of data from an EHR a contract or license agreement for the patient-chosen apps, personal health technology would not qualify for this EHR technology (84 FR 7541). apps, standalone/untethered personal exception unless they also meet two Comments. A commenter requested health records (PHR), email) to request additional conditions. First, we clarification regarding the proposal to and/or receive their EHI. This includes proposed that health IT developers of exclude from the exception costs related sharing it with an entity designated by certified health IT would, for purposes to fees to export or convert data from an the individual (e.g., allowing of the exception, be precluded from EHR technology, unless such fee was individuals to donate/share EHI with a charging a fee to perform an export of agreed to in writing at the time the biomedical research program of the EHI via the capability of health IT technology was acquired. The individual’s choice). Practices that certified to the proposed 2015 Edition commenter asked that ONC clarify if involve an actor charging an individual ‘‘EHI export’’ certification criterion for this provision is applicable to export or (or the individual’s personal the purposes of supporting single the conversion of EHI from certified health IT or if it is applicable to any representative or another person or patient EHI export upon a valid request export or conversion of EHI from any entity designated by the individual) a from that patient or a user on the health IT. The commenter also fee to access, exchange, or use their EHI patient’s behalf, or supporting the requested that ONC clarify if this would be inherently suspect and would export of all EHI when health care provision is prospective in nature, be extremely likely to implicate the provider chooses to transition or migrate meaning it would only apply to information blocking provision. We information to another health IT system. agreements entered into after the emphasize that practices that do not We stated that, as part of the effective date of a final rule. The meet this condition, or any other ‘‘Assurances’’ Condition of Certification, conditions in the Fees Exception, would commenter recommended that ONC health IT developers that produce and be subject to case-by-case review (unless change the focus of this proposal so that electronically manage EHI would need another exception applies). We further it only requires that the parties agree in to be certified to the criterion and refer readers to our discussion of writing that fees of a particular nature provide the functionality to its ‘‘interfere with’’ or ‘‘interference,’’ may be charged for the export of EHI. customers. We stated that fees or including examples of practices that Response. We appreciate this limitations associated with the use of would likely interfere with access, comment. In response to the comment, the ‘‘EHI export’’ certification criterion exchange, and use of EHI (section we clarify that this exclusion from the (as distinguished from deployment or VIII.C.6). exception is not limited to the export of other costs reasonably incurred by the EHI from certified health IT. Instead, Export and Portability of EHI developer) would not receive protection this provision applies to the export or Maintained in EHR Systems under the exception and may be suspect conversion of any EHI from an actor’s We explained in the Proposed Rule under the information blocking technology(ies). As we discuss that the definition of information provision (84 FR 7541). elsewhere in this Final Rule, we blocking specifically mentions We clarified that the condition would interpret the information blocking transitions between health IT systems not preclude a developer from charging provision broadly such that practices of and the export of complete information a fee to deploy the ‘‘EHI export’’ a health IT developer of certified health sets as protected forms of access, certification criterion in a health care IT that do not pertain specifically to exchange, and use (see section provider’s production environment, or certified health IT may implicate the 3022(a)(2)(C)(i) of the PHSA). We noted to provide additional services in information blocking provision. that in our experience, health care connection with this capability other Consistent with this interpretation of providers frequently encounter rent- than those reasonably necessary to the information blocking provision, the seeking and opportunistic pricing enable its intended use. For example, exception will not protect practices practices in these and other contexts in we explained that this condition would where an actor charges fees to export or which they are attempting to export EHI not preclude a developer from charging convert data from any EHR technology, from their systems for use in connection a fee to perform an export of EHI via the unless such fee was agreed to in writing with other technologies or services that capability of health IT certified to the at the time technology was acquired. compete with or could reduce the proposed § 170.315(b)(10) for a third- Further, we clarify that if a fee to export revenue opportunities associated with party analytics company. We noted in or convert data is not subject to this an EHR developer’s own suite of the Proposed Rule that, because the exclusion in § 171.302(b)(4) because it products and services. We explained certification criterion provides only a was agreed to in writing, it still must that most EHI is currently maintained in baseline capability for exporting data, meet the other applicable conditions in EHRs and other source systems that use we anticipated that health IT developers § 171.302 to be covered by the Fees proprietary data models or formats; this of certified health IT will need to Exception. puts EHR developers in a unique provide other data portability services to Without this exclusion, actors may position to block the export and facilitate the smooth transition of health seek to take advantage of the exception portability of EHI for use in competing care providers between different health and enable rent-seeking or opportunistic systems or applications, or to charge IT systems. We proposed that such fees pricing practices. Thus, we have rents for access to the basic technical may qualify for protection under the decided not to limit the condition so information needed to facilitate the exception, but only if they meet the that it only requires that the parties

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00247 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25888 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

agree in writing that fees of a particular usage fee to patient-oriented apps. We the information blocking provision that nature may be charged for the export of noted that information blocking would permit actors to license EHI as suggested by the commenter. concerns would arise if a provider were interoperability elements on reasonable Only requiring the parties to agree to the to charge such a fee, notwithstanding and non-discriminatory (RAND) terms, fee in writing (without applying the the fact that the provider is not subject provided that certain conditions are other conditions in this exception), may to the certification requirements. For met. We proposed that the information allow an actor to charge an this reason, we proposed that, if the blocking provision would be implicated unreasonable fee or engage in a practice actor is an API Data Provider, the actor if an actor were to refuse to license or that is likely to interfere with the access, would only be permitted to charge the allow the disclosure of interoperability exchange, or use of EHI. While a party same fees that an API Technology elements to persons who require those may agree to pay a fee under specific Supplier would be permitted to charge elements to develop and provide circumstances, that agreement does not to recover costs consistent with the interoperable technologies or services— change the fact that the fee must be permitted fees specified in the including those that might complement reasonably related to the actor’s costs or Condition of Certification (84 FR 7541). or compete with the actor’s own may otherwise interfere with the access, Comments. We did not receive technology or services (84 FR 7544). exchange, or use of EHI. comments on these proposals. Moreover, we proposed that the We have finalized these provisions as Response. We have finalized the first information blocking provision would proposed with a slight modification. We provision detailed above as proposed be implicated if the actor licensed such changed the condition from ‘‘A fee to with a slight modification for clarity. interoperability elements subject to export or convert data from an EHR The final provision in § 171.302(c) terms or conditions that have the technology, unless such fee was agreed states: Notwithstanding any other purpose or effect of excluding or to in writing at the time the technology provision of this exception, if the actor discouraging competitors, rivals, or was acquired’’ (see 84 FR 7603) to ‘‘A is a health IT developer subject to the other persons from engaging in these fee to export or convert data from an Conditions of Certification in pro-competitive and interoperability- EHR technology that was not agreed to § 170.402(a)(4), § 170.404, or both of this enhancing activities. Thus, we proposed in writing at the time the technology subchapter, the actor must comply with the Licensing Exception would apply in was acquired’’ (§ 171.302(b)(4)). We all requirements of such conditions for both vertical and horizontal made this change for clarity based on all practices and at all relevant times. relationships and provided an example the change we made to the introductory We added ‘‘or both’’ into the final emphasizing that point in the Proposed language in the exception, that a language because a health IT developer Rule (see 84 FR 7544). practice will not be considered could be subject to both § 170.402(a)(4) We noted in the Proposed Rule that information blocking when the practice and § 170.404 and in such instances some licensees do not require meets the conditions in paragraph (a), would be covered by this provision. interoperability elements to develop does not include any of the excluded We have removed the second products or services that can be fees in paragraph (b), and, as applicable, provision detailed above regarding a interoperable with the actor’s health IT. meets the condition in paragraph (c). health care provider that acts as an API We explained that there may be firms This modification does not change the Data Provider (see the Proposed Rule at that simply want to license the actor’s substance of this condition in any way. 84 FR 7603) for clarity, as not all of the technology for use in developing their own interoperability elements. Their Compliance With the Conditions of permitted fees specified in the API interest would be for access to the Certification Condition of Certification (§ 170.404) are applicable for API Data Providers. technology itself—not for the use of the We stated in the Proposed Rule that technology to interoperate with either health IT developers of certified health Application of the Exception to the actor or its customers to enable the IT subject to the API Condition of Individual Practices access, exchange, or use of EHI. We Certification may not charge certain We stated in the Proposed Rule that emphasized that in such cases, the types of fees and are subject to more the conditions of this exception, actor’s licensing of its intellectual specific cost accountability provisions including those governing the property (IP) in such a context would than apply generally under this methodology and criteria by which an not implicate the information blocking proposed exception. We noted that the actor calculates and distributes its costs, provision (in other words, would not be failure of developers to comply with must be satisfied for each and every fee in scope for information blocking). For these additional requirements would that an actor charges to a customer, a non-exhaustive list of examples of impose impediments to consumer and requestor, or other person for accessing, situations that would implicate the other stakeholder access to EHI without exchanging, or using EHI. All applicable information blocking provision, see the special effort and would be suspect conditions of the exception must be met Proposed Rule (84 FR 7544–45). under the information blocking at all relevant times for each practice (84 In our experience, contractual and IP provision. We proposed, therefore, that FR 7541). rights are frequently used to extract a health IT developer of certified health Comments. We did not receive any unreasonable rents for access to EHI or IT subject to the API Condition of comments on this proposed policy. to prevent competition from developers Certification must comply with all Response. We have finalized this of interoperable technologies and requirements of that condition for all policy as proposed. services. These practices frustrate practices and at all relevant times in access, exchange, and use of EHI and order to qualify for the exception (84 FR c. Licensing Exception—When will an stifle competition and innovation in the 7541). actor’s practice to license health IT sector. As a case in point, we We also stated that a health care interoperability elements in order for noted in the Proposed Rule that even provider that acts as an API Data electronic health information to be following the enactment of the Cures Provider should be subject to the same accessed, exchanged, or used not be Act, some health IT developers had constraints. We noted that the API considered information blocking? been selectively prohibiting—whether Condition of Certification prohibits a We proposed in the Proposed Rule in expressly or through commercially health IT developer from charging a § 171.206 to establish an exception to unreasonable terms—the disclosure or

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00248 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25889

use of technical interoperability exchange, and use of EHI, particularly business purposes. We emphasize that information required for third-party because of the power dynamics that we made such a distinction in the applications to access, exchange, and exist in the health IT market (84 FR Proposed Rule and we reiterate that use EHI maintained in EHR systems. We 7545). distinction here in the final rule. In noted that such practices limit health We also emphasized that actors are order for an actor to consider licensing care providers’ use of the EHI not required to seek the protection its interoperability elements under this maintained on their behalf to the under this (or any other) exception. We exception, the requestor would need to particular capabilities and use cases that explained that if an actor does not want have a claim to the underlying, existing their EHR developer happens to to license a particular technology in EHI for which the interoperability support. More than this, by limiting the accordance with the exception, it may element would be necessary for access, ability of providers to choose what choose to comply with the information exchange, or use (see the Privacy applications and technologies they can blocking provision in another way, such Exception discussion in VIII.D.1.b). An use with their EHR systems, we as by developing and providing actor will not implicate the information indicated that these practices close off alternative means of accessing, blocking provision and does not need to the market to innovative applications exchanging, and using EHI that are seek coverage under this exception in and services that providers and other similarly efficient and efficacious (84 FR circumstances where the entity stakeholders need to deliver greater 7545). requesting to license or use the value and choice to health care Comments. We received many interoperability element is not seeking purchasers and consumers (84 FR 7545). comments in support of this proposed to use the interoperability element to Despite these serious concerns, we exception. One commenter highlighted interoperate with either the actor or the recognized in the Proposed Rule that the the significance of the exception, noting actor’s customers in order for EHI to be definition of information blocking may that data is often locked in proprietary accessed, exchanged, or used. For be broader than necessary and could software systems, at times preventing instance, an actor would not need to have unintended consequences. We providers from being able to connect consider licensing its interoperability proposed that it is generally appropriate and exchange information. Some elements in accordance with this for actors to license their IP on RAND commenters requested additional exception to a firm that requested a terms that do not interfere with access, examples and that ONC issue guidance license solely for that firm’s use in exchange, or use of EHI provided certain to assist actors in understanding how developing its own technologies or conditions were met. We explained that they can determine whether a request to business when no EHI is sought to be these practices would further the goals license is valid, when this exception accessed, exchanged, or used. In other of the information blocking provision by would apply, and what steps actors words, if there is no nexus between a allowing actors to protect the value of would be required to take to attain requestor’s need to license an coverage under the exception. A couple their innovations and earn returns on interoperability element and existing of commenters suggested that there the investments made to develop, EHI on one or more patients, an actor should be a distinction between maintain, and update those innovations. does not need to consider licensing the requests to license interoperability We explained that this would protect interoperability element requested in elements to facilitate a patient’s future incentives to invest in, develop, accordance with this exception. For treatment or individual access versus and disseminate interoperable example, if a developer of certified requests that are simply for the technologies and services. Conversely, health IT included proprietary APIs in we explained that if actors cannot (or requestor’s own business purposes, such its product to support referral believe they cannot) protect and as commercializing a competing management, it would not need to commercialize their innovations, they product. A couple of commenters license the interoperability element(s) may not engage in these productive requested additional provisions in the associated with those referral activities that improve access, exchange, final rule to improve transparency management APIs simply because a and use of EHI (84 FR 7545). regarding licensing of interoperability We proposed that the exception elements. Commenters recommended requestor ‘‘knocked on the actor’s door’’ would be subject to strict conditions to that ONC require regulated actors who and asked for a license with no EHI ensure, among other things, that actors engage in RAND licensing of involved. The license request from a license interoperability elements on interoperability elements to publish requestor must always be based on a RAND terms and that actors do not either standard licensing rate offers or need to access, exchange, or use EHI at impose collateral terms or engage in actual licenses. the time the request is made—not on the other practices that would impede the Response. We thank commenters for requestor’s prospective intent to access, use of the interoperability elements or their support for this exception as well exchange, or use EHI at some point in otherwise undermine the intent of the as the constructive feedback. We may the future. exception (84 FR 7545). We consider developing materials in the We appreciate the recommendation acknowledged that preventing IP future regarding the application of the that ONC should require regulated holders from extracting rents for access exceptions should the need arise. actors who license interoperability to EHI may differ from standard IP However, we believe the final rule elements to publish either standard policy. We proposed that absent specific clearly describes the conditions actors licensing rate offers or actual licenses. circumstances, IP holders are generally must meet in order to be covered by However, we have decided not to free to negotiate with prospective each exception, and informational finalize such a requirement because we licensees to determine the royalty to materials are not necessary at this time. believe actors should have discretion to practice their IP, and this negotiated We appreciate the comments that decide whether to publish their royalty frequently reflects the value the recommended that there should be a licensing rates and/or licenses. We licensee would obtain from exercising distinction between requests for believe this exception will still those rights. However, in the context of licensing of interoperability elements to effectively regulate the licensing of EHI, we proposed that a limitation on facilitate a patient’s treatment or interoperability elements even if it does rents is essential due to the likelihood individual access versus requests that not require the publication of such rates that rents will frustrate access, are simply for the requestor’s own and licenses. Nonetheless, we commend

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00249 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25890 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

commenters’ desire to enhance Commenters recommended that actors interfere with the access, transparency in the final rule and will licensing agreements that were entered exchange, and use of EHI is through continue to consider steps to further into prior to the effective date of the formal restrictions, such as promote transparency regarding our final rule should be considered valid discriminatory licensing agreements, information blocking policies in future and effective. Commenters also and this final rule, as well as this rulemakings. recommended that all negotiations and exception, seek to address those very We note that we have changed the licensing agreements entered into after circumstances and situations. title of this exception from ‘‘Exception— the effective date of ONC’s final rule Comments. One commenter expressed Licensing of interoperability elements should comply with the requirements of concern about this exception on privacy on reasonable and non-discriminatory the final rule. Commenters requested and security grounds. The commenter terms’’ to ‘‘When will an actor’s practice that if ONC plans to enforce provisions noted that a proliferation of EHI to a to license interoperability elements in of the final rule retroactively, ONC multitude of entities who have not and order for electronic health information should allow actors to review and cannot be vetted is likely to increase the to be accessed, exchanged, or used not renegotiate licensing agreements for risks to the privacy and security of such be considered information blocking?’’ compliance with the terms at the data and create secondary and tertiary Throughout this final rule preamble, we request of the licensee. markets for such data without clear use ‘‘Licensing Exception’’ as a short Response. We thank commenters for regulation and oversight. form of this title, for ease of reference. these comments. We emphasize that Response. We appreciate this As stated in Section VIII.D of this final actors are expected to be in full comment and understand that the rule preamble, we have changed the compliance with the information secondary use of data creates privacy titles of all of the exceptions to blocking provision when this rule and security challenges in the health questions to improve clarity. We have becomes effective. We note that the care industry and beyond. We refer also edited the wording of the information blocking section of this readers to section VIII.C.6 of this introductory text in § 171.303, in final rule (part 171) will not become preamble for a detailed discussion of comparison to that proposed (84 FR effective until 6 months after the how we are addressing this issue in this 7602), so that it is consistent with the publication date of the final rule. We rule. finalized title in § 171.303. We believe believe this delayed compliance date i. Responding to Requests these conforming changes in wording of will provide actors with adequate time the introductory text also improve to assess their existing licensing We proposed that, upon receiving a clarity in this section. contracts or agreements and make request to license or use interoperability Comments. We received many appropriate changes and amendments to elements, an actor would be required to comments requesting greater clarity and comply with this final rule. respond to the requestor within 10 precision regarding key terms within the OIG and ONC are coordinating timing business days from receipt of the proposed exception in order to clarify of the compliance date of the request. We noted that the request could the scope and application of the information blocking section of this be made to ‘‘license’’ or ‘‘use’’ the exception. final rule (45 CFR part 171) and the start interoperability elements because a Response. We appreciate these of information blocking enforcement. requestor may not always know that comments and agree with commenters We are providing the following ‘‘license’’ is the legal mechanism for that it is essential that our final policies information on timing for actors. ‘‘use’’ when making the request (84 FR are clear, administrable, and actionable. Enforcement of information blocking 7546). Accordingly, we have made several CMPs in section 3022(b)(2)(A) of the In order to meet this condition, we updates to this exception as well as to PHSA will not begin until established proposed that the actor would be terms and concepts that apply broadly by future notice and comment required to respond to the requestor throughout the information blocking rulemaking by OIG. As a result, actors within 10 business days from the receipt section. Notably, we have: (1) Revised would not be subject to penalties until of the request by: (1) Negotiating with the definition of interoperability CMP rules are final. At a minimum, the the requestor in a RAND fashion to element (see section VIII.C.3.b); (2) timeframe for enforcement would not identify the interoperability elements clarified the process and timeframe for begin sooner than the compliance date that are needed; and (2) offering an negotiating a license (see the discussion of this final rule and will depend on appropriate license with RAND terms, later in this section of the preamble); (3) when the CMP rules are final. Discretion consistent with its other obligations removed the ‘‘RAND’’ framework, will be exercised such that conduct that under the exception. We emphasized which commenters noted was confusing occurs before that time will not be that, in order to qualify for the proposed (see the discussion later in this section subject to information blocking CMPs. exception, the actor would only be of the preamble); and (4) clarified the We are aware that some actors may required to negotiate with the requestor relationship between this exception and currently have in place licensing in a RAND fashion and to offer a license the Fees Exception (see § 171.302 and agreements that contravene the with RAND terms. We proposed that the the discussion later in this section of the information blocking provision and do actor would not be required to grant a preamble). not meet the requisite conditions for license in all instances. We did not Comments. A few commenters this exception. We expect actors in propose a set timeframe for when the requested clarification regarding these situations to take immediate steps negotiations must be resolved (84 FR whether the information blocking to come into compliance with the 7546). provision, and particularly this information blocking provision by We requested comment on whether 10 exception, applies to all licensing amending their contracts or agreements business days is an appropriate amount agreements already in effect; only to eliminate or void any clauses that of time for the actor to respond to the licensing agreements that were entered contravene the information blocking requestor. We noted that we considered into following the effective date of the provision. We emphasize that an proposing response timeframes ranging Cures Act; or only those licensing existing license is no excuse or from 5 business days to 15 business agreements entered into after the justification for information blocking. days. We also considered proposing two effective date of ONC’s final rule. One of the ways we have heard that separate timeframes for: (1) Negotiating

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00250 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25891

with the requestor; and (2) offering the The finalized provision in § 171.303(a) ii. Licensing Conditions license. We stated that if commenters states that, upon receiving a request to We proposed to require, as a prefer a different response timeframe or license an interoperability element for condition of this exception, that any approach than proposed, we requested the access, exchange, or use of EHI, the terms upon which an actor licenses that commenters explain their rationale actor must: (1) Begin license interoperability elements must be with as much detail as possible. In negotiations with the requestor within reasonable and non-discriminatory addition, we requested comment on 10 business days from receipt of the (RAND). We recognized in the Proposed whether we should create set limits for: request (§ 171.303(a)(1)); and (2) Rule that strong legal protections for IP (1) The amount of time the requestor has negotiate a license with the requestor, rights can promote competition and to accept the actor’s initial offer or make subject to the licensing conditions in innovation. Nevertheless, IP rights can a counteroffer; (2) if the requestor makes paragraph (b) of the exception, within also be abused in ways that undermine a counteroffer, the amount of time the 30 business days from receipt of the these goals. We explained that we actor has to accept the requestor’s request (§ 171.303(a)(2)). We note that believe this potential for abuse is counteroffer or make its own the expectation in (2) above is that the heightened when the IP rights pertain to counteroffer; and (3) an allowable actor will negotiate with the requestor functional aspects of technology that are number of counteroffers in negotiations in good faith. If it is determined that the essential to enabling interoperability. (84 FR 7546). negotiation is not in good faith, the actor We emphasized that to the extent that Comments. We received many would not qualify for this exception. the interoperability elements are comments regarding the proposed These provisions create a clear and essential to enable the efficient access, framework and timeframe for administrable timeline for actors to exchange, or use of EHI by particular responding to requests to license or use follow that is informed by stakeholder persons or for particular purposes, any interoperability elements. Some comments and will reduce potential practice by the actor that could impede commenters were supportive of our burden on actors. Further, it provides proposal and stated that 10 business actors with appropriate flexibility for the use of the interoperability elements days is an appropriate amount of time negotiating a good faith license, taking for that purpose—or that could for the actor to respond to the requestor. into consideration the potential unnecessarily increase the cost or other Other commenters disagreed with the complexity and variability associated burden of using the elements for that proposed timeframe, explaining that 10 with negotiations for licensing purpose—would give rise to an obvious business days is insufficient time to interoperability elements. risk of interference with access, begin a license negotiation. Commenters In instances when an actor is unable exchange, or use of EHI under the suggested various alternate timeframes to negotiate a good faith license subject information blocking provision (84 FR ranging from 20 to 90 business days. to the requirements in § 171.303(a)(2), 7546). One commenter requested that ONC the actor may not meet the conditions We explained that our goal was to consider differentiating the timeline of this exception. As part of an balance the need for IP protections with expected for making an offer predicated information blocking investigation, ONC the need to ensure that this proposed on an interoperability element being and OIG may consider documentation exception does not permit actors to available as an existing capability, as or other writings maintained by the abuse their IP or other proprietary rights opposed to an interoperability element actor around the time of the request that in inappropriate ways that would block requiring new formal licensure or indicate why the actor was unable to the development, adoption, or use of requiring one off ‘‘custom’’ or ‘‘spec’’ meet the conditions. This would not interoperable technologies and services. development. Another commenter permit the actor to be covered by this The abuse of IP rights in such ways is recommended that the process be exception, but discretion in determining incompatible with the information divided into a series of steps with a whether to enforce the information blocking provision, which protects the requirement that a request for blocking provision may be exercised. investments that taxpayers and the information be acknowledged and We note that we have revised health care industry have made to adopt negotiations begin within 10 business paragraph § 171.303(a) by changing ‘‘a technologies that will enable the days and completed within 20 business request to license or use’’ to ‘‘a request efficient sharing of EHI to benefit days. One commenter recommended to license’’ for clarity. We emphasize, consumers and the health care system. that the 10-day timeframe be for however, that this change does not alter We emphasized that while actors are beginning negotiations with the intent the meaning or application of the entitled to protect and exercise their IP to furnish a quotation for a license. provision. We reiterate, as we proposed, rights, to benefit from the exception to Some commenters stated that that the request could be made to the information blocking provision they timeframes should not be set, as the ‘‘license’’ or ‘‘use’’ the interoperability must do so on terms that do not license negotiation process is highly elements because a requestor may not undermine these efforts and prevent the variable based on the specific requestor always know that ‘‘license’’ is the legal appropriate flow of EHI. We proposed and circumstances. One commenter mechanism for ‘‘use’’ when making the that these requirements would apply to expressed concern that the proposed request (see 84 FR 7546). We believe it both price terms (such as royalties and exception would increase the is unnecessary to include ‘‘or use’’ in license fees) and other terms, such as administrative burden on covered the regulation text because actors conditions or limitations on access to entities, particularly regarding the should know that a request to ‘‘use’’ interoperability elements or the response timeframe and the actor’s would be synonymous with a request to purposes for which they can be used inability to review and/or vet the ‘‘license’’ and would thus be covered by (see 84 FR 7546). appropriateness of a request before this exception. Further, the inclusion of Comments. Several health IT responding. ‘‘or use’’ could be confusing since ‘‘use’’ developers strongly disagreed with the Response. We thank commenters for is a defined term in the context of framework and conditions of this these thoughtful comments. To be ‘‘access, exchange, or use’’ of EHI, but exception. These commenters stated responsive to comments, we have would carry different meaning in the that compulsory licensing of health IT updated the response and license context of ‘‘using’’ an interoperability on RAND terms is inconsistent with the negotiation framework and timeframe. element, as opposed to ‘‘using’’ EHI. usual use of RAND with regards to

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00251 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25892 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

standards development. The the licensing of proprietary IP. Further, interoperability elements is often a commenters opined that the proposed if the actor chooses to respond in the proxy for control of access, exchange exception is a significant overstep that manner requested, and such manner and use of EHI. For example, where EHI exceeds Congressional intent in the requires the licensing of an is stored in a proprietary format, the EHI Cures Act and would have a detrimental interoperability element(s), the actor cannot be accessed or used if effect on innovation in the industry. could license the interoperability information about the proprietary Commenters stated that IP rights would elements(s) with whatever terms the format does not accompany the EHI. not be adequately protected under the actor chooses, so long as the actor is Similarly, when EHI is stored exception, as the exception would allow able to reach agreeable terms with the electronically, a technological solution unprecedented access to IP, and requestor. We refer readers to the must exist to make the EHI available for requested that ONC better protect IP discussion in the Content and Manner use by others. We clarify that health IT rights in the final rule. One commenter Exception in VIII.D.2.a, which developers are not required to license recommended that ONC make clear that highlights how the Content and Manner all of their IP. As discussed earlier in there are other ways for actors to be in Exception supports an actor’s ability to this section, an actor would not need to compliance with the information protect their IP. seek coverage under this exception if blocking provision besides licensing We understand and appreciate that the actor’s practice is not likely to interoperability elements to all. health IT developers and other entities interfere with the access, exchange, or Response. We appreciate these have invested significant resources to use of actual EHI. Thus, an essential comments. Responsive to these innovate and our policies aim to element of the information blocking comments, we have removed all support these innovations and provision is that there is actual EHI at references to ‘‘RAND.’’ However, we advancements regarding the access, stake. Further, as discussed above, there have finalized the majority of the exchange, and use of EHI. We stress that would also need to be a nexus between substantive conditions for the licensing this exception was drafted with a requestor’s need to license an of interoperability elements under this innovation in mind and operates to interoperability element and the exception (§ 171.303(b)) as proposed benefit health IT developers and other existing EHI. If there is not such a (i.e., the sections on scope of rights, actors by allowing them to obtain nexus, the actor would not need to seek reasonable royalty, non-discriminatory remuneration for their IP. The Cures Act coverage under this exception (see the terms, collateral terms, and non- did not create a specific carve out to the Privacy Exception discussion in disclosure agreement), with slight information blocking provision for IP VIII.D.1.b). modifications discussed below. rights, but did provide HHS with the We clarify that, if an actor licenses an In response to comments regarding authority to establish reasonable and interoperability element to one compulsory licensing, we emphasize necessary exceptions that do not requestor, the actor must license that that we do not view this exception as constitute information blocking. We same interoperability element to future constituting compulsory licensing. Each interpret the definition of information similarly situated requestors with the exception is voluntary and actors may blocking in the Cures Act (section same terms. Once an actor has granted choose whether or not they want to seek 3022(a) of the PHSA) to encompass any a license for a particular interoperability coverage under an exception. The fee that materially discourages or element, an actor cannot choose to exceptions operate to the benefit of otherwise inhibits the access, exchange, license an interoperability element to actors and are intended to provide or use of EHI, so long as the actor has one requestor and then refuse or use actors with certainty that certain the requisite intent in the statute. Thus, different terms to license the same practices that would normally constitute without clarifying this exception, an interoperability element to a second information blocking will not be actor could implicate the information similarly situated requestor, even if the considered information blocking, blocking provision whenever it charged actor offers to provide the EHI via an provided the actor’s practice meets the any royalty to license its interoperability alternative manner in accordance with conditions of the exception. The fact elements. We believe this broad the Content and Manner Exception in that a practice to license interoperability interpretation of the information § 171.301. In other words, an actor elements does not meet the conditions blocking provision would have a cannot pick and choose who can license of an exception does not mean that the detrimental effect of innovation, a given interoperability element or who practice would necessarily constitute competition, and consumer welfare. As gets favorable license terms based on the information blocking. As a result, such, we established this exception to actor’s relationship with the requestor. practices that do not meet the exception provide assurances to actors that Comments. A couple of commenters will have to be reviewed on a case-by- licensing of interoperability elements noted that there is a wide-spectrum of case basis in order to assess the specific for access, exchange, or use will not be perspectives among stakeholders of facts and circumstances and to considered information blocking, so common license agreement terms such determine, for example, the actor’s long as the actor’s practice meets all as limitations on liability and intent and whether the practice rises to conditions in the exception. We indemnification, which may make the level of an interference. reiterate that the actor would also need reasonableness and non-discriminatory In addition, under the Content and to have the requisite intent, as set forth aspects challenging to interpret. Manner Exception (§ 171.301), we in the statute. We emphasize that actors Response. We appreciate these establish that an actor is not required to are able to make reasonable profits from concerns and understand that there is respond to a request to access, the licensing of interoperability the potential for significant variability exchange, or use EHI in the manner elements, so long as such profits comply in the terms included in license requested if the actor would be required with the ‘‘reasonable royalty’’ provision agreements, particularly for licensing to license IP and cannot reach agreeable in this exception in § 171.303(b)(2). We interoperability elements. We believe terms for the license with the requestor also note that the non-disclosure the conditions adopted in this final (§ 171.301(b)(1)(ii)). This provision agreement provision in § 171.303(b)(5) exception are clear, equitable, and allows actors who do not want to establishes additional IP protections. implementable. We emphasize that each license their IP to respond in an We emphasize that, in the context of information blocking case will turn on alternative manner that does not require information blocking, control of its own unique facts and circumstances.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00252 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25893

This fact-based approach is appropriate who currently uses the actor’s they are able to respond to the request for this exception particularly due to the interoperability elements to interoperate to access, exchange, or use EHI through potential variability in interoperability with the actor’s health IT or health IT an alternative manner specified in elements and licensing terms noted by under the actor’s control. § 171.301(b)(2)(ii)(A)–(C). the commenters. Response. We thank commenters for We have decided not to broaden the these thoughtful comments. We have Scope of Rights scope of rights regarding the streamlined the ‘‘scope of rights’’ development of products or services To qualify for the proposed exception, section of this exception for clarity and that are interoperable as suggested by we proposed that the actor must license to align with the overarching goal the commenter because we believe this the requested interoperability elements throughout the information blocking provision, as proposed, is appropriately with all rights necessary to access and section of enabling the access, exchange, tailored to addresses information use the interoperability elements for the and use of EHI. The finalized ‘‘scope of blocking and should be focused on following purposes, as applicable: rights’’ section in § 171.303(c)(1) states • health IT under the actor’s control or All rights necessary to access and that the license must provide all rights any third party who currently uses the use the interoperability elements for the necessary to: (1) Enable the access, actor’s interoperability elements to purpose of developing products or exchange, or use of EHI; and (2) achieve interoperate with health IT under the services that are interoperable with the the intended access, exchange, or use of actor’s control. actor’s health IT or with health IT under EHI via the interoperability element(s). the actor’s control and/or any third These rights replaced the rights we Reasonable Royalty party who currently uses the actor’s proposed in the ‘‘scope of rights’’ As a condition of this exception, we interoperability elements to interoperate section (see proposed § 171.206(b)(1)(i)– proposed that if an actor charges a with the actor’s health IT or health IT (iii) and 84 FR 7546 and 7547) because royalty for the use of interoperability under the actor’s control. These rights they more clearly and succinctly elements, the royalty base and rate must would include the right to incorporate explain the scope of rights we were be reasonable. Importantly, we proposed and use the interoperability elements in trying to convey in the Proposed Rule. that the reasonableness of any royalties the licensee’s own technology to the The proposed scope of rights included would be assessed solely on the basis of extent necessary to accomplish this examples that are not necessary in the the independent value of the actor’s purpose. regulatory text. technology to the licensee’s product, not • All rights necessary to market, offer, Regarding the comment that we on any strategic value stemming from and distribute the interoperable should specify that actors can require the actor’s control over essential means products and services described above that licensees of the proprietary IP of accessing, exchanging, or using EHI to potential customers and users, embodied in an interoperability element (84 FR 7547). including the right to copy or disclose use that IP only for the licensed In evaluating the actor’s assertions the interoperability elements as purpose, or ONC should allow actors to and evidence that the royalty was necessary to accomplish this purpose. decline to license that IP at all, we reasonable, we proposed that ONC may • All rights necessary to enable the clarify that actors may require that consider the following factors: use of the interoperable products or licensees of the proprietary IP embodied • The royalties received by the actor services in production environments, in an interoperability element only use for the licensing of the proprietary including using the interoperability that IP for the licensed purpose, so long elements in other circumstances elements to access and enable the as such limits are in compliance with all exchange and use of EHI (84 FR 7546 the conditions in § 171.303, including comparable to RAND-licensing and 7547). circumstances. the scope of rights provisions in • We requested comment on whether § 171.303(c)(1). For instance, an actor The rates paid by the licensee for these rights are sufficiently inclusive to could place a limitation in the license the use of other comparable proprietary support licensees in developing elements. that the license only covers a one-time • interoperable technologies, bringing use of the interoperability element for The nature and scope of the license. • them to market, and deploying them for accessing and exchanging certain EHI. The effect of the proprietary use in production environments. We In this scenario, this limitation could be elements in promoting sales of other also requested comment on the breadth allowed under the exception if: (1) products of the licensee and the of these required rights and if they Despite the limitation, the licensee’s licensor, taking into account only the should be subject to any limitations that request for access, exchange, or use of contribution of the elements themselves would not interfere with the uses we EHI is met; and (2) the limitation and not of the enhanced interoperability have described above (84 FR 7547). complies with the conditions in that they enable. Comments. We received a couple of § 171.303. Similarly, if an app developer • The utility and advantages of the comments regarding the scope of rights requests to license a health IT actor’s interoperability element over the under this exception. One commenter developer’s interoperability element in existing technology, if any, that had recommended that ONC specify that order to enable the exchange of EHI by been used to achieve a similar level of actors can require that licensees of the integrating the app developer’s CDS access, exchange, or use of EHI. proprietary IP embodied in an software into Provider A’s EHR, the • The contribution of the elements to interoperability element use that IP only health IT developer could scope the the technical capabilities of the for the licensed purpose, or ONC should rights in the license to restrict the app licensee’s products, taking into account allow actors to decline to license that IP developer from using the license to only the value of the elements at all. One commenter suggested that we complete the same integration for themselves and not the enhanced broaden the scope of rights regarding Provider B, so long as the license interoperability that they enable. the development of products or services complies with the conditions in • The portion of the profit or of the that are interoperable so that § 171.303. We also emphasize that selling price that may be customary in interoperability does not need to be tied under the Content and Manner the particular business or in comparable to the actor’s health IT, health IT under Exception (§ 171.301), actors are decline businesses to allow for the use of the the actor’s control, or any third party to license their proprietary IP so long as proprietary elements or analogous

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00253 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25894 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

elements that are also covered by RAND of the actor’s technology that are used terms on the licensee but may not commitments. only to establish interoperability and charge a royalty. The commenter also • The portion of the realizable profit enable EHI to be accessed, exchanged, expressed concern that the overlap that should be credited to the and used. Additionally, we proposed between this exception and the proprietary elements as distinguished that to address the potential risk of exception for recovering costs from non-proprietary elements, the royalty stacking, we would need to reasonably incurred creates the manufacturing process, business risks, consider the aggregate royalties that potential for actors to earn a double significant features or improvements would apply if owners of other essential recovery. The commenter explained that added by the licensee, or the strategic interoperability elements made royalty licensing of IP is intended to recoup the value resulting from the network effects, demands of the implementer. costs of development of that IP, so switching costs, or other effects of the Specifically, we proposed that, to where the IP is an interoperability adoption of the actor’s technology. qualify for the exception, the actor must element, the costs reasonably incurred • The opinion testimony of qualified grant licenses on terms that are for its development should be experts. objectively commercially reasonable incorporated into the royalty rate. The • The amount that a licensor and a taking into account the overall licensing commenter recommended that we be licensee would have agreed upon (at the situation, including the cost to the clearer that in these circumstances, only time the licensee began using the licensee of obtaining other a single recovery is permitted. Provider elements) if both were considering the interoperability elements that are and registry organizations were RAND obligation under the exception important for the viability of the concerned that the ability to charge and its purposes, and had been products for which it is seeking to reasonable royalties to license reasonably and voluntarily trying to license interoperability elements from interoperability elements may present reach an agreement (84 FR 7547). the actor (84 FR 7547 and 7548). an opening for health IT developers to We noted that these factors mirror We clarified that this condition would charge unreasonably high fees for those used by courts that have examined not preclude an actor from licensing its exchanging information with provider the reasonableness of royalties charged interoperability elements pursuant to an groups and registries. As such, the pursuant to a commitment to a existing RAND commitment to a commenters recommended that ONC standards developing organization to standards developing organization. We require actors to disclose the license standard-essential technologies also noted that, in addition to methodology behind their fees. on RAND terms (see Microsoft Corp. v. complying with the requirements Alternatively, other commenters, Motorola, Inc.; 187 In re Innovatio IP described above, to meet this proposed consisting primarily of health IT Ventures, LLC Patent Litig.; 188 and condition, any royalties charged must developers, expressed concern that the Realtek Semiconductor Corp. v. LSI meet the condition, proposed separately proposals regarding reasonable royalties Corp. 189 ). We noted, however, that we below, that any license terms be non- were too restrictive. Commenters were adapted the factors to the information discriminatory (84 FR 7548). concerned that the exception, as blocking context (84 FR 7547). We requested comment on these proposed, would have a detrimental We proposed that the RAND inquiry aspects of the proposed exception. We effect on innovation in the industry as should focus on whether the royalty encouraged commenters to consider, in it provides disincentives for established demanded by the actor represents the particular, whether the factors and companies to develop new, forward- independent value of the actor’s approach we described will be leaning solutions. A few commenters proprietary technology. We proposed administrable and appropriately balance recommended that the value of the that if the actor has licensed the the unreasonable blocking by actors of actor’s technology must be constructed interoperability element through a the use of essential interoperability on a ‘‘fair market’’ basis. Commenters standards developing organization in elements with the need to provide stated that ONC should not set or accordance with such organization’s adequate assurance to investors and determine the reasonableness of policies regarding the licensing of innovators that they will be able to earn royalties. However, if ONC decided to standards-essential technologies on a reasonable return on their investments set or define the reasonableness of RAND terms, the actor may charge a in interoperable technologies. Further, royalties, the primary factor for such a royalty that is consistent with such we noted that if our proposed approach determination should be the willingness policies. We proposed that we would did not adequately balance these of licensees to agree to a given royalty ask whether the actor is charging a concerns or would not achieve our rate. A couple of commenters requested royalty that is not based on the value of stated policy goals, we asked that clarification regarding ONC’s approach its technology (embodied in the commenters suggest revisions or for calculating reasonable royalties and interoperability elements) but rather alternative approaches. We asked that ONC’s basis for determining whether a includes the strategic value stemming such comments be as detailed as royalty is ‘‘reasonable.’’ from the adoption of that technology by possible and provide rigorous economic Response. We thank commenters for customers or users. We proposed that justifications for any suggested revisions these thoughtful comments. First, we we would consider the technical or alternative approaches (84 FR 7548). note, as discussed previously in this contribution of the actor’s Comments. We received many section, we have removed all references interoperability elements to the comments regarding reasonable to ‘‘RAND.’’ However, we have finalized licensee’s products—such as any royalties and the ability of actors to this reasonable royalty provision proprietary capabilities or features that make a profit. Some commenters (§ 171.303(c)(2)) as proposed, with a the licensee uses in its product—but supported the proposed framework. A slight modification for consistency and would screen out any functional aspects couple of commenters recommended the addition of a paragraph in that we not allow any royalty for § 171.303(c)(2)(iv). The slight 187 Case No. 10–cv–1823 JLR, 2013 WL 2111217 licensing interoperability elements. One modification was made to (W.D.Wash. Apr. 25, 2013). of those commenters suggested we § 171.303(c)(2)(iii), in which we deleted 188 MDL 2303, 2013 WL 5593609 (N.D.Ill. Oct. 3, 2013). require ‘‘RAND-Zero’’ licensing, by ‘‘on reasonable and non-discriminatory 189 Case No. 5:12–cv–03451–RMW, 2014 WL which the copyright holder may still terms’’ in order to align with the overall 46997 (N.D.Cal. Jan. 6, 2014). impose non-discriminatory licensing approach of removing ‘‘RAND’’

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00254 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25895

throughout the exception. In response to § 171.303(b)(2)) because the allowance the actor’s control over essential means comment, we added a paragraph in of such royalties will promote of accessing, exchanging, or using EHI § 171.303(c)(2)(iv) to address the competition, consumer welfare, and (84 FR 7547 and 7548). For additional potential for double recovery in this investment in innovation. The clarification regarding the specific exception and the Fees Exception conditions we have finalized in factors to be considered in evaluating an (§ 171.302). The new paragraph states § 171.303(b)(2) are specifically tailored actor’s assertion and evidence that a that an actor may not charge a royalty to address the type of abuse about royalty was reasonable, we refer reader for IP if the actor recovered any which commenters expressed concern. to the discussion above and the development costs pursuant to Under the finalized reasonable royalty discussion in the Proposed Rule § 171.302 that led to the creation of the provision, it would generally be regarding reasonable royalties (see 84 IP. appropriate for actors to license their IP FR 7547 and 7548). In response to the commenters who on terms that are non-discriminatory Non-Discriminatory Terms expressed concern that our approach for and do not interfere with the access, allowing reasonable royalties is too exchange, or use of EHI so long as the We proposed that for the exception to restrictive and could slow innovation, actor meets all of the conditions in apply, the terms on which an actor we emphasize that our regulatory § 171.303. We emphasize that actors are licenses and otherwise provides approach to implementing the able to make reasonable profits from the interoperability elements must be non- information blocking provision of the licensing of interoperability elements, discriminatory. We explained that this Cures Act is informed by years of so long as such profits comply with condition would apply to both price and research and stakeholder engagement § 171.303(b)(2). These licensing non-price terms, and thus would apply indicating that information blocking practices will further the goals of the to the royalty terms discussed undermines public and private sector information blocking provision by immediately above as well as other investments in the nation’s health IT allowing actors to protect the value of types of terms that may be included in infrastructure and frustrates efforts to their innovations and earn returns on licensing agreements or other use modern technologies to improve the investments they have made to agreements related to the provision or health care quality and efficiency, develop, maintain, and update those use of interoperability elements (84 FR accelerate research and innovation, and innovations. This approach will also 7548). provide greater value and choice to protect future incentives to invest in, We proposed that to comply with this health care consumers. In our develop, and disseminate interoperable condition, the terms on which the actor experience, contractual and IP rights are technologies and services that could licensed the interoperability elements frequently used to extract rents for improve the lives and safety of patients must be based on criteria that the actor access to EHI or to prevent competition nationwide. applied uniformly for all substantially from health IT developers of We acknowledge that limiting the similar or similarly situated classes of interoperable technologies and services. royalties IP holders can charge for persons and requests. In order to be These practices frustrate access, access, exchange, or use of EHI departs considered non-discriminatory, such exchange, and use of EHI and stifle from IP policy. Absent specific criteria would have to be objective and competition and innovation in the circumstances, IP holders are generally verifiable, not based on the actor’s health IT sector. free to negotiate with prospective subjective judgment or discretion. We We believe the general claim that the licensees to determine the royalty to emphasized that this proposal does not limits on licensing royalties within this practice their IP, and this negotiated mean that the actor must apply the same exception would inhibit innovation royalty frequently reflects the value the terms for all persons or classes of misstates the experiences many licensee would obtain from exercising persons requesting a license. However, stakeholders face today. Our experience those rights. However, in the context of any differences in terms would have to in the health IT industry has highlighted EHI, a limitation on royalties is essential be based on actual differences in the that innovation has struggled under due to the likelihood that unreasonable costs that the actor incurred or other current market practices, in which there royalties would frustrate access, reasonable and non-discriminatory is no limit on fees and royalties for exchange, and use of the EHI, criteria. Moreover, we proposed that any access and use of interoperability particularly because of the imbalanced criteria upon which an actor varies its elements. In fact, the ability of large power dynamics that currently exist in terms or conditions would have to be entities with significant market power to the health IT market. both competitively neutral—meaning prevent access and use of essential In response to commenters who that the criteria are not based in any part interoperability elements has prevented requested clarification regarding ONC’s on whether the requestor or other and continues to prevent large amounts approach for calculating reasonable person is a competitor, potential of potential investment in innovative royalties, we emphasize that each case competitor, or will be using EHI solutions for the United States health of potential information blocking, as obtained via the interoperability care market. We also refer readers to the well as the ‘‘reasonableness’’ of a elements in a way that facilitates Content and Manner Exception royalty, will hinge on the specific facts competition with the actor—and neutral (§ 171.301), where we further address and circumstances of the case. We as to the revenue or other value that the commenter concerns regarding explained in the Proposed Rule that the requestor may derive from access, protections for their proprietary IP. actor would need to show that the exchange, or use of the EHI obtained via We also appreciate the comments that royalty base was reasonable and that the the interoperability elements, including suggested we not allow any royalty for royalty was within a reasonable range any secondary use of such EHI (84 FR licensing interoperability elements for the interoperability elements at 7548). For a detailed example regarding because allowing a royalty could create issue. Importantly, we explained that this proposed condition, see the an opening for actors to continue to the reasonableness of any royalties Proposed Rule (84 FR 7548). charge unreasonably high fees for the would be assessed solely on the basis of We noted that the foregoing exchange of EHI. We have decided to the independent value of the actor’s conditions were not intended to limit an allow reasonable royalties that must technology to the licensee’s product, not actor’s flexibility to set different terms meet certain requirements (see on any strategic value stemming from based on legitimate differences in the

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00255 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25896 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

costs to different classes of persons or in regulation text because such an example prohibitions for certain types of response to different classes of requests, is not necessary in the regulation text collateral terms or agreements that we so long as any such classification was in (see 84 FR 7604). We emphasize, believe are inherently likely to interfere fact based on neutral criteria (in the however, that we continue to maintain with access, exchange, or use of EHI. We sense described above) that are that the terms must not be based on proposed that any attempt to require a objectively verifiable and were applied revenue or other value derived from the licensee or its agents or contractors to in a consistent manner for persons and/ subsequent use of EHI. Our policy on do or agree to do any of the following or requests within each class. For this point has not changed from the would disqualify the actor from the instance, the proposed condition would Proposed Rule. The terms and exception and would be suspect under not preclude an actor from pursuing conditions could vary based on neutral, the information blocking provision (84 strategic partnerships, joint ventures, objectively verifiable, and uniformly FR 7549). co-marketing agreements, cross- applied criteria. These might include, First, we proposed that the actor must licensing agreements, and other similar for example, significantly greater not require the licensee or its agents or types of commercial arrangements resources consumed by certain types of contractors to not compete with the under which it provides more favorable apps, such as those that export large actor in any product, service, or market, terms than for other persons with whom volumes of data on a continuous basis, including markets for goods and it has a more arms-length relationship. or the heightened risks associated with services, technologies, and research and We explained that in these instances, apps designed to ‘‘write’’ data to the development. We explained that we are the actor should have no difficulty EHR database or to run natively within aware that such agreements have been identifying substantial and verifiable the EHR’s user interface. used to either directly exclude suppliers efficiencies that demonstrate that any We emphasize that health IT of interoperable technologies and variations in its terms and conditions developers that license interoperability services from the market or to create were based on objective and neutral elements in order for EHI to be accessed, exclusivity that reduces the range of criteria (84 FR 7548). exchanged, or used could not vary the technologies and options available to We proposed that a health IT license terms and conditions based on health care providers and other health developer of certified health IT who is subjective criteria, such as whether it IT customers and users (84 FR 7549). an ‘‘API Technology Supplier’’ under thinks an app will be ‘‘popular’’ or is a Second, we proposed that the actor the Condition of Certification proposed ‘‘good fit’’ for its ecosystem. Nor could must not require the licensee or its in § 170.404 would not be permitted to developers offer different terms or agents or contractors to deal exclusively offer different terms in connection with conditions on the basis of objective with the actor in any product, service, the APIs required by that Condition of criteria that are not competitively or market, including markets for goods Certification. We proposed that API neutral, such as whether an app and services, technologies, and research Technology Suppliers are required to ‘‘connects to’’ other technologies or and development (84 FR 7549). make these APIs available on terms that services, provides capabilities that the Third, we proposed that the actor are no less favorable than provided to EHR developer plans to incorporate in must not require the licensee or its their own customers, suppliers, a future release of its technology, or agents or contractors to obtain partners, and other persons with whom enables an efficient means for customers additional licenses, products, or they have a business relationship (84 FR to export data for use in other databases services that are not related to or can be 7548 and 7549). or technologies that compete directly unbundled from the requested We requested comments on the with the EHR developer. Similarly, the interoperability elements. We explained foregoing conditions (84 FR 7549). EHR developer could not set different that without this condition, we believe Comments. One commenter disagreed terms or conditions based on how much that an actor could require a licensee to with the proposal that the terms must revenue or other value the app might take a license to additional not be based in any part on revenue or generate from the information it collects interoperability elements that the other value the requestor may derive through the APIs, such as by licensee does not need or want, which from access, exchange, or use of EHI introducing a revenue-sharing could enable the actor to extract obtained via the interoperability requirement for apps that use data for royalties that are inconsistent with its elements, including the secondary use secondary purposes that are very RAND obligations under this exception. of such EHI. The commenter stated that lucrative and for which the EHR We clarified that this condition would such information should be considered. developer would like a ‘‘piece of the not preclude an actor and a willing Response. We thank the commenter pie.’’ Such practices would disqualify licensee from agreeing to such an for this feedback, but have decided to the actor from this exception and would arrangement, so long as the arrangement finalize this provision as proposed, with implicate the information blocking was not required (84 FR 7549). slight modification. We continue to provision. Fourth, we proposed that the actor believe that license terms for licensing We note that we made a slight must not condition the use of interoperability elements required for modification to § 171.303(c)(3)(i) in that interoperability elements on a the access, exchange, or use of EHI we removed ‘‘substantially similar.’’ We requirement or agreement to license, should not be based in any part of the believe ‘‘similarly situated,’’ without grant, assign, or transfer the licensee’s revenue or other value the requestor ‘‘substantially similar’’ is clearer, own IP to the actor. We explained that may derive from access, exchange, or maintains the intended effect, and is it would raise information blocking use of EHI obtained via the consistent with language used in other concerns for an actor to use its control interoperability elements, including the exceptions. over interoperability elements as subsequent use of such EHI. The leverage to obtain a ‘‘grant back’’ of IP allowance of such terms could enable Collateral Terms rights or other consideration whose the type of opportunistic pricing and We proposed five additional value may exceed that of a reasonable anti-competitive behavior that this conditions that would reinforce the royalty. We proposed that, consistent exception seeks to address. We note that requirements of the proposed exception. with our approach under other we have removed the proposed example We explained that these additional conditions of this exception, this about ‘‘secondary use’’ from the conditions would provide bright-line condition would not preclude an actor

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00256 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25897

and a willing licensee from agreeing to have also defined ‘‘controlled by the that interoperability elements may be a cross-licensing, co-marketing, or other actor’’ in § 171.102 in the context of the protected as trade secrets. Trade secrets agreement if they so choose. However, interoperability element definition for are a type of IP that consist of the actor could not require the licensee clarity. If the actor could not lawfully information and can include a formula, to enter into such an agreement. We confer a right or authorization, the actor pattern, compilation, program, device, proposed that the actor must offer the would not have the requisite ‘‘control’’ method, technique or process,190 and option of licensing the interoperability under the ‘‘interoperability element.’’ could fall within the definition of elements without a promise to provide Last, we emphasize that in situations ‘‘interoperability element’’ (see consideration beyond a reasonable when an actor does not have the ability § 171.102). We note, as discussed in to lawfully confer rights or licenses to royalty (84 FR 7549). more detail in VIII.C.5.b, that we have Finally, we proposed that the actor enable the access, exchange, or use of leveraged the definition of ‘‘health must not condition the use of EHI, the actor could seek coverage interoperability elements on a under the Infeasibility Exception (see information technology’’ from section requirement or agreement to pay a fee of § 171.204(a)(3)) or the Content and 3000(5) of the PHSA for the definition any kind whatsoever unless the fee Manner Exception (see § 171.301(b)). of ‘‘interoperability element’’ in meets either the narrowly crafted Comments. We did not receive any § 171.102, and that IP is included in that condition to this exception for a other comments regarding the proposed definition of ‘‘health information reasonable royalty, or, alternatively, the collateral terms proposals except those technology.’’ The PHSA defines ‘‘health fee satisfies the separate exception in noted in the comment summary above. information technology’’ as ‘‘hardware, § 171.302, which permits the recovery of Response. We have finalized the software, integrated technologies or certain costs reasonably incurred (84 FR collateral terms as proposed. related licenses, intellectual property, 7549). Non-Disclosure Agreement upgrades, or packaged solutions sold as We requested comment on these services that are designed for or support categorical exclusions. In particular, we We proposed that an actor would be the use by health care entities or permitted under this exception to encouraged commenters to weigh in on patients for the electronic creation, require a licensee to agree to a our assumption that these practices are maintenance, access, or exchange of confidentiality or non-disclosure inherently likely to interfere with health information.’’ access, exchange, or use of EHI. We also agreement (NDA) to protect the actor’s encouraged commenters to suggest any trade secrets, provided that the NDA is In response to the commenter that conceivable benefits that these practices no broader than necessary to prevent the expressed concern that this exception might offer for interoperability or for unauthorized disclosure of the actor’s acts to require NDAs in certain competition and consumers that we trade secrets. Further, we proposed that circumstances, we emphasize that we might have overlooked. Again, we asked the actor would have to identify (in the are not requiring NDAs. We included that to the extent possible commenters NDA) the specific information that it this provision in order to help actors provide detailed economic rationale in claims as trade secrets, and that such protect their IP and actors may draft the support of their comments (84 FR 7549). information would have to meet the NDA in a manner that best suits their Comments. One commenter noted definition of a trade secret under needs so long as the NDA meets the that situations exist where licensors do applicable law. We noted that if the requisite conditions in § 171.303(b)(5). not have the ability to lawfully confer actor is a health IT developer of certified We have decided not to allow actors to rights or licenses to information or health IT, it may be subject to the ‘‘generally’’ identify the information products without the agreement of a Condition of Certification that prohibits that they claim as trade secrets because third party. The commenter certain health IT developer prohibitions such a change could enable actors to recommended that we add ‘‘except as and restrictions on communications make broad assertions of trade secret required by law’’ to the collateral terms about a health IT developer’s technology provisions in order to clarify that the and business practices. We emphasized protection that exceed the actual trade expectation is not that an actor must that the exception would not in any way secrets. The safeguards we have obtain such rights on behalf of the abrogate the developer’s obligations to finalized in the NDA provision (e.g., requestor. comply with that condition. We that the agreement is no broader than Response. We appreciate this encouraged comment on this condition necessary to prevent unauthorized comment, but have decided not to make of the proposed exception (84 FR 7549). disclosure of the actor’s trade secrets the suggested edit because we do not Comments. We received a couple of and the agreement states with believe such an addition is necessary. comments regarding the proposed NDA particularity all information the actor The collateral terms provisions do not provision. One commenter claims as trade secrets) are necessary to address whether an actor is expected to recommended that we state in the final ensure that the NDA is not used to obtain rights from a third party to rule that interoperability elements impose restrictions or burdensome lawfully confer rights or licenses to themselves may not be protected as requirements that are not actually interoperability elements. Instead, the trade secrets. Another commenter necessary to protect the actor’s trade collateral terms provisions describe expressed concern that this exception secrets and that impede the use of the conditions that the actors must not acts to require NDAs in certain interoperability elements. We require of the licensee or its agents or circumstances. The commenter also emphasize that the use of an NDA for contractors to do because such suggested edits to preamble language such purposes would preclude an actor conditions are inherently likely to that would allow the actor to from qualifying for this exception and interfere with access, exchange, or use ‘‘generally’’ identify the information would implicate the information of EHI. We note that we have revised the that it claims as trade secrets, as blocking provision. definition of ‘‘interoperability element’’ opposed to the proposed language of (see § 171.102) to clarify that in order to identifying the ‘‘specific’’ information meet the definition, the element must be that it claims as trade secrets. 190 USPTO, Trade Secret Policy, https:// ‘‘controlled by the actor,’’ which Response. We thank commenters for www.uspto.gov/patents-getting-started/ addresses the commenter’s concern. We these thoughtful comments. We clarify international-protection/trade-secrets-policy.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00257 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25898 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

iii. Additional Requirements Relating to Comments. One commenter stated conduct. Future notice and comment the Provision of Interoperability that the proposed restriction regarding rulemaking by OIG will provide more Elements breaking compatibility or otherwise additional detail regarding information We proposed that an actor’s practice degrading the performance or blocking enforcement. would need to comply with additional interoperability of the licensee’s We may consider developing conditions that ensure that actors who products or services is too broad. The materials in the future regarding the license interoperability elements on commenter suggested that ONC add application of the exceptions should the RAND terms do not engage in separate procedural safeguards to avoid misuse need arise. However, we believe the practices that impede the use of those and unpredictable enforcement. final rule clearly describes the elements or otherwise undermine the Specifically, the commenter conditions actors must meet in order to be covered by each exception, and intent of this exception. We explained recommended that ONC: (1) Institute a informational materials are not that these conditions are analogous to grace period for licensors to provide necessary at this time. the conditions described in our proposal fixes where interoperability elements concerning collateral terms but address are inadvertently unavailable due to iv. Compliance With Conditions of a broader range of practices that may not software changes; (2) permit health IT Certification developers to maintain their existing be effected through the license As a final condition of the proposed agreements themselves or that occur processes to notify customers about upgraded standards on a reasonable exception, we proposed that health IT separately from the licensing timeframe; (3) allow, with a year’s developers of certified health IT who are negotiations and other dealings between notice, retirement of functionality in subject to the Conditions of Certification the actor and the licensee. Specifically, future versions of the software; (4) proposed in §§ 170.402, 170.403, and we proposed that an actor would not acknowledge that the use of 170.404 must comply with all qualify for this exception if it engaged interoperability elements will always requirements of those Conditions of in a practice that had the purpose or require some initial work and ongoing Certification for all practices and at all effect of impeding the efficient use of upkeep by the licensee, such as testing relevant times (84 FR 7550). the interoperability elements to access, and continuous work to deploy Comments. We did not receive any exchange, or use EHI for any technology at health systems with comments on this proposed condition. permissible purpose; or the efficient different workflows; and (5) the ONC- Response. We have removed this development, distribution, deployment, administered advisory opinion process proposed condition from the final rule or use of an interoperable product or should account for review of RAND for consistency with other exceptions service for which there is actual or licensing terms to provide clarity to the and for clarity, as the condition is not potential demand. We explained that regulated actors. necessary. the exception would not apply if the Response. We agree with the E. Additional Exceptions—Request for developer licensed its proprietary APIs commenter that it is critical that the Information for use by third-party apps but then final exceptions are transparent and prevented or delayed the use of those cannot be misused. Each exception 1. Exception for Complying With apps in production environments by, for should clearly explain what conduct Common Agreement for Trusted example, restricting or discouraging would be covered by the exception and Exchange customers from enabling the use of the what conduct falls outside the scope of In the Proposed Rule, we included a apps, or engaging in ‘‘gate keeping’’ the exception. In response to the request for information (RFI) regarding practices, such as requiring apps to go commenter, we note that we have not whether we should propose, in a future through a vetting process and then prevented health IT developers from rulemaking, a narrow exception to the applying that process in a maintaining their existing processes to information blocking provision for discriminatory or unreasonable manner. notify customers about upgraded practices that are necessary to comply Finally, to ensure the actor’s standards on a reasonable timeframe, with the requirements of the Common commitments under this exception are nor have we instituted any new policies Agreement (84 FR 7552). The most durable, we proposed one additional regarding the retirement of functionality recent draft Trusted Exchange safeguard: An actor could not avail itself in future versions of software. Further, Framework and Common Agreement of this exception if, having licensed the we acknowledge that the use of was released for public comment on interoperability elements, the actor interoperability elements may require April 19, 2019.191 makes changes to the elements or its some initial work and ongoing upkeep Comments. We received over 40 technology that ‘‘break’’ compatibility or by the licensee, such as testing and comment submissions on this RFI otherwise degrade the performance or continuous work to deploy technology expressing various viewpoints on the interoperability of the licensee’s in health systems with different purpose, need, and structure of a products or services (84 FR 7549 and workflows. However, we emphasize that TEFCA exception. 7550). such initial work, ongoing upkeep, or Response. We thank commenters for We emphasized that this proposed any additional burden on licensees must their feedback. As noted in the Proposed condition would in no way prevent an meet all the conditions of this exception Rule, we may use this feedback to actor from making improvements to its as all relevant times. inform a future rulemaking. technology or responding to the needs We have decided not to institute a 2. New Exceptions of its own customers or users. However, grace period for licensors to provide to benefit from the exception, the actor’s fixes where interoperability elements In the Proposed Rule, we included an practice would need to be necessary to are inadvertently unavailable due to RFI regarding any potential new accomplish these purposes and the actor software changes because we do not exceptions we should consider for must have afforded the licensee a believe such a grace period is necessary. future rulemaking (84 FR 7552). reasonable opportunity under the Having consulted with OIG, we note circumstances to update its technology that OIG generally does not pursue civil 191 ONC, Draft 2 Trusted Exchange Framework and Common Agreement, https://www.healthit.gov/ to maintain interoperability (84 FR monetary penalties for actors who make sites/default/files/page/2019-04/FINALTEFCAQTF 7550). innocent mistakes or for accidental 41719508version.pdf.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00258 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25899

Comments. We received a number of would allow health care providers who Exception). We also note that the actor requests for a new exception to cover conduct research at their institutions to would not be required to share EHI if sensitive and/or privileged information. require that other providers who request the interference with access, exchange, A health IT developer suggested a new EHI are also collaborators in that or use of the EHI is explicitly required exception to allow actors to withhold research. One commenter suggested an by State or Federal law (see the sensitive information. The commenter exception for health care providers who discussion regarding ‘‘required by law’’ expressed concern that EHI at a certain cannot send data to a public health at section VIII.C.1 of this preamble). data class or data element level will registry when the public health agency F. Complaint Process require health care providers to exert is not ready to onboard the provider due substantial manual effort to mediate factors outside of the provider’s control We explained in the Proposed Rule disclosure. Health care providers and (e.g., lack of resources or a backup in the that section 3022(d)(3)(A) of the PHSA provider organizations suggested an onboarding queue). directs the National Coordinator to exception that would exempt actors Response. We thank commenters for implement a standardized process for from the information blocking provision these suggestions. We note that actors the public to submit reports on claims if they are protecting privileged faced with a request to access, exchange, of information blocking (84 FR 7552). information. One commenter expressed or use EHI related to research can seek Section 3022(d)(3)(B) further requires concern about providing access, coverage under the exceptions for that the complaint process provide for exchange, or use of quality program and promoting the privacy of EHI (§ 171.202) the collection of such information as the reporting data. A hospital suggested that or infeasibility (§ 171.204), depending originating institution, location, type of requiring providers to waive privilege in on the specific research being transaction, system and version, order to avoid information blocking conducted and EHI at issue. We refer timestamp, terminating institution, would have a detrimental effect on peer readers to those exceptions, as well as locations, system and version, failure reviews and safety assessments that the preamble discussions at sections notice, and other related information. help providers resolve adverse events. VIII.D.2 (Privacy Exception) and VIII.D.4 In the Proposed Rule, we stated that Response. We thank commenters for (Infeasibility Exception). We also note we intend to implement and evolve the these suggestions. We first note that the that an actor would not be required to complaint process by building on health information must fall within the share EHI if the interference with existing mechanisms, including the EHI definition, which aligns with the access, exchange, or use of the EHI is process for providing feedback and ePHI definition contained in the HIPAA explicitly required by State or Federal expressing concerns about health IT that Rules. We note that actors faced with a law (see the discussion regarding is currently available at https:// request to access, exchange, We note ‘‘required by law’’ at section VIII.C.1 of www.healthit.gov/healthit-feedback (84 that actors faced with a request to this preamble). FR 7553). We requested comment on access, exchange, or use sensitive and/ Comments. Some commenters this approach and any alternative or privileged information can seek requested a new exception to protect approaches that would best effectuate coverage under the exceptions for actors who seek independent opinions this aspect of the Cures Act. In addition preventing harm (§ 171.201), promoting from external validators regarding their to any other comments that the public the privacy of EHI (§ 171.202), business practices, in case one of those may have wished to submit, we promoting the security of EHI practices falls within the definition of specifically requested comment on (§ 171.203), or infeasibility (§ 171.204), information blocking. several specific questions. The scope of depending on the specific information Response. We appreciate this these questions was specific to the at issue and the circumstances of the suggestion. With regard to private information blocking complaint case. We refer readers to those ‘‘external validators,’’ we note that we submission process and the information exceptions, as well as the preamble are not restricting an actor’s ability to collection necessary to enable effective discussions at sections VIII.D.1 hire private companies to assess its investigations and safeguard the (Preventing Harm Exception), VIII.D.2 business practices. confidentiality of information submitted (Privacy Exception), VIII.D.3 (Security Comments. A commenter through the complaint process. Exception), and VIII.D.4 (Infeasibility recommended an exception for standard Comments. We received over 25 Exception). We also note that an actor business practices. The commenter comment submissions that included would not be required to share EHI if explained that examples of such suggestions for the information blocking the interference with access, exchange, conduct include suspending the access complaint process. A few commenters or use of the EHI is explicitly required of any health IT developer or e- responded to one or more of the specific by State or Federal law (see the prescribing application that is not questions in the Proposed Rule, offering discussion regarding ‘‘required by law’’ compliant with State laws or uses the suggestions for specific data elements at section VIII.C.1 of this preamble). We provider’s technology platform for that complainants should be able to emphasize that this final rule does not reasons that compromises the integrity enter as part of a complaint. Some require actors to waive privilege of the provider’s network (e.g., using the commenters suggested specific features provided by law. network for commercial messaging). such as: A dedicated secure online Comments. Some commenters Response. We appreciate this portal for entry of information blocking expressed concern about the effect of suggestion. While we would need more complaints and any supporting the information blocking provision on facts to properly assess these scenarios, documents; a dedicated email box or research. Public health organizations we believe that such situations could toll-free phone number for submission proposed an exception to exclude likely be covered by either the exception of information blocking complaints; the research (as defined by 45 CFR 164.501) for promoting the privacy of EHI ability to batch multiple instances of and non-direct clinical care conducted (§ 171.202) or the exception for potential information blocking activity by public health authorities, from promoting the security of EHI by the same actor into one complaint implicating the information blocking (§ 171.203). We refer readers to those submission; and a user interface of pick- provision. A hospital requested that we exceptions, as well as the preamble lists to help submitters more easily establish a new sub-exception under the discussions at sections VIII.D.2 (Privacy categorize their concerns and/or mark exception for preventing harm that Exception) and VIII.D.3 (Security specific portions of or attachments to

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00259 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25900 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

their complaints according to their level for those who submit information authorities under applicable Federal of sensitivity or requested blocking complaints. law, as the Secretary sets forth through confidentiality. Numerous commenters Response. Section 3022(d)(2) of the notice and comment rulemaking. We expressed support for the existence of a PHSA exempts from public disclosure requested comment on potential publicly available, user-friendly ‘‘any information that is received by the disincentives and whether modifying complaint process and recommended National Coordinator in connection disincentives already available under that the development and publication of with a claim or suggestion of possible existing Department programs and the complaint process include robust information blocking and that could regulations would provide for more educational and informational reasonably be expected to facilitate effective deterrents (84 FR 7553). materials. A few commenters requested identification of the source of the We also sought information on the an opportunity for public comment on information’’ except as may be implementation of section 3022(d)(4) of the complaint process’s operational necessary to carry out the purpose of the PHSA, which provides that in details prior to it going live. PHSA section 3022. We believe the carrying out section 3022(d) of the Response. We note that the complaint publishing of complaints could lead to PHSA, the Secretary shall, to the extent process is not required by statute to be the identification of the source of the possible, not duplicate penalty established through rulemaking and we information or reasonably facilitate structures that would otherwise apply did not intend to give an impression identification of the source; therefore, with respect to information blocking that it would by including the request we do not intend to make complaints and the type of individual or entity for information about the complaint publicly available. In specific reference involved as of the day before December process in the Proposed Rule. Rather, as to health IT developers of certified 13, 2016—enactment of the Cures Act. was the intended outcome, we have health IT, however, we note that we Comments. We received over 40 received thoughtful suggestions that publish in the Certified Health IT submissions on this RFI. We have have informed our initial rollout of the Product List (CHPL) information about organized and summarized the information blocking complaint process non-conformities with Program comments by topic below. as well as have provided considerations requirements, which would include any Need for Disincentives for further evolution of the process. non-conformities with the Information We have identified several themes Blocking Condition of Certification Views on the need for additional and specific suggestions in the requirement. We also note that the disincentives generally diverged based comments that we will address below information blocking complaint process on stakeholder type. Health care for the purposes of transparency and to offers the option for users to submit providers were generally opposed to inform stakeholders. We have anonymously, explaining in multiple additional disincentives. Provider developed a dedicated complaint places types of submission information organizations were opposed to any new process that is based upon and informed to exclude for those who would like to disincentives. Nearly all these by our experience with our current maintain confidentiality. organizations stated that any additional health IT feedback process and the Comments. Several commenters disincentives would be duplicative of comments received on the Proposed requested that complainants be required disincentives for information blocking Rule. We also plan to publish to submit sufficient evidence of put in place through the QPP and informational materials to accompany intentional information blocking in the Promoting Interoperability Programs. In the rollout of this dedicated information complaint submission process. Another particular, hospitals noted concerns that blocking complaint process so that commenter suggested complainants be they are already subject to a 75 percent potential complainants across the required to meet particular negative adjustment to their market affected stakeholder categories can qualifications in order to submit a basket increase if they are unable to successfully use it to submit complaints formal complaint. make the Medicare Access and CHIP where they believe they have Response. We thank commenters for Reauthorization Act of 2015 (MACRA)- experienced or observed conduct that their input. However, we do not believe mandated attestation that they have not constitutes information blocking. While requiring a complaint submission to engaged in information blocking. we do not anticipate publishing include more than the minimum However, a few provider organizations potential operational details of the information necessary to understand the noted that any new disincentives would complaint process and submission complainant’s concern would best serve only be duplicative for providers that mechanism in advance of its rollout, we the purpose of the complaint process. are eligible for these specific CMS- would like to amplify a point we noted We believe that requiring that a administered programs, recognizing that in the Proposed Rule, which is that we complainant meet a proof, evidentiary, the existing disincentives under intend to implement and evolve the or qualification standard as a pre- Medicare would not reach providers complaint process. After we launch the requisite to them submitting a that do not participate in QPP or PI information blocking complaint process, complaint would inappropriately Programs. we anticipate using our own experience discourage or prevent many individuals Multiple provider organizations stated and users’ feedback about the and organizations who are subjected to that additional disincentives would be information blocking complaint process conduct that may meet the definition of duplicative of fines for HIPAA Rules to identify opportunities to further information blocking from sharing their violations and mentioned that the Office evolve and enhance all aspects of the concerns with us. for Civil Rights (OCR) has expressed an information blocking complaint process, intent to increase HIPAA Rules G. Disincentives for Health Care including but not limited to its enforcement on providers. associated informational materials. Providers—Request for Information A patient-facing app developer Comments. Several commenters Section 3022(b)(2)(B) of the PHSA commented that the HIPAA Rule’s requested that all information blocking provides that any health care provider disincentives, attestation, and public complaints be publicly posted and determined by OIG to have committed reporting are not enough to discourage available. Conversely, many information blocking shall be referred to information blocking. commenters were in strong support of the appropriate agency to be subject to Several health IT developers were ONC ensuring adequate confidentiality appropriate disincentives using neutral on the topic, stating that it was

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00260 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25901

unclear if additional disincentives disincentive mechanisms, with one provided by commenters and may use would duplicate disincentives in other developer specifically recommending this information to inform future programs. utilization of the Conditions of rulemaking. One payer, one patient advocacy Participation, Conditions for Coverage, XI. Incorporation by Reference organization, and one HIN were and Requirements for Participation. One supportive of additional provider app developer recommended that fines The Office of the Federal Register has disincentives. for information blocking be substantial established requirements for materials The HITAC recommended that ONC and per record blocked. The HITAC (e.g., standards and implementation work with CMS to build information stated that fines should be significant specifications) that agencies incorporate blocking disincentives into a broad enough to discourage problematic by reference in the Code of Federal range of CMS programs, and that ONC behavior, encourage compliance, and Regulations (79 FR 66267; 1 CFR 51.5). work with other Federal departments incent providers to address and Specifically, § 51.5(b) requires agencies and agencies that contract with remediate problematic behavior. A to discuss, in the preamble of a final providers (e.g., Veterans Health payer commented that fines should be rule, the ways that the materials they Administration, Department of Defense consistent with those levied against incorporate by reference are reasonably Military Health System, Indian Health developers, HINs, and HIEs. available to interested parties and how Service, Centers for Disease Control and interested parties can obtain the Prevention) to similarly build Enforcement materials, and to summarize, in the information blocking disincentives into Most health care providers and preamble of the final rule, the material contracting and other programs. The provider organizations recommended they incorporate by reference. HITAC also recommended that that providers be given the opportunity To make the materials we intend to providers be required to attest to to become compliant before being incorporate by reference reasonably compliance with requirements to avoid subject to any fines, except in instances available, we provide a uniform information blocking as part of of clear, egregious violations. Some resource locator (URL) for the standards Conditions of Participation, Conditions provider organizations recommended and implementation specifications. In for Coverage, contracts, and other that there be an appeals process for many cases, these standards and similar relationships, covering fee-for- disincentives or findings that health implementation specifications are service (FFS), value-based care, and care providers had violated the directly accessible through the URLs direct payment relationships. The information blocking provision, with provided. In instances where they are HITAC noted that such an attestation one organization noting that an appeals not directly available, we note the steps requirement could potentially allow for process is especially needed for small and requirements necessary to gain pursuit of serious penalties should OIG and rural practices. access to the standard or find the provider engaged in Response. We have shared all the implementation specification. In most of information blocking. comments received with the appropriate these instances, access to the standard or implementation specification can be Magnitude of Penalties agencies and offices within the Department for consideration in gained through no-cost (non-monetary) While health care providers were subsequent rulemaking to implement participation, subscription, or generally opposed to disincentives, section 3022(b)(2)(B) and (d) of the membership with the adopted standards some did offer recommendations for PHSA. developing organization (SDO) or keeping penalties to a minimum. About custodial organization. In certain half of the provider organizations IX. Registries Request for Information instances, where noted, access requires commenting stated that any fines for In the Proposed Rule, we included a a fee or paid membership. As an providers should not be at the same Request for Information (RFI) on how alternative, a copy of the standards may level as those levied against health IT health IT solutions and the proposals in be viewed for free at the U.S. developers, HINs, and HIEs. Other the Proposed Rule could aid Department of Health and Human provider organizations had more bidirectional exchange with registries Services, Office of the National specific recommendations, including a for a wide range of public health, Coordinator for Health Information tiered approach to penalties. One quality reporting, and clinical quality Technology, 330 C Street SW, provider organization recommended a improvement initiatives (84 FR 7553). Washington, DC 20201. Please call (202) two-tiered approach, with more We received 75 comments in response 690–7171 in advance to arrange significant financial penalties for large to this RFI. We thank commenters for inspection. hospitals and health systems and public their input and we may consider The National Technology Transfer reporting or QPP score reductions for including this information in a future and Advancement Act (NTTAA) of 1995 physicians. Another provider rulemaking. (15 U.S.C. 3701 et seq.) and the Office organization recommended a tiered of Management and Budget (OMB) approach that mimics the approach X. Patient Matching Request for Circular A–119 require the use of, used under HIPAA (as modified by Information wherever practical, technical standards HITECH), in which penalties increase Patient matching is a critical that are developed or adopted by based on the nature and extent of the component to interoperability and the voluntary consensus standards bodies to violation and resulting harm. Another nation’s health IT infrastructure. In the carry out policy objectives or activities, provider organization recommended Proposed Rule, we included a Request with certain exceptions. The NTTAA that organizations found to engage in for Information (RFI) on additional and OMB Circular A–119 provide information blocking be disqualified opportunities that may exist in the exceptions to selecting only standards from the PI category in QPP. patient matching space and ways that developed or adopted by voluntary Some health IT developers ONC can lead and contribute to consensus standards bodies, namely recommended significant penalties for coordination efforts with respect to when doing so would be inconsistent providers. Several health IT developers patient matching (84 FR 7554). We with applicable law or otherwise recommended that ONC work with CMS received 128 comments in response to impractical. As discussed in section IV to utilize and enhance existing this RFI. We appreciate the input of this preamble, we have followed the

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00261 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25902 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

NTTAA and OMB Circular A–119 in Hospitals (EH), Critical Access Hospitals partners who utilize C–CDA for adopting standards and implementation (CAH), and developers to submit QRDA information exchange. specifications for adoption, including I data for consumption by CMS systems • National Council for Prescription describing any exceptions in the including for Hospital Quality Reporting Drug Programs (NCPDP), SCRIPT adoption of standards and (HQR). Standard Implementation Guide, implementation specifications. Over the • CMS Implementation Guide for Version 2017071 (Approval Date for years of adopting standards and Quality Reporting Document ANSI: July 28, 2017) implementation specifications for Architecture Category III Eligible URL: http://www.ncpdp.org/ certification, we have worked with Clinicians and Eligible Professionals Standards/Standards-Info. SDOs, such as HL7, to make the Programs Implementation Guide for Access requires registration, a standards we adopt and incorporate by 2019, October 8, 2018 reference in the Federal Register membership fee, a user account, and a available to interested stakeholders. As URL: https://ecqi.healthit.gov/system/ license agreement to obtain a copy of _ _ _ _ _ described above, this includes making files/2019 CMS QRDA III Eligible the standard. _ _ _ the standards and implementation Clinicians and EP IG-508.pdf. Summary: NCPDP SCRIPT standards specifications available through no-cost This is a direct access link. are developed for transmitting memberships and no-cost subscriptions. Summary: The Health Level Seven prescription information electronically As required by 1 CFR 51.5(b), we International (HL7) Quality Reporting between prescribers, pharmacies, provide summaries of the standards we Document Architecture (QRDA) defines payers, and other entities for new have adopted and incorporate by constraints on the HL7 Clinical prescriptions, changes of prescriptions, reference in the Code of Federal Document Architecture Release 2 (CDA prescription refill requests, prescription Regulations (CFR). We also provide R2). QRDA is a standard document fill status notifications, cancellation relevant information about these format for the exchange of electronic notifications, relaying of medication standards and implementation clinical quality measure (eCQM) data. history, transactions for long-term care, specifications throughout the preamble. QRDA reports contain data extracted electronic prior authorization and other We have organized the standards and from EHRs and other information transactions. New transactions in this implementation specifications that we technology systems. The reports are update include Prescription drug have adopted through this rulemaking used for the exchange of eCQM data administration message, New according to the sections of the Code of between systems for quality prescription requests, New prescription Federal Regulation (CFR) in which they measurement and reporting programs. response denials, Prescription transfer will be codified and cross-referenced for This QRDA guide contains the CMS message, Prescription fill indicator associated certification criteria and supplemental implementation guide to change, Prescription recertification, Risk requirements that we have adopted. the HL7 Implementation Guide for CDA Evaluation and Mitigation Strategy Release 2: Quality Reporting Document (REMS) initiation request, REMS Content Exchange Standards and Architecture, Category III, STU Release initiation response, REMS request, and Implementation Specifications for 2.1 (June, 2017) for the 2019 REMS response. Exchanging Electronic Health performance period. This HL7 base Information—45 CFR 170.205 standard is referred to as the HL7 Standards for Health Information • QRDA–III STU R2.1. Technology To Protect Electronic Health CMS Implementation Guide for Information Created, Maintained, and • ® Quality Reporting Document Health Level 7 (HL7 ) CDA R2 Exchanged—45 CFR 170.210 Architecture Category I Hospital Quality Implementation Guide: C–CDA Reporting Implementation Guide for Templates for Clinical Notes R2.1 • ASTM E2147–18 Standard 2019, May 4, 2018 Companion Guide, Release 2–US Realm, Specification for Audit and Disclosure URL: https://ecqi.healthit.gov/system/ October 2019 Logs for Use in Health Information Systems, approved May 1, 2018 files/QRDA_HQR_2019_CMS_IG_final_ URL: http://www.hl7.org/implement/ 508.pdf. standards/product_brief.cfm?product_ URL: https://www.astm.org/ This is a direct access link. id=447. Standards/E2147.htm. Summary: This guide is a CMS Access requires a ‘‘user account’’ and This is a direct access link. However, Quality Reporting Document a license agreement. There is no a fee is required to obtain a copy of the Architecture Category I (QRDA I) monetary cost for a user account and standard. implementation guide to the HL7 license agreement. Summary: This specification Implementation Guide for CDA Release Summary: The Companion Guide to describes the security requirements 2: Quality Reporting Document Consolidated Clinical Document involved in the development and Architecture Category I, Release 1, STU Architecture (C–CDA) R2, provides implementation of audit and disclosure Release 5 (published December 2017), essential implementer guidance to logs used in health information systems. and referred to as the HL7 QRDA IG continuously expand interoperability It specifies how to design an access STU R5 in this guide. This guide for clinical information shared via audit log to record all access to patient describes additional conformance structured clinical notes. The guidance identifiable information maintained in statements and constraints for electronic supplements specifications established computer systems, and includes health record (EHR) data submissions in the Health Level Seven (HL7) CDA® principles for developing policies, that are required for reporting R2.1 IG: C–CDA Templates for Clinical procedures, and functions of health information to the Centers for Medicare Notes. This additional guidance is information logs to document all & Medicaid Services (CMS) for the intended to make implementers aware disclosure of confidential health care Hospital Inpatient Quality Reporting of emerging expectations and best information to external users for use in Program 2019 Reporting Period. The practices for C–CDA document manual and computer systems. This purpose of this guide is to serve as a exchange. The objective is to increase specification has two main purposes, companion to the base HL7 QRDA I consistency and expand interoperability namely: To define the nature, role, and STU R5 for entities such as Eligible across the community of data sharing function of system access audit logs and

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00262 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25903

their use in health information systems standardized applications. Release 4 • OpenID Connect Core 1.0 as a technical and procedural tool to provides new standard operation on Incorporating Errata Set 1, November 8, help provide security oversight; and to how to obtain data from multiple 2014 identify principles for establishing a patients via FHIR. API services that URL: http://openid.net/specs/openid- permanent record of disclosure of health focus on multiple patients would enable connect-core-1_0.html. information to external users and the health care providers to manage various data to be recorded in maintaining such internal patient populations as well as This is a direct access link. record of disclosure. external services a health care provider Summary: OpenID Connect 1.0 is a United States Core Data for may contract for to support quality simple identity layer on top of the Interoperability—45 CFR 170.213 improvement, population health OAuth 2.0 protocol. It enables clients to verify the identity of the end user based • management, and cost accountability United States Core Data for vis-a`-vis the provider’s partners (e.g., on the authentication performed by an Interoperability (USCDI), February 2020, health plans). authorization server, as well as to obtain Version 1 (v1) basic profile information about the end • URL: https://www.healthit.gov/ HL7 FHIR Bulk Data Access (Flat user in an interoperable and REST-like USCDI. FHIR) (v1.0.0: STU 1), August 22, 2019 manner. This specification defines the This is a direct access link. core OpenID Connect functionality: Summary: The United States Core URL: http://hl7.org/fhir/uv/bulkdata/. Authentication built on top of OAuth Data for Interoperability (USCDI) This is a direct access link. 2.0 and the use of claims to establishes a minimum set of data Summary: This implementation communicate information about the end classes that are required to be specification defines a standardized, user. It also describes the security and privacy considerations for using OpenID interoperable nationwide and is HL7 FHIR-based approach for exporting Connect. designed to be expanded in an iterative health information for multiple patients and predictable way over time. Data from a server compliant with the HL7 Incorporation by Reference—45 CFR classes listed in the USCDI are FHIR standard. This implementation 170.599 represented in a technically agnostic specification is intended to be used by manner. • ISO/IEC 17025:2017(E)—General apps to request information on multiple Requirements for the Competence of Application Programming Interface patients. The implementation Testing and Calibration Laboratories, Standards—45 CFR 170.215 specification includes (Third Edition), November 2017 • HL7 FHIR® US Core Implementation OperationDefinitions, which define how URL: https://www.iso.org/standard/ Guide STU 3.1.0, November 6, 2019 the multiple patient export operations are invoked by clients, and the SMART 66912.html. URL: http://hl7.org/fhir/us/core/ Backend Services: Authorization Guide, This is a direct access link. However, STU3.1/. which describes how a client can a fee is required to obtain a copy of the This is a direct access link. standard. Summary: The US Core register with and obtain an access token Implementation Guide STU 3.1.0 is from a server compliant with the Summary: This document has been based on FHIR Version R4 and defines implementation specification. developed with the objective of promoting confidence in the operation the minimum conformance • HL7 FHIR SMART Application requirements for accessing patient data. of laboratories. This document contains Launch Framework Implementation requirements for laboratories to enable The Argonaut pilot implementations, Guide Release 1.0.0, November 13, 2018 ONC 2015 Edition Common Clinical them to demonstrate they operate Data Set (CCDS), and the latest ONC URL: http://hl7.org/fhir/smart-app- competently and are able to generate valid results. Laboratories that conform United States Core Data for launch/. to this document will also operate Interoperability (USCDI) provided the This is a direct access link. requirements for this guide. The prior generally in accordance with the Argonaut search and vocabulary Summary: SMART on FHIR provides principles of ISO 9001. This document requirements, based on FHIR DSTU2, reliable, secure authorization for a requires the laboratory to plan and are updated in this guide to support variety of app architectures through the implement actions to address risks and FHIR Version R4. use of the OAuth 2.0 standard. This opportunities. Addressing both risks Authorization Guide supports the four and opportunities establishes a basis for • Health Level 7 (HL7) Version 4.0.1 use cases defined for Phase 1 of the increasing the effectiveness of the Fast Healthcare Interoperability Argonaut Project. This profile is management system, achieving Resources Specification (FHIR) Release intended to be used by developers of improved results, and preventing 4, October 30, 2019 apps that need to access FHIR resources negative effects. The laboratory is responsible for deciding which risks URL: http://hl7.org/fhir/R4/. by requesting access tokens from OAuth and opportunities need to be addressed. This is a direct access link. 2.0 compliant authorization servers. The Summary: The HL7 Version 4.0.1 Fast This third edition cancels and replaces profile defines a method through which Healthcare Interoperability Resources the second edition (ISO/IEC an app requests authorization to access (FHIR) Release 4, which also includes 17025:2005), which has been a FHIR resource, and then uses that technical corrections to R4, provides the technically revised. first set of normative FHIR resources. authorization to retrieve the resource. Other security mechanisms required by • ISO/IEC 17065:2012 (E)—Conformity This normative designation means that Assessment—Requirements for Bodies the future changes will be backward the HIPAA Security Rule, such as end- user authentication, session time-out, Certifying Products, Processes and compatible for the first time. These Services (First Edition), September 2012 resources define the content and security auditing, and accounting of structure of core health data which can disclosures, are outside the scope of this URL: https://www.iso.org/standard/ be used by developers to build profile. 46568.html.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00263 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25904 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

This is a direct access link. However, edition certification) in § 170.523(p), (q), estimate less than ten annual a fee is required to obtain a copy of the (t), and § 170.550(1). respondents for all of the regulatory standard. As stated in the Proposed Rule per ‘‘collection of information’’ Summary: This International § 170.550(l), ONC–ACBs would not be requirements for ONC–ACBs under part Standard specifies requirements, the able to certify health IT until they 170 of title 45, including those observance of which is intended to review and verify health IT developers’ previously approved by OMB and in ensure that certification bodies operate attestations confirming that the this final rule, and that the regulatory certification schemes in a competent, developers are compliant with ‘‘collection of information’’ consistent and impartial manner, Conditions and Maintenance of requirements under the Program thereby facilitating the recognition of Certification requirements. ONC–ACBs described in this section are not subject such bodies and the acceptance of would also submit the health IT to the PRA under 5 CFR 1320.3(c). For certified products, processes, and developer attestations to ONC per the cost estimates of these new services on a national and international § 170.523(q). regulatory requirements, we refer As stated in the Proposed Rule for basis and so furthering international readers to section XIII (Regulatory § 170.523(p)(3), ONC–ACBs would be trade. Impact Analysis) of this final rule. required to collect and report certain XII. Collection of Information information to ONC related to real B. Health IT Developers Requirements world testing plans and results. ONC– Under the Paperwork Reduction Act ACBs would be required to verify that We proposed two separate collections of 1995 (PRA), codified as amended at the health IT developer submits an from health IT developers in the 44 U.S.C. 3501 et seq., agencies are annual, publicly available real world Proposed Rule. First, we proposed in 45 required to provide a 60-day notice in testing plan and perform a completeness CFR 170.580(a)(2)(iii) that ONC may the Federal Register and solicit public check for both real world testing plans take action against a health IT developer comment on a proposed collection of and results. for failure to comply with Conditions information before it is submitted to the In the Proposed Rule, we stated for and Maintenance of Certification Office of Management and Budget for § 170.523(t), ONC–ACBs would ensure requirements. As stated in the Proposed review and approval. In order to fairly health IT developers opting to take Rule, we proposed to generally use the evaluate whether an information advantage of the Standard Version same processes previously codified in collection should be approved by the Advancement Process flexibility per regulation (§§ 170.580 and 170.581) to OMB, the PRA requires that we solicit § 170.405(b) provide timely advance take administrative enforcement action. comment on the following issues: written notice to the ONC–ACB and all These processes would require health IT 1. Whether the information collection affected customers. ONC–ACBs would developers to submit information to is necessary and useful to carry out the maintain a record of the date of issuance ONC to facilitate and conclude ONC’s proper functions of the agency; and the content of developers’ notices, review. The PRA, however, exempts 2. The accuracy of the agency’s and timely post content of each notice these information collections. We estimate of the information collection received publicly on the CHPL explained in the Proposed Rule that, burden; attributed to the certified Health IT specifically, 44 U.S.C. 3518(c)(1)(B)(ii) 3. The quality, utility, and clarity of Module(s) to which it applies. excludes collection activities during the the information to be collected; and In the 2015 Edition proposed rule (80 conduct of administrative actions or 4. Recommendations to minimize the FR 16894), we estimated fewer than ten investigations involving the agency information collection burden on the annual respondents for all of the against specific individuals or entities. affected public, including automated regulatory ‘‘collection of information’’ collection techniques. requirements that applied to the ONC– Secondly, we proposed in 45 CFR Under the PRA, the time, effort, and ACBs, including those previously 170.402(b)(1) that a health IT developer financial resources necessary to meet approved by OMB. In the 2015 Edition must, for a period of 10 years beginning the information collection requirements final rule (80 FR 62733), we concluded from the date each of a developer’s referenced in this section are to be that the regulatory ‘‘collection of health IT is first certified under the considered. We solicited comment on information’’ requirements for the ONC– Program, retain all records and these issues in the Proposed Rule (84 FR ACBs were not subject to the PRA under information necessary to demonstrate 7558 and 7559) for the matters 5 CFR 1320.3(c). initial and ongoing compliance with the discussed in detail below. Comments. We did not receive any requirements of the Program for each comments specific to the new ONC– health IT product. We stated in the A. ONC–ACBs ACB collection and reporting Proposed Rule that it would take In the Proposed Rule, we proposed to requirements for the certification of approximately two hours per week, on add new ONC—Authorized Certification health IT to the 2015 Edition (and any average, to comply with our proposed Bodies (ONC–ACB) collection and subsequent edition certification) in record retention requirement. We reporting requirements for the § 170.523(p), (q), (t), and § 170.550(1). welcomed comments on whether more certification of health IT to the updated Response. We continue to maintain or less time should be included in our 2015 Edition (and any subsequent our past determinations in that we estimate.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00264 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25905

TABLE 4—ESTIMATED ANNUALIZED TOTAL BURDEN HOURS FOR HEALTH IT DEVELOPERS TO COMPLY WITH RECORDS AND INFORMATION RETENTION REQUIREMENTS

Number of Code of Federal Regulations section health IT Average Total developers burden hours

45 CFR 170.402(b)(1) ...... 458 104 47,632

Total Burden Hours ...... 47,632

Comments. We did not receive any significant benefits for health care the Cures Act, in the least burdensome comments specific to either collection of providers and patients. We outline some way. We welcomed comments on our information from health IT developers of these benefits below. We emphasize assessment and any alternatives that we or our corresponding PRA in this regulatory impact analysis (RIA) should consider. determinations. that we believe this final rule will create Comments. We received comments Response. For the first information opportunities for health IT innovation suggesting alternatives to our proposals. collection, we continue to maintain that through new market entrants and Specifically, some commenters stated information collected pursuant to an remove barriers to interoperability and that we should consider an alternative administrative enforcement action is not electronic health information exchange. approach to the EHI export subject to the PRA under 44 U.S.C. These efforts would greatly benefit (§ 170.315(b)(10)) certification 3518(c)(1)(B)(ii), which excludes health care providers and patients by criterion’s scope to align with other collection activities during the conduct increasing access to important health regulations and data standards, such as of administrative actions or information and new technologies the USCDI. Other commenters requested investigations involving the agency resulting in improvements in health we reconsider the adoption of the against specific individuals or entities. care delivery and patient outcomes. consent management for APIs For the second information collection, The provisions in this final rule seek (§ 170.315(g)(11)) certification criterion we continue to believe it will take to advance an interoperable health or use a different platform because the approximately two hours per week on system that empowers individuals to consent2share (C2S) platform was not average to comply with our records and use their electronic health information mature enough. We also received information retention requirements as (EHI) to the fullest extent and enable comments requesting we consider reflected in Table 4. We refer readers to health care providers and communities alternative definitions for various section XIII (Regulatory Impact to deliver smarter, safer, and more information blocking terms and Analysis) of this final rule for the cost efficient care. Given this goal, there will reconsider our approach to certain estimates of the second information be instances where the benefits and information blocking exceptions. collection. costs are multifaceted and Commenters recommended that we XIII. Regulatory Impact Analysis unquantifiable. We note in this RIA consider these alternatives in order to when we had difficulty quantifying provide clarity to and reduce potential A. Statement of Need benefits and costs due to lack of burden for the regulated community. This final rule is necessary to meet applicable research or data. Response. Based on comments our statutory responsibilities under the Additionally, there are ongoing received, we considered and adopted 21st Century Cures Act (Cures Act) and regulatory and policy activities outside revisions to our proposals that will to advance HHS policy goals to promote of this final rule that might influence substantially reduce real and perceived interoperability and mitigate burden for the rule’s impact in an unquantifiable burden. For the certification criteria, we stakeholders. The provisions finalized manner. When possible, we revised and narrowed the scope of the in this rule that could result in acknowledge these complexities as well. EHI export certification criterion so that monetary costs for stakeholders include Unquantifiable costs and benefits it is more manageable and less the: (1) Updates to the 2015 Edition identified in this rule are summarized in administratively burdensome for health health IT certification criteria; (2) Table 31. IT developers. The criterion will link Conditions and Maintenance of the data exported to the focused Certification requirements for a health B. Alternatives Considered definition of EHI as finalized (see IT developer; (3) oversight for the In the Proposed Rule, we noted that section IV.B.6.c). We also reevaluated Conditions and Maintenance of we were unable to identify alternatives and determined, consistent with Certification requirements; and (4) to our proposals that would commenter input, that there is information blocking. appropriately implement our continued work to be done to ballot and While much of the costs of this final responsibilities under the Cures Act and field test the C2S platform and the rule will fall on health IT developers support interoperability. At the time, we Consent Implementation Guide and, that seek to certify health IT under the assessed whether there were alternatives therefore, did not adopt the consent ONC Health IT Certification Program to our proposals, specifically our management for APIs (§ 170.315(g)(11)) (Program), we believe the proposals concerning EHI export, certification criterion in this final rule implementation and use of health IT application programming interfaces (see section IV.B.9.b). certified to the 2015 Edition (including (APIs), and real world testing. We Within the information blocking the new and updated criteria in this concluded that our proposals took the section, we have focused the scope of final rule), compliance with the necessary steps to fulfill the mandates many terms to address commenter Conditions and Maintenance of specified in the Public Health Service concerns and reduce potential burden Certification requirements, and the Act (PHSA), as amended by the Health on actors. We have focused the limited exceptions to information Information Technology for Economic definition of EHI (§ 171.102) (see blocking would ultimately result in and Clinical Health (HITECH) Act and VIII.C.3). We have also focused the

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00265 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25906 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

Health Information Network (HIN) Regulation and Regulatory Review ability presents the costs and benefits of definition in consideration of comments (January 18, 2011), Executive Order this final rule. in four ways. First, we combined the 13771 on Reducing Regulation and a. Costs and Benefits definitions of HIN and Health Controlling Regulatory Costs (January Information Exchange (HIE) to create 30, 2017), the Regulatory Flexibility Act We have estimated the monetary costs one functional definition that applies to (5 U.S.C. 601 et seq.), section 202 of the and benefits of this final rule for health both statutory terms in order to clarify Unfunded Mandates Reform Act of 1995 IT developers, health care providers, the types of individuals and entities that (2 U.S.C. 1532), and Executive Order patients, ONC—Authorized Certification would be covered. Second, we limited 13132 on Federalism (August 4, 1999). Bodies (ONC–ACBs), ONC—Authorized the types of actions that would be 1. Executive Order 13771—Reducing Testing Laboratories (ONC–ATLs), and necessary for an actor to meet the Regulation and Controlling Regulatory the Federal Government (i.e., ONC), and definition of HIN or HIE. Third, we have Costs have broken those costs and benefits out revised the definition to specify that to into the following categories: (1) Executive Order 13771 on Reducing be a HIN or HIE there must be exchange Deregulatory actions (no associated Regulation and Controlling Regulatory among more than two unaffiliated costs); (2) updates to the 2015 Edition Costs was issued on January 30, 2017 individuals or entities besides the HIN/ health IT certification criteria; (3) HIE that are enabled to exchange with and directs agencies to repeal two existing regulations for each new Conditions and Maintenance of each other. Fourth, we focused the Certification requirements for a health definition on treatment, payment, and regulation issued in fiscal year (FY) 2017 and thereafter. It further directs IT developer; (4) oversight for the health care operations, as each are Conditions and Maintenance of defined in the HIPAA Rules (45 CFR agencies, via guidance issued by the Office of Management and Budget Certification requirements; and (5) 164.501) (see VIII.C.2.c). We have also information blocking. clarified the scope of the ‘‘access,’’ (OMB), that the total incremental costs ‘‘exchange,’’ and ‘‘use’’ definitions and of all regulations should be no greater In accordance with Executive Order refer readers to the discussion of those than zero in FY 2018. The analysis 12866, we have included the RIA changes in section VIII.C.5.a. required by Executive Order 13771, as summary table as Table 30. In addition, We have also considered and supplemented by Executive Order we have included a summary to meet finalized alternatives relating to the 13777, adds additional requirements for the regulatory reform analysis information blocking exceptions. Of analysis of regulatory actions. The new requirements under Executive Order note, we have finalized the new Content requirements under Executive Orders 13771. and Manner Exception (see § 171.301 13771 and 13777 do not change or Cost and benefit calculations were and the preamble discussion in section reduce existing requirements under performed in 2017 dollars, as this year VIII.D.2.a), which will significantly Executive Orders 12866 or 13563. This was the most recent data available to reduce burden on actors. First, the final rule is an E.O. 13771 regulatory address all cost and benefit estimates content condition (§ 171.301(a)) action. We estimate this rule generates consistently. For summary tables 29 establishes that, in order to satisfy the $0.84 billion in annualized costs in through 31, all estimates are rounded to exception, for up to May 2, 2022, an 2016 dollars, discounted at 7 percent the nearest dollar and expressed in 2016 actor must respond to a request to relative to year 2016 over a perpetual dollars to meet regulatory reform access, exchange, or use EHI with, at a time horizon. analysis requirements under Executive minimum, the EHI identified by the data 2. Executive Orders 12866 and 13563— Order 13771. elements represented in the USCDI Regulatory Planning and Review We note that estimates presented in standard adopted in § 170.213. Second, Analysis the manner condition (§ 171.301(b)) the following ‘‘Employee Assumptions explains acceptable alternative manners Executive Orders 12866 on Regulatory and Hourly Wage,’’ ‘‘Quantifying the for fulfilling a request to access, Planning and Review and 13563 on Estimated Number of Health IT exchange, or use EHI when an actor is Improving Regulation and Regulatory Developers and Products,’’ and technically unable to fulfill a request in Review direct agencies to assess all ‘‘Number of End Users that Might Be any manner requested or cannot reach costs and benefits of available regulatory Impacted by ONC’s Final Rule’’ sections agreeable terms with the requestor to alternatives and, if regulation is are used throughout this RIA. fulfill the request in any manner necessary, to select regulatory In this final rule, we used a number requested. This exception creates a approaches that maximize net benefits of methods to quantify direct and transparent and flexible framework for (including potential economic, indirect benefits of our provisions. For actors to fulfill requests for access, environmental, public health and safety provisions where no such research was exchange, or use of EHI. We refer effects, distributive impacts, and available, we developed estimates based readers to the discussion of the Content equity). A regulatory impact analysis on a reasonable proxy. Interoperability, and Manner Exception in section (RIA) must be prepared for major rules for example, can positively impact VIII.D.2.a, as well as the broader with economically significant effects patient safety, care coordination, and discussion within the information ($100 million or more in any one year). improve health care processes and blocking section where we discuss Pursuant to the Congressional Review health outcomes.192 However, achieving various other changes we have made in Act (5 U.S.C. 801 et seq.), the Office of interoperability is a function of several response to comments that will reduce Information and Regulatory Affairs factors, not just the capability of the burden (see section VIII.D). designated this rule as a ‘major rule’ as technology used by health care defined by 5 U.S.C. 804(2). OIRA has C. Overall Impact providers. Therefore, to assess some of also determined that this final rule is an the benefits of this final rule, we used We have examined the impact of this economically significant rule as we have regression analysis to assess their final rule as required by Executive estimated the costs to implement this Order 12866 on Regulatory Planning final rule may be greater than $100 192 https://www.qualityforum.org/Publications/ and Review (September 30, 1993), million per year. Accordingly, we have 2017/09/Interoperability_2016-2017_Final_ Executive Order 13563 on Improving prepared an RIA that to the best of our Report.aspx.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00266 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25907

respective effects on interoperability We found a statistically significant We have used Bureau of Labor holding other factors constant. marginal effect of using 2014 Edition Statistics (BLS) data to calculate private One example of this approach is the certified health IT associated with a five sector employee wage estimates (e.g., methodology used to quantify the percentage point increase in health IT developers, health care 195 benefits of our real world testing and interoperability. providers, health information networks API provisions on interoperability. We While we acknowledge that there (HINs), attorneys, etc.), as we believe used regression analysis to calculate the might be shared benefits across BLS provides the most accurate and impact of our real world testing and API provisions, we have taken steps to comprehensive wage data for private provisions on interoperability. We ensure that the benefits attributed to sector positions. Just as with the General assumed that the real world testing and each provision is unique to the Schedule Federal Salary Classification API provisions would collectively have provision referenced. For example, in calculations, we have assumed that the same impact on interoperability as the case of assessing the impact of our overhead costs (including benefits) are upgrading health IT certified to the 2014 real world testing and API provisions on equal to 100 percent of pre-tax wages. Edition. Therefore, we estimated linear interoperability, we assumed that the We estimated using 2016 dollars in probability models that identified the marginal effect is true and distributed the Proposed Rule. However, we stated impact of 2014 Edition certified health the five percentage point benefit across in the Proposed Rule that we would IT on hospitals’ interoperability.193 We our provisions at (0.1–1) to (1–4) consider using 2017 and even 2018 used data from the 2014 and 2015 percentage points respectively. Given dollars, if available, for our cost and American Hospital Association (AHA) data limitations, we believe this benefit estimates in the final rule. Annual Survey Information Technology approach allowed us to estimate the Therefore, in this final rule, we updated Supplement (IT Supplement), which benefits of our final provisions without our estimates using 2017 dollars for the consists of an analytic sample of 4,866 double counting the impact each GS Federal Salary Classification and the observations of non-Federal acute care provision might have on BLS data. interoperability. hospitals that responded to the IT Quantifying the Estimated Number of Supplement.194 We controlled for Employee Assumptions and Hourly Health IT Developers and Products additional factors such as participation Wage in a health information exchange We derived our estimates for the We have made employee assumptions organization, hospital characteristics, potential impact of the new 2015 about the level of expertise needed to and urban/rural status. More criteria on the number of certified complete the requirements in this specifically, we used the following products in the health IT market. This section of the final rule. For wage explanatory variables: analysis is based on the number of calculations for Federal employees and certified health IT products (i.e., Health Edition = 1 if a hospital adopted 2014 Edition ONC–ACBs, we have correlated the IT Modules), product capability, and the EHR, 0 otherwise employee’s expertise with the number of health IT developers that left, RHIO = 1 if a hospital participates in health corresponding grade and step of an merged, and/or entered the ONC Health information exchange organization, 0 employee classified under the General otherwise IT Certification Program between the Government = 1 if a hospital is publicly Schedule (GS) Federal Salary 2011 Edition health IT certification owned, 0 otherwise Classification, relying on the associated criteria (2011 Edition) and the Alt_teaching = 1 if a hospital is teaching, 0 employee hourly rates for the implementation of the 2014 Edition otherwise Washington, DC locality pay area as health IT certification criteria (2014 Nonprofit = 1 if a hospital is not for profit, published by the Office of Personnel Edition).198 0 otherwise Management for 2017.196 We have In Table 5, we quantify the extent to Largebed = 1 if a hospital has more than 399 assumed that overhead costs (including which the certified health IT market beds, 0 otherwise benefits) are equal to 100 percent of pre- consolidated between the 2011 Edition Medbed = 1 if a hospital’s number of beds tax wages. Therefore, we have doubled is between 100 and 399, 0 otherwise and 2014 Edition. We found that the Urban_rural = 1 if a hospital is urban, 0 the employee’s hourly wage to account number of health IT developers otherwise for overhead costs. We have concluded certifying products between the 2011 CAH = 1 if a hospital is critical access, 0 that a 100 percent expenditure on Edition and 2014 Edition decreased by otherwise overhead costs which includes benefits 22.1 percent and the number of Year = year of the data (2014 and 2015) is an appropriate estimate based on products available decreased by 23.2 S = state fixed effects research conducted by HHS.197 percent.

193 The interoperability dependent variable is a 195 Results were similar when we used logit or Planning and Evaluation (ASPE), Guidelines for binary indicator for whether a hospital routinely Probit specifications. Note, the percentage point Regulatory Impact Analysis, at 28–30 (2016), sends, receives, and integrates summary of care refers to the arithmetic difference between two available at https://aspe.hhs.gov/system/files/pdf/ records electronically outside of its system and percentages. 242926/HHS_RIAGuidance.pdf. finds any health information electronically outside 196 https://www.opm.gov/policy-data-oversight/ 198 Availability of 2014 CEHRT for Meaningful of its system. pay-leave/salaries-wages/salary-tables/pdf/2017/ Users Providers, Health IT Policy Committee Data 194 American Hospital Association Health IT DCB_h.pdf. Supplement Survey, http://www.ahadata.com/aha- 197 See U.S. Department of Health and Human Update (Sept. 9, 2015), available at http:// _ healthcare-database/. Services, Office of the Assistant Secretary for www.healthit.gov/FACAS/sites/faca/files/HITPC Data_Update_Presentation_Final_2015-09-09.pdf.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00267 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25908 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

TABLE 5—CERTIFIED HEALTH IT MARKET CONSOLIDATION FROM THE 2011 EDITION TO THE 2014 EDITION

Market 2011 Edition 2014 Edition consolidation (%)

Health IT Developers ...... 1,017 792 ¥22.1 Products Available ...... 1,408 1,081 ¥23.2 A For the purposes of these market consolidation calculations, we included the total number of active or suspended health IT products and their developers. Withdrawn products and their developers were excluded from this total.

Using the rates identified in Table 5, • Products capable of recording EHI products (–23.2 percent) and health IT we then applied our estimate for market data available in 2015 equal the number developers (–22.1 percent) from the consolidation to estimate the number of products available in 2014. In 2014, 2011 Edition to the 2014 Edition holds 2015 Edition certified health IT there were 710 products by 588 constant for the 2015 Edition. Although products and health IT developers that developers capable of recording EHI. we are using this number to estimate would be impacted by our policies in Since the new criteria involve the access product availability, we are unable to this final rule. Specifically, to estimate to and movement and exchange of EHI, assess how market consolidation might the number of 2015 Edition products we used only products that record EHI impact other production costs such as and health IT developers in the market, as a basis for our estimates. We believe the supply and demand for personnel we assumed: the 2014 totals reflect a realistic over time. • Products capable of recording EHI estimate of the currently available will include new certification criteria. products and their developers that As shown in Table 6, based on the We assume that products capable of could include the new 2015 certification assumptions, we have estimated the recording patient health data will be the criteria. total number of 2015 products (545) and types of products most likely to be • Market consolidation rates denoted their developers (458). impacted by and include the new in Table 5 hold constant. We assume certification criteria. that the rate of market consolidation for

TABLE 6—TOTAL NUMBER OF HEALTH IT DEVELOPERS AND PRODUCTS BY SCENARIO

Estimated number of Estimated Scenario health IT number of developers products

2015 Edition Projection—All Products ...... 617 830 2015 Edition Projection—Products Capable of Recording EHI ...... 458 545

Number of End Users That Might Be reported adopting an EHR.199 Nearly 95,470 clinical practices 202 and 4,519 Impacted by ONC’s Final Rule half of these facilities reported engaging hospitals 203 that participated in the aspects of health information exchange. CMS EHR Incentive Program. We For the purpose of this analysis, the However, we are unable to quantify, estimate that these entities will be population of end users differs specifically the use of certified health IT impacted by our rule. according to the regulatory action products, among these provider types. General Comments on the RIA finalized. In many cases, the end-user Despite these limitations, participants population impacted is the number of in the CMS EHR Incentive Programs Comments. Several commenters hospitals and health care providers that represent an adequate sample on which expressed concern that the estimated possess certified health IT. Due to data to base our estimates.200 There were costs and developer hours in the limitations, our analysis regarding the 439,187 health care providers 201 in proposed rule were significantly number of hospitals and health care underestimated. One commenter stated providers impacted by the regulatory 199 Henry, J., Pylypchuck, Y., & Patel, V. that the cost estimates did not (November 2018) Electronic Health Record accurately reflect provider action is based on the number of Adoption and Interoperability among U.S. Skilled implementations costs, including those hospitals and health care providers that Nursing Facilities in 2017. ONC Data Brief, no. 41. Office of the National Coordinator for Health related to ensuring compliance with the have historically participated in the HIPAA Rules, 42 CFR part 2 and other Centers for Medicare & Medicaid Information Technology: Washington, DC. 200 See Office of the National Coordinator for Federal and State privacy laws. Some Services (CMS) EHR Incentive Programs Health Information Technology, Office-based commenters were concerned about the (now Promoting Interoperability (PI) Health Care Professionals Participating in the CMS impact of the requirements, as proposed Programs). EHR Incentive Programs (Aug. 2017), dashboard.healthit.gov/quickstats/pages/FIG- in the Proposed Rule, on existing small One limitation of this approach is that Health-Care-Professionals-EHR-Incentive- health IT developers and their ability to we are unable to account for the impact Programs.php; Office of the National Coordinator of our provisions on users of health IT for Health Information Technology, Hospitals 202 This number was estimated based on the de- Participating in the CMS EHR Incentive Programs duplicated number of practices that had at least one that were ineligible or did not (Aug. 2017), dashboard.healthit.gov/quickstats/ clinician participate in the CMS Medicare participate in the CMS EHR Incentive pages/FIG-Hospitals-EHR-Incentive-Programs.php. Electronic Health Record Incentive Program. Programs. For example, in 2017, 78 201 This estimate is the total number of eligible 203 This estimate is the total number of eligible percent of home health agencies and 66 providers that ever participated in the CMS hospitals that ever participated in the CMS Medicare and Medicaid Electronic Health Record Medicare Electronic Health Record Incentive percent of skilled nursing facilities Incentive Program. Program.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00268 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25909

compete with large developers, as well will create opportunities for new market Therefore, we estimated the low end to as the impact on potential new market entrants and will remove barriers to be half of the $13.7 million (0.5*$13.7 entrants. One commenter stated that this interoperability and electronic health million = $6.8 million). This estimate is environment will result in only a small information exchange, which will based on feedback we received from our number of health IT developers greatly benefit health care providers and ONC–ATLs and ONC–ACBs. ONC– surviving while also limiting market patients as well. ACBs performed randomized entry. One commenter expressed surveillance an average of 22 times the (1) Deregulatory Actions concern that the Proposed Rule will first year the requirement was in effect. provide unfettered access to the Costs The following year surveillance was intellectual property of health IT We do not expect incurred costs to be performed an average of two times. We developers while increasing their associated with the deregulatory actions cannot predict how many randomized compliance costs, which will limit their in this final rule, but rather cost savings surveillance events the ONC–ACBs will potential investment returns and create as detailed further in this Regulatory perform now that we are not enforcing barriers to market entry. A few Impact Analysis. the requirement. It will be completely at commenters expressed concern that the the discretion of the ONC–ACBs. costs incurred by health IT developers Benefits In the Proposed Rule, we noted that to improve interoperability and comply We expect the deregulatory actions of we considered other potential benefits with other aspects of the rule as the rulemaking to result in benefits for that we were unable to quantify. For proposed will be passed on to providers health IT developers, providers, ONC– instance, we considered that health care and patients. ACBs, ONC–ATLs, and ONC. provider burden may decrease from the Response. We thank commenters for elimination of the two percent their input regarding our estimated costs (i) Removal of the Randomized minimum threshold requirements and developer hours in the Proposed Surveillance Minimum Threshold because a provider would previously Rule. We considered and adopted Requirements aid the ONC–ACB in software revisions to our proposals based on In this final rule, we have revised demonstrations. comments that would substantially § 170.556(c) to specify that ONC–ACBs We welcomed comments on potential reduce any real or perceived burden. We may conduct in-the-field, randomized means, methods, and relevant reanalyzed our approach and made surveillance. We have removed comparative studies and data that we adjustments for this final rule. For § 170.556(c)(2), which specifies that could use to better quantify these instance, we have included additional ONC–ACBs must conduct randomized benefits. developer hours for the additional data surveillance for a minimum of two Comments. We did not receive any elements we finalized in this final rule. percent of certified health IT products comments specific to the calculation of We have also included additional costs per year. Additionally, we have benefits of the elimination of the two for the bulk data standard support and removed the requirement that ONC– percent minimum threshold API support. Lastly, with regards to the ACBs make a good faith effort to requirements. comment that the cost estimates did not complete randomized surveillance and Response. We have maintained our accurately reflect implementation costs the circumstances permitted for approach in calculating the benefits of to providers, when possible ONC has exclusion from the requirement found this provision in this final rule. We quantified provider costs associated in § 170.556(c)(5). believe the removal of the randomized with the deployment of new certified In the 2015 Edition final rule, we did surveillance minimum threshold health IT functionalities and the not independently estimate the costs for requirements will reduce the burden on optional acquisition of emerging API randomized surveillance. Rather, we health care providers by reducing their technologies. Costs that are not relied on prior regulatory cost estimates exposure to randomized in-the-field quantifiable are noted in Table 31. for all surveillance actions. One of our surveillance of their health IT products. However, costs related to ensuring four ONC–ACBs charges a $3,000 Health care providers previously compliance with the HIPAA Rules, 42 annual fee per product for surveillance expressed concern about the time CFR part 2 and other Federal and State due to the new randomized surveillance commitment to support ONC–ACB privacy laws, are beyond the scope of requirements and to help normalize randomized surveillance of health IT the certification criteria and are not their revenue stream during down products, particularly if no non- included in the final rule. cycles between certification editions. conformities with certified health IT We understand commenters’ concerns Using this fee as a cost basis and were found. Providers have generally about the impact of the provisions as assuming it would apply to all certified stated that reactive surveillance (e.g., proposed on small health IT developers health IT (as opposed to the market- complaint-based surveillance) is a more and the potential impact on new market adjusted universe of health IT that is logical and economical approach to entrants. However, we continue to used in other calculations in this RIA), surveillance of health IT products believe that while much of the costs of we estimated that the removal of the implemented in a health care setting. the final rule will fall on health IT randomized surveillance ‘‘two percent We also believe the removal of these developers seeking to certify health IT minimum threshold’’ requirements will requirements will provide health IT under the Program, the implementation result in cost savings between $6.8 and developers more time to focus on and use of health IT certified to the 2015 $13.7 million for all stakeholders. To interoperability, and will provide ONC– Edition (including the updated and new arrive at this estimate, we multiplied the ACBs more time to respond to reactive criteria in this final rule), compliance $3000 annual fee per product for surveillance, including health care with the Conditions and Maintenance of surveillance by the total number of provider complaints about certified Certification requirements, and the products certified to the 2014 Edition health IT. limited exceptions to information which was 4,559 products at the time blocking would ultimately result in ($3,000*4,559 = $13.7 million). We (ii) Removal of the 2014 Edition From significant benefits for health care anticipate the number of products the Code of Federal Regulations providers and patients. We also certified for 2014 to decrease to a little We estimate that health IT developers emphasize that we believe the final rule as half of the original count over time. would realize monetary savings from no

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00269 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25910 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

longer supporting the 2014 Edition health IT industry, increases risk to up-to-date and supported systems to certification criteria due to a reduction patient safety. care for patients. in activities related to maintaining From the implementer’s perspective, Comments. We did not receive certification and surveillance. We are the research indicated that retaining comments specific to our methods for aware that one of our ONC–ACBs legacy systems tends to inhibit quantifying the potential costs for charges an inherited certified status scalability and growth for businesses. maintaining and supporting products to (ICS) fee of $1,000. This fee has been The perpetuity of outdated legacy previous editions. applied over the last calendar year. Over systems increases connection and Response. We have maintained our that time period, the number of new, system integration costs and limits the approach for quantifying costs for health unique 2014 Edition products has been ability to realize increased efficiency IT developers maintaining and declining (24 products, and no new through IT implementation. Newer supporting products to the previous products in the last four months) products are developed to current 2014 Edition. We have also emphasized compared to the number of ICS specifications and updated standards, again that the research indicates that certifications (569). Just assuming the which decreases barriers and marginal retaining legacy software would not be cost of continued ICS certification, cost of ancillary product beneficial or profitable to the health IT health IT developers would be paying implementation and increases the market. approximately $569,000 each year to accessibility of data in ancillary (iii) Removal of the ONC-Approved keep their 2014 Edition products up to systems—including via mobile devices Accreditor From the ONC Health IT date. Based on recent analysis of the and the latest applications. Finally, Certification Program number of unique 2014 Edition office staff in a health care setting would We expect ONC to realize monetary products, our assumptions hold true. no longer need to be trained to We are not aware of comparable fees cost savings from removing the ONC- accommodate differing data access Approved Accreditor (ONC–AA) from charged by ONC–ATLs; however, based needs or workarounds required to on our experience with the Program, we 205 the Program. We expect ONC to realize integrate to the legacy product. costs savings from no longer: (1) expect health IT developers would The research also indicates that realize similar cost savings associated Developing and publishing a Federal retaining legacy software would not be Register Notice and listserv; (2) with ONC–ATL maintenance of the beneficial or profitable to the health IT testing component associated with ICS. monitoring the open application period market. Prolonging backwards and reviewing and making decisions Thus, we estimate an additional compatibility of newer products to $569,000 cost savings for health IT regarding applications; and (3) oversight legacy systems encourages market and enforcement of the ONC–AA. We developers due to the reduced testing 206 fragmentation. We intend to have calculated the estimated annual requirements. encourage the health IT market to keep We also attempted to identify a cost savings for removing the ONC–AA progressing with a baseline expectation potential reduction in maintenance and from the Program, taking into of functionalities that evolve over time. administrative costs as a result of consideration that the ONC–AA This requires limiting fragmentation by removing 2014 Edition certification renewed its status every three years. no longer supporting outdated or For our calculations, we used the criteria. We could not obtain data to 207 conduct a full quantitative analysis obsolete legacy software. estimated hours for collaborating with specific to the reduction of health IT We also estimate that additional and informing an ONC–AA in 2017 developer and health care provider costs savings could be realized by reducing (using 2017 wage estimates). We related to supporting and maintaining regulatory complexity and burden estimated that ONC spent the 2014 Edition. However, we invited caused by having two certification approximately 110 hours collaborating comments on methods to quantify editions. We observed that the task of with the ONC–AA in 2017, which potential costs for maintaining and managing two different editions within includes (all at the GS–13, Step 1 level): supporting products to previous different rules increases complexity and Annual assessments; providing editions. burden for ONC staff, contractors, ONC– appropriate guidance; implementing We did conduct a review of academic ACBs, CMS programs referencing the new requirements and initiatives; and literature and qualitative analysis certification criteria, and other consultations as necessary. The hourly regarding potential savings from no stakeholders, as compared to removing wage with benefits for a GS–13, Step 1 longer supporting the 2014 Edition. We the 2014 Edition certification criteria. employee located in Washington, DC is looked at data in IT industry systems as However, we were unable to estimate approximately $91. Therefore, we whole, which showed that upgrading these benefits because we have no estimated the annual cost savings to be outdated legacy systems saves resources means for quantifying the benefits $3,337. otherwise spent on maintaining gained from only using the 2015 We estimate that ONC would commit compatibilities to multiple systems and Edition. approximately eight hours of staff time also increases quality and efficiency.204 We also expect that health care to develop the Federal Register Notice, Furthermore, as technology evolves, providers would benefit from removing which would include approximately: newer software and products allow for the 2014 Edition certification criteria Four hours for drafting and review by an smoother updates compared to their because such action would likely analyst at the GS–13, Step 1 level; two predecessors. Newer products provide motivate health IT developers to certify hours for review and analysis by senior better security features that can address health IT products to the 2015 Edition, certification staff at the GS–14, Step 1 both new and existing issues. In thus enabling providers to use the most level; and two hours for review and addition, older software has an submittal for publication by Immediate increased risk of failure, which, in the 205 Id. Office staff at the GS–15, Step 1 level. 206 Il-Horn Hann, Byungwan Koh, and Marius F. The hourly wage with benefits for a GS– 204 James Crotty and Ivan Horrocks, Managing Niculescu, The Double-Edged Sword of Backward 13, Step 1 employee located in Compatibility: The Adoption of Multigenerational legacy system costs: A case study of a meta- Washington, DC is approximately $91. assessment model to identify solutions in a large Platforms in the Presence of Intergenerational financial services company, Applied Computing Services, Inform. Systems Res. (2016), at 112–30. The hourly wage with benefits for a GS– and Informatics (2017), at 1–9. 207 Id. 14, Step 1 employee located in

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00270 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25911

Washington, DC is approximately $107. January 1, 2022 to align with developers who developed products for The hourly wage with benefits for a GS– requirements of the CMS Medicaid PI certification to a certain criterion by the 15, Step 1 employee located in Program. estimated cost per criterion, $475. We Washington, DC is approximately $126. For determining calculations for the then took five percent of that number to Therefore, we estimate the annual cost majority of the 2015 Edition identify the high end for the cost savings to be $277. Additionally, we certification criteria we removed, we savings. We then took 10 percent to estimate a cost of $477 to publish each used the following assumptions. (For identify the low end. The five percent page in the Federal Register, which the removal of § 170.315(b)(4) Common was derived from looking at the number includes operational costs. The Federal Clinical Data Set summary—create and of unique developers who have at least Register Notice for ONC–AAs requires, (b)(5) Common Clinical Data Set one active 2014 Edition product and the on average, one page in the Federal summary—receive, we outlined the number of unique developers who have Register (every three years), so we slightly different approach used). at least one active 2015 Edition. The estimated an additional annual cost In the 2015 Edition final rule, we denominator is the number of unique savings of $159. estimated the costs for developing and developers who have at least one active We estimated that ONC will commit preparing health IT to meet the 2015 2014 Edition product, which is 793. The approximately two hours of staff time by Edition certification criteria. The numerator is the number of unique an analyst at the GS–13, Step 1 level to development and preparation costs we developers who have at least one active draft, review, and publish the listserv to estimated were derived through a health 2015 Edition product and one active announce the Federal Register Notice. IT developer per criterion cost. We 2014 edition product, which is 41. (41/ The hourly wage with benefits for a GS– estimated the development and 793 = 0.0517024 or 5 percent). 13, Step 1 employee located in preparation costs over a four-year Washington, DC is approximately $91. period, and we projected the costs (A) Common Clinical Data Set Summary Therefore, we estimate the annual cost would be unevenly distributed. In Record Criteria savings to be $61. figuring out the cost savings for the In this final rule, we removed the We estimated that ONC would deregulatory actions, we initially used Common Clinical Data Set summary— commit approximately 25 hours of staff the distribution from the 2015 Edition, create (§ 170.315(b)(4)) and Common time to manage the open application but then adjusted the percentages of Clinical Data Set summary—receive process, review applications and reach development and preparation costs due (§ 170.315 (b)(5)) criteria. application decisions, which would to current empirical and anecdotal Our expectation was for ONC to include approximately: 20 hours by an evidence. The distribution was realize cost savings associated with analyst at the GS–13, Step 1 level; three reevaluated to account for 2019 and we internal infrastructure support and hours by senior certification staff at the estimated the actual development and maintenance, which would include GS–14, Step 1 level; and two hours for preparation distribution for 2018 to be actions such as: (1) Developing and review and approval by Immediate 35 percent and for 2019 to be 15 maintaining information regarding these Office staff at the GS–15, Step 1 level. percent. We took the average criteria on the ONC website; (2) creating The hourly wage with benefits for a GS– development and preparation cost documents related to these criteria and 13, Step 1 employee located in estimates (low and high) per criterion making those documents 508 compliant; Washington, DC is approximately $91. from Table 14 of the 2015 Edition final (3) updating, revising, and supporting The hourly wage with benefits for a GS– rule (80 FR 62737). We then used our Certification Companion Guides, test 14, Step 1 employee located in new distribution to identify the cost per procedures, and test tools; and (4) Washington, DC is approximately $107. year for years 2018 and 2019. We took responding to inquiries concerning The hourly wage with benefits for a GS– the total estimated costs for 2018 and these criteria. Based on ONC data on the 15, Step 1 employee located in 2019 and divided that by 12 to number of inquiries received since early Washington, DC is approximately $126. determine the cost savings per month 2016, we estimated approximately 12 Therefore, we estimated the annual cost and took a range of 6 to 12 months. annual inquiries about § 170.315(b)(4) savings to be $798. Based on analysis of recent data, our and (5) respectively, (24 total inquiries Taking all of these potential costs assumptions continue to hold true. for two criteria). We estimate it will take savings into consideration, we estimated To determine the testing costs of the an analyst at the GS–13, Step 1 level an the overall annual costs savings for deregulatory actions, we took the average of two hours to conduct all tasks removing the ONC–AA from the number of health IT developers who associated with each inquiry. The Program to be $4,632. develop products for certification for the hourly wage with benefits for a GS–13, identified criteria from the 2015 Edition Step 1 employee located in Washington, (iv) Removal of Certain 2015 Edition final rule and then figured out the DC is approximately $91. Based on Certification Criteria average cost per criterion. Based on the analysis of recent data, our assumptions In section III.B.4 of this final rule, we costs that one of the ONC–ATLs charges continue to hold true. removed the following certification for testing, we estimated the average Therefore, we estimated the annual criteria from the 2015 Edition: cost for testing per criterion and cost savings to be $4,360. § 170.315(b)(4) ‘‘Common Clinical Data determined subsequent cost savings. In We do not expect cost savings Set summary—create;’’ (b)(5) ‘‘Common 2017, only about five to ten percent of associated with software maintenance Clinical Data Set summary—receive’’ products have been tested and certified because both criteria incorporate the and § 170.315(a)(11) ‘‘Smoking status.’’ compared to the number of certified Common Clinical Data Set and We did not finalize the proposal to 2014 Edition products. Therefore, up to essentially the same data input and remove of § 170.315(a)(10) ‘‘Drug 90 to 95 percent of products remain to validation requirements as the formulary and preferred drug list be tested and certified to the 2015 transitions of care criterion checks,’’ § 170.315(a)(13) ‘‘Patient- Edition. Based on analysis of recent (§ 170.315(b)(1)). The removal of these specific education resources’’ and data, our assumptions continue to hold two criteria would not affect the test § 170.315(e)(2) ‘‘Secure messaging’’ but true. data and software maintenance costs, as rather will only permit ONC–ACBs to We estimated the total cost savings by the same test data and software issue certificates for these criteria until multiplying the number of health IT validation elements remain in

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00271 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25912 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

§ 170.315(b)(1) and the Common Comments. We did not receive hour and the assumed hourly rate and Clinical Data Set used in other criteria. comments specific to the removal of the calculated the cost savings to be ONC–ACBs could realize minimal 2015 Edition ‘‘smoking status’’ criterion $50,353. savings, as they would need to conduct (§ 170.315(a)(11)). slightly less surveillance based on the Response. We maintain our approach (2) Updates to the 2015 Edition two products that are currently certified and estimates for removing the 2015 Certification Criteria to these criteria. We estimated the Edition ‘‘smoking status’’ criterion The following section details the costs overall annual costs savings for (§ 170.315(a)(11)) from the 2015 Edition. and benefits for updates to the 2015 removing the Common Clinical Data Set However, we did update estimates to Edition health IT certification criteria, summary record certification criteria 2017 dollars. which includes costs and benefits to from the 2015 Edition to be $4,368. update certain 2015 Edition criteria to Comments. We did not receive (v) Removal of Certain Certification due to the adoption of the United States comments specific to the removal of the Requirements Core Data for Interoperability (USCDI) Common Clinical Data Set summary— In this final rule, we removed as a standard, and costs for new or create (§ 170.315(b)(4)) and Common § 170.523(k)(1)(iii)(B), which requires revised 2015 Edition criteria for: EHI Clinical Data Set summary—receive ONC–ACBs to ensure that certified export, API, privacy and security (§ 170.315 (b)(5)) criteria. health IT includes a detailed description transparency attestations, and security Response. We maintained our of all known material information tags. approach and estimates for removing concerning limitations that a user may (i) United States Core Data for the Common Clinical Data Set summary encounter in the course of Interoperability record certification criteria from the implementing and using the certified 2015 Edition. However, we did update health IT, whether to meet ‘‘meaningful In order to advance interoperability estimates to 2017 dollars. use’’ objectives and measures or to by ensuring compliance with new achieve any other use within the scope structured data and code sets that (B) Smoking Status of the health IT’s certification. We also support the data, we have replaced the In this final rule, we removed the removed § 170.523(k)(1)(iv)(B) and (C), ‘‘Common Clinical Data Set’’ (CCDS) 2015 Edition ‘‘smoking status’’ criterion which state that the types of information definition and its references with the (§ 170.315(a)(11)), which would include required to be disclosed include, but are ‘‘United States Core Data for removing it from the 2015 Edition Base not limited to: (B) Limitations, whether Interoperability’’ (USCDI) standard, EHR definition. To calculate the cost by contract or otherwise, on the use of naming Version 1 (v1) in § 170.213 and savings for removing this criterion, we any capability to which technology is incorporated it by reference in used the 2015 Edition estimated costs of certified for any purpose within the § 170.299. The USCDI will replace the developing and preparing the criterion scope of the technology’s certification; CCDS 24 months after the publication to the 2015 Edition, between $15,750 or in connection with any data date of this final rule. The USCDI v1 and $31,500 and estimated that 35 generated in the course of using any establishes a minimum set of data percent of developers would be newly capability to which health IT is classes (including structured data) that certified in 2018 and 15 percent in 2019. certified; (C) limitations, including, but are required for health IT to be We estimated the cost of development not limited to, technical or practical interoperable nationwide and is and preparation costs to be between limitations of technology or its designed to be expanded in an iterative $5,512.50 and $11,025 for 2018 and capabilities, that could prevent or and predictable way over time. $2,362.50 and $4,725 for 2019. We impair the successful implementation, The USCDI v1 adds three new data calculated the cost per month for years configuration, customization, classes, ‘‘Allergies and Intolerances,’’ 2018 and 2019 and using the high point maintenance, support, or use of any ‘‘Clinical Notes,’’ and ‘‘Provenance;’’ estimates, estimated the development capabilities to which technology is and adds to ‘‘Patient Demographics’’ the and preparation costs over a 6 to 12 certified; or that could prevent or limit data elements ‘‘Previous Address,’’ month period between August 2018 and the use, exchange, or portability of any ‘‘Phone Number,’’ ‘‘Phone Number August 2019. We estimated the costs to data generated in the course of using Type,’’ and ‘‘Email Address’’ that were be between $4,068.75 at six months and any capability to which technology is not defined in the CCDS. This requires $6,825 at 12 months. Based on analysis certified. updates to the Consolidated Clinical of recent data, our assumptions To calculate the savings related to Document Architecture (C–CDA) continue to hold true. removing these two disclosure standard and updates to the following To calculate the cost for testing for requirements, we estimated 830 certification criteria: § 170.315(b)(1) this criterion, five developers were products certified to the 2015 Edition. (transitions of care); (e)(1) (view, estimated in the 2015 Edition to develop We did so by applying the market download, and transmit to 3rd party); products to this criterion. We multiplied consolidation rate of ¥23.2 percent (g)(6) (Consolidated CDA creation the five developers by our estimated which was the rate observed between performance); (f)(5) (transmission to cost to test per criterion of $475. This 2011 and 2014 Editions. If an ONC–ACB public health agencies—electronic case estimated cost per criterion was based spends 1 hour on average reviewing reporting); and (g)(9) (application on what one ONC–ATL charged for costs, limitations and mandatory access—all data request). From our testing and averaged per criterion. To be disclosures, we estimated the time analysis of the C–CDA standard, we conservative, we reduced the number by saved by no longer having to review the concluded that the requirements of the ten percent and five percent limitations to be two-thirds of an hour. ‘‘Provenance’’ data class are already met respectively resulting in $2,137.50 and The hourly wage with benefits for a GS– by the existing C–CDA standard and $2,256.25. 13, Step 1 employee located in will not require any new development. Taking these estimated costs into Washington, DC is approximately $91 Therefore, we have estimated the cost to account we expect the cost savings for and we assume this to be the hourly rate health IT developers to add support for removing the 2015 Edition ‘‘smoking for an ONC–ACB reviewer. We ‘‘Allergies and Intolerances’’ and status’’ criterion to be between multiplied 830, the projected number of ‘‘Clinical Notes’’ data classes and $8,962.50 and $9,081.25. certified products, by two-thirds of an ‘‘Previous Address,’’ ‘‘Phone Number,’’

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00272 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25913

‘‘Phone Number Type,’’ and ‘‘Email estimates in this section assume all patient data.208 There were 710 Address’’ data elements in C–CDA, and health IT developers will incur the costs products by 588 developers with at least the necessary updates to the affected noted in Table 7. one 2014 Edition product capable of certification criteria. These estimates are • A proxy is needed to project the recording patient data. We then detailed in Table 7 and are based on the number of 2015 Edition certified health multiplied these numbers by our following assumptions: IT products. As the 2015 Edition • certified health IT market consolidation Health IT developers will use the certification is ongoing, using the estimates of ¥22.1 percent and ¥23.2 same labor costs and data models. Table current count of developers and percent to project the number of 2015 7 shows the estimated labor costs per products would underestimate the developers and products, respectively. product for a health IT developer to overall costs and benefits, so we develop support for the additional therefore use a proxy. We estimate that • According to the May 2017 BLS USCDI data element in the C–CDA 545 products from 458 developers will occupational employment statistics, the standard and affected certification be affected. Our proxy is based on the mean hourly wage for a ‘‘Software criteria. We recognize that health IT number of 2014 Edition certified health Developer’’ is $53.74.209 developer costs will vary; however, our IT products that are capable of recording

TABLE 7—COSTS TO HEALTH IT DEVELOPERS TO DEVELOP SUPPORT FOR THE ADDITIONAL USCDI DATA ELEMENT IN C– CDA STANDARD AND AFFECTED CERTIFICATION CRITERIA [2017 Dollars]

Lower bound Upper bound Tasks Details hours hours Remarks

Update C–CDA creation ...... New development to support ‘‘Al- 1,200 2,400 (1) Lower bound assumes health lergies and Intolerances,’’ ‘‘Clin- IT already has developed C– ical Notes,’’ ‘‘Previous Address,’’ CDA R2.1 into their system and ‘‘Phone Number,’’ ‘‘Phone Num- only needs to be updated for ber Type,’’ and ‘‘Email Address’’ new data elements. for C–CDA and C–CDA 2.1 (2) Upper bound estimates effort Companion Guide. for organizations that are on older versions of C–CDA stand- ard, for example C–CDA R1.1. § 170.315(b)(1) (transitions of care) New development to support ‘‘Al- 200 600 Necessary updates to health IT to lergies and Intolerances,’’ ‘‘Clin- support the new data class to ical Notes,’’ ‘‘Previous Address,’’ meet the criteria requirements. ‘‘Phone Number,’’ ‘‘Phone Num- ber Type,’’ and ‘‘Email Address’’ for C–CDA and C–CDA 2.1 Companion Guide. § 170.315(e)(1) (view, download, New development to support ‘‘Al- 400 1,000 Necessary updates to health IT to and transmit to 3rd party). lergies and Intolerances,’’ ‘‘Clin- support the new data class to ical Notes,’’ ‘‘Previous Address,’’ meet the criteria requirements. ‘‘Phone Number,’’ ‘‘Phone Num- ber Type,’’ and ‘‘Email Address’’ for C–CDA and C–CDA 2.1 Companion Guide. § 170.315(g)(6) (Consolidated CDA New development to support ‘‘Al- 200 600 §170.315(b)(1) and creation performance). lergies and Intolerances,’’ ‘‘Clin- § 170.315(g)(6) are related and ical Notes,’’ ‘‘Previous Address,’’ may be developed together. ‘‘Phone Number,’’ ‘‘Phone Num- ber Type,’’ and ‘‘Email Address’’ for C–CDA and C–CDA 2.1 Companion Guide.

Total Hours ...... 2,000 4,600

Hourly Rate ...... $107 ......

Cost per Product ...... $214,000 $492,200

Total Cost (545 products) ...... $116.6 million $268.2 million

We estimated that the cost to a health developers would, on average, range We believe this would benefit health IT developer to develop support for the from $116.6 million to $268.2 million. care providers, patients, and the additional USCDI data elements would This would be a one-time cost to industry as a whole. Clinical notes and range $214,000 to $492,200. Therefore, developers per product that is certified provenance were included in the draft assuming 545 products, we estimate that to the specified certification criteria and USCDI v1 based on significant feedback the total annual cost to all health IT would not be perpetual. from the industry, which highly

208 We defined ‘‘products capable of recording criteria: Demographics ((a)(5)), Medication List 209 See ‘‘software developer, systems software’’— patient data’’ as any 2014 Edition health IT product ((a)(7)), Medication Allergy List ((a)(8)), Problem https://www.bls.gov/oes/2017/may/oes151133.htm. that was certified for at least one of the following List ((a)(6)), and Family Health History ((a)(12)).

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00273 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25914 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

regarded their desirability as part of Comments. We did not receive • Health IT developers will use the interoperable exchanges. The free text comments regarding an approach to same labor costs and data models. Table portion of the clinical notes was most quantify benefits. However, we did 8 shows the estimated labor costs per often relayed by clinicians as the data receive comment regarding estimation product for a health IT developer to they sought, but were often missing of the time and effort on behalf of health develop and maintain the EHI export during electronic health information IT developers to update to the USCDI. functionality. We recognize that health exchange. Similarly, the provenance of Commenters stated that we have IT developer costs will vary; however, data was also referenced by stakeholders underestimated the number of hours our estimates in this section assume all as a fundamental need to improve the necessary for health IT developers, health IT developers will incur the costs trustworthiness and reliability of the suggesting that it is triple our estimates. noted in Table 8. data being exchanged. Response. We thank commenters for • A proxy is needed to project the We expect improvements to their input. We maintain the approach number of 2015 Edition certified health interoperable exchange of information we proposed in the Proposed Rule in IT products containing the ‘‘EHI export’’ and data provenance to significantly regard to our estimates for updating the criterion. We estimated that 545 benefit providers and patients. For USCDI. This final rule constrains products from 458 developers will example, in 2018, among individuals ‘‘provenance’’ to only the scope of data contain the ‘‘EHI export’’ criterion. To who had viewed their online medical for which the health IT developer is the record within the past year owner/steward. Hence, the scope is develop these estimates, we first (representing 30 percent nationally), fairly limited and therefore, we believe identified a proxy for the number of about half indicated that clinical notes our estimates to be accurate. We note health IT developers that may create a were included in their online medical the removal of ‘‘data export’’ 2015 Edition certified health IT product record.210 Additionally, seven percent (§ 170.315(b)(6)) from the cost estimate containing the ‘‘EHI export’’ criterion. of individuals who viewed their online in Table 6, in alignment with our final Our proxy is based on the number of medical record requested a correction of policy decisions and no longer updating 2014 Edition certified health IT inaccurate information. Thus, enabling the criterion to USCDI. We did, products that are capable of recording patients to have access to their clinical however, increase the hour per patient data.212 We based our estimates notes might assist in reducing medical developer based on additional data on these products because data must be coding errors. elements included in this final rule. captured to be exported under the Patient matching is a barrier to (ii) Electronic Health Information Export adopted criterion. There were 710 interoperability. In 2017, 36 percent of products by 588 developers with at least In this final rule, we adopted a one 2014 Edition product capable of non-Federal acute care hospitals modified version of the ‘‘EHI export’’ reported difficulty matching or recording patient data. We then criterion in § 170.315(b)(10). Notably, multiplied these numbers by our identifying the correct patient between we have defined and further constrained 211 certified health IT market consolidation systems. The data elements ‘‘Previous the criterion’s scope of data for export estimates of ¥22.1 percent and ¥23.2 Address,’’ ‘‘Phone Number,’’ ‘‘Phone as EHI, as defined in § 171.102, that can percent to project the number of 2015 Number Type,’’ and ‘‘Email Address’’ be stored at the time of certification by developers and products, respectively. were included in the USCDI v1 based on the product, of which the Health IT feedback from industry, for their usage Module is a part. The final criterion • Wages are determined using BLS in accurate patient matching. provides a focused set of data from a estimates. According to the May 2017 However, we are not aware of an scope perspective and clarifies what a BLS occupational employment approach for quantifying these benefits product with a certified Health IT statistics, the mean hourly wage for a and we welcomed comments on Module must be capable of exporting. ‘‘Software Developer’’ is $53.74.213 As potential approaches to quantifying The intent of this criterion aims to noted previously, we have assumed that these benefits in the Proposed Rule. provide Health IT Module users the overhead costs (including benefits) are functionality to efficiently export or equal to 100 percent of pre-tax wages, so 210 Patel V & Johnson C. (May 2019). Trends in direct the export of EHI for a single the hourly wage including overhead Individuals’ Access and Use of Online Medical patient or a patient population in a costs is $107. Records and Technology for Health Needs: 2017– 2018. ONC Data Brief, no.48 Office of the National computable, electronic format. 212 Coordinator for Health Information Technology: (A) Costs To Develop and Maintain EHI We defined ‘‘products capable of recording Washington DC. patient data’’ as any 2014 Edition product that was 211 Pylypchuk Y., Johnson C., Henry J. & Ciricean Export Criterion certified for at least one of the following criteria: D. (November 2018). Variation in Interoperability This section describes the estimated Demographics ((a)(5)), Medication List ((a)(7)), among U.S. Non-Federal Acute Care Hospitals in Medication Allergy List ((a)(8)), Problem List 2017. ONC Data Brief, no.42. Office of the National costs of the ‘‘EHI export’’ criterion. The ((a)(6)), and Family Health History ((a)(12)). Coordinator for Health Information Technology: cost estimates are based on the 213 https://www.bls.gov/oes/2017/may/ Washington DC. following assumptions: oes151133.htm.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00274 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25915

TABLE 8—ESTIMATED LABOR COSTS TO DEVELOP AND MAINTAIN THE EHI EXPORT CRITERION PER PRODUCT

Lower bound Upper bound Activity hours hours Remarks

Task 1: Developing the Data Dic- 160 1,600 This is the effort to document all the data exported by the product for a tionary software capability to ex- single patient and for all patients. port EHI in a developer format The lower bound assumes that the health IT developer already has a (per product). standard format in which they are exporting the data for either case (e.g., C–CDA for single patient, CSV file or database dump for all data) and the effort is merely to publish it to the users. On the other hand, the upper bound reflects the case where the health IT has to develop the export capability de novo into their product and docu- ment the data output. This still assumes that the developer will be able to use the format of their choice. Task 2: Updating the Data Dic- 80 500 This is the maintenance cost to update the data dictionary published by tionary and publishing the up- the product to ensure that the data dictionary is compatible with dated format (per product). newer releases of the product. The lower bound estimate assumes the effort when there are only minor changes to the formats of the data stored by the product. The upper bound estimate assumes the effort when the product makes substantial changes to the formats of the data. Task 3: Updating the software that 80 500 This is the maintenance cost to upgrade the software that would gen- performs EHI Export (per product). erate the EHI export files. The lower bound estimates the cost to maintain the software when there are only minor changes to the product, including updates to underlying software (e.g., database versions, operating systems, etc.). The upper bound estimate ac- counts for substantial reworking of the export software program to ex- port in new formats or based on substantial changes made to the un- derlying storage system.

Total Labor Hours ...... 320 2,600

TABLE 9—EXAMPLE CALCULATION FOR THE LOWER BOUND ESTIMATED COST TO HEALTH IT DEVELOPERS TO PERFORM TASK 1 FOR THE EHI EXPORT CRITERION [2016 Dollars]

Estimated Activity labor hours Developer Projected lower bound salary products

Task 1 ...... 160 hours $107 per hour 545 products

Example Calculation

160 hours * $107 * 545 products = $9,330,400

TABLE 10—TOTAL COST TO DEVELOP AND MAINTAIN THE EHI EXPORT CRITERION [2017 Dollars]

Estimated cost Activity Lower bound Upper bound

Task 1 (545 products) ...... $9,330,400 $93,304,000 Task 2 (545 products) ...... 4,665,200 29,157,500 Task 3 (545 products) ...... 4,665,200 29,157,500

Total (545 products) ...... 18,660,800 151,619,000

(B) Costs To Implement and Support the Agency for Healthcare Research and system. We assume that all stakeholders EHI Export Criterion Quality and were based on the average impacted by this rule will already have cost to implement an EHR for a clinical a base EHR system implemented, The cost estimates are based on the practice.214 This publication was based therefore we discounted these estimates following assumptions: on the implementation of an entire EHR by a factor of 10 to better reflect the cost • Health care providers will use the to implement an EHI Export module same costs and data models. Table 11 214 Fleming, N., Impact of Health Information only. We did not have cost estimates for Technology on Primary Care Workflow and shows the estimated costs to implement hospitals. Therefore, to estimate the cost and support the EHI Export criterion. Financial Measures AHRQ Publication No. 11– 0081–4–EF, October 2011 https://digital.ahrq.gov/ for a hospital to implement an EHR The cost estimates used in this _ _ _ sites/default/files/docs/page/Fleming SS 508 system, we multiplied the estimate to calculation were published by the 20111021_d.pdf.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00275 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25916 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

implement an EHR for a clinical compared to a clinical practice. We • Hospitals and clinical practices that practice by a factor of 10. We believe recognize that costs health care have participated in the CMS EHR this will better reflect the increased providers incur will vary; our estimates Incentive Program will be impacted. We magnitude and complexity of in this section assume health care estimate that 95,470 clinical implementing and supporting a new providers incur the costs noted in Table practices 215 and 4,519 hospitals 216 will health IT module in a hospital 11. be impacted by our rule.

TABLE 11—ESTIMATED COST TO HOSPITALS AND CLINICAL PRACTICES TO IMPLEMENT AND SUPPORT THE EHI EXPORT CRITERION [2017 Dollars]

Cost per entity Task Entity type Number of Remarks entities Lower bound Upper bound

Task 1: Implementa- Clinical Practices ...... 95,470 $2,000 $4,000 This task would involve costs associated tion and Support. with staff support during implementation, workflow mapping and redesign, content development and customization, project management, and other technical deploy- ment including networking. Hospitals ...... 4,519 20,000 40,000 Task 2: Staff Training Clinical Practices ...... 95,470 500 1,000 This task would involve staff training for im- plementation teams and staff end users. Hospitals ...... 4,519 5,000 10,000

TABLE 12—TOTAL COST TO IMPLEMENT AND SUPPORT THE EHI EXPORT CRITERION [2017 Dollars]

Task Lower bound Upper bound

Task 1: Implementation and Support ...... Clinical Practices ...... $190,940,000 $381,880,000 Hospitals ...... 90,380,000 180,760,000 Task 2: Staff Training ...... Clinical Practices ...... 47,735,000 95,470,000 Hospitals ...... 22,595,000 45,190,000

Total Cost ...... 351,650,000 703,300,000

Based on the stated assumptions and IT developers’ business incentives, our rule eliminating these two tasks. costs outlined in Tables 8 and 10, the make it difficult and costly for EHR The benefit calculations below are based total estimated cost for health IT users to transfer system data from one on the following assumptions: developers to develop products to the developer to another. Data transfer costs • On average, five percent of ‘‘EHI export’’ criterion will range from vary depending on how contracts are providers and hospitals switch their $18.7 million to $151.6 million. structured.217 Specifically, contracts health IT annually. Using CMS Assuming 458 health IT developers, might include high data-transfer fees or Medicare EHR Incentive Program data there would be an average cost per do not include conditions for data health IT developer ranging from transfer. Providers may also pay fees for from years 2013–2016, we estimate the $40,744 to $331,045. We note that the consultants or technical staff to help rate of providers (hospitals and eligible development costs, which equal half of with the data-transfer process given professionals) that changed their health the total, would be a one-time cost and differences in how data may be mapped IT developer. We believe that the EHI would not be perpetual. The total from one developer to another. Hence, export functionality would help estimated cost for hospitals and clinical health care providers will experience alleviate the burden of switching practices to implement and support the benefits associated with the between health IT systems by increasing EHI Export will range from $351.7 standardization proposed in the EHI portability of EHI that can be stored at million to $703.3 million. The midpoint export functionality. the time of certification by the product, of ranges stated is used as the primary Because of the EHI export of which the Health IT Module is a part. estimate of costs. functionality, providers will no longer Thus, the benefit calculations are based on assumptions regarding the number of (C) Benefits incur the costs associated with mapping data from their health IT database into clinical practices (n = 4,774) and Health care providers may choose to standard terms or exporting said data hospitals (n = 226) that are projected to change their EHRs for a number of using a standardized format when switch products in a year. reasons. However, the steps and costs switching EHRs. In our analysis, we associated with switching one’s EHR are calculated the benefits in terms of the complex. Market forces, such as health reduced costs to providers as a result of

215 This number was estimated based on the de- 216 This estimate is the total number of eligible 217 Pratt, Mary, The True Cost of Switching EHRs, duplicated number of practices that had at least one hospitals that ever participated in the CMS Medical Economics, May 30, 2018, Volume: 96 clinician participate in the CMS Medicare Medicare Electronic Health Record Incentive Issue: 10. Electronic Health Record Incentive Program. Program.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00276 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25917

• Health IT consultants 218 will use without the EHI export functionality. statistics, the mean hourly wage for a the same labor costs and data models. We recognize that these costs will vary ‘‘Software Developer’’ is $53.74.219 As Table 13 shows the estimated labor based on the size of the hospital or noted previously, we have assumed that costs per product for a hospital or health clinical practice. overhead costs (including benefits) are care provider to hire a health IT • Wages are determined using BLS equal to 100 percent of pre-tax wages, so consultant to perform data export of estimates. According to the May 2017 the hourly wage including overhead EHI, as defined in 45 CFR 171.102, BLS occupational employment costs is $107.

TABLE 13—COST PER PROVIDER TO PERFORM DATA EXPORT WITHOUT EHI EXPORT FUNCTIONALITY WHEN SWITCHING HEALTH IT PRODUCTS [2017 Dollars]

Estimated cost Estimated cost per health IT per health IT Activity switch switch Remarks (lower bound) (upper bound) (hours) (hours)

Task 1: Understanding and mapping the data in 320 3,200 The lower bound is an estimate for a small provider health IT database into standard terms. practice using the standard instance of a certified health IT product with no customization and use of nationally recognized content standards. The upper bound estimates a medium to large practice with substantial local customization of content. Task 2: Exporting the data from the health IT into a 160 1,600 The lower bound assumes that the certified health IT format that can be subsequently used to import. product is capable of exporting most of the data into standard output format such as C–CDA. The upper bound estimates the case where a large amount of data is not easily exported by the cer- tified health IT product and therefore substantial one-off software needs to be written to export the data into a custom (de novo) format developed for the transition.

Total Labor Hours ...... 480 4,800

Table 14 provides an example calculation for how we calculated our total costs presented in Table 15.

TABLE 14—EXAMPLE CALCULATION FOR THE LOWER BOUND ESTIMATED COST TO PROVIDERS TO HIRE A HEALTH IT CONSULTANT TO PERFORM TASK 1 WITHOUT THE EHI EXPORT CRITERION [2017 Dollars]

Estimated annual Activity Estimated labor Developer salary number of health hours lower bound IT switches

Task 1 ...... 320 hours $107 per hour 5,000 switches

Example Calculation: 320 hours * $107 * 5000 switches = $171,200,000.

TABLE 15—TOTAL COST TO PROVIDERS TO PERFORM DATA EXPORT WITHOUT THE EHI EXPORT CRITERION WHEN SWITCHING HEALTH IT PRODUCTS [2017 Dollars]

Estimated cost Activity Lower bound Upper bound

Task 1 ...... $171,200,000 $1,712,000,000 Task 2 ...... 85,600,000 856,000,000

Total Cost Savings (5,000 switches) ...... 256,800,000 2,568,000,000

218 ‘‘Health IT consultant’’ refers to a technical migrate their data from a legacy system to a new 219 https://www.bls.gov/oes/2017/may/ expert that a hospital or provider will hire to EHR. oes151133.htm.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00277 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25918 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

We multiplied the costs to switch develop and maintain an API. We developers and products, respectively. health IT by the estimated number of recognize that health IT developer costs Some developers and products are hospitals and clinical practices affected. will vary based on whether they have already leveraging aspects of the API Thus the estimated annual benefit, in already implemented aspects of the API certification criterion. This could reduce terms of cost savings to hospitals and certification criterion; including their cost to implement the criterion. To clinical practices, would range from adopting the Fast Healthcare determine the number of developers and $256.8 million to $2.6 billion. Interoperability Resources (FHIR®) API. products applicable to cost Table 16 A To account for this variation, we have (iii) Application Programming Interfaces or 16 B, we calculated the proportion of estimated two cost tables. Table 16 A products and developers that have The API requirements in this final reflects the range of costs incurred for already certified to API certification rule reflect the full depth and scope of new products or those developers that criterion. We then applied this estimate what we believe is necessary to have not previously certified to the API to the projected number of 2015 Edition implement the API Condition of certification criteria. Table 16 B shows certified health IT products. Certification requirement described in the cost for developers that have already Specifically, we estimate that 50 percent section 4002 of the Cures Act. We have implemented the API criteria. We have of products (230) and 55 percent of adopted new standards, new assumed in our calculations that all developers (217) will incur costs implementation specifications, a new health IT developers will incur costs reflected in Table 16 A because they certification criterion, and detailed noted in either Table 16 A or Table 16 have no prior experience with certifying Conditions and Maintenance of B. • to the API criteria. We believe this Certification requirements in §§ 170.213 A proxy is needed to project the estimate serves as a reasonable proxy for number of 2015 Edition certified health and 170.215, 170.315, and 170.404, products’ capability to send patient data IT products containing the API respectively. We also modified the Base and the cost of implementation. The API certification criterion. We estimated that EHR definition in § 170.201. functionality required by the 2015 459 products from 394 developers will Edition achieves a similar end by (A) Costs To Develop and Maintain contain the API criterion. We used a Certified API Technology proxy to determine the number of health allowing providers to retrieve patient This section describes the potential IT developers that may develop an API data from secure data servers hosted by costs of the API certification criterion. for the certification to the 2015 Edition. other developers, as well as providing The cost estimates below are based on There were 598 products and 506 patients access to their medical records the following assumptions: developers with at least one 2014 through third-party applications • Health IT developers will use labor Edition certified health IT product that connected to these same secure servers. costs and data models based on whether could perform transitions of care. We • Wages are determined using BLS they have adopted aspects of the API then multiplied this number by our estimates. According to the May 2017 certification criterion. Tables 16 A and certified health IT market consolidation BLS occupational employment 16 B show the estimated labor costs per estimates of ¥22.1 percent and ¥23.2 statistics, the mean hourly wage for a product for a health IT developer to percent to project the number of 2015 ‘‘Software Developer’’ is $53.74.220

TABLE 16 A—ESTIMATED LABOR HOURS TO DEVELOP AND MAINTAIN API—NEW PRODUCTS

Estimated labor hours Activity Details Remarks Lower bound Upper bound

Task 1: Implementing (1) New development to support OpenID 1000 1500 (1) Lower bound assumes health IT has security via SMART Connect. already implemented security via App Launch Frame- (2) Implementation of the Smart Guide SMART App Launch Framework IG work IG (per prod- with support for refresh tokens and the and need to be updated to account for uct). core capabilities specified in the rule. additional requirements in the rule in- (3) New development to respond to re- cluding Support for additional ‘‘core’’ quest for access token verification. capabilities required by rule and Token Introspection. (2) Upper bound assumes new develop- ment for implementation of SMART App Launch Framework IG, and addi- tional requirements in the rule including Token Introspection. Task 2: Develop sup- (1) New development to support FHIR R4 2000 6000 (1) Lower bound assumes health IT al- port for Fast (2) Implementation to the FHIR US Core ready has developed FHIR DSTU2 Healthcare Inter- IG. 2015 Edition for data classes that were operability Re- specified in prior rule and only needs to sources (FHIR®) be updated to R4 and new data class- API and associated es specified in the rule IGs (per product). (2) Upper bound assumes new develop- ment of FHIR API for all resources

220 https://www.bls.gov/oes/2017/may/ oes151133.htm.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00278 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25919

TABLE 16 A—ESTIMATED LABOR HOURS TO DEVELOP AND MAINTAIN API—NEW PRODUCTS—Continued

Estimated labor hours Activity Details Remarks Lower bound Upper bound

Task 3: Develop API (1) New development to support FHIR 2000 4500 (1) Lower bound assumes health IT al- for Population Level Bulk Data Access IG. ready has an existing API for popu- Services (per prod- lation level services; and need to mi- uct). grate to the standardized API specified Note: One-time cost .. in the rule. (2) Upper bound assumes new develop- ment of FHIR Bulk Data Access IG. Task 4: Development (1) New registration server development 1000 2500 (1) Lower bound assumes that the devel- of App registration (or updates to existing server) to sup- oper already has existing application Server and Portal port registration timeliness and publica- registration infrastructure in place, and (per developer). tion of FHIR endpoints. only needs to update it to support the (2) Development of portal and managing API Maintenance of Certification re- the application registration system. quirements. (2) Upper bound is new development of an application registration service and portal. Task 5: Update Appli- (1) Yearly updates and maintenance to 400 1300 (1) Lower bound estimates hours to keep cation Registration keep the portal running. We do not an- it running with junior staff. Server and Portal ticipate any major changes to the (2) Upper bound estimates small up- (per developer). standard and will be primarily driven by dates. usage and developer interest. Task 6: Develop sup- (1) Develop capability to identify apps au- 250 1500 (1) Lower bound assumes that the devel- port for patients to thorized by registered users. oper already has a portal used by pa- revoke access to (2) Provide capability to remove access tients for managing their preferences authorized app (per at patient direction. and new development will be needed product).. to provide patients with ability to view Note: One-time cost .. and revoke access to their authorized apps. (2) Upper bound assumes that devel- oper’s current capability of managing registered patients need to be signifi- cantly enhanced to support enabling patients to revoke access to the au- thorized apps. Other costs (50% per (1) Server costs for application registra- $7,500 $30,000 (1) Estimated as monetized costs and not product, 50% per tion, sandbox, bulk data storage, and as hours; most of the costs would be devel- costs associated with making docu- one-time procurement costs plus yearly oper) (2017 Dollars). mentation publicly available. maintenance. Note: One-time cost .. (2) Software costs (e.g., databases, appli- cation servers, portal technology).

TABLE 16 B—ESTIMATED LABOR HOURS TO DEVELOP AND MAINTAIN API—CURRENTLY CERTIFIED PRODUCTS

Estimated labor hours Activity Details Remarks Lower bound Upper bound

Task 1: Implementing (1) Development to support OpenID Con- 800 1000 (1) Lower bound assumes health IT has security via SMART nect. already implemented security via App Launch Frame- (2) Implementation of the Smart Guide SMART App Launch Framework IG work IG (per prod- with support for refresh tokens and the and need to be updated to account for uct). core capabilities specified in the rule. additional requirements in the rule. (3) Development to respond to request (2) Upper bound assumes additional de- for access token verification. velopment for implementation of SMART App Launch Framework IG, and additional requirements in the rule. Task 2: Develop sup- (1) Development to support FHIR R4 ...... 1600 2000 (1) Lower bound assumes health IT al- port for Fast (2) Implementation to the FHIR US Core ready has developed FHIR R4 for data Healthcare Inter- IG. classes that were specified in prior rule operability Re- and only needs to be updated to new sources (FHIR®) data classes specified in the rule. API and associated (2) Upper bound assumes health IT was IGs (per product). originally developed for FHIR DSTU2 and needs additional development of FHIR API to support upgrading to FHIR R4 and new data classes.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00279 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25920 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

TABLE 16 B—ESTIMATED LABOR HOURS TO DEVELOP AND MAINTAIN API—CURRENTLY CERTIFIED PRODUCTS— Continued

Estimated labor hours Activity Details Remarks Lower bound Upper bound

Task 3: Develop API (1) New development to support FHIR 2000 4500 (1) Lower bound assumes health IT al- for Population Level Bulk Data Access IG. ready has an existing API for popu- Services (per prod- lation level services; and need to mi- uct). grate to the standardized API specified Note: One-time cost .. in the rule. (2) Upper bound assumes new develop- ment of FHIR Bulk Data Access IG. Task 4: Development (1) New registration server development 800 1000 (1) Lower bound assumes that the devel- of App registration (or updates to existing server) to sup- oper already has existing application Server and Portal port registration timeliness and publica- registration infrastructure in place, and (per developer). tion of FHIR endpoints. only needs to update it to support the (2) Development of portal and managing API Maintenance of Certification re- the application registration system. quirements. (2) Upper bound assumes additional de- velopment to support requirements in rule. Task 5: Update Appli- (1) Yearly updates and maintenance to 320 400 (1) Lower bound estimates hours to keep cation Registration keep the portal running. We do not an- it running with junior staff. Server and Portal ticipate any major changes to the (2) Upper bound estimates small up- (per developer). standard and will be primarily driven by dates. usage and developer interest. Task 6: Develop sup- (1) Develop capability to identify apps au- 150 250 (1) Lower bound assumes the developer port for patients to thorized by registered users. provides this functionality based on revoke access to (2) Provide capability to remove access 2015 ONC Edition and needs to per- authorized app (per at patient direction. form minimum verification. product). (2) Upper bound assumes that the devel- Note: One-time cost .. oper already has a portal used by pa- tients for managing their preferences and new development will be needed to provide patients with ability to view and revoke access to their authorized apps. Other costs (50% per (1) Server costs for application registra- $6000 $7,500 (1) Estimated as monetized costs and not product, 50% per tion, sandbox, bulk data storage, and as hours; most of the costs would be devel- costs associated with making docu- one-time procurement costs plus yearly oper) (2017 Dollars). mentation publicly available. maintenance. Note: One-time cost .. (2) Software costs (e.g., databases, appli- cation servers, portal technology).

Table 17 provides an example total costs presented in Tables 18 A and calculation for how we calculated our 18 B.

TABLE 17—EXAMPLE CALCULATION FOR THE LOWER BOUND ESTIMATED COST TO NEW PRODUCTS TO PERFORM TASK 1 IN TABLE 13 A TO DEVELOP API [2017 Dollars]

Estimated labor hours Activity Developer salary Projected products Lower bound

Task 1 ...... 1,000 hours ...... $107 per hour ...... 230 products.

Example Calculation: 1,000 hours * $107 * 230 products = $24,610,000.

TABLE 18 A—TOTAL COST TO DEVELOP AND MAINTAIN API—NEW PRODUCTS [2017 Dollars]

Estimated lost Activity Lower bound Upper bound

Task 1 (230 products) ...... $24,556,500 $36,834,750 Task 2 (230 products) ...... 49,113,000 147,339,000 Task 3 (230 products) ...... 49,113,000 110,504,250

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00280 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25921

TABLE 18 A—TOTAL COST TO DEVELOP AND MAINTAIN API—NEW PRODUCTS—Continued [2017 Dollars]

Estimated lost Activity Lower bound Upper bound

Task 4 (217 developers) ...... 23,186,900 57,967,250 Task 5 (217 developers) ...... 9,274,760 30,142,970 Task 6 (230 products) ...... 6,152,500 36,915,000 Other Costs (230 products) ...... 860,625 3,442,500 Other Costs (217 developers) ...... 812,625 3,250,500

Total (230 products and 217 developers) ...... 163,069,910 426,396,220

TABLE 18 B—TOTAL COST TO DEVELOP AND MAINTAIN API—CURRENTLY CERTIFIED PRODUCTS [2017 Dollars]

Estimated cost Activity Lower bound Upper bound

Task 1 (229 products) ...... $19,645,200 $24,556,500 Task 2 (229 products) ...... 39,290,400 49,113,000 Task 3 (229 products) ...... 49,113,000 110,504,250 Task 4 (177 developers) ...... 15,176,880 18,971,100 Task 5 (177 developers) ...... 6,070,752 7,588,440 Task 6 (229 products) ...... 3,675,450 6,125,750 Other Costs (229 developers) ...... 688,500 860,625 Other Costs (177 products) ...... 531,900 664,875

Total (229 products and 177 developers) ...... 134,192,082 218,384,540

We note that we have adopted in (B) Optional Cost To Acquire and Use Although not required under this rule, § 170.404(b)(3) a specific requirement Applications That Interact With this section describes the potential costs that an API Technology Supplier must Certified API Technology of health care providers to acquire and support the publication of Service Base We believe the API certification use new software applications that URLs for all of its customers that are criterion and associated Condition and interact with certified API technology. centrally managed by the Certified API Maintenance of Certification The cost estimates are based on the Developer, and make such information requirements finalized in this rule will following assumptions: publicly available (in a computable create an environment that promotes • Health care providers will use the format) at no charge. Thus, we are innovation for software developers to same costs and data models. Table 19 placing the responsibility of publishing connect new tools and services that shows the estimated costs to acquire the URLs on health IT developers and create efficiencies for health care and use software applications that those costs are captured in the providers throughout their course of interact with certified API technology. registration portal cost estimation in this care delivery. Software applications that We recognize that costs health care RIA. connect to APIs is an emerging market providers incur will vary based on Based on the stated assumptions and that we believe will be further enhanced several factors including, but not costs outlined in Tables 16 A and 16 B, by the standards, transparency, and pro- limited to, size of the health care entity, the total estimated costs for health IT competitive requirements finalized in application usage, and complexity of developers to develop and maintain a this rule. As of October 25, 2018, deployment and maintenance. However, product to the API criterion would researchers identified nearly 300 our estimates in this section assume range from $297.3 million to $644.8 software applications being marketed on health care providers incur the costs million with an average cost per EHR vendors’ app stores. The majority noted in Table 19. developer ranging from $0.75 million to of these applications are designed for • Hospitals and clinical practices that $1.64 million. We note that the ‘‘other health care providers to help support have participated in the CMS EHR costs’’ and costs associated with tasks 3 use cases for population health Incentive Program will be impacted. We and 6, which account for $110.9 million analytics, clinical decision support, estimate that 95,470 clinical to $272.3 million of this total, are one- patient education, as well as to conduct practices 222 and 4,519 hospitals 223 will time costs and are not perpetual. administrative and financial tasks.221 be impacted by our rule.

221 Dullabh P, Hovey L, Heaney-Huls K, 222 This number was estimated based on the de- 223 This estimate is the total number of eligible Rajendron N, Wright A, Sittig D. Application duplicated number of practices that had at least one hospitals that ever participated in the CMS Programming Interfaces in Health Care: Findings clinician participate in the CMS Medicare Medicare Electronic Health Record Incentive from a Current-State Sociotechnical Assessment. Electronic Health Record Incentive Program. Program. Applied Clinical Informatics. 2020; 11(01): 059– 069.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00281 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25922 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

TABLE 19—ESTIMATED COST TO HOSPITALS AND CLINICAL PRACTICES TO ACQUIRE AND USE SOFTWARE APPLICATIONS THAT ENGAGE WITH CERTIFIED API TECHNOLOGY [2017 Dollars]

Cost per entity Total cost Entity type Number of entities Lower bound Upper bound Lower bound Upper bound

Clinical Practices ...... 95,470 $1,000 $5,000 $95,470,000 $477,350,000 Hospitals ...... 4,519 10,000 100,000 45,190,000 451,900,000

Total ...... 140,660,000 929,250,000

The total cost to health care providers associated with these measures is high additional computer and other clerical to acquire and use software applications and the impact of health information work. Despite the number of hours that engage with certified API exchange is likely to result in significant providers spend in their EHR, there is technology would range from $140.6 benefits in the form of a cost evidence that the introduction of EHRs million to $929.3 million. The midpoint reduction.225 Finally, we quantify an is associated with time saved. Adler- of ranges stated is used as the primary increase in the number of individuals Milstein (2013) found that EHR use estimate of costs. with access to their health information compared to non-EHR use resulted in a 5.3 percent increase in work relative (C) Benefits through a mechanism of their choice such as apps. value units per clinician work day.228 The Medicare Access and CHIP The benefit calculations are based on Improved efficiencies are not limited Reauthorization Act (MACRA), (Pub. L. the following assumptions: to the installation of an EHR. Providers 114–10), tasks ONC with measuring • Benefits noted in academic also benefit from the use of emerging interoperability in the health IT literature are assumed accurate. technologies. Amusan (2008) found that industry.224 The measurement concepts Estimates of the benefits are based on EHR and computerized provider order developed include a multi-part estimates obtained from peer reviewed entry (CPOE) implementation was approach analyzing not only adoption of academic literature. ONC reviewed associated with 3.69 minutes of time health IT functionalities supporting academic articles for validity; however, saved five months post information exchange but the models were not replicated. implementation.229 Similarly, Helmons downstream impact of these • Hospitals and eligible professionals (2015) found that the impact of technologies on data completeness, data that have participated in the CMS EHR suppressing clinically irrelevant alerts integration, and supports for core Incentive Programs will be impacted: and adding clinical-decision support to functions of patient care. The benefits of Estimates assume that 439,187 health EHRs saved providers about two percent our API proposal are similarly care providers and/or 4,519 hospitals of their time. multifaceted. would be affected by this regulatory To measure the benefits of the API Our API proposal will increase action. provision on providers’ time as a result interoperability by ensuring that more of new technologies, we examined the data is available and shared between (D) Benefits: Provider Time Saved as a literature on the impact of IT on EHR users. The proposal will also make Result of New Efficiencies in Care productivity across various industries. data more widely available to software Delivery Due to the Optional Purchase As explained in Bartel (2007), developers outside of those specializing of New Technologies, Such as Provider improvements in IT could affect in EHR development. As a result, this Facing Apps productivity through multiple data will lead to greater innovation in Improvements in technology result in mechanisms that are not necessarily the app market resulting in new benefits for consumers and producers associated with the underlying intention technologies for health care providers through increased production of that technology.230 When examining and patients alike. In the analysis, we efficiencies (Stoneman 2018).226 The the effect of IT in manufacturing, quantify benefits in the following three introduction of EHRs into the health researchers found that adoption of IT areas: First, provider time saved as a care industry is an example of this. affected production plants’ composition result of new efficiencies in care Sinsky (2016) found physicians spend of products, reduced time of production delivery due to new technologies, such 27 percent of their total time on direct processes, and increased hiring of as provider facing apps. Second, the clinical face time with patients, and skilled workers. We adopt the same effects of interoperability on cost- 49.2 percent of their time on EHR and logic here. Specifically, we assume that savings associated with reductions in desk work.227 Outside of office hours, the impact of the data made available duplicate lab tests, readmissions, physicians spend another one to two under our API provisions will not be emergency room (ER) visits, and adverse hours of personal time each night doing 228 Julia Adler-Milstein and Robert S. Huckman, drug events. We focused on these The Impact of Electronic Health Record Use on outcomes for two reasons: Evidence in 225 Analyzing the Public Benefit Attributable to Physician Productivity, Am J Manag Care (Nov. 19, literature indicates that health Interoperable Health Information Exchange https:// 2013). information exchange impacts the aspe.hhs.gov/pdf-report/analyzing-public-benefit- 229 Amusan, Tongen, Speedie, and Mellin, A attributable-interoperable-health-information- time-motion study to evaluate the impact of EMR chosen measures; and cost of care exchange. and CPOE implementation on physician efficiency, 226 Stoneman P, Bartoloni E., Baussola M. The J. Healthcare Inf. Manag. (Fall 2008), at 31–7. 224 Health IT Buzz Blog, Measuring Microeconomics of Product Innovation. Oxford, 230 Bartel, Ann & Ichniowski, Casey & Shaw, Interoperability: Listening and Learning, https:// United Kingdom: Oxford University Press, 2018. Kathryn. (2007). How Does Information Technology www.healthit.gov/buzz-blog/electronic-health-and- 227 Christine Sinsky et al., Allocation of Physician Affect Productivity? Plant-Level Comparisons of medical-records/interoperability-electronic-health- Time in Ambulatory Practice: A Time and Motion Product Innovation, Process Improvement, and and-medical-records/measuring-interoperability- Study in 4 Specialties, Ann Intern Med. (Dec. 6, Worker Skills. The Quarterly Journal of Economics. listening-learning/. 2016), at 753–60. 122. 1721–1758. 10.1162/qjec.2007.122.4.1721.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00282 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25923

through a single mechanism, such as an to improve patient scheduling and available through APIs on the future EHR, but will have multiple spillover billing processes. Use of this tool could health IT market. effects. For example, data made result in improvements in the providers’ Table 20 provides a summary of the available through an API could be used workflow. Thus, is important to results of the literature review used to by a software developer to create tools quantify the impacts of data made quantify this benefit.

TABLE 20—FINDINGS FROM LITERATURE ON THE IMPACT OF INFORMATION TECHNOLOGY ON PRODUCTIVITY

Findings: Study Description (%)

Bartel et al (2007) ...... Identify impact in improvements in information technology on production time of valve manu- 4–8 facturing. IT is defined as adoption of separated information system that enable various automations. Lee et al (2013) ...... Identified impact of IT capital on hospital productivity where IT capital is defined as hospital 3–6 expenditure on IT. Shao and Lin (2002) ...... Identifies impact of IT expense on productivity of fortune 500 firms ...... 2–7 Adler-Milstein et al (2013) ...... Identifies the impact of the introduction of the EHR on providers’ time compared to non-EHR 5 users. Helmons et al (2015) ...... Identifies impact of suppressing clinically irrelevant alerts and adding clinical-decision support 2 to EHRs on time saved. Wagholikar KB, et al (2015) ..... Identifies impact of clinical-decision support on time saved among primary care providers ...... 1 Sources: a Jinhyung Lee Jeffrey S. McCullough Robert J. Town. The impact of health information technology on hospital productivity. The RAND Journal of Economics 44(3):545. b Shao, W. Lin, Technical efficiency analysis of information technology investments: a two-stage empirical investigation, Information and Man- agement 39, 2002, pp. 391–401. c Adler-Milstein, J. and Huckman, R, The Impact of Electronic Health Record Use on Physician Productivity, AM J Manage Care, Nov. 19, 2013. d Helmons PJ1, Suijkerbuijk BO2, Nannan Panday PV3, Kosterink JG4. Drug-drug interaction checking assisted by clinical decision support: a return on investment analysis. J Am Med Inform Assoc. 2015 Jul; 22(4):764–72. doi: 10.1093/jamia/ocu010. Epub 2015 Feb 10. e Wagholikar KB1, Hankey RA2, Decker LK2, Cha SS2, Greenes RA3, Liu H2, Chaudhry R2. Evaluation of the effect of decision support on the efficiency of primary care providers in the outpatient practice. J Prim Care Community Health. 2015 Jan;6(1):54–60. doi: 10.1177/ 2150131914546325. Epub 2014 Aug 25.

As illustrated in the Table 20, the (E) Benefits: Reduced Costs Associated each provision are unique to the specific incremental effects of improvements in With the Impact of Interoperability on provision. We assumed that the IT on productivity range from one Health Outcomes collective impact of real world testing percent to eight percent. Based on these To identify the impact of the API and API proposals on interoperability findings, we assume the impact of the proposal on interoperability and would not exceed the impact of 2014 API provision on providers’ time ranges therefore identified health outcomes, we Edition certified health IT (estimated at between one percent and five percent. used regression analysis. Specifically, five percent). We distributed the five The lower bound estimate of one we estimated linear probability models percent benefit across our real world percent assumes that, at a minimum, that identified the impact of 2014 testing and API proposals at (0.1–1 providers will use one new app created Edition certified EHR on hospitals’ percent) to (1–4 percent) respectively. as a result of the data made available interoperability (whether a hospital Moreover, the number of providers under the API provision. We assume sends, receives, finds, and integrates impacted is specific to each provision. that this app will save providers time summary of care records). Using data Thus, to finalize our calculations of the equivalent to the introduction of clinical from the American Hospital Association reduced costs related to reductions in decision support tools found in 232 (AHA) from years 2014 to 2015 in the duplicate lab tests, readmissions, Wagholikar (2015). The upper bound model, we controlled for hospital size, emergency room (ER) visits, and adverse estimate of five percent assume that, at profit status, participation in a health drug events due to increased a maximum, providers will use multiple information organization, and state and interoperability, we leveraged evidence apps created such that the combination year fixed effects. The marginal effect of will result in an increase in using a 2014 Edition certified health IT from the literature that found an productivity. Furthermore, we assume equated to a five percent increase in association between providers’ rates of that the API provision will affect only interoperability. This is an upper bound interoperability and applied the providers with certified EHRs and those estimate. For the purpose of this estimated marginal effect of each that participated in the CMS EHR analysis, we assume that one to four proposal on interoperability. Given data Incentive Program (439,187). Given that percentage points would be a reasonable limitations, we believe this approach an average provider spends six hours range for API’s marginal impact on allows us to estimate the benefits of our with an EHR per day,231 earns $97.85 interoperability. final rule without double counting the per hour, and works 260 days per year, As noted previously, there might be impact each provision might have on physicians’ time saved attributed to API shared benefits across certain interoperability. technology range from $670 million to provisions, and we have taken steps to $3.4 billion per year. ensure that the benefits attributed to

231 Christine Sinsky et al., Allocation of Physician Study in 4 Specialties, Ann Intern Med. (Dec. 6, 232 American Hospital Association Health IT Time in Ambulatory Practice: A Time and Motion 2016), at 753–60. Supplement Survey, http://www.ahadata.com/aha- healthcare-database/.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00283 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25924 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

TABLE 21—BENEFIT OF API ON HEALTH CARE OUTCOMES [2017 dollars]

Impact of API Percentage of Total benefit a Benefit type Number Overall interop impact Total cost total cost affected (marginal effect) Min Max impacted Min Max

Duplicate testing ...... 439,187 pro- 0.09 b ...... 0.01 0.04 $200 billion c ...... 100 $185 million per $742 million per viders. year. year. Avoidable hospitalizations and readmissions ...... 4,519 hospitals .. 0.09 b ...... 0.01 0.04 $41 billion d ...... 100 $38 million per $152 million per year. year. ER visits ...... 131 million vis- 0.03 b ...... 0.01 0.04 $1,233 per ER 100 $50 million per $200 million per its e. visit. year. year. Adverse drug events ...... 20 of events af- 22 f ...... 0.01 0.04 $30 billion g ...... 20 $14 million per $54 million per fected. year. year. a Total benefit is a product of total cost, percent of total cost impacted, overall impact of interoperability, and impact of API, adjusted for inflation (1.03). b Stephen E. Ross, Tiffany A. Radcliff, William G. Leblanc, L. Miriam Dickinson, Anne M. Libby, and Donald E. Nease Jr., Effects of health information exchange adoption on ambulatory test- ing rates, J. Am. Med. Inform. Assoc. (2013), at 1137–1142; Bridget A. Stewart, Susan Fernandes, Elizabeth Rodriguez-Huertas, and Michael Landzberg, A preliminary look at duplicate testing associated with lack of electronic health record interoperability for transferred patients, J. of the Am. Med. Informatics Assoc. (2010), at 341–344; Sezgin Ayabakan, Indranil R. Bardhan, Zhiqiang (Eric) Zheng, and Kirk Kirksey Value of health information sharing in reducing healthcare waste: An analysis of duplicate testing across hospitals, MIS Quarterly (Jan. 1, 2017); Eric J. Lammers, Julia Adler-Milstein, and Keith E. Kocher, Does health information exchange reduce redundant imaging? Evidence from emergency departments, Med Care (Mar. 2014), at 227–34. c National Academy of Medicine. (2016), http://money.cnn.com/2017/05/20/news/economy/medical-tests/index.html. d Agency for Healthcare Research and Quality (AHRQ) Statistical Brief #199 (Dec. 2015), https://www.hcup-us.ahrq.gov/reports/statbriefs/sb199-Readmissions-Payer-Age.pdf; AHRQ Statistical Brief #72, Nationwide Frequency and Costs of Potentially Preventable Hospitalizations (Apr. 2009), https://www.hcup-us.ahrq.gov/reports/statbriefs/sb72.pdf. e National Center for Health Statistics (NCHS) Data Brief No. 252 (June 2016), https://www.cdc.gov/nchs/data/databriefs/db252.pdf; Nolan Caldwell, Tanja Srebotnjak, Tiffany Wang, and Renee Hsia, ‘‘How Much Will I Get Charged for This?’’ Patient Charges for Top Ten Diagnoses in the Emergency Department (2013), https://doi.org/10.1371/journal.pone.0055491. f M.F. Furukawa, W.D. Spector, M.R. Limcangco, and W.E. Encinosa, Meaningful use of health information technology and declines in in-hospital adverse drug events, J. of the Am. Med. Informatics Assoc. (2017). g Janet Sultana, Paola Cutroneo, and Gianluca Trifiro`, Clinical and economic burden of adverse drug reactions.

Based on this analysis, the benefits of Under 45 CFR 164.524(c)(4), a covered proportion of individuals who reported the API provision on reduced costs on entity may impose a reasonable, cost- having to bring a test result to a doctor’s health outcomes range from $287 based fee (consistent with the appointment at least once in the past million to $1.1 billion. conditions in § 164.524(c)(4)(i) through year. In 2018, approximately 81 percent (iv)). For purposes of this analysis, we of Americans reported that they saw a (F) Benefits: Increase in Percent of assume covered entities can charge a flat doctor in the past year and about 19 Individuals With Access to Their Health fee not to exceed $6.50 (inclusive of all percent of these individuals reporting Information labor, supplies, and any applicable having to bring a test result to an This provision will also provide postage). The API Condition and appointment. Therefore, using Census individuals with better access to their Maintenance of Certification data from December 31, 2017, we data. APIs make it easier for patients to requirements finalized in § 170.404 do conducted the following calculation transmit data to smartphone health not allow for a ‘‘Certified API (total U.S. population 325.9M) * (81 applications. According to the Health Developer’’ (as defined in § 170.404(c)) percent of individuals saw a doctor in Information National Trends Survey,233 to charge patients for connecting to an the past year) * (19 percent of nearly 20 percent of Americans were API to access, exchange, or use their individuals who had to bring a test offered access and viewed their online EHI. A Certified API Developer is result to an appointment). This resulted medical record using smartphone health permitted to charge fees to an API in an estimate of 50.2 million applications in 2019. The proportion of Information Source related to the use of Americans who bring test results to a individuals accessing their online certified API technology. The fees must doctor’s appointment each year. We medical records using smartphone be limited to the recovery of recognize that not all of these health applications is expected to grow incremental costs reasonably incurred individuals will have the capability to as APIs become more widespread. This by the Certified API Developer when it access an online medical record using a will result in cost savings to patients. hosts certified API technology on behalf smartphone health application. Specifically, patients who use new of the API Information Source Therefore, we discounted this estimate applications to access copies of their (§ 170.404). Thus, patients would based on the proportion of individuals medical record instead of contacting ultimately see cost savings by accessing who currently access their online their provider will have cost savings. their online medical record using a medical records using a smartphone Under the HIPAA Privacy Rule, smartphone health application instead health applications (14 percent), as our individuals have the right to access their of contacting their provider for an lower bound. Our upper bound is the Protected Health Information (PHI) (45 electronic copy. proportion of individuals who reported CFR 164.524), and 45 CFR 164.524(c)(4) To identify the potential cost savings being offered access to an online sets forth implementation specifications this rule will have for patients, we used medical record by a health care provider for fees that covered entities may charge data from the Health Information or insurer (58 percent). These individuals for access to their PHI. National Trends Survey to estimate the calculations are in Table 22.

233 These estimates were derived from Health Information National Trends Survey 5, Cycle 1 (2017).

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00284 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25925

TABLE 22—BENEFIT OF API ON PATIENTS HAVING ACCESS TO THEIR HEALTH INFORMATION [2017 Dollars]

Proportion of Total benefit Benefit type Number affected individuals impacted Total cost savings Min Max Min Max

Cost savings to patients for requesting 50,156,010 a pa- 14% b .... 58% b .... $6.50 c per patient $45.8 million per $189.8 million per an electronic copy of their medical tients. year. year. record. a This represents the number of individuals who had to bring a medical test result to an appointment with a health care provider in the past year. Calculation: US Population on December 31, 2017 (325.9M)*81 percent who saw a doctor in the past year*19 percent who had to bring a test result to an appointment. Sources: (1) https://www.census.gov/popclock/; (2) https://dashboard.healthit.gov/quickstats/pages/consumers- gaps-in-information-exchange.php. b Lower bound represents the proportion of individuals nationwide who were offered access to their online medical record by a health care pro- vider or insurer. Upper bound represents the proportion of individuals nationwide who were offered access and subsequently viewed their online medical record using a smartphone health app. Source: Johnson C. & Patel V. The Current State of Patients’ Access and Using their Electronic Health Information. Presented at the ONC Annual Meeting on January 27, 2020. c We assume that providers charge individuals a flat fee for all requests for electronic copies of PHI maintained electronically, provided the fee does not exceed $6.50, inclusive of all labor, supplies, and any applicable postage.

Based on the above calculations, we rationale to substantiate our approach authentication credentials or support estimated the annual benefit to health and we updated estimates to 2017 multi-factor authentication (MFA). care providers for the use of these API dollars. Instead, we have required that they capabilities would, on average, range (iv) New Privacy and Security attest to whether or not they support the from $6.7 million to $140 million. We Certification Criteria certification criteria. By requiring an estimated the annual benefit due to attestation, we are promoting improved health outcomes would, on As specified in section IV.C.3 of this transparency, which might motivate average, range from $287 million to $1.1 final rule, we have adopted two new some health IT developers that do not billion. We estimated the annual benefit privacy and security transparency currently encrypt authentication attestation certification criteria in to patients having access to their online credentials or support MFA to do so. If medical record would, on average, range § 170.315(d)(12) and (13) that are part of health IT developers are motivated by from $45.8 million and $189.8 million. the 2015 Edition privacy and security Therefore, we estimated the total annual certification framework. The criteria these criteria and ultimately do encrypt benefit of APIs, on average, to range will serve to identify whether certified authentication credentials and/or from $0.34 billion to $1.43 billion. health IT supports encrypting support MFA, we acknowledge that Comments. We did not receive authentication credentials and/or multi- there would be costs to do so; however, comments specific to our approach to factor authentication (MFA). They do we assume that the benefits will estimating the benefits of API support. not require new development or substantially exceed the costs. Such Response. We have maintained our implementation to take place in order to encryption and adopting MFA would overall approach for the costs and be met. However, certification to these reduce the likelihood that benefits associated with the API criteria will provide increased authentication credentials would be provisions of this rule. As discussed in transparency and, perhaps, motivate the compromised and would eliminate an section IV.B.7 of this final rule small percentage of health IT developers unnecessary use of IT resources. preamble, we have added a new that do neither to encrypt authentication Encrypting authentication credentials requirement in the finalized credentials and/or support multi-factor and adopting MFA could directly § 170.315(g)(10) that gives patients the authentication, which will help prevent reduce providers’ operating and support capability to revoke access to an exposure to unauthorized persons/ costs, which will reduce their authorized application. Cost estimates entities. administrative and financial burden. for this new requirement were added to (A) Costs Encrypting authentication credentials cost tables 16 A and 16 B as task six. will also help decrease costs and The task of meeting this additional Comments. We did not receive any burdens by reducing the number of finalized requirement increased the comment specific to any method we password resets due to possible overall cost estimate for the API could use to quantify the costs of the phishing or other vulnerabilities. provisions by $9.8 million to $43 new privacy and security certification million. Due to this increase in cost, we criteria, encrypt authentication According to Verizon’s 2017 Data re-evaluated our benefits estimates credentials (§ 170.315(d)(12)) and multi- Breach Investigations Report, 81 percent associated with increasing patients’ factor authentication (MFA) (§ 170.315 of hacking-related breaches leveraged access to their health information. In the (d)(13)), and requiring health IT either stolen and/or weak passwords.234 Proposed Rule, we qualitatively developers to assess their Health IT The Verizon report encourages discussed benefits of patients having Modules’ capabilities and attest ‘‘yes’’ or customers to vary their passwords and increased access to their health ‘‘no’’ to the certification criteria. use two-factor authentication. Also, information. However, upon further Response. We have maintained our National Institute of Standards and consideration, and additional data estimates of the costs of this provision Technology (NIST) Special Publication sources, we were able to estimate cost in the final rule. 800–63B: Digital Identity Guidelines, savings to patients for requesting Authentication and Lifecycle electronic copies of their medical (B) Benefits record. These estimates are reflected in As stated previously, we have not 234 https://enterprise.verizon.com/resources/ Table 22. We provided additional required health IT developers to encrypt reports/2017_dbir.pdf.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00285 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25926 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

Management,235 recommends the use of, capabilities and attest ‘‘yes’’ or ‘‘no’’ to tagging requirements under these and provides the requirements for the certification criteria. criteria. We anticipate developers will multi-factor authenticators. Response. We maintain our estimates need approximately 1,500 to 2,500 Based on these reports and other of the costs and benefits of this hours to upgrade databases and/or other anecdotal evidence, we believe provision in the final rule. We also backend infrastructure to appropriately encrypting authentication credentials continue to believe that the adoption of apply security tags to data and/or and supporting MFA are established these criteria will motivate these health develop access control capabilities. best practices among industry IT developers to speed their Moreover, developers will likely incur developers, including health IT implementation process. costs to upgrade health IT to generate a developers. As described above, in this (v) Security Tags—Summary of Care— security-labeled C–CDA conforming to final rule, we required health IT Send and Security Tags—Summary of the DS4P standard. We estimated developers to attest to whether they Care—Receive developers will need 400 to 600 hours encrypt authentication credentials. We per criterion to make these upgrades on do not have access to published In this final rule, we updated the 2015 systems that had previously certified to literature that details how health IT Edition Data Segmentation for Privacy the document-level DS4P criteria, or 720 developers are already encrypting (DS4P) certification criteria in to 1220 hours per criterion for systems authentication credentials and § 170.315(b)(7) and (8) to support a more that are implementing these criteria for supporting MFA industry-wide, but we granular approach to privacy tagging the first time. We believe this work believe most health IT developers, or data for health information exchange. would be performed by a ‘‘Software around 80 percent, are taking such We also renamed the criteria to reduce Developer.’’ According to the May 2017 actions. We assume that building this confusion and better align with the BLS occupational employment functionality is in the future project criteria, ‘‘Security tags—Summary of statistics, the mean hourly wage for Care—send’’ and ‘‘Security tags— plans for the remaining 20 percent software developer is $53.74. As noted Summary of Care—receive.’’ The criteria because, as noted previously, adopting previously, we have assumed that will remain based on the C–CDA and these capabilities is an industry best overhead costs (including benefits) are the HL7 DS4P standard. These criteria practice. Health IT developers that have equal to 100 percent of pre-tax wages, so will include capabilities for applying not yet adopted these capabilities are the hourly wage including overhead the DS4P standard at the document, likely already making financial costs is $107. Therefore, we estimated section, and entry level. In the Proposed investments to get up to speed with the total cost to developers could range Rule, we proposed to adopt a third 2015 industry standards. We believe the from $2,910,400 to $6,933,600. We note Edition DS4P certification criterion, adoption of these criteria will motivate that this would be a one-time cost. The ‘‘consent management for APIs’’ these health IT developers to speed their midpoint of ranges stated is used as the (§ 170.315(g)(11)), that requires health implementation process, but we have primary estimate of costs. IT to be capable of responding to not attributed a monetary estimate to Additionally, we proposed that the requests for data through an API in this potential benefit because our rule is health IT support the capability to accordance with the Consent not a direct cause of health IT respond to requests for patient consent Implementation Guide, which we did developers adopting these capabilities. information through an API compatible not finalize. We anticipate that when we release this with FHIR Release 3. However, we did final rule, many more, or perhaps all, (A) Costs not finalize that proposal. Therefore, we health IT developers will likely already did not include an estimate in this final be encrypting authentication credentials We anticipate these updated criteria will result in up-front costs to health IT rule. and supporting MFA. We welcomed We have estimated costs using the comments on this expectation and any developers as health IT would be required to support all three levels— following assumptions: means or methods we could use to • document, section, and entry—as For the two Security tags— quantify these benefits. Summary of Care criteria, we anticipate Comments. We did not receive any specified in the current DS4P standard. developers will need approximately comment specific to any means or However, we note that these criteria are 1,500 to 2,500 hours to upgrade methods we could use to quantify the not being required in any program at databases and/or other backend costs and benefits of having the new this time. As of the beginning of the infrastructure to appropriately apply privacy and security transparency fourth quarter of the 2019 calendar year, security tags to data and/or develop attestation certification criteria, encrypt only about 30 products (products with access control capabilities. We expect authentication credentials multiple certified versions were counted that this would be a one-time cost. (§ 170.315(d)(12)) and multi-factor once) were certified to the current 2015 • According to the May 2017 BLS authentication (MFA) (§ 170.315(d)(13)), Edition DS4P certification criteria. We occupational employment statistics, the and requiring health IT developers to estimated that 10 to 15 products will mean hourly wage for a ‘‘Software assess their Health IT Modules’ implement the new DS4P criteria. Developers may need to perform fairly Developer’’ is $53.74. Our cost estimates are explained in 234 https://enterprise.verizon.com/resources/ extensive health IT upgrades to support reports/2017_dbir.pdf. the more complex and granular data the Table 23.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00286 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25927

TABLE 23—COSTS RELATED TO SECURITY TAGS—SUMMARY OF CARE CRITERIA [2017 Dollars]

Tasks Lower bound Upper bound Remarks

Task 1: Enhancements to health IT to upgrade data- 1,500 hours ...... 2,500 hours ...... This is a one-time cost for health IT systems to bases and/or other backend infrastructure to ap- support data segmentation for discrete data. propriately apply security tags to data and/or de- velop access control capabilities. Total Labor Hours ...... 1,500 hours ...... 2,500 hours.

Hourly Rate ...... $107 per hour

Cost per Product ...... $160,500 ...... $267,500. Total Cost (23 products) ...... $3,691,500 ...... $6,152,500.

We believe the voluntary nature of documents. Implementing security tags Security tags—Summary of Care— these criteria would significantly enables providers to more effectively receive), the developer costs were mitigate health IT developer costs. We share patient records with sensitive estimated for supporting DS4P IG also expect developers to see a return on information, thereby protecting patient enhancements to include tagging the their investment in developing and privacy while still delivering actionable data at the section and entry level when preparing their health IT for these clinical content. We emphasize that exchanged using the C–CDA. The lower certification criteria given the benefits to health care providers already have bound estimates include developers interoperable exchange. processes and workflows to address who are already supporting the DS4P IG We anticipate potential costs for ONC their existing compliance obligations, for tagging data at ‘‘document’’ level and related to the updated DS4P criteria which could be made more efficient and estimates additional effort to support (Security tags—Summary of Care—send cost effective through the use of health tagging at ‘‘section’’ and ‘‘entry’’ level. and Security tags—Summary of Care— IT. We expect these benefits for The criteria do not require the capability providers, patients, and ONC to be receive) associated with: (1) Developing to segment the data, only to tag the data. and maintaining information regarding significant; however, we are unable to these updated criteria on the ONC quantify these benefits at this time The certification criteria does not website; (2) creating documents related because we do not have adequate make any additional expectations to these updated criteria and making information to support quantitative around compliance beyond what the those documents 508 compliant; (3) estimates. We welcomed comments providers are currently expected to do, updating, revising, and supporting regarding potential approaches for nor does it add any additional Certification Companion Guides, test quantifying these benefits. requirements for developers around procedures, and test tools; and (4) Comments. Several commenters how they handle the data received with responding to inquiries concerning indicated there would be cost burden the tags. Therefore, we disagree with the these criteria. We estimate an ONC associated with our proposal of commenters about underestimating the analyst at the GS–13, Step 1 level staff adopting two new DS4P certification cost. Rather, the commenters may be would devote, on average, 200 hours to criteria and a consent management for suggesting implementation costs which the above tasks annually. The hourly API criterion. Commenters stated that are beyond the costs associated with the wage with benefits for a GS–13, Step 1 ONC needs to quantify and include the certification criteria itself. These costs employee located in Washington, DC is cost of this burden in our impact are unquantifiable and are noted in approximately $91. Therefore, we analysis section. Another commenter Table 31. estimate the annual costs to be $18,200. conducted their own analysis and indicated a cost of $5–6 billion with a (3) Conditions and Maintenance of (B) Benefits multi-year implementation timeframe. Certification Requirements We believe leveraging the DS4P Commenters stated there could be (i) Information Blocking standard’s ability to allow for both significant upfront costs and ongoing document level and more granular costs for maintenance of the systems For a discussion of the costs and tagging would offer functionality that is necessary to comply with these criteria benefits of the exceptions to information more valuable to providers and patients, and one commenter further explained blocking, please see section (5) of this especially given the complexities of the that segmenting data at the document, RIA. privacy landscape for multiple care and section, and entry level as opposed to specialty settings. The updated DS4P the document level only, would (ii) Assurances criteria (Security tags—Summary of significantly increase costs and could Care—send and Security tags— potentially impact system performance. In this final rule, we included a Summary of Care—receive) would One commenter was specifically provision that requires health IT benefit providers, patients, and ONC concerned that the proposal would developers to make certain assurances because it would support more broadly impact HIEs both in terms of as Conditions and Maintenance of complete records, contribute to patient administration and implementation but Certification requirements: (1) safety, and enhance care coordination. did not state specifics. Assurances regarding the ‘‘EHI export’’ We believe this will also reduce burden Response. We thank commenters for certification criterion in § 170.315(b)(10) for providers by enabling an automated their input. We did not finalize the and (2) assurances regarding retaining option, rather relying on case-by-case consent management for API criterion. records and information in manual redaction and subsequent For the DS4P-related criteria (Security 170.402(b)(1)(i)–(ii). workarounds to transmit redacted tags—Summary of Care—send and

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00287 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25928 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

(A) Electronic Health Information As stated in the Proposed Rule, estimated that a health IT developer’s Export currently, there are no existing office clerk will commit (overall) Alongside the criterion revisions in regulatory requirements regarding approximately 40 hours to drafting and § 170.315(b)(10), we have finalized in record and information retention by mailing notices when necessary. § 170.402(a)(4), that a health IT health IT developers. We expect there According to the May 2017 BLS developer of a certified health IT are costs to developers to retain the occupational employment statistics, the records and information described mean hourly wage for an office clerk is Modules that is part of a health IT 237 product which electronically stores EHI above but they may be mitigated due to $16.30. As noted previously, we have must certify to the certification criterion other factors. For example, we expect assumed that overhead costs (including that health IT developers are already in § 170.315(b)(10). We have finalized in benefits) are equal to 100 percent of pre- keeping most of their records and tax wages, so the hourly wage including § 170.402(b)(2) that within 36 months information in an electronic format. We overhead costs is $32. Therefore, we from the final rule’s publication date, a also expect that some developers may estimated the annual cost per developer health IT developer that must comply already be retaining records and to be $1,280 and the total cost for all with the requirements of paragraph information for extended periods of health IT developers (792 health IT § 170.402(a)(4) of this section must time due to existing requirements of developers certified to the 2014 Edition) provide all of its customers of certified other programs, including for those to be $1 million. We note that a health IT with the health IT certified to programs their customers participate in. developer must notify all customers the certification criterion in For instance, Medicaid managed care annually until any contracts § 170.315(b)(10). We also finalized that companies are required to keep records contravening the Condition are on and after 36 months from the for 10 years from the effective date of a amended. publication of this final rule, health IT contract. We also note that mailing is one developers that must comply with the We estimated that each health IT option for delivery, along with other requirements of § 170.402(a)(4) must developer will, on average, spend two means such as email. We do not have provide all of their customers of hours each week to comply with our information concerning how health IT certified health IT with health IT proposed record retention requirement. developers will deliver their notices. We certified to § 170.315(b)(10). In addition, We expect that a health IT developer’s have estimated a total cost for all a health IT developer must attest office clerk could complete the record developers to mail the initial notices accurately in accordance with retention responsibilities. According to (including postage) to be $80,000. As § 170.402(a)(4) and (b)(2) if the Health the May 2017 BLS occupational noted above, this notice may have to be IT Module presented for certification is employment statistics, the mean hourly provided annually, depending on when part of a heath IT product which can wage for an office clerk is $16.30.236 As contracts contravening this provision electronically store EHI. If the product noted previously, we have assumed that are amended. stores such information, the health IT overhead costs (including benefits) are In order to meet the Cures Act developer must ensure all EHI is equal to 100 percent of pre-tax wages, so requirement that health IT developers available for export in accordance with the hourly wage including overhead do not prohibit or restrict § 170.315(b)(10). costs is $32. communication regarding health IT, For a detailed discussion of the costs Therefore, we estimated the annual some health IT developers will and benefits of the assurances regarding cost per developer on average, would be eventually need to amend their the criterion in § 170.315(b)(10), please $3,328 and the total annual cost for all contracts to reflect such a change. Many see section (2)(ii) (EHI export) of this health IT developers (458 health IT standard form health IT contracts limit RIA above. developers have products certified to the ability of users to voluntarily (B) Records and Information Retention the 2015 Edition that are capable of discuss problems or report usability and recording patient health data) on safety concerns that they experience As a Maintenance of Certification average, would be $1.5 million. We note when using their health IT. This type of requirement in § 170.402(b)(1), a health that this is a perpetual cost. discussion or reporting is typically IT developer must, for a period of 10 prohibited through broad years beginning from the date of (iii) Prohibition or Restriction of Communications confidentiality, nondisclosure, and certification, retain all records and intellectual property provisions in the information necessary that demonstrate (A) Costs developer’s standard form health IT initial and ongoing compliance with the Health IT developers need to notify contract. Some standard form health IT requirements of the ONC Health IT their customers about the contracts may also include non- Certification Program. In an effort to unenforceability of communications and disparagement clauses that prohibit reduce administrative burden, we also contract provisions that violate the customers from making statements that finalized that in situations where Communications Condition of could reflect negatively on the health IT applicable certification criteria are Certification requirements in developer. These practices are often removed from the Code of Federal § 170.403(a). Generally, health IT referred to colloquially in the industry Regulations before the 10 years have developers already have mechanisms in as ‘‘gag clauses.’’ We expect expired, records must only be kept for place, whether via online postings, amendments to these clauses to be three years from the date of removal for email, mail, or phone, for alerting accomplished in the normal course of those certification criteria and related customers to changes in their policies business, such as when renegotiating Program provisions unless that and procedures. Such alerts should be contracts or updating them for HIPAA timeframe would exceed the overall 10- standard practice. However, we have Rules or other compliance requirements year retention period. This ‘‘three-year estimated the potential costs for health outside of the ONC Health IT from the date of removal’’ records IT developers to draft the notice and Certification Program. As such, we do retention period also aligns with the mail the notice as appropriate. We not estimate any direct or indirect costs records retention requirements for ONC–ACBs and ONC–ATLs under the 235 https://pages.nist.gov/800-63-3/sp800- 237 See https://www.bls.gov/oes/2017/may/ Program. 63b.html. oes439061.htm.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00288 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25929

for health IT developers to amend their § 170.315(g)(10), please see section deployed health IT products in contracts to comply with this Condition (2)(iii) of this RIA. operational production settings are of Certification requirement. (A) Transparency Requirements for demonstrating compliance to (B) Benefits Application Programming Interfaces certification criteria and functioning with the intended use cases for We expect health care providers to In this final rule, as part of the continued maintenance of certification benefit from this provision. There is Conditions and Maintenance of requirements. Real world testing should growing recognition that these practices Certification requirements in § 170.404, ensure certified health IT products have of prohibiting or restricting we have required that API Technology communication do not promote health Suppliers make specific business and the ability to share electronic health IT safety or good security hygiene and technical documentation necessary to information between systems. Real that health IT contracts should support interact with the APIs in production world testing should assess that the and facilitate the transparent exchange freely and publicly accessible. We certified health IT is meeting the of information relating to patient care. expect that the API Technology intended use case(s) of the certification We were unable to estimate these Suppliers will perform the following criteria to which it is certified within benefits because we do not have tasks related to transparency of business the workflow, health IT architecture, adequate information to determine the and technical documentation and would and care/practice setting in which the prevalence of gag clauses and other devote the following number of hours health IT is implemented. We note that restrictive practices, nor do we have a annually to such tasks: (1) Health Level we expect real world testing would take means to quantify the value to providers 7’s (HL7®) Fast Healthcare about three months of the year to of being able to freely communicate and Interoperability Resources (FHIR®) API perform. share information. We welcomed documentation (the developer would comments on approaches to quantify most likely point to the HL7 FHIR (A) Costs these benefits. standard for API documentation) This section describes the potential Comments. We did not receive (estimated eight hours); (2) patient costs of the real world testing comments specific to our approach of application registration documentation, quantifying the benefits of our provision which will include a development effort requirements in this final rule. The costs to inform customers regarding the to create a website that manages the estimates are based on the following prohibition or restriction of application registration activity assumptions: communications. We did receive several (estimated 40 hours); (3) publication of • Health IT developers will use the comments stating that our notification the FHIR Endpoint—Base URLs for all same labor costs. Table 24 shows the and contract revision estimates centrally managed providers (estimated estimated labor costs for a health IT underestimate the volume of agreements 40 hours); (4) publication of FHIR developer to perform real world testing. for large developers and the cost of Endpoints for provider-managed APIs We recognize that health IT developer compliance. We also received several (estimated 160 hours); and (5) API cost costs will vary; however, our estimates comments that the burden for revising information documentation, which will in this section assume all developers contracts could be significant and typically be documented as a tiered rate will incur the costs noted in Table 24. costly, particularly in the timeframe based on usage or some form of monthly • originally proposed, with one comment rate (estimated 40 hours). Proxy needed to project the number adding that the cost for revising We believe each of the above tasks of 2015 Edition products impacted by contracts should be included in the would be performed by a ‘‘Software real world testing. We estimated that impact analysis. Developer.’’ According to the May 2017 523 products from 429 developers will Response. We maintain that we were BLS occupational employment be impacted by real world testing. We unable to estimate the benefits of the statistics, the mean hourly wage for used a proxy to determine developers provision due to inadequate information software developer is $53.74.238 As that would be subject to real world however, we believe that prohibiting or noted previously, we have assumed that testing. There were 681 products and restricting communication does not overhead costs (including benefits) are 551 developers with at least one of its promote health IT safety or good equal to 100 percent of pre-tax wages, so 2014 Edition certified products that security hygiene and that health IT the hourly wage including overhead could perform transitions of care and/or contracts should support and facilitate costs is $107. Therefore, we estimated send any type of public health data. We the transparent exchange of information the cost per developer to be $30,816. As then multiplied these numbers by our relating to patient care. We maintain our noted in section (2)(iii) of this RIA, we estimates for certified health IT market notification estimates as we believe that estimated that 459 products from 394 consolidation by ¥22.1 percent and large developers would have efficient developers will contain the API ¥23.2 percent to project the number of means of sending notifications i.e. by criterion. Therefore, we estimated the email. We reiterate that we expect total developer cost would be $12.1 2015 developers and products, revision of contracts to be accomplished million. We note that this is a one-time respectively. We believe this estimate in the normal course of business and do cost and would not be perpetual. We serves as a reasonable proxy for not estimate any direct or indirect costs did not receive comments on this products impacted by real world testing, for health IT developers to amend their discussion and have therefore finalized as these products primarily focus on contracts to comply. our figures. interoperability. (iv) Application Programming Interfaces (v) Real World Testing The tables below describe the various costs to health IT developers to perform For a discussion of the costs and The objective of real world testing in real world testing by task. benefits of the new API criterion in § 170.405 is to verify the extent to which

238 See https://www.bls.gov/oes/2017/may/ oes439061.htm.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00289 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25930 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

TABLE 24—ESTIMATED COST TO HEALTH IT DEVELOPERS TO PERFORM REAL WORLD TESTING [2017 Dollars]

Tasks and labor category Hours Rate Total

Task 1: Design Real world Testing Approach and Submit Plan (per developer) ...... $34,560 15–1133 Software Developers, Systems Software ...... 80 107 8,560 15–1143 Computer Network Architects ...... 120 104 12,480 15–1121 Computer Systems Analysts ...... 80 89 7,120 15–1199 Computer Occupations, All Other ...... 40 88 3,520 27–3042 Technical Writers ...... 40 72 2,880 Task 2: Prepare Staff and Environments (per developer) ...... 14,920 15–1121 Computer Systems Analysts ...... 40 89 3,560 15–1142 Network and Computer Systems Administrators ...... 40 83 3,320 15–1152 Computer Network Support Specialists ...... 40 65 2,600 15–1199 Computer Occupations, All Other ...... 40 88 3,520 15–1122 Information Security Analysts ...... 20 96 1,920 Task 3: Perform Testing (per product) ...... 32,240 15–1121 Computer Systems Analysts ...... 80 89 7,120 15–1133 Software Developers, Systems Software ...... 40 107 4,280 15–1199 Computer Occupations, All Other ...... 160 88 14,080 15–1142 Network and Computer Systems Administrators ...... 40 83 3,320 15–1141 Database Administrators ...... 40 86 3,440 Task 4: Collect Results and Prepare-Submit Report (per developer) ...... 20,560 15–1199 Computer Occupations, All Other ...... 120 88 10,560 15–1121 Computer Systems Analysts ...... 80 89 7,120 27–3042 Technical Writers ...... 40 72 2,880

Total Labor Hours ...... 1,140 Other Direct Costs—printing, publishing (per product) ...... 150.00

TABLE 25—REAL WORLD TESTING TOTAL ANNUAL COST [2017 Dollars]

Task Calculation Total cost

Task 1 ...... $34,560 * 429 developers ...... $14,826,240 Task 2 ...... $14,920 * 429 developers ...... 6,400,680 Task 3 ...... $32,240 * 523 products ...... 16,861,520 Task 4 ...... $20,560 * 429 developers ...... 8,820,240 Other Direct Costs ...... $150 * 523 products ...... 78,450

Total Cost ...... 46,987,130

Based on the stated assumptions and complained about their EHR system, Interoperability Programs will be costs outlined in the above tables, we time saved documenting in their EHR impacted. Estimates were based on the estimated the total annual cost for real due to improved usability; for providers assumption that 439,187 health care world testing would, on average, be $47 that are dissatisfied with their EHR, providers and/or 4,519 hospitals will be million with an average cost per increased provider satisfaction resulting affected by this regulatory action. developer of $109,557. in fewer providers incurring the costs of • Estimates of the impact of real switching products; and benefits related world testing on rates of interoperability (B) Benefits to reductions in duplicate lab tests, (0.1 to 1 percent) are based on ONC There are several benefits that can be readmissions, ER visits, and adverse analysis. To identify the impact of real attributed to real world testing. Real drug events due to increased world testing on interoperability, we world testing may impact the effective interoperability. We focused on these used regression analysis. Specifically, integration of varied health IT systems, outcomes for two reasons: (i) Evidence we estimated linear probability models including integration of certified health in literature indicates that health that identified impact of 2014 Edition IT with non-certified and ancillary information exchange impacts the certified EHR on hospitals’ technologies such as picture archiving chosen measures; and (ii) cost of care interoperability (whether a hospital and communications systems (PACS) or associated with these measures is high sends, receives, finds, and integrates specialty-specific interfaces. This could and the impact of health information summary of care records). Using data result in greater interoperability among exchange is likely to result in significant from the AHA from years 2014 and 2015 health IT systems. For providers that are benefits in the form of reduced costs. in the model, we controlled for hospital currently dissatisfied with how their The benefit calculations were based size, profit status, participation in a health IT is performing, real world on the following assumptions: health information organization, and testing might also influence the effective • Benefits noted in academic state and year fixed effects. The implementation of workflows in a literature are assumed accurate and marginal effect of using a 2014 Edition clinical setting. In this analysis, we results were not externally validated. was a five percentage point increase in calculated the benefits in the following • Hospitals and eligible professionals interoperability. This is an upper bound categories: For providers that have that participate in the CMS Promoting estimate. For the purpose of this

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00290 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25931

analysis, we assume 0.1 percent to 1 that might be underperforming. We assumed that this marginal effect percent would be a reasonable range for Therefore, we estimated that the is true for our provisions and real world testing to impact providers impacted by this rule are distributed the five percent benefit interoperability. limited to the proportion of providers across our real world testing and API • Impact of real world testing is also that have issued complaints about their provisions at (0.1 to 1 percent) to (1 to based on the estimated number of system to ONC. 4 percent) respectively. Moreover, the providers that switch health IT As noted previously in this analysis, number of providers impacted is developers (rate = five percent) and are we acknowledge that there might be provision specific. Given data dissatisfied with their current EHR (44 shared benefits across certain provisions limitations, we believe this approach percent). To calculate the number of and have taken steps to ensure that the allows us to estimate the benefits of our providers that are likely to switch their provisions without double counting the EHR due to dissatisfaction with their benefits attributed to each provision are unique to the provision referenced. impact each provision might have on system, we estimate the rate of interoperability. switching using CMS Medicare EHR Specifically, we used regression Incentive Program data from years 2013 analysis to calculate the impact of our Table 26 shows the benefits of real to 2016. This results in 4,774 clinical real world testing and API provisions on world testing for providers. We practices and 226 hospitals that are interoperability. We assumed that the quantified the monetary benefits of real projected to switch products in a year. real world testing and API provisions world testing based on a reduction in We then leverage results from Stanford would collectively have the same the amount of time a provider spends on Medicine’s research conducted by The impact on interoperability as use of their EHR by improving its usability or Harris Poll which reports that nearly 44 2014 Edition certified health IT. the cost-savings associated with percent of providers are not satisfied Therefore, we estimated linear switching from an underperforming with their EHR.239 Based on this probability models that identified the EHR system. Note, these benefits are research, we assume that approximately impact of 2014 Edition certified health limited to providers who have 2,195 providers are less likely to switch IT on hospitals’ interoperability.240 We expressed dissatisfaction with their EHR their EHR with real world testing. controlled for additional factors such as and only represent a fraction of all • Estimates of the rate of eligible participation in a health information health care providers. Table 27 professionals (10 percent) and hospitals exchange organization, hospital quantifies the benefits associated with (five percent) that will be impacted by characteristics, and urban/rural status. improved interoperability for these real world testing are based on ONC We found the marginal effect of using providers. This is primarily because complaint data. We recognize that the 2014 Edition certified health IT was a provider behavior is more directly benefits of real world testing are limited five percentage point increase in affected by improvements in to those providers that have systems interoperability. interoperability. TABLE 26—BENEFIT OF REAL WORLD TESTING FOR PROVIDERS [2017 Dollars]

C Hours saved Number of Total benefit Number (percent) AB Hours per day Benefit type affected Hourly wage with EHR working days Min Max in a year Min Max

Reduction in provider time 43,919 pro- $97.85 1 5 6 E 260 $65 million $335 million spent in health IT by im- viders or per year. per year. proving usability and 10% D (based interoperability. on complaint data). Number of providers 2,195; Cost of ...... $34M per $158M per switching health IT F. Switching. year. year. Min = $15,000 Max = $70,000

Total Benefit ...... $99M per $493M per year. year. A Julia Adler-Milstein and Robert S. Huckman, The Impact of Electronic Health Record Use on Physician Productivity, Am J Manag Care (Nov. 19, 2013). B Amusan, Tongen, Speedie, and Mellin, A time-motion study to evaluate the impact of EMR and CPOE implementation on physician efficiency, J. Healthcare Inf. Manag. (Fall 2008), at 31–7. C Total benefits for the provider and administrative time spent in health IT by improving usability and interoperability. Total benefits from switching EHR developer is a product of the number providers switching and cost of EHR. D The estimate is based on the number of providers that currently possess products with complaints. This is identified by flagging health IT developers and products about whom/which complaints are logged on ONC’s database. These health IT developers are then matched to physicians using the Meaningful Use database. E Christine Sinsky et al., Allocation of Physician Time in Ambulatory Practice: A Time and Motion Study in 4 Specialties, Ann Intern Med. (Dec. 6, 2016), at 753–60. Physician Practice, Calculating the Right Number of Staff for Your Medical Practice, available at http://www.physicianspractice.com/blog/calculating-right-number-staff- your-medical-practice. F This estimate was obtained from Meaningful Use data from years 2013–2016. ‘‘Switching’’ is defined as an annual change in all health IT developers by providers/ hospitals.

239 How Doctors Feel About Electronic Health http://med.stanford.edu/content/dam/sm/ehr/ 240 American Hospital Association Health IT Records National Physician Poll by The Harris Poll documents/EHR-Poll-Presentation.pdf. Supplement Survey, http://www.ahadata.com/aha- healthcare-database.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00291 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25932 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

TABLE 27—BENEFIT OF REAL WORLD TESTING FOR PATIENTS AND PAYERS [2017 Dollars]

A Overall interop Impact of real world testing Percentage of Total benefit Benefit type Population impact Total cost total cost affected (marginal Min Max Min Max effect) impacted

Duplicate testing 35,607 providers B 0.09 0.001 0.01 $200 billion C ..... 10 $1.9 million per $18.5 million per year. year. Avoidable hos- 5% of hospitals B 0.09 0.001 0.01 $41 billion D ...... 5 $0.2 million per $1.9 million per pitalizations (n = 226). year. year. and readmis- sions. ER visits ...... 5% of visits af- B 0.03 0.001 0.01 $1,233, Per ER 5 $0.2 million per $2.54 million per fected (n = visit E. year. year. 131 million). Adverse drug 5% of events af- F 0.22 0.001 0.01 $30 billion G ...... 5 $0.3 million per $3.4 million per events. fected. year. year.

Total Benefit ...... $2.6 million ...... $26.3 million. A Total benefit is a product of total cost, percent of total cost impacted, overall impact of interoperability, and impact of real world testing. B Stephen E. Ross, Tiffany A. Radcliff, William G. Leblanc, L. Miriam Dickinson, Anne M. Libby, and Donald E. Nease Jr., Effects of health information exchange adoption on ambulatory testing rates, J. Am. Med. Inform. Assoc. (2013), at 1137–1142; Bridget A. Stewart, Susan Fernandes, Elizabeth Rodriguez-Huertas, and Mi- chael Landzberg, A preliminary look at duplicate testing associated with lack of electronic health record interoperability for transferred patients, J. of the Am. Med. Informatics Assoc. (2010), at 341–344; Sezgin Ayabakan, Indranil R. Bardhan, Zhiqiang (Eric) Zheng, and Kirk Kirksey Value of health information sharing in reducing healthcare waste: An analysis of duplicate testing across hospitals, MIS Quarterly (Jan. 1, 2017); Eric J. Lammers, Julia Adler-Milstein, and Keith E. Kocher, Does health information exchange reduce redundant imaging? Evidence from emergency departments, Med Care (Mar. 2014), at 227–34. C National Academy of Medicine. (2016), http://money.cnn.com/2017/05/20/news/economy/medical-tests/index.html. D Agency for Healthcare Research and Quality (AHRQ) Statistical Brief #199 (Dec. 2015), https://www.hcup-us.ahrq.gov/reports/statbriefs/sb199-Readmissions- Payer-Age.pdf; AHRQ Statistical Brief #72, Nationwide Frequency and Costs of Potentially Preventable Hospitalizations (Apr. 2009), https://www.hcup-us.ahrq.gov/re- ports/statbriefs/sb72.pdf. E National Center for Health Statistics (NCHS) Data Brief No. 252 (June 2016), https://www.cdc.gov/nchs/data/databriefs/db252.pdf; Nolan Caldwell, Tanja Srebotnjak, Tiffany Wang, and Renee Hsia, ‘‘How Much Will I Get Charged for This?’’ Patient Charges for Top Ten Diagnoses in the Emergency Department (2013), https://doi.org/10.1371/journal.pone.0055491. F M.F. Furukawa, W.D. Spector, M.R. Limcangco, and W.E. Encinosa, Meaningful use of health information technology and declines in in-hospital adverse drug events, J. of the Am. Med. Informatics Assoc. (2017). G Janet Sultana, Paola Cutroneo, and Gianluca Trifiro`, Clinical and economic burden of adverse drug reactions (Dec. 2013).

Based on the stated assumptions and up with ways to perform real world developers submit real world testing benefits outlined in Table 26, we testing that mitigate provider plans in accordance with estimate the total annual benefit for real disruption. § 170.405(b)(1); (2) reviewing and world testing to providers would range, Comments. We did not receive confirming that applicable health IT on average, from $99 million to $493 comment specific to whether health IT developers submit real world testing million. Based on the stated developers would incur reduced real results in accordance with assumptions and benefits outlined in world testing costs through cloud-based § 170.405(b)(2); and (3) submitting real Table 27, we estimate the total annual deployments as opposed to other world testing plans by December 15 and benefit for patients and payers would deployment methods. We also did not results by March 15 of each calendar range, on average, from $2.6 million to receive comments regarding the ratio of year to ONC for public availability. In $26.3 million. Therefore, we estimate cloud-based to non-cloud based addition, under § 170.523(t), ONC–ACBs the total benefit of real world testing deployments and cost variations will be required to: (1) Maintain a would range, on average, from $101.6 regarding different types of record of the date of issuance and the million to $519.3 million. deployments. We also did not receive content of developers’ notices; and (2) We recognize that health IT comments regarding the burden to timely post content of each notice on developers may deploy their systems in providers in time spent assisting health the CHPL. a number of ways, including cloud- IT developers. Using the information from the ‘‘Real based deployments, and requested Response. We maintain our World Testing Costs’’ section of this comment on whether our cost estimates assumptions and estimates as proposed RIA, we estimated that 429 developers of real world testing should factor in regarding real world testing. will be impacted by real world testing. such methods of system deployment. We estimate that, on average, it will take For example, we requested feedback (C) Real World Testing Maintenance an ONC–ACB employee at the GS–13, about whether health IT developers Requirements Step 1 level approximately 30 minutes would incur reduced real world testing In this final rule, we revised the to collect all updates made to standards costs through cloud-based deployments Principle of Proper Conduct in in Health IT Modules in accordance as opposed to other deployment § 170.523(m) to require ONC–ACBs to with § 170.523(m). The hourly wage methods. We specifically solicited collect, no less than quarterly, all with benefits for a GS–13, Step 1 comment on the general ratio of cloud- updates successfully made to standards employee located in Washington, DC is based to non-cloud-based deployments in certified health IT pursuant to the approximately $91. Since the collection within the health care ecosystem and developers having opted to avail must occur no less than quarterly, we specific cost variations in performing themselves of the Standards Version assume it occurs, on average, four times real world testing based on the type of Advancement Process flexibility under per year. Therefore, we estimate the deployment. We also requested the real world testing Condition of annual cost to ONC–ACBs to comply comment on our assumptions about the Certification requirement. Under with the collection requirements under burden to providers in time spent § 170.523(p), ONC–ACBs will be § 170.523(m) to be $78,078. assisting health IT developers since we responsible for: (1) Reviewing and We estimated that, on average, it will encourage health IT developers to come confirming that applicable health IT take an ONC–ACB employee at the GS–

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00292 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25933

13, Step 1 level approximately one hour Washington, DC is approximately $91. efficiency without additional to review and confirm that applicable This was the hourly rate we used for rulemaking. We have finalized our health IT developers submit real world this RIA, so it is consistent with prior estimates. testing plans in accordance with calculations. This wage is used to (vi) Attestations § 170.405(b)(1). We estimate that, on determine the ONC–ACB time cost to average, it will take an ONC–ACB complete this requirement under The Cures Act requires that a health employee at the GS–13, Step 1 level § 170.523(t). For this estimate, we take IT developer, as a Condition and approximately 30 minutes to review and half the hourly rate and multiply it by Maintenance of Certification confirm that applicable health IT the number of products predicted to requirement under the Program, provide developers submit real world testing certify each of the applicable criteria. to the Secretary an attestation to all the results in accordance with For each criterion, we estimate a lower Conditions and Maintenance of § 170.405(b)(2). We estimate that, on bound and upper bound prediction. The Certification requirements specified in average, it will take an ONC–ACB lower bound assumes that 25 percent of the Cures Act, except for the ‘‘EHR employee at the GS–13, Step 1 level certified products update any of the Reporting Program’’ Condition of approximately 30 minutes to submit real applicable standards. The upper bound Certification requirement. It also world testing plans and results to ONC prediction assumes that all certified requires that a health IT developer attest for public availability. The hourly wage products update any of the applicable that its health IT allows for health with benefits for a GS–13, Step 1 standards. These estimates are information to be exchanged, accessed, employee located in Washington, DC is calculated for each criterion and then and used in the manner described by approximately $91. Therefore, we the cumulative sum of all the individual the API Condition of Certification estimate the annual cost to ONC–ACBs criterion calculations is made. We requirement. We have finalized our to comply with the submission and estimate, at 30 minutes per notice, it proposal to implement the Cures Act reporting requirements under will cost $60,606 if 25 percent of ‘‘attestations’’ requirement in § 170.406 §§ 170.523(m) and 170.550(l) to be certified products update any of the by requiring health IT developers to $156,156. applicable standards across all criteria, attest to the aforementioned Conditions. Throughout the RIA we have used 830 and if all products update any of the For the purposes of estimating the products as our 2015 Edition projection. applicable standards, we estimate it will potential burden of these attestations on We came up with this projection by cost $242,424. Our maximum estimate health IT developers, ONC–ACBs, and multiplying a ¥23.2 percent market for time to comply is one hour per ONC, we estimate that all health IT consolidation rate from the total number notice. developers under the Program will of products certified to 2014 Edition. Using the same methodology submit an attestation biannually. As This assumption was based on the explained above, we estimate, at 60 noted previously in this RIA, there are market consolidation rate observed minutes per notice, it will cost $121,212 792 health IT developers certified to the between the 2011 and 2014 Editions. if 25 percent of certified products 2014 Edition. We have estimated the number of 2015 update any of the applicable standards We estimated it would take a health Edition products that will certify each across all criteria, and if all products IT developer employee approximately criterion included in the real world update any of the applicable standards, one hour on average to prepare and testing Condition of Certification we estimate it will cost $484,848. Our submit each attestation to the ONC– requirement. We assume that there will lower bound estimate for the cost of this ACB. According to the May 2017 BLS be a cost associated with a notice for requirement is $60,606. Our upper occupational employment statistics, the each certified criterion (even if an bound estimate for the cost of this mean hourly wage for a software individual product were to update the requirement is $484,848. developer is $53.74.241 Therefore, we same standard across multiple criteria Comments. We received a comment estimated the annual cost including that use that standard). This estimation recommending that ONC add overhead costs to be $84,744. We have was calculated by multiplying the accountability to the real world testing finalized that attestations will be current percent of 2015 Edition process by having ONC–ACBs review a submitted to ONC–ACBs on behalf of products that certify a criterion by the randomly selected percentage of ONC and the Secretary. We assume estimated number of total 2015 Edition submitted results for potential non- there will be four ONC–ACBs as this is products (830). For example, we conformity with certification the current number of ONC–ACBs, and calculated that 43 percent of 2015 requirements. we also assume an equal distribution in Edition products certified 170.315(b)(1); Response. We thank commenters for responsibilities among ONC–ACBs. we then multiplied this percentage by their input. It is within ONC–ACBs’ ONC–ACBs would have two 830—the predicted number of 2015 rights and interests to randomly select responsibilities related to attestations. Edition products. Thus, based on this certified Health IT Modules that have One responsibility we finalized in calculation, for 2015 Edition, we predict been real world tested as part of their § 170.523(q) is that an ONC–ACB must that 359 products will certify the surveillance activities. ONC will be review attestations for completion and 170.315(b)(1) criterion. This method working closely with ONC–ACBs to submit the health IT developers’ was used across all criteria included in provide direction on how ONC–ACBs attestations to ONC. We estimate it will the real world testing Condition of can leverage existing Program and ISO/ take an ONC–ACB employee at the GS– Certification requirement. IEC 17065 requirements to provide 13, Step 1 level approximately 30 We assume that the amount of time oversight without increasing burden by minutes on average to review and for an ONC–ACB staff person to: (1) setting a minimum expectation in submit each attestation to ONC. The Maintain a record of the date of issuance regulation. Setting a regulatory quota other responsibility we are finalizing in and the content of developers’ notices; could potentially create burden as § 170.550(l) is that an ONC–ACB would and (2) to timely post content of each workloads amongst the different ONC– need to ensure that the health IT notice on the CHPL can be anywhere ACBs vary. Additionally, it limits ONC– developer of the Health IT Module has from 30 minutes to one hour. ACBs to what is adopted in the final The hourly wage with benefits for a rule and prevents future adjustments 241 See https://www.bls.gov/oes/2017/may/ GS–13, Step 1 employee located in that may be needed to improve oes439061.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00293 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25934 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

met its responsibilities related to the the Conditions and Maintenance of two to three analysts at the GS–13 level Conditions and Maintenance of Certification requirements). However, working one to two hours each per Certification requirements as solely we acknowledge that this final rule may complaint. The hourly wage with evidenced by its attestation. We eventually require health IT developers benefits for a GS–13, Step 1 employee estimate it will take an ONC–ACB to correct certain actions or non- located in Washington, DC is employee at the GS–13, Step 1 level conformities with their health IT that do approximately $91. Therefore, we approximately one hour on average to not conform to the Conditions and estimate each review and inquiry will complete this task. The hourly wage Maintenance of Certification cost ONC, on average, between $182 and with benefits for a GS–13, Step 1 requirements. $546. We estimate the total annual cost employee located in Washington, DC is If we identify a non-conforming to ONC will, on average, range from approximately $91. Therefore, we action by a health IT developer, the $18,200 and $109,200. This range takes estimate the annual cost to ONC–ACBs costs incurred by the health IT into account both the low end of to be $108,108. developer to bring its actions into reviews that are resolved quickly and We have finalized that we would conformance will be determined on a the high end in which staff will need to make the attestations publicly available case-by-case basis. Factors that will be discuss issues with ONC leadership or on the CHPL once they are submitted by considered include, but are not limited in some cases, HHS senior leadership the ONC–ACBs. ONC posts information to: (1) The extent of customers and/or including the Office of General Counsel. regularly to the CHPL and we estimate business affected; (2) how pervasive the We have not estimated health IT the added costs to post the attestation action(s) is across the health IT developer costs associated with ONC will be de minimis. developer’s business; (3) the period of review prior to the issuance of a notice Comments. We did not receive time that the health IT developer was of non-conformity because, in most comment specific to the methods related taking the action(s) in question; and (4) cases, health IT developers are not to the estimates for posting attestations. the corrective action required to resolve required to take action prior to the Response. We maintain our the issue. We are unable to reliably notice of non-conformity. assumptions and estimates as proposed estimate these costs as we do not have (D) ONC Review and Inquiry Following regarding attestations. cost estimates for a comparable the Issuance of a Notice of Non- situation. We requested comment on (4) Oversight for the Conditions and Conformity and the Health IT Developer existing relevant data and methods we Maintenance of Certification Does Not Contest ONC’s Findings could use to estimate these costs. Requirements Comments. We did not receive any This category captures cases that Our processes for overseeing the comments specific to the relevant data require review and inquiry following Conditions and Maintenance of and methods used to estimate the costs ONC’s issuance of a notice of non- Certification requirements will, for the to correct non-conforming actions conformity, but that do not proceed to most part, mirror our processes for identified by ONC. the appeals process. Examples of such direct review of non-conformities in Response. We maintain our approach situations would include, but not be certified health IT as described in used to estimate the costs to correcting limited to: (1) A health IT developer current § 170.580. We may directly identified non-conformities. violates a Condition of Certification review a health IT developer’s actions to requirement and does not contest ONC’s (B) Costs for Health IT Developers and determine whether they conform to the finding that it is in violation of the ONC Costs Related to ONC Review and Conditions and Maintenance of Condition of Certification requirement; Inquiry Into Health IT Developer Certification requirements finalized in or (2) a health IT developer fails to meet Actions this final rule. The estimated costs and a deadline, such as for its corrective benefits for such oversight and review In order to calculate the potential action plan (CAP). We estimate that are detailed below. costs to health IT developers and ONC ONC will, on average, conduct between related to ONC review and inquiry into 12 and 18 of these reviews annually. (i) Costs health IT developer actions, we have We estimate that a health IT We estimated the potential monetary created the following categories for developer may commit, on average and costs of allowing ONC to directly review potential costs: (1) ONC review and depending on complexity, between 10 a health IT developer’s actions to inquiry prior to the issuance of a notice and 40 hours of staff time per case to determine whether the actions conform of non-conformity; (2) ONC review and provide ONC with all requested records to the requirements of the Program as inquiry following the issuance of a and documentation that ONC would use follows: (1) Costs for health IT notice of non-conformity and the health to review and conduct an inquiry into developers to correct non-conforming IT developer does not contest ONC’s health IT developer actions, and, when actions identified by ONC; (2) costs for findings (i.e., no appeal); and (3) ONC necessary, make a certification ban and/ health IT developers and ONC costs review and inquiry following the or termination determination. We related to ONC review and inquiry into issuance of a notice of non-conformity assumed that the work will be non-conforming actions by the health IT and the health IT developer contests performed by a ‘‘Computer Systems developer; and (3) costs for ONC–ACBs ONC’s findings (i.e., appeal). Analyst.’’ According to the May 2017 related to the new reporting requirement (C) ONC Review and Inquiry Prior to the BLS occupational employment in the Principles of Proper Conduct in Issuance of a Notice of Nonconformity statistics, the mean hourly wage for § 170.523(s). computer systems analyst is $44.59.242 We anticipate that ONC will receive, (A) Costs for Health IT Developers to As noted previously, we have assumed on average, between 100 and 200 that overhead costs (including benefits) Correct Non-Conforming Actions complaints per year concerning the Identified by ONC are equal to 100 percent of pre-tax Conditions and Maintenance of wages, so the hourly wage including We do not believe health IT Certification requirements that will overhead costs would be $89. Therefore, developers face additional direct costs warrant review and inquiry by ONC. We for the ONC direct review of health IT estimate that such initial review and 242 https://www.bls.gov/oes/2017/May/ developer actions (see cost estimates for inquiry by ONC will require, on average, oes151121.htm.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00294 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25935

we estimate the average annual cost for will, on average, conduct between three the issuance of a notice of non- health IT developers would range from and five of these reviews annually. conformity; (2) ONC review and inquiry $10,680 to $64,080. We note that some We estimated that a ‘‘Computer following the issuance of a notice of health IT developers’ costs are expected Systems Analyst’’ for the health IT non-conformity and the health IT to be less and some health IT developer may commit, on average and developer does not contest ONC’s developers’ costs are expected to be depending on complexity, between 20 findings (i.e., no appeal); and (3) ONC more than this estimated cost range. and 80 hours to provide the required review and inquiry following the Further, we note that these costs would information to appeal a certification ban issuance of a notice of non-conformity be perpetual. and/or termination under and the health IT developer contests We estimate that ONC may commit, § 170.580(a)(2)(iii) and respond to any ONC’s findings (i.e., appeal). on average and depending on requests from the hearing officer. Response. We maintain our approach complexity, between eight and 80 hours According to the May 2017 BLS used to estimate the costs to health IT of staff time to complete a review and occupational employment statistics, the developers and to ONC, related to ONC inquiry into health IT developer actions. mean hourly wage for a computer review and inquiry into health IT We assume that the expertise of a GS– systems analyst is $44.59.243 Assuming developer actions. that overhead costs (including benefits) 15, Step 1 Federal employee(s) will be (F) Costs for ONC–ACBs necessary. The hourly wage with are equal to 100 percent of pre-tax We also note that ONC–ACBs could benefits for a GS–15, Step 1 employee wages, the hourly wage including realize costs associated with the new located in Washington, DC is overhead costs is $89. Therefore, we reporting requirement in the Principles approximately $126. Therefore, based estimate the annual cost, including of Proper Conduct in § 170.523(s) that on the estimate of between 12 and 18 overhead costs, for a health IT developer they report, at a minimum, no later than cases each year, we estimate ONC’s to appeal a certification ban and/or a week after becoming aware of, any annual costs would range, on average, termination under § 170.580(a)(2)(iii) information that could inform whether from $12,096 to $181,440. We note that would, on average, range from $5,340 to $35,600. We note that some health IT ONC should exercise direct review some reviews and inquiries may cost under § 170.580(a). We estimate that, on less and some may cost more than this developers’ costs are expected to be less and some health IT developers’ costs are average, it will take an ONC–ACB estimated cost range. Further, we note employee at the GS–13, Step 1 level that these costs would be perpetual. expected to be more than this estimated cost range. Further, we note that these approximately 30 minutes to prepare We welcomed comments on our the report. The hourly wage with estimated costs and any comparable costs would be perpetual. We estimated that ONC would benefits for a GS–13, Step 1 employee processes and costs that we could use to commit, on average and depending on located in Washington, DC is improve our estimates. complexity, between 40 and 160 hours approximately $91. Since the collection Comments. We did not receive any of staff time to conduct each appeal. must occur no less than weekly, we will comments specific to the relevant data This will include the time to represent assume it occurs, on average, 52 times and methods used to estimate the costs ONC in the appeal and support the costs per year. Therefore, given that there are to: (1) ONC review and inquiry prior to for the hearing officer. We assume that currently three ONC–ACBs, we estimate the issuance of a notice of non- the expertise of a GS–15, Step 1 Federal the annual cost to ONC–ACBs to comply conformity; (2) ONC review and inquiry employee(s) would be necessary. The with the reporting requirement under following the issuance of a notice of hourly wage with benefits for a GS–15, § 170.523(s) would, on average, be non-conformity and the health IT Step 1 employee located in Washington, $7,098. We did not receive comments developer does not contest ONC’s DC is approximately $126. Therefore, regarding our calculations. We have findings (i.e., no appeal); and (3) ONC based on the estimate of between three finalized these estimates. review and inquiry following the and five cases each year, we estimate (ii) Benefits issuance of a notice of non-conformity the cost for ONC to conduct an appeal and the health IT developer contests would range, on average, from $15,120 This final rule’s provisions for ONC ONC’s findings (i.e., appeal). to $100,800. We note that some appeals direct review of the Conditions and Response. We maintain our approach may cost less and some may cost more Maintenance of Certification used to estimate the costs to health IT than this estimated cost range. Further, requirements would promote health IT developers and to ONC, related to ONC we note that these costs would be developers’ accountability for their review and inquiry into health IT perpetual. actions and ensure that health IT developer actions. Based on the above estimates, we developers’ actions conform with the requirements of the Cures Act and (E) ONC Review and Inquiry Following estimated the total annual costs for Conditions and Maintenance of the Issuance of a Notice of Non- health IT developers related to ONC Certification requirements in Conformity and the Health IT Developer review and inquiry into health IT §§ 170.400–406. Specifically, ONC’s Contests ONC’s Findings developer actions would range, on average, from $16,020 to $99,680. We direct review of health IT developer As discussed in section VII.C of this estimated the total annual costs for ONC actions will facilitate ONC’s ability to preamble, we permit a health IT related to ONC review and inquiry into require comprehensive corrective action developer to appeal an ONC health IT developer actions would by health IT developers to address non- determination to issue a certification range, on average, from $44,603 to conforming actions determined by ONC. ban and/or terminate a certification $383,345. If ONC ultimately implements a under § 170.580(a)(2)(iii). This category Comments. We did not receive any certification ban and/or terminates a of cost calculations captures cases that comments specific to the relevant data certification(s), such action will serve to require review and inquiry following and methods used to estimate the costs protect the integrity of the Program and ONC’s issuance of a notice of non- of (1) ONC review and inquiry prior to users of health IT. While we do not have conformity and where the health IT available means to quantify the benefits developer contests ONC’s finding and 243 See https://www.bls.gov/oes/2017/May/ of ONC direct review of health IT files an appeal. We estimate that ONC oes151121.htm. developer actions, we note that ONC

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00295 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25936 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

direct review supports and enables the detailed discussion of the negative interoperability on the health outcome] National Coordinator to fulfill his impacts of information blocking, we * [total cost of health outcome]. responsibilities under the HITECH Act refer readers to section XIV.C.2.a(2) of We extracted the ‘‘ME effect of and Cures Act, instills public the Proposed Rule (84 FR 7584). interoperability on the health outcome’’ confidence in the Program, and protects The exceptions to the information and ‘‘cost of health outcomes’’ from public health and safety. We did not blocking definition adopted in this final academic literature (see citations in receive comments regarding our rule create clear guidelines for industry Table 24). We then determined a proxy calculations. We have finalized these regarding pro-competitive and other for the number of providers that engage estimates. (5) Information Blocking beneficial activities and will enable in cross-vendor exchange. We did this (i) Costs stakeholders to determine more easily by leveraging hospital referral data from and with greater certainty whether their 2015 to determine the proportion of We expect ONC to incur an annual activities are excepted from the hospitals that referred patients to a cost for issuing educational resources information blocking definition. provider outside of their system where related to the information blocking Overall, the finalized exceptions are the receiving provider used a different ‘‘reasonable and necessary’’ exceptions. accommodating to legitimate industry EHR vendor. We determined that 82 We estimate that ONC issues practices for health IT developers, percent of hospitals engaged in cross- educational resources each quarter, hospitals, and health care providers vendor exchange. This estimate was therefore, four per year. We assume that and, we believe, will ease the burden used as the proxy for ‘‘providers that the educational resources would be and compliance costs for these parties. engaged in cross-vendor exchange.’’ provided by ONC staff with the To estimate the benefits of We estimated the ‘‘ME of information expertise of a GS–15, Step 1 Federal information blocking, we first examined employee(s). The hourly wage with blocking on interoperability’’ through existing data sources to identify a proxy the following research design: benefits for a GS–15, Step 1 employee that will indicate the extent to which located in Washington, DC is information blocking is occurring. Y = b1InforBlock + X’B + e approximately $126. We estimate it According to analysis of data from the Where y = 1 if a hospital routinely would take ONC staff between 200 and American Hospital Association IT engages in four domains of 400 hours to develop the guidance. Supplement survey, 53 percent of non- interoperability—sending, receiving, Therefore, we estimate the annual cost Federal acute care hospitals reported finding, and integrating data, 0 to ONC would range, on average, from that they had challenges with otherwise. The variable InforBlock is a $100,800 to $201,600. exchanging data across different vendor binary indicator for whether a hospital Comments. We did not receive any 244 comments regarding the specific costs platforms. Moreover, 31 percent reported experiencing challenges with associated with information blocking. reported that they must pay additional exchanging data across different vendor Response. We have adopted our costs to exchange information with platforms. We assume the impact of estimates as proposed. We note that we organizations outside of the system. reporting this barrier is a proxy for the did receive comments regarding Nearly one in four hospitals reported extent to which vendors hinder a ‘‘burden’’ on various stakeholder groups that they had to develop customized hospital’s interoperability. In the model, related to our information blocking interfaces to electronically exchange we control for the following: Hospital’s proposals, and those comments are information. primary vendor, participation in health addressed throughout the information To quantify the magnitude of exchange organization, participation in blocking section (section VIII) of this information blocking and the benefits of five different networks, system final rule. restricting information blocking, we ownership, level of system estimated the following, which gives us centralization, bed size, profit status, (ii) Benefits the imposed cost of information public status, region, location in urban Information blocking not only blocking for each health outcome: area. The marginal effect of b is 0.04. We interferes with effective health [Percent of providers that engage in assume that this effect may capture information exchange, but also cross-vendor exchange] * [marginal other reasons not related to information negatively impacts many important effect (ME) of information blocking on blocking, so we use half of this estimate aspects of health and health care. For a interoperability] * [ME effect of for our benefit calculations—0.02.

TABLE 28—BENEFITS OF PROHIBITING AND/OR DETERRING INFORMATION BLOCKING [2017 Dollars]

Overall interop Percent of Marginal effect Total cost im- impact providers of information Benefit Benefit type Total cost susceptible to blocking A pacted (marginal information (percentage benefit effect) blocking points)

Duplicate testing ...... 100% ...... 200 billion B ...... C 0.09 82 0.02 $295,200,000 Avoidable hospitalizations and re- 100% ...... $41 billion D ...... 0.09 82 0.02 60,516,000 admissions. ER visits ...... 131 million vis- Cost per ER visit 0.03 82 0.02 79,469,316 its E. $1,233. Adverse drug events ...... 20% ...... $30 billion F ...... 0.22 82 0.02 21,648,000

244 Pylypchuk Y., Johnson C., Henry J. & Ciricean among U.S. Non-Federal Acute Care Hospitals in Coordinator for Health Information Technology: D. (November 2018). Variation in Interoperability 2017. ONC Data Brief, no.42. Office of the National Washington DC.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00296 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25937

TABLE 28—BENEFITS OF PROHIBITING AND/OR DETERRING INFORMATION BLOCKING—Continued [2017 Dollars]

Percent of Marginal effect Overall interop providers of information Benefit type Total cost im- Total cost impact susceptible to blocking Benefit A pacted (marginal information (percentage benefit effect) blocking points)

Total benefit per year ...... $456,833,316 A Total benefit would be a product of % of total cost impacted, total cost, overall interop impact, percent of providers susceptible to information blocking, and marginal effect of information blocking; however, no reasonable estimate of the marginal effect of information blocking is currently available. B National Academy of Medicine (2016), http://money.cnn.com/2017/05/20/news/economy/medical-tests/index.html. C Stephen E. Ross, Tiffany A. Radcliff, William G. Leblanc, L. Miriam Dickinson, Anne M. Libby, and Donald E. Nease Jr., Effects of health in- formation exchange adoption on ambulatory testing rates, J. Am. Med. Inform. Assoc. (2013), at 1137–1142; Bridget A. Stewart, Susan Fernandes, Elizabeth Rodriguez-Huertas, and Michael Landzberg, A preliminary look at duplicate testing associated with lack of electronic health record interoperability for transferred patients, J. of the Am. Med. Informatics Assoc. (2010), at 341–344; Sezgin Ayabakan, Indranil R. Bardhan, Zhiqiang (Eric) Zheng, and Kirk Kirksey Value of health information sharing in reducing healthcare waste: An analysis of duplicate testing across hospitals, MIS Quarterly (Jan. 1, 2017); Eric J. Lammers, Julia Adler-Milstein, and Keith E. Kocher, Does health information exchange reduce re- dundant imaging? Evidence from emergency departments, Med Care (Mar. 2014), at 227–34. D Agency for Healthcare Research and Quality (AHRQ) Statistical Brief #199 (Dec. 2015), https://www.hcup-us.ahrq.gov/reports/statbriefs/ sb199-Readmissions-Payer-Age.pdf; AHRQ Statistical Brief #72, Nationwide Frequency and Costs of Potentially Preventable Hospitalizations (Apr. 2009), https://www.hcup-us.ahrq.gov/reports/statbriefs/sb72.pdf. E National Center for Health Statistics (NCHS) Data Brief No. 252 (June 2016), https://www.cdc.gov/nchs/data/databriefs/db252.pdf; Nolan Caldwell, Tanja Srebotnjak, Tiffany Wang, and Renee Hsia, ‘‘How Much Will I Get Charged for This?’’ Patient Charges for Top Ten Diagnoses in the Emergency Department (2013), https://doi.org/10.1371/journal.pone.0055491. F Janet Sultana, Paola Cutroneo, and Gianluca Trifiro`, Clinical and economic burden of adverse drug reactions.

As a result of this calculation, we the cost per developer will range from estimates outlined above, would range estimate that the benefit of the $1.1 million to $2.4 million. Based on from $1.2 billion to $5.0 billion with information blocking provision is $456 previous participation in the CMS EHR primary estimated annual benefit of $3.1 million. Incentive Program, we estimated that billion. Our estimates include benefits Comments. We did not receive any 439,187 health care providers in 95,470 attributed to the entire health care comments regarding our approach to clinical practices and 4,519 hospitals system, including hospitals, clinicians, estimating benefits or the specific that participated in the CMS EHR payers and patients.(8) Total benefit estimates associated with Incentive Program will be impacted by Annualized Net Benefit information blocking. this final rule. We estimated the total The total annualized net benefit is Response. ONC has revised its cost to health care providers to be between $478 million to $1.6 billion. expressed in 2016 dollars to meet methodological approach to quantifying regulatory reform analysis requirements the benefits of our information blocking We did not calculate per entity costs for under Executive Order 13771. We provision. This new methodology is health care providers. We acknowledged estimate the total annualized net benefit described in the RIA. that costs may be passed from health IT developers to their customers (i.e. for this final rule, based on the estimates (6) Total Annual Cost Estimate health care providers) during the outlined above, would range from $191 The total annual cost estimate is licensing of their health IT modules. We million to $2.3 billion with a primary expressed in 2016 dollars to meet estimated the total costs to ONC–ACBs net benefit estimate of $1.3 billion. to be between $391,000 and $792,000. regulatory reform analysis requirements b. Accounting Statement and Table under Executive Order 13771. We We estimated the government costs estimated that the total cost for this final (through labor hours of ONC staff) to be When a rule is considered an rule for the first year after it is finalized between $159,000 and $586,000 with economically significant rule under (including one-time costs), based on the $4,497 in cost savings from deregulatory Executive Order 12866, we are required cost estimates outlined above and actions. In addition to the above- to develop an accounting statement throughout this RIA, would range, on mentioned cost savings that are indicating the classification of the average, from $953 million to $2.6 attributable to specific stakeholder expenditures associated with the groups, we estimated an additional cost billion with an average annual cost of provisions of the proposed rule. savings of $6.6 million to $13.3 million $1.8 billion. We estimated that the total Monetary annual benefits are presented to all stakeholders affected by this perpetual cost for this final rule (starting as discounted flows using three percent in year two), based on the cost estimates provision. We are unable to attribute these amounts to specific stakeholder and seven percent factors in Table 29. outlined above, would range, on We are not able to explicitly define the average, from $366 million to $1.3 groups. We did not receive comment regarding these calculations. We have universe of all costs, but have provided billion with an average annual cost of an average of likely costs of this final $840 million. We also included finalized our estimates. rule as well as a high and low range of estimates based on the stakeholder (7) Total Annual Benefit Estimate likely costs. Unquantifiable costs and groups affected. We estimated the total costs to health IT developers to be The total annual benefit estimate is benefits are noted in Table 31. This final between $483 million and $1.1 billion expressed in 2016 dollars to meet rule requires no Federal transfers, but it (including one-time and perpetual costs) regulatory reform analysis requirements might bring about a reduction in with $633,000 in cost savings from under Executive Order 13771. We fraudulent payments to providers by the deregulatory actions. Assuming that 458 estimated the total annual benefit for health IT developers will be impacted, this final rule, based on the benefit

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00297 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25938 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

Federal Government and other payers.245

TABLE 29—EO 12866 SUMMARY TABLE [In $ millions, 2016 Dollars]

Primary Lower bound Upper bound Primary Lower bound Upper bound (3%) (3%) (3%) (7%) (7%) (7%)

Present Value of Quantified Costs ...... 6,454 2,966 9,943 4,574 2,120 7,028 Present Value of Quantified Benefits ...... 23,411 8,831 37,991 16,552 6,244 26,859 Present Value of Net Benefits ...... 16,957 5,865 28,049 16,552 4,124 19,832 Annualized Quantified Costs ...... 852 391 1,312 854 396 1,312 Annualized Quantified Benefits ...... 3,089 1,165 5,013 2,184 824 3,544 Annualized Net Quantified Benefits ...... 2,237 774 3,701 1,330 428 2,232

TABLE 30—E.O. 12866 SUMMARY TABLE NON-DISCOUNTED FLOWS [2016 Dollars]

Year 1 Year 2 Year 3 Year 4 Year 5

Costs ...... 942,795,801 839,887,346 839,887,346 839,887,346 839,887,346 Benefits ...... 3,088,980,583 3,088,980,583 3,088,980,583 3,088,980,583 3,088,980,583

Year 6 Year 7 Year 8 Year 9 Year 10

Costs ...... 839,887,346 839,887,346 839,887,346 839,887,346 839,887,346 Benefits ...... 3,088,980,583 3,088,980,583 3,088,980,583 3,088,980,583 3,088,980,583

TABLE 31—NON-QUANTIFIABLE BENEFITS [2016 Dollars]

Present value of 10 years by Annualized value over 10 discount rate years by discount rate Benefits (in millions) (in millions) 3 Percent 7 Percent 3 Percent 7 Percent

Quantified Benefits ...... 23,411 16,552 3,089 2,184

Non-quantified Benefits: Impact on users of health IT that were ineligible or did not participate in the CMS EHR Incentive Programs; developer cost savings from no longer supporting the 2014 Edition; provider and patient benefit from implementation of USCDI and Security tags (DS4P) provisions due to improvements in interoperability; benefits associated with communication provision because we do not have adequate information to determine the prevalence of gag clauses and other such restrictive practices nor do we have a means to quantify the value to providers of being able to freely communicate and share information; benefit of ONC oversight on real world testing and non-conformance; external regulatory and policy activities.

Costs 3 Percent 7 Percent 3 Percent 7 Percent

Quantified Costs ...... 6,454 4,574 852 396

Non-quantified Costs: Impact of provisions on health IT production costs such as the supply and demand for personnel over time; costs developers to correct non-conformities; ONC cost to review non-conformities, real-world testing maintenance by ACBs; additional provider implementation ac- tivities related to USCDI and DS4P; external regulatory and policy activities.

3. Regulatory Flexibility Act businesses for Federal Government flexibilities and relief for health IT programs based on average annual developers of certified health IT, health The Regulatory Flexibility Act (RFA) receipts or the average employment of a information networks, health requires agencies to analyze options for firm.246 The entities that are likely to be information exchanges, and health care regulatory relief of small businesses if a directly affected by the requirements in providers in relation to the information rule has a significant impact on a this final rule are health IT developers. blocking provision of the Cures Act. substantial number of small entities. We note that the reasonable and These reasonable and necessary The Small Business Administration necessary activities that do not activities also take into account the (SBA) establishes the size of small constitute information blocking provide potential burden on small entities to

245 Parente, Stephen T., Karen Mandelbaum, Healthcare Information Management 22(3): 42–51. proprietorship, ‘‘gross income’’) plus ‘‘cost of goods Susan P. Hanson, Bonnie S. Cassidy and Donald W. June 2008. sold’’ as these terms are defined and reported on Simborg. ‘‘Crime and Punishment: Can the NHIN 246 The SBA references that annual receipts Internal Revenue Service tax return forms. Reduce the Cost of Healthcare Fraud?’’ Journal of means ‘‘total income’’ (or in the case of a sole

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00298 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25939

meet these ‘‘exceptions’’ to information Additionally, we have attempted to Health records, Hospitals, Privacy, blocking, such as with considering the offset some of the burden imposed on Reporting and recordkeeping size and resources of small entities health IT developers in this final rule requirements, Public health, Security. when meeting security requirements to with cost saving provisions through For the reasons set forth in the qualify for the ‘‘promoting the security deregulatory actions (see section III). preamble, 45 CFR subtitle A, subchapter of electronic health information’’ Additionally, the Secretary certifies that D, is amended as follows: exception. this final rule will not have a significant While health IT developers that impact on a substantial number of small PART 170—HEALTH INFORMATION pursue certification of their health IT entities. TECHNOLOGY STANDARDS, under the Program represent a small IMPLEMENTATION SPECIFICATIONS, 4. Executive Order 13132—Federalism segment of the overall information AND CERTIFICATION CRITERIA AND technology industry, we believe that Executive Order 13132 establishes CERTIFICATION PROGRAMS FOR many health IT developers impacted by certain requirements that an agency HEALTH INFORMATION the requirements in this final rule most must meet when it promulgates a final TECHNOLOGY likely fall under the North American rule that imposes substantial direct Industry Classification System (NAICS) requirement costs on State and local ■ 1. The authority citation for part 170 code 541511 ‘‘Custom Computer governments, preempts State law, or continues to read as follows: 247 Programming Services.’’ The SBA otherwise has federalism implications. Authority: 42 U.S.C. 300jj–11; 42 U.S.C size standard associated with this Nothing in this final rule imposes 300jj–14; 5 U.S.C. 553 NAICS code is set at $27.5 million substantial direct compliance costs on ■ annual receipts or less. There is enough State and local governments, preempts 2. Revise § 170.101 to read as follows: data generally available to establish that State law, or otherwise has federalism § 170.101 Applicability. implications. We are not aware of any between 75 percent and 90 percent of The standards, implementation entities that are categorized under the State laws or regulations that are specifications, and certification criteria NAICS code 541511 are under the SBA contradicted or impeded by any of the adopted in this part apply to Health IT size standard. We also note that with the provisions in this final rule. Modules and the testing and exception of aggregate business 5. Unfunded Mandates Reform Act of certification of such Health IT Modules. information available through the U.S. 1995 Census Bureau and the SBA related to ■ 3. Amend § 170.102 by: NAICS code 541511, it appears that Section 202 of the Unfunded ■ a. Removing the definitions of ‘‘2014 many health IT developers that pursue Mandates Reform Act of 1995 requires Edition Base EHR’’ and ‘‘2014 Edition certification of their health IT under the that agencies assess anticipated costs EHR certification criteria’’; Program are privately held or owned and benefits before issuing any rule that ■ b. Revising paragraph (3) in the and do not regularly, if at all, make their imposes unfunded mandates on State, definition of ‘‘2015 Edition Base EHR’’; specific annual receipts publicly local, and tribal governments or the ■ c. Revising the definition of ‘‘Common available. As a result, it is difficult to private sector requiring spending in any Clinical Data Set’’; locate empirical data related to many of one year of $100 million in 1995 dollars, ■ d. Removing the definition of these health IT developers to correlate updated annually for inflation. The ‘‘Complete EHR, 2014 Edition’’; and to the SBA size standard. However, current inflation-adjusted statutory ■ e. Adding in alphabetical order although not perfectly correlated to the threshold is approximately $150 definitions for ‘‘Electronic Health size standard for NAICS code 541511, million. While the estimated potential Information’’, ‘‘Fee’’, ‘‘Health we do have information indicating that cost effects of this final rule reach the information technology’’, over 60 percent of health IT developers statutory threshold, we do not believe ‘‘Interoperability’’, and ‘‘Interoperability that have had Complete EHRs and/or this final rule imposes unfunded element’’. Health IT Modules certified to the 2011 mandates on State, local, and tribal The revisions and additions read as Edition had less than 51 employees (80 governments or the private sector. follows: OMB reviewed this final rule. FR 62741). § 170.102 Definitions. We estimated that the requirements in List of Subjects this final rule will have effects on health * * * * * IT developers, some of which may be 45 CFR Part 170 2015 Edition Base EHR *** small entities, that have certified health Computer technology, Electronic (3) Has been certified to the IT or are likely to pursue certification of health record, Electronic information certification criteria adopted by the their health IT under the Program. We system, Electronic transactions, Health, Secretary in— believe, however, that we have finalized Health care, Health information (i) Section 170.315(a)(1), (2), or (3); the minimum amount of requirements technology, Health insurance, Health (a)(5), (a)(9), (a)(14), (b)(1), (c)(1), (g)(7) necessary to accomplish our primary records, Hospitals, Incorporation by and (9), and (h)(1) or (2); policy goal of enhancing reference, Laboratories, Medicaid, (ii) Section 170.315(g)(8) or (10) until interoperability. Further, as discussed in Medicare, Privacy, Reporting and May 2, 2022; and section XIII.B of this RIA above, there recordkeeping requirements, Public (iii) Section 170.315(g)(10) on and are no appropriate regulatory or non- health, Security. after May 2, 2022. * * * * * regulatory alternatives that could be 45 CFR Part 171 developed to lessen the compliance Common Clinical Data Set means the burden associated with this final rule Computer technology, Electronic following data expressed, where because many of the provisions are health record, Electronic information indicated, according to the specified derived directly from legislative system, Electronic transactions, Health, standard(s): mandates in the Cures Act. Health care, Health care provider, (1) Patient name. Health information exchange, Health (2) Sex: The standard specified in 247 https://www.sba.gov/sites/default/files/files/ information technology, Health § 170.207(n)(1). Size_Standards_Table_2017.pdf. information network, Health insurance, (3) Date of birth.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00299 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25940 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

(4) Race: (16) Immunizations: In accordance § 170.204 [Amended] (i) The standard specified in with, at a minimum, the standards ■ 6. Amend § 170.204 by removing and § 170.207(f)(2); and specified in § 170.207(e)(3) and (4). reserving paragraphs (b)(1) and (2) and (ii) The standard specified in (17) Unique device identifier(s) for a removing paragraph (c). patient’s implantable device(s): In § 170.207(f)(1) for each race identified in ■ 7. Amend § 170.205 by: accordance § 170.207(f)(2). accordance with the ‘‘Product Instance’’ ■ a. Removing and reserving paragraphs (5) Ethnicity: in the ‘‘Procedure Activity Procedure (a)(1) and (2); (i) The standard specified in Section’’ of the standard specified in ■ b. Adding paragraphs (a)(5) and (b)(1); § 170.207(f)(2); and § 170.205(a)(4). ■ c. Removing and reserving paragraphs (ii) The standard specified in (18) Assessment and plan of (d)(3), (e)(3), and (h)(1); § 170.207(f)(1) for each ethnicity treatment: ■ d. Adding paragraph (h)(3); identified in accordance § 170.207(f)(2). (i) In accordance with the ■ e. Removing and reserving paragraphs (6) Preferred language: The standard ‘‘Assessment and Plan Section (V2)’’ of (i)(1) and (j); and specified in § 170.207(g)(2). the standard specified in § 170.205(a)(4); ■ f. Adding paragraph (k)(3). (7) Smoking status. or The additions read as follows: (ii) In accordance with the (8) Problems: At a minimum, the ‘‘Assessment Section (V2)’’ and ‘‘Plan of § 170.205 Content exchange standards standard specified in § 170.207(a)(4). Treatment Section (V2)’’ of the standard and implementation specifications for (9) Medications: At a minimum, the specified in § 170.205(a)(4). exchanging electronic health information. standard specified in § 170.207(d)(3). (19) Goals: In accordance with the (a) * * * (10) Medication allergies: At a ‘‘Goals Section’’ of the standard (5) Standard. HL7 CDA® R2 minimum, the standard specified in specified in § 170.205(a)(4). Implementation Guide: C–CDA § 170.207(d)(3). (20) Health concerns: In accordance Templates for Clinical Notes R2.1 (11) Laboratory test(s): At a minimum, with the ‘‘Health Concerns Section’’ of Companion Guide, Release 2 the standard specified in § 170.207(c)(3). the standard specified in § 170.205(a)(4). (incorporated by reference in § 170.299). (12) Laboratory value(s)/result(s). * * * * * * * * * * (13) Vital signs: Electronic health information (EHI) is (b) * * * (i) The patient’s diastolic blood defined as it is in § 171.102. (1) Standard. National Council for pressure, systolic blood pressure, body Fee is defined as it is in § 171.102 of Prescription Drug Programs (NCPDP): height, body weight, heart rate, this subchapter. SCRIPT Standard Implementation respiratory rate, body temperature, * * * * * Guide; Version 2017071 (incorporated pulse oximetry, and inhaled oxygen Health information technology means by reference in § 170.299). concentration must be exchanged in hardware, software, integrated * * * * * numerical values only; and technologies or related licenses, IP, (h) * * * (ii) In accordance with the standard upgrades, or packaged solutions sold as (3) Standard. CMS Implementation specified in § 170.207(c)(3) and with the services that are designed for or support Guide for Quality Reporting Document associated applicable unit of measure the use by health care entities or Architecture: Category I; Hospital for the vital sign measurement in the patients for the electronic creation, Quality Reporting; Implementation standard specified in § 170.207(m)(1). maintenance, access, or exchange of Guide for 2019 (incorporated by (iii) Optional: The patient’s BMI health information. reference in § 170.299). percentile per age and sex for youth 2– * * * * * * * * * * 20 years of age, weight for age per length Interoperability is, with respect to (k) * * * and sex for children less than 3 years of health information technology, such (3) Standard. CMS Implementation age, and head occipital-frontal health information technology that— Guide for Quality Reporting Document circumference for children less than 3 (1) Enables the secure exchange of Architecture: Category III; Eligible years of age must be recorded in electronic health information with, and Clinicians and Eligible Professionals numerical values only in accordance use of electronic health information Programs; Implementation Guide for with the standard specified in from, other health information 2019 (incorporated by reference in § 170.207(c)(3) and with the associated technology without special effort on the § 170.299). applicable unit of measure for the vital part of the user; * * * * * sign measurement in the standard (2) Allows for complete access, specified in § 170.207(m)(1). For BMI exchange, and use of all electronically § 170.207 [Amended] percentile per age and sex for youth 2– accessible health information for ■ 8. Amend § 170.207 by removing and 20 years of age and weight for age per authorized use under applicable State or reserving paragraphs (d)(2), (e)(2), (g)(1), length and sex for children less than 3 Federal law; and (h), and (j). years of age, the reference range/scale or (3) Does not constitute information growth curve should be included as blocking as defined in § 171.103 of this § 170.210 [Amended] appropriate. subchapter. ■ 9. Amend § 170.210: (14) Procedures: Interoperability element is defined as ■ a. By removing and reserving (i) At a minimum, the version of the it is in § 171.102 of this subchapter. paragraphs (a)(1) and (c)(1); standard specified in § 170.207(a)(4) or * * * * * ■ b. In paragraph (e)(1)(i), by removing § 170.207(b)(2); or the words ‘‘7.2 through 7.4, 7.6, and (ii) For technology primarily § 170.200 [Amended] 7.7’’ and adding in their place ‘‘7.1.1 developed to record dental procedures, ■ 4. Amend § 170.200 by removing the through 7.1.3 and 7.1.6 through 7.1.9’’; the standard specified in phrase ‘‘Complete EHRs and’’. and § 170.207(b)(3). ■ c. In paragraph (h), by removing the (iii) Optional: The standard specified § 170.202 [Amended] words ‘‘ASTM E2147–01 (Reapproved in § 170.207(b)(4). ■ 5. Amend § 170.202 by removing and 2013)’’ and adding in their place (15) Care team member(s). reserving paragraph (a)(1). ‘‘ASTM E2147–18’’.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00300 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25941

■ 10. Add § 170.213 to read as follows: Systems, approved May 1, 2018, IBR § 170.314 [Removed and Reserved] approved for § 170.210(h). ■ § 170.213 United States Core Data for 14. Remove and reserve § 170.314. Interoperability * * * * * ■ 15. Amend § 170.315: (e) * * * ■ a. By removing and reserving Standard. United States Core Data for (4) CMS Implementation Guide for Interoperability (USCDI), Version 1 (v1) paragraphs (a)(6) through (8); Quality Reporting Document ■ b. In paragraph (a)(9)(ii)(B)(1)(iii) by (incorporated by reference in § 170.299). Architecture Category I Hospital Quality ■ 11. Add § 170.215 to read as follows: removing ‘‘medication allergy’’ and Reporting Implementation Guide for adding in its place ‘‘allergy and § 170.215 Application Programming 2019; published May 4, 2018, IBR intolerance’’; Interface Standards. approved for § 170.205(h). ■ c. In paragraph (a)(9)(ii)(B)(2) by (5) CMS Implementation Guide for The Secretary adopts the following removing ‘‘medication allergies’’ and Quality Reporting Document application programming interface (API) adding in its place ‘‘allergies and Architecture Category III Eligible standards and associated intolerance’’; Clinicians and Eligible Professionals implementation specifications: ■ d. By removing and reserving Programs Implementation Guide for (a)(1) Standard. HL7® Fast Healthcare paragraph (a)(11); 2019; published October 8, 2018, IBR Interoperability Resources (FHIR ®) ■ e. In paragraphs (b)(1)(ii)(A) approved for § 170.205(k). Release 4.0.1 (incorporated by reference introductory text, (b)(1)(ii)(A)(2) and (3), (f) * * * ® ® (b)(1)(ii)(B), and (b)(1)(ii)(C) in § 170.299). (30) HL7 CDA R2 Implementation introductory text, by removing the (2) Implementation specification. HL7 Guide: C–CDA Templates for Clinical reference ‘‘§ 170.205(a)(3) and FHIR US Core Implementation Guide Notes R2.1 Companion Guide, Release § 170.205(a)(4)’’ and adding in its place STU 3.1.0. (incorporated by reference in 2–US Realm, October 2019, IBR the reference ‘‘§ 170.205(a)(3), (4), and § 170.299). approved for § 170.205(a). (3) Implementation specification. HL7 (31) HL7 FHIR® Bulk Data Access (5)’’; ■ SMART Application Launch Framework (Flat FHIR®) (v1.0.0: STU 1), August 22, f. In paragraph (b)(1)(iii) introductory Implementation Guide Release 1.0.0, 2019, IBR approved for § 170.215(a). text, by removing the reference including mandatory support for the (32) HL7 FHIR SMART Application ‘‘§ 170.205(a)(4)’’ and adding in its place ‘‘SMART Core Capabilities’’ Launch Framework Implementation the reference ‘‘§ 170.205(a)(3), (4), and (incorporated by reference in § 170.299). Guide Release 1.0.0, November 13, (5)’’; ■ (4) Implementation specification. 2018, IBR approved for § 170.215(a). g. By revising paragraphs (b)(1)(iii)(A) FHIR Bulk Data Access (Flat FHIR) (33) HL7 Fast Healthcare and (b)(2) and (3); (v1.0.0: STU 1), including mandatory Interoperability Resources Specification ■ h. By removing and reserving support for the ‘‘group-export’’ (FHIR®) Release 4, Version 4.0.1: R4, paragraphs (b)(4) and (5); ‘‘OperationDefinition’’ (incorporated by October 30, 2019, including Technical ■ i. By revising paragraphs (b)(7) reference in § 170.299). Correction #1, November 1, 2019, IBR through (9); (b) Standard. OpenID Connect Core approved for § 170.215(a). ■ j. By adding paragraph (b)(10); 1.0, incorporating errata set 1 (34) HL7 FHIR® US Core ■ k. By revising paragraph (c)(3); (incorporated by reference in Implementation Guide STU3 Release ■ l. By adding paragraphs (d)(12) and § 170.299). 3.1.0, November 06, 2019, IBR approved (13); ■ 12. Amend § 170.299 by: for § 170.215(a). ■ m. By revising paragraphs ■ a. Revising paragraph (c)(1); (e)(1)(i)(A)(1) through (5); * * * * * ■ ■ b. Removing and reserving paragraphs (k) * * * n. By adding paragraphs (e)(1)(i)(A)(6) (c)(2) and (3) and (d)(2), (7), and (8); (3) SCRIPT Standard, Implementation and (7) ■ ■ c. Adding paragraphs (e)(4) and (5); Guide, Version 2017071 (Approval Date o. In paragraph (e)(1)(i)(B)(1)(ii) and ■ d. Removing and reserving paragraphs for ANSI: July 28, 2017), IBR approved (e)(1)(i)(B)(2) introductory text, by (f)(3), (6), (7), (10), and (11); for § 170.205(b). removing the reference ‘‘§ 170.205(a)(4)’’ ■ e. Adding paragraphs (f)(30) through and adding in its place the reference * * * * * (34); ‘‘§ 170.205(a)(4) and (5)’’; (m) * * * ■ f. Removing and reserving paragraphs ■ p. By removing and reserving (5) United States Core Data for (h)(1) and (j)(1); paragraph (e)(1)(ii)(B); Interoperability (USCDI), Version 1, ■ g. Adding paragraph (k)(3); ■ q. By revising paragraphs February 2020, IBR approved for ■ h. Removing and reserving paragraph (f)(5)(iii)(B)(1) through (4), § 170.213; available at https:// (l)(3); ■ r. By adding paragraph (f)(5)(iii)(B)(5); www.healthit.gov/USCDI. ■ i. Adding paragraph (m)(5); ■ s. By revising paragraphs (g)(1) and ■ j. Redesignating paragraphs (n) * * * * * (2), (g)(3)(i), and (g)(6) through (r) as paragraphs (o) through (s), (n) OpenID Foundation, 2400 Camino ■ t. By removing paragraphs respectively; Ramon, Suite 375, San Ramon, CA (g)(7)(ii)(A)(3) and (g)(8)(ii)(A)(3); ■ k. Adding new paragraph (n); and 94583, Telephone +1 925–275–6639, ■ u. By revising paragraph (g)(9)(i)(A); ■ l. Removing and reserving newly http://openid.net/. ■ v. By removing paragraph redesignated paragraphs (r)(4) and (5). (1) OpenID Connect Core 1.0 (g)(9)(ii)(A)(3); and The revision and additions read as Incorporating errata set 1, November 8, ■ w. By adding paragraph (g)(10). follows: 2014, IBR approved for § 170.215(b). The revisions and additions read as (2) [Reserved] follows: § 170.299 Incorporation by reference. * * * * * * * * * * § 170.315 2015 Edition health IT (c) * * * § 170.300 [Amended] certification criteria. (1) ASTM E2147–18 Standard ■ 13. Amend § 170.300 in paragraphs (a) * * * * * Specification for Audit and Disclosure and (c) by removing the phrase (b) * * * Logs for Use in Health Information ‘‘Complete EHRs and’’. (1) * * *

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00301 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25942 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

(iii) * * * (C) Enable a user to review and (A) Enable a user to perform the (A)(1) The data classes expressed in validate the accuracy of a final set of following prescription-related electronic the standard in § 170.213 and in data. transactions in accordance with the accordance with § 170.205(a)(4), (5), and (D) Upon a user’s confirmation, standard specified in § 170.205(b)(1) paragraphs (b)(1)(iii)(A)(3)(i) through automatically update the list, and and, at a minimum, the version of the (iii) of this section, or incorporate the following data standard specified in § 170.207(d)(3) as (2) The Common Clinical Data Set in expressed according to the specified follows: accordance with § 170.205(a)(4) and standard(s) on and after May 2, 2022: (1) Create new prescriptions (NewRx). paragraph (b)(1)(iii)(A)(3)(i) through (iv) (1) Medications. At a minimum, the (2) Request and respond to change of this section for the period until May version of the standard specified in prescriptions (RxChangeRequest, 2, 2022, and § 170.213; RxChangeResponse). (2) Allergies and intolerance. At a (3) The following data classes: (3) Request and respond to cancel minimum, the version of the standard prescriptions (CancelRx, (i) Assessment and plan of treatment. specified in § 170.213; and CancelRxResponse). In accordance with the ‘‘Assessment (3) Problems. At a minimum, the (4) Request and respond to renew and Plan Section (V2)’’ of the standard version of the standard specified in prescriptions (RxRenewalRequest, specified in § 170.205(a)(4); or in § 170.213. RxRenewalResponse). accordance with the ‘‘Assessment (iv) System verification. Based on the (5) Receive fill status notifications Section (V2)’’ and ‘‘Plan of Treatment data reconciled and incorporated, the (RxFill). Section (V2)’’ of the standard specified technology must be able to create a file (6) Request and receive medication in § 170.205(a)(4). formatted according to the standard history (RxHistoryRequest, (ii) Goals. In accordance with the specified in § 170.205(a)(4) using the RxHistoryResponse). ‘‘Goals Section’’ of the standard Continuity of Care Document template (7) Relay acceptance of a transaction specified in § 170.205(a)(4). and the standard specified in back to the sender (Status). (iii) Health concerns. In accordance § 170.205(a)(5) on and after May 2, 2022. (8) Respond that there was a problem with the ‘‘Health Concerns Section’’ of (3) Electronic prescribing. (i) For with the transaction (Error). the standard specified in § 170.205(a)(4). technology certified prior to May 2, (9) Respond that a transaction (iv) Unique device identifier(s) for a 2022, subject to the real world testing requesting a return receipt has been patient’s implantable device(s). In provisions at § 170.405(b)(5), received (Verify). accordance with the ‘‘Product Instance’’ (A) Enable a user to perform the (B) Optionally, enable a user to in the ‘‘Procedure Activity Procedure following prescription-related electronic perform the following prescription- Section’’ of the standard specified in transactions in accordance with, at a related electronic transactions in § 170.205(a)(4). minimum, the version of the standard accordance with the standard specified (2) Clinical information reconciliation specified in § 170.207(d)(3) as follows: in § 170.205(b)(1) and, at a minimum, and incorporation—(i) General (1) Create new prescriptions the version of the standard specified in requirements. Paragraphs (b)(2)(ii) and (NEWRX). § 170.207(d)(3) as follows: (iii) of this section must be completed (2) Change prescriptions (RXCHG, (1) Create and respond to new based on the receipt of a transition of CHGRES). prescriptions (NewRxRequest, care/referral summary formatted in (3) Cancel prescriptions (CANRX, NewRxResponseDenied). accordance with the standards adopted CANRES). (2) Receive fill status notifications in § 170.205(a)(3) through (5) using the (4) Refill prescriptions (REFREQ, (RxFillIndicator). Continuity of Care Document, Referral REFRES). (3) Ask the Mailbox if there are any Note, and (inpatient setting only) (5) Receive fill status notifications transactions (GetMessage). Discharge Summary document (RXFILL). (4) Request to send an additional templates on and after May 2, 2022. (6) Request and receive medication supply of medication (Resupply). history information (RXHREQ, (5) Communicate drug administration (ii) Correct patient. Upon receipt of a RXHRES). events (DrugAdministration). transition of care/referral summary (B) For each transaction listed in (6) Request and respond to transfer formatted according to the standards paragraph (b)(3)(i)(A) of this section, the one or more prescriptions between adopted § 170.205(a)(3) through (5), technology must be able to receive and pharmacies (RxTransferRequest, technology must be able to demonstrate transmit the reason for the prescription RxTransferResponse, that the transition of care/referral using the diagnosis elements in the DRU RxTransferConfirm). summary received can be properly Segment. (7) Recertify the continued matched to the correct patient. (C) Optional: For each transaction administration of a medication order (iii) Reconciliation. Enable a user to listed in paragraph (b)(3)(i)(A) of this (Recertification). reconcile the data that represent a section, the technology must be able to (8) Complete Risk Evaluation and patient’s active medication list, allergies receive and transmit the reason for Mitigation Strategy (REMS) transactions and intolerance list, and problem list as prescription using the indication (REMSInitiationRequest, follows. For each list type: elements in the SIG Segment. REMSInitiationResponse, (A) Simultaneously display (i.e., in a (D) Limit a user’s ability to prescribe REMSRequest, and REMSResponse). single view) the data from at least two all oral liquid medications in only (9) Electronic prior authorization sources in a manner that allows a user metric standard units of mL (i.e., not cc). transactions (PAInitiationRequest, to view the data and their attributes, (E) Always insert leading zeroes PAInitiationResponse, PARequest, which must include, at a minimum, the before the decimal point for amounts PAResponse, PAAppealRequest, source and last modification date. less than one and must not allow PAAppealResponse, PACancelRequest, (B) Enable a user to create a single trailing zeroes after a decimal point and PACancelResponse). reconciled list of each of the following: when a user prescribes medications. (C) For the following prescription- Medications; Allergies and Intolerances; (ii) For technology certified related transactions, the technology and problems. subsequent to June 30, 2020: must be able to receive and transmit the

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00302 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25943

reason for prescription using the re-disclosure according to the standard measures in § 170.205(h)(3) and CMS diagnosis elements: adopted in § 170.205(o)(1) at the: implementation guide for QRDA, or : (A) Document, section, and entry category III for ambulatory measures in (1) Required transactions: (data element) level; or § 170.205 (k)(3). (i) Create new prescriptions (NewRx). (B) Document level for the period * * * * * (ii) Request and respond to change until May 2, 2022; and (d) * * * prescriptions (RxChangeRequest, (ii) Preserve privacy markings to (12) Encrypt authentication RxChangeResponse). ensure fidelity to the tagging based on credentials. Health IT developers must (iii) Cancel prescriptions (CancelRx). consent and with respect to sharing and make one of the following attestations (iv) Request and respond to renew re-disclosure restrictions. and may provide the specified prescriptions (RxRenewalRequest, (9) Care plan. Enable a user to record, accompanying information, where RxRenewalResponse). change, access, create, and receive care applicable: (v) Receive fill status notifications plan information in accordance with: (i) Yes—the Health IT Module (RxFill). (i) The Care Plan document template, encrypts stored authentication (vi) Receive medication history including the Health Status Evaluations credentials in accordance with (RxHistoryResponse). and Outcomes Section and standards adopted in § 170.210(a)(2). (2) Optional transactions: Interventions Section (V2), in the (ii) No—the Health IT Module does (i) Request to send an additional standard specified in § 170.205(a)(4); not encrypt stored authentication supply of medication (Resupply) and credentials. When attesting ‘‘no,’’ the (ii) The standard in § 170.205(a)(5)) on (ii) Request and respond to transfer health IT developer may explain why and after May 2, 2022. one or more prescriptions between the Health IT Module does not support (10) Electronic Health Information pharmacies (RxTransferRequest, encrypting stored authentication export—(i) Single patient electronic RxTransferResponse) credentials. health information export. (A) Enable a (iii) Complete Risk Evaluation and (13) Multi-factor authentication. user to timely create an export file(s) Mitigation Strategy (REMS) transactions Health IT developers must make one of with all of a single patient’s electronic (REMSInitiationRequest, the following attestations and, as health information that can be stored at REMSInitiationResponse, applicable, provide the specified the time of certification by the product, REMSRequest, and REMSResponse). accompanying information: (iv) Electronic prior authorization of which the Health IT Module is a part. (B) A user must be able to execute this (i) Yes—the Health IT Module (ePA) transactions (PAInitiationRequest, supports the authentication, through PAInitiationResponse, PARequest, capability at any time the user chooses and without subsequent developer multiple elements, of the user’s identity PAResponse, PAAppealRequest, with the use of industry-recognized PAAppealResponse and assistance to operate. (C) Limit the ability of users who can standards. When attesting ‘‘yes,’’ the PACancelRequest, PACancelResponse). health IT developer must describe the (D) Optional: For each transaction create export file(s) in at least one of these two ways: use cases supported. listed in paragraph (b)(3)(ii)(C) of this (ii) No—the Health IT Module does section, the technology must be able to (1) To a specific set of identified users (2) As a system administrative not support authentication, through receive and transmit reason for function. multiple elements, of the user’s identity prescription using the (D) The export file(s) created must be with the use of industry-recognized element in the SIG electronic and in a computable format. standards. When attesting ‘‘no,’’ the segment. (E) The publicly accessible hyperlink health IT developer may explain why (E) Limit a user’s ability to prescribe of the export’s format must be included the Health IT Module does not support all oral liquid medications in only with the exported file(s). authentication, through multiple metric standard units of mL (i.e., not cc). (ii) Patient population electronic elements, of the user’s identify with the (F) Always insert leading zeroes health information export. Create an use of industry-recognized standards. before the decimal point for amounts export of all the electronic health (e) * * * less than one and must not allow information that can be stored at the (1) * * * trailing zeroes after a decimal point time of certification by the product, of (i) * * * when a user prescribes medications. which the Health IT Module is a part. (A) * * * * * * * * (A) The export created must be (1) The data classes expressed in the (7) Security tags—summary of care— electronic and in a computable format. standards in § 170.213 (which should be send. Enable a user to create a summary (B) The publicly accessible hyperlink in their English (i.e., non-coded) record formatted in accordance with the of the export’s format must be included representation if they associate with a standard adopted in § 170.205(a)(4) that with the exported file(s). vocabulary/code set), and in accordance is tagged as restricted and subject to (iii) Documentation. The export with § 170.205(a)(4) and (a)(5), and restrictions on re-disclosure according format(s) used to support paragraphs paragraphs (e)(1)(i)(A)(3)(i) through (iii) to the standard adopted in (b)(10)(i) and (ii) of this section must be of this section, or § 170.205(o)(1) at the: kept up-to-date. (2) The Common Clinical Data Set in (i) Document, section, and entry (data (c) * * * accordance with § 170.205(a)(4) and element) level; or (3) Clinical quality measures—report. paragraphs (e)(1)(i)(A)(3)(i) through (iv) (ii) Document level for the period Enable a user to electronically create a of this section for the period until May until May 2, 2022. data file for transmission of clinical 2, 2022. (8) Security tags—summary of care— quality measurement data in accordance (3) The following data classes: receive. (i) Enable a user to receive a with the applicable implementation (i) Assessment and plan of treatment. summary record that is formatted in specifications specified by the CMS In accordance with the ‘‘Assessment accordance with the standard adopted implementation guides for Quality and Plan Section (V2)’’ of the standard in § 170.205(a)(4) that is tagged as Reporting Document Architecture specified in § 170.205(a)(4); or in restricted and subject to restrictions on (QRDA), category I, for inpatient accordance with the ‘‘Assessment

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00303 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25944 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

Section (V2)’’ and ‘‘Plan of Treatment eligible to be included in the measure’s (ii) Reference C–CDA match. (A) For Section (V2)’’ of the standard specified numerator. The information in the health IT certified to (g)(6)(i)(A) of this in § 170.205(a)(4). report or file created must be of section, create a data file formatted in (ii) Goals. In accordance with the sufficient detail such that it enables a accordance with the standard adopted ‘‘Goals Section’’ of the standard user to match those patients or actions in § 170.205(a)(4) and (5) that matches a specified in § 170.205(a)(4). to meet the measure’s denominator gold-standard, reference data file. (iii) Health concerns. In accordance limitations when necessary to generate (B) For health IT certified to with the ‘‘Health Concerns Section’’ of an accurate percentage. (g)(6)(i)(B) of this section, create a data the standard specified in § 170.205(a)(4). (2) Automated measure calculation. file formatted in accordance with the (iv) Unique device identifier(s) for a For each Promoting Interoperability standard adopted in § 170.205(a)(4) that patient’s implantable device(s). In Programs percentage-based measure that matches a gold-standard, reference data accordance with the ‘‘Product Instance’’ is supported by a capability included in file. in the ‘‘Procedure Activity Procedure a technology, record the numerator and (iii) Document-template conformance. Section’’ of the standards specified in denominator and create a report (A) For health IT certified to (g)(6)(i)(A) § 170.205(a)(4). including the numerator, denominator, of this section, create a data file (4) Ambulatory setting only. and resulting percentage associated with formatted in accordance with the Provider’s name and office contact each applicable measure. standard adopted in § 170.205(a)(4) and information. (3) * * * (5) that demonstrates a valid (5) Inpatient setting only. Admission (i) User-centered design processes implementation of each document and discharge dates and locations; must be applied to each capability template applicable to the certification discharge instructions; and reason(s) for technology includes that is specified in criterion or criteria within the scope of hospitalization. the following certification criteria: the certificate sought. (6) Laboratory test report(s). Paragraphs (a)(1) through (5), (9), and (B) For health IT certified to Laboratory test report(s), including: (14), and (b)(2) and (3). (g)(6)(i)(B) of this section, create a data (i) The information for a test report as * * * * * file formatted in accordance with the specified all the data specified in 42 (6) Consolidated CDA creation standard adopted in § 170.205(a)(4) that CFR 493.1291(c)(1) through (7); performance. The following technical demonstrates a valid implementation of (ii) The information related to and performance outcomes must be each document template applicable to reference intervals or normal values as demonstrated related to Consolidated the certification criterion or criteria specified in 42 CFR 493.1291(d); and CDA creation. The capabilities required within the scope of the certificate (iii) The information for corrected under paragraphs (g)(6)(i) through (v) of sought. reports as specified in 42 CFR this section can be demonstrated in (iv) Vocabulary conformance. (A) For 493.1291(k)(2). tandem and do not need to be health IT certified to (g)(6)(i)(A) of this (7) Diagnostic image report(s). individually addressed in isolation or section, create a data file formatted in * * * * * sequentially. accordance with the standard adopted (f) * * * (i) This certification criterion’s scope in § 170.205(a)(4) and (5) that (5) * * * includes: demonstrates the required vocabulary (iii) * * * (A) The data classes expressed in the standards (and value sets) are properly (B) * * * standard in § 170.213, and in implemented. (1) The data classes expressed in the accordance with § 170.205(a)(4) and (5) (B) For health IT certified to standards in § 170.213, and in and paragraphs (g)(6)(i)(C)(1) through (3) (g)(6)(i)(B) of this section, create a data accordance with § 170.205(a)(4) and (5), of this section; or file formatted in accordance with the or (B) The Common Clinical Data Set in standard adopted in § 170.205(a)(4) that (2) The Common Clinical Data Set in accordance with § 170.205(a)(4) and demonstrates the required vocabulary accordance with § 170.205(a)(4) for the paragraphs (g)(6)(i)(C)(1) through (4) of standards (and value sets) are properly period until May 2, 2022. this section for the period until May 2, implemented. (3) Encounter diagnoses. Formatted 2022. (v) Completeness verification. Create a according to at least one of the following (C) The following data classes: data file for each of the applicable standards: (1) Assessment and plan of treatment. document templates referenced in (i) The standard specified in In accordance with the ‘‘Assessment paragraph (g)(6)(iii) of this section § 170.207(i). and Plan Section (V2)’’ of the standard without the omission of any of the data (ii) At a minimum, the version of the specified in § 170.205(a)(4); or in included in either paragraph (g)(6)(i)(A) standard specified in § 170.207(a)(4). accordance with the ‘‘Assessment or (B) of this section, as applicable. (4) The provider’s name, office Section (V2)’’ and ‘‘Plan of Treatment * * * * * contact information, and reason for Section (V2)’’ of the standard specified (9) * * * visit. in § 170.205(a)(4). (i) * * * (5) An identifier representing the row (2) Goals. In accordance with the (A)(1) Respond to requests for patient and version of the trigger table that ‘‘Goals Section’’ of the standard data (based on an ID or other token) for triggered the case report. specified in § 170.205(a)(4). all of the data classes expressed in the * * * * * (3) Health concerns. In accordance standards in § 170.213 at one time and (g) Design and performance—(1) with the ‘‘Health Concerns Section’’ of return such data (according to the Automated numerator recording. For the standard specified in § 170.205(a)(4). specified standards, where applicable) each Promoting Interoperability (4) Unique device identifier(s) for a in a summary record formatted in Programs percentage-based measure, patient’s implantable device(s). In accordance with § 170.205(a)(4) and (5) technology must be able to create a accordance with the ‘‘Product Instance’’ following the CCD document template, report or file that enables a user to in the ‘‘Procedure Activity Procedure and as specified in paragraphs review the patients or actions that Section’’ of the standard specified in (g)(9)(i)(A)(3)(i) through (iii) of this would make the patient or action § 170.205(a)(4). section, or

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00304 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25945

(2) The Common Clinical Data Set in the search criteria included in the variables and their types/structures, accordance with paragraphs implementation specification adopted exceptions and exception handling (g)(9)(i)(A)(3)(i) through (iv) of this in § 170.215(a)(4). methods and their returns. section for the period until May 2, 2022, (iii) Application registration. Enable (2) The software components and and an application to register with the configurations that would be necessary (3) The following data classes: Health IT Module’s ‘‘authorization for an application to implement in order (i) Assessment and plan of treatment. server.’’ to be able to successfully interact with In accordance with the ‘‘Assessment (iv) Secure connection. (A) Establish a the API and process its response(s). and Plan Section (V2)’’ of the standards secure and trusted connection with an (3) All applicable technical specified in § 170.205(a)(4); or in application that requests data for patient requirements and attributes necessary accordance with the ‘‘Assessment and user scopes in accordance with the for an application to be registered with Section (V2)’’ and ‘‘Plan of Treatment implementation specifications adopted a Health IT Module’s authorization Section (V2)’’ of the standards specified in § 170.215(a)(2) and (3). server. in § 170.205(a)(4). (B) Establish a secure and trusted (B) The documentation used to meet (ii) Goals. In accordance with the connection with an application that paragraph (g)(10)(viii)(A) of this section ‘‘Goals Section’’ of the standards requests data for system scopes in must be available via a publicly specified in § 170.205(a)(4). accordance with the implementation accessible hyperlink without any (iii) Health concerns. In accordance specification adopted in § 170.215(a)(4). preconditions or additional steps. with the ‘‘Health Concerns Section’’ of (v) Authentication and * * * * * the standards specified in authorization—(A) Authentication and ■ 16. Add subpart D to part 170 to read § 170.205(a)(4). authorization for patient and user as follows: (iv) Unique device identifier(s) for a scopes—(1) First time connections—(i) patient’s implantable device(s). In Authentication and authorization must Subpart D—Conditions and Maintenance of accordance with the ‘‘Product Instance’’ occur during the process of granting Certification Requirements for Health IT Developers in the ‘‘Procedure Activity Procedure access to patient data in accordance Section’’ of the standards specified in with the implementation specification Sec. § 170.205(a)(4). 170.400 Basis and scope. adopted in § 170.215(a)(3) and standard 170.401 Information blocking. * * * * * adopted in § 170.215(b). 170.402 Assurances. (10) Standardized API for patient and (ii) An application capable of storing 170.403 Communications. population services. The following a client secret must be issued a refresh 170.404 Application programming technical outcomes and conditions must token valid for a period of no less than interfaces. be met through the demonstration of three months. 170.405 Real world testing. application programming interface (2) Subsequent connections. (i) Access 170.406 Attestations. technology. must be granted to patient data in (i) Data response. (A) Respond to accordance with the implementation Subpart D—Conditions and requests for a single patient’s data specification adopted in § 170.215(a)(3) Maintenance of Certification according to the standard adopted in without requiring re-authorization and Requirements for Health IT Developers § 170.215(a)(1) and implementation re-authentication when a valid refresh § 170.400 Basis and scope. specification adopted in § 170.215(a)(2), token is supplied by the application. This subpart implements section including the mandatory capabilities (ii) An application capable of storing 3001(c)(5)(D) of the Public Health described in ‘‘US Core Server a client secret must be issued a new Service Act by setting forth certain CapabilityStatement,’’ for each of the refresh token valid for a new period of Conditions and Maintenance of data included in the standard adopted no less than three months. Certification requirements for health IT (B) Authentication and authorization in § 170.213. All data elements developers participating in the ONC for system scopes. Authentication and indicated as ‘‘mandatory’’ and ‘‘must Health IT Certification Program. support’’ by the standards and authorization must occur during the implementation specifications must be process of granting an application § 170.401 Information blocking. supported. access to patient data in accordance (a) Condition of Certification (B) Respond to requests for multiple with the ‘‘SMART Backend Services: requirement. A health IT developer patients’ data as a group according to Authorization Guide’’ section of the must not take any action that constitutes the standard adopted in § 170.215(a)(1), implementation specification adopted information blocking as defined in 42 and implementation specifications in § 170.215(a)(4) and the application U.S.C. 300jj–52 and § 171.103 on or after adopted in § 170.215(a)(2) and (4), for must be issued a valid access token. November 2, 2020. each of the data included in the (vi) Patient authorization revocation. (b) [Reserved] standard adopted in § 170.213. All data A Health IT Module’s authorization elements indicated as ‘‘mandatory’’ and server must be able to revoke an § 170.402 Assurances. ‘‘must support’’ by the standards and authorized application’s access at a (a) Condition of Certification implementation specifications must be patient’s direction. requirement. (1) A health IT developer supported. (vii) Token introspection. A Health IT must provide assurances satisfactory to (ii) Supported search operations. (A) Module’s authorization server must be the Secretary that the health IT Respond to search requests for a single able to receive and validate tokens it has developer will not take any action that patient’s data consistent with the search issued. constitutes information blocking as criteria included in the implementation (viii) Documentation. (A) The API(s) defined in 42 U.S.C. 300jj–52 and specification adopted in § 170.215(a)(2), must include complete accompanying § 171.103 on and after November 2, specifically the mandatory capabilities documentation that contains, at a 2020, unless for legitimate purposes as described in ‘‘US Core Server minimum: specified by the Secretary; or any other CapabilityStatement.’’ (1) API syntax, function names, action that may inhibit the appropriate (B) Respond to search requests for required and optional parameters exchange, access, and use of electronic multiple patients’ data consistent with supported and their data types, return health information.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00305 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25946 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

(2) A health IT developer must ensure restricts a communication regarding the existing in the developer’s health IT that its health IT certified under the subject matters enumerated in (including third-party intellectual ONC Health IT Certification Program paragraph (a)(1) of this section, unless property), provided that any prohibition conforms to the full scope of the the practice is specifically permitted by or restriction imposed by a developer certification criteria. this paragraph and complies with all must be no broader than necessary to (3) A health IT developer must not applicable requirements of this protect the developer’s legitimate take any action that could interfere with paragraph. intellectual property interests and a user’s ability to access or use certified (i) Unqualified protection for certain consistent with all other requirements of capabilities for any purpose within the communications. A health IT developer paragraph (a)(2)(ii) of this section. A full scope of the technology’s must not prohibit or restrict any person restriction or prohibition is deemed certification. or entity from communicating any broader than necessary and inconsistent (4) A health IT developer of a certified information whatsoever (including with the requirements of paragraph Health IT Module that is part of a heath proprietary information, confidential (a)(2)(ii) of this section if it would IT product which electronically stores information, and intellectual property) restrict or preclude a public display of EHI must certify to the certification when the communication is about one a portion of a work subject to copyright criterion in § 170.315(b)(10). or more of the subject matters protection (without regard to whether (b) Maintenance of Certification enumerated in paragraph (a)(1) of this the copyright is registered) that would requirements. (1) A health IT developer section and is made for any of the reasonably constitute a ‘‘fair use’’ of that must retain all records and information following purposes: work. necessary to demonstrate initial and (A) Making a disclosure required by (D) Screenshots and video. A health ongoing compliance with the law; IT developer may require persons who requirements of the ONC Health IT (B) Communicating information about communicate screenshots or video to— Certification Program for: adverse events, hazards, and other (1) Not alter the screenshots or video, (i) A period of 10 years beginning unsafe conditions to government except to annotate the screenshots or from the date a developer’s Health IT agencies, health care accreditation video or resize the screenshots or video; Module(s) is first certified under the organizations, and patient safety (2) Limit the sharing of screenshots to Program; or organizations; the relevant number of screenshots (ii) If for a shorter period of time, a (C) Communicating information about needed to communicate about the period of 3 years from the effective date cybersecurity threats and incidents to health IT regarding one or more of the that removes all of the certification government agencies; six subject areas in paragraph (a)(1) of criteria to which the developer’s health (D) Communicating information about this section; and IT is certified from the Code of Federal information blocking and other (3) Limit the sharing of video to: Regulations. unlawful practices to government (i) The relevant amount of video (2)(i) Within 36 months of May 1, agencies; or needed to communicate about the 2020, a health IT developer that must (E) Communicating information about health IT regarding one or more of the comply with the requirements of a health IT developer’s failure to comply six subject areas in paragraph (a)(1) of paragraph (a)(4) of this section must with a Condition of Certification this section; and provide all of its customers of certified requirement, or with any other (ii) Only videos that address temporal health IT with the health IT certified to requirement of this part, to ONC or an matters that cannot be communicated the certification criterion in ONC–ACB. through screenshots or other forms of § 170.315(b)(10). (ii) Permitted prohibitions and communication. (ii) On and after 36 months from May restrictions. For communications about (E) Pre-market testing and 1, 2020, a health IT developer that must one or more of the subject matters development. A health IT developer comply with the requirements of enumerated in paragraph (a)(1) of this may prohibit or restrict communications paragraph (a)(4) of this section must section that is not entitled to that disclose information or knowledge provide all of its customers of certified unqualified protection under paragraph solely acquired in the course of health IT with the health IT certified to (a)(2)(i) of this section, a health IT participating in pre-market product the certification criterion in developer may prohibit or restrict development and testing activities § 170.315(b)(10). communications only as expressly carried out for the benefit of the § 170.403 Communications. permitted by paragraphs (a)(2)(ii)(A) developer or for the joint benefit of the developer and communicator. A (a) Condition of Certification through (E) of this section. developer must not, once the subject requirements. (1) A health IT developer (A) Developer employees and health IT is released or marketed for may not prohibit or restrict any contractors. (1) A health IT developer purposes other than product communication regarding— may prohibit or restrict the (i) The usability of its health IT; communications of the developer’s development and testing, and subject to (ii) The interoperability of its health employees or contractors. the permitted prohibitions and IT; (2) A self-developer must not prohibit restrictions described in paragraph (iii) The security of its health IT; or restrict communications of users of (a)(2)(ii) of this section, prohibit or (iv) Relevant information regarding their health IT who are also employees restrict communications about matters users’ experiences when using its health or contractors. enumerated in paragraph (a)(1) of this IT; (B) Non-user-facing aspects of health section. (v) The business practices of IT. A health IT developer may prohibit (b) Maintenance of Certification developers of health IT related to or restrict communications that disclose requirements—(1) Notice. Health IT exchanging electronic health information about non-user-facing developers must issue a written notice information; and aspects of the developer’s health IT. to all customers and those with which (vi) The manner in which a user of the (C) Intellectual property. A health IT it has contracts or agreements health IT has used such technology. developer may prohibit or restrict containing provisions that contravene (2) A health IT developer must not communications that involve the use or paragraph (a) of this section annually, engage in any practice that prohibits or disclosure of intellectual property beginning in calendar year 2020, until

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00306 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25947

paragraph (b)(2)(ii) of this section is (1) Needed to develop software facilitates competition with the Certified fulfilled, stating that any applications to interact with the API Developer. communication or contract provision certified API technology; (C) Prohibited fees. A Certified API that contravenes paragraph (a) of this (2) Needed to distribute, deploy, and Developer is prohibited from charging section will not be enforced by the enable the use of software applications fees for the following: health IT developer. in production environments that use the (1) Costs associated with intangible (2) Contracts and agreements. (i) A certified API technology; assets other than actual development or health IT developer must not establish, (3) Needed to use software acquisition costs of such assets; renew, or enforce any contract or applications, including to access, (2) Opportunity costs unrelated to the agreement that contravenes paragraph exchange, and use electronic health access, exchange, or use of electronic (a) of this section. information by means of the certified health information; and (ii) If a health IT developer has a API technology; (3) The permitted fees in this section contract or agreement in existence as of (4) Needed to use any electronic cannot include any costs that led to the November 2, 2020, that contravenes health information obtained by means of creation of intellectual property if the paragraph (a) of this section, then the the certified API technology; actor charged a royalty for that developer must amend the contract or (5) Used to verify the authenticity of intellectual property pursuant to agreement to remove or void the API Users; and § 171.303 and that royalty included the contractual provision that contravenes (6) Used to register software development costs for the creation of paragraph (a) of this section whenever applications. the intellectual property. the contract is next modified for other (B) API fees. Any and all fees charged (D) Record-keeping requirements. A reasons or renewed. by a Certified API Developer for the use Certified API Developer must keep for (c) Communication, defined. of its certified API technology must be inspection detailed records of any fees ‘‘Communication’’ as used in this described in detailed, plain language. charged with respect to the certified API section means any communication, The description of the fees must include technology, the methodology(ies) used irrespective of the form or medium. The all material information, including but to calculate such fees, and the specific term includes visual communications, not limited to: costs to which such fees are attributed. such as screenshots and video. (1) The persons or classes of persons (ii) Permitted fee—development, to whom the fee applies; deployment, and upgrades. A Certified § 170.404 Application programming (2) The circumstances in which the API Developer is permitted to charge interfaces. fee applies; and fees to an API Information Source to The following Condition and (3) The amount of the fee, which for recover the costs reasonably incurred by Maintenance of Certification variable fees must include the specific the Certified API Developer to develop, requirements apply to developers of variable(s) and methodology(ies) that deploy, and upgrade certified API Health IT Modules certified to any of will be used to calculate the fee. technology. the certification criteria adopted in (3) Fees conditions—(i) General (iii) Permitted fee—recovering API § 170.315(g)(7) through (10). conditions—(A) All fees. All fees related usage costs. A Certified API Developer (a) Condition of certification to certified API technology not is permitted to charge fees to an API requirements—(1) General. A Certified otherwise permitted by this section are Information Source related to the use of API Developer must publish APIs and prohibited from being imposed by a certified API technology. The fees must allow electronic health information Certified API Developer. The permitted be limited to the recovery of from such technology to be accessed, fees in paragraphs (a)(3)(ii) and (iv) of incremental costs reasonably incurred exchanged, and used without special this section may include fees that result by the Certified API Developer when it effort through the use of APIs or in a reasonable profit margin in hosts certified API technology on behalf successor technology or standards, as accordance with § 171.302. of the API Information Source. provided for under applicable law, (B) Permitted fees requirements. For (iv) Permitted fee—value-added including providing access to all data all permitted fees, a Certified API services. A Certified API Developer is elements of a patient’s electronic health Developer must: permitted to charge fees to an API User record to the extent permissible under (1) Ensure that such fees are based on for value-added services related to applicable privacy laws. objective and verifiable criteria that are certified API technology, so long as such (2) Transparency conditions—(i) uniformly applied to all similarly services are not necessary to efficiently Complete business and technical situated API Information Sources and and effectively develop and deploy documentation. A Certified API API Users; production-ready software that interacts Developer must publish complete (2) Ensure that such fees imposed on with certified API technology. business and technical documentation, API Information Sources are reasonably (4) Openness and pro-competitive including the documentation described related to the Certified API Developer’s conditions; general condition. A in paragraph (a)(2)(ii) of this section, via costs to supply certified API technology Certified API Developer must grant an a publicly accessible hyperlink that to, and if applicable, support certified API Information Source the allows any person to directly access the API technology for, API Information independent ability to permit an API information without any preconditions Sources; User to interact with the certified API or additional steps. (3) Ensure that such fees to supply technology deployed by the API (ii) Terms and conditions—(A) and, if applicable, support certified API Information Source. Material information. A Certified API technology are reasonably allocated (i) Non-discrimination. (A) A Certified Developer must publish all terms and among all similarly situated API API Developer must provide certified conditions for its certified API Information Sources; and API technology to an API Information technology, including any fees, (4) Ensure that such fees are not based Source on terms that are no less restrictions, limitations, obligations, on whether API Information Sources or favorable than it provides to itself and registration process requirements, or API Users are competitors, potential its own customers, suppliers, partners, other similar requirements that would competitors, or will be using the and other persons with whom it has a be: certified API technology in a way that business relationship.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00307 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25948 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

(B) The terms on which a Certified Developer must make reasonable efforts (4) Compliance for existing certified API Developer provides certified API to maintain the compatibility of its API technology. By no later than technology must be based on objective certified API technology and to November 2, 2020, a Certified API and verifiable criteria that are uniformly otherwise avoid disrupting the use of Developer with Health IT Module(s) applied to all substantially similar or certified API technology in production certified to the certification criteria in similarly situated classes of persons and environments. § 170.315(g)(7), (8), or (9) must comply requests. (B) Changes to terms and conditions. with paragraph (a) of this section, (C) A Certified API Developer must Except as exigent circumstances require, including revisions to their existing not offer different terms or services prior to making changes to its certified business and technical API based on: API technology or to the terms and documentation and make such (1) Whether a competitive conditions thereof, a Certified API documentation available via a publicly relationship exists or would be created; Developer must provide notice and a accessible hyperlink that allows any (2) The revenue or other value that reasonable opportunity for API person to directly access the another party may receive from using Information Sources and API Users to information without any preconditions the API technology. update their applications to preserve or additional steps. (ii) Rights to access and use certified compatibility with certified API (c) Definitions. The following API technology—(A) Rights that must be technology and to comply with definitions apply to this section: granted. A Certified API Developer must applicable terms and conditions. API Information Source means an have and, upon request, must grant to (b) Maintenance of certification organization that deploys certified API API Information Sources and API Users requirements—(1) Authenticity technology created by a ‘‘Certified API all rights that may be reasonably verification and registration for Developer;’’ necessary to: production use. The following apply to API User means a person or entity that (1) Access and use the Certified API a Certified API Developer with a Health creates or uses software applications Developer’s certified API technology in IT Module certified to the certification that interact with the ‘‘certified API a production environment; criterion adopted in § 170.315(g)(10): technology’’ developed by a ‘‘Certified (2) Develop products and services that (i) Authenticity verification. A API Developer’’ and deployed by an are designed to interact with the Certified API Developer is permitted to ‘‘API Information Source;’’ Certified API Developer’s certified API institute a process to verify the Certified API Developer means a technology; and authenticity of API Users so long as health IT developer that creates the (3) Market, offer, and distribute such process is objective and the same ‘‘certified API technology’’ that is products and services associated with for all API Users and completed within certified to any of the certification the Certified API Developer’s certified ten business days of receipt of an API criteria adopted in § 170.315(g)(7) API technology. User’s request to register their software (B) Prohibited conduct. A Certified through (10); and application for use with the Certified Certified API technology means the API Developer is prohibited from API Developer’s Health IT Module capabilities of Health IT Modules that conditioning the receipt of the rights certified to § 170.315(g)(10). are certified to any of the API-focused described in paragraph (a)(4)(ii)(A) of (ii) Registration for production use. A certification criteria adopted in this section on: Certified API Developer must register (1) Receiving a fee, including but not § 170.315(g)(7) through (10). and enable all applications for limited to a license fee, royalty, or production use within five business § 170.405 Real world testing. revenue-sharing arrangement; (a) Condition of Certification (2) Agreeing to not compete with the days of completing its verification of an requirement. A health IT developer with Certified API Developer in any product, API User’s authenticity, pursuant to Health IT Module(s) certified to any one service, or market; paragraph (b)(1)(i) of this section. (3) Agreeing to deal exclusively with (2) Service base URL publication. A or more 2015 Edition certification the Certified API Developer in any Certified API Developer must publish criteria in § 170.315(b), (c)(1) through product, service, or market; the service base URLs for all Health IT (3), (e)(1), (f), (g)(7) through (10), and (h) (4) Obtaining additional licenses, Modules certified to § 170.315(g)(10) must successfully test the real world use products, or services that are not related that can be used by patients to access of those Health IT Module(s) for to or can be unbundled from the their electronic health information. The interoperability (as defined in 42 certified API technology; Certified API Developer must publicly U.S.C.300jj(9) and § 170.102) in the type (5) Licensing, granting, assigning, or publish the service base URLs: of setting in which such Health IT transferring any intellectual property to (i) For all of its customers regardless Module(s) would be/is marketed. the Certified API Developer; of whether the Health IT Modules (b) Maintenance of Certification (6) Meeting any Certified API certified to § 170.315(g)(10) are centrally requirements—(1) Real world testing Developer-specific testing or managed by the Certified API Developer plan submission. A health IT developer certification requirements; and. or locally deployed by an API with Health IT Module(s) certified to (7) Providing the Certified API Information Source; and any one or more of the criteria Developer or its technology with (ii) In a machine-readable format at no referenced in paragraph (a) of this reciprocal access to application data. charge. section must submit to its ONC–ACB an (iii) Service and support obligations. (3) Rollout of (g)(10)-certified APIs. A annual real world testing plan A Certified API Developer must provide Certified API Developer with certified addressing each of those certified Health all support and other services API technology previously certified to IT Modules by a date determined by the reasonably necessary to enable the the certification criterion in ONC–ACB that enables the ONC–ACB effective development, deployment, and § 170.315(g)(8) must provide all API to publish a publicly available use of certified API technology by API Information Sources with such certified hyperlink to the plan on CHPL no later Information Sources and API Users in API technology deployed with certified than December 15 of each calendar year. production environments. API technology certified to the (i) The plan must be approved by a (A) Changes and updates to certified certification criterion in § 170.315(g)(10) health IT developer authorized API technology. A Certified API by no later than May 2, 2022. representative capable of binding the

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00308 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25949

health IT developer for execution of the paragraph (a) of this section by a date § 170.315(b)(7) and/or § 170.315(b)(8) plan and include the representative’s determined by the ONC–ACB that prior to May 1, 2020, must: contact information. enables the ONC–ACB to publish a (i) Update their certified health IT to (ii) The plan must include all health publicly available hyperlink to the be compliant with the revised versions IT certified to any one or more of the results report on CHPL no later than of the criteria adopted in § 170.315(b)(7) criteria referenced in paragraph (a) of March 15 of each calendar year. The real and/or the revised versions of the this section as of August 31 of the year world testing results must report the criteria adopted in § 170.315(b)(8); and in which the plan is submitted, and following for each of the certification (ii) Provide its customers of the address the real world testing to be criteria identified in paragraph (a) of previously certified health IT with conducted in the calendar year this section that are included in the certified health IT that meets paragraph immediately following plan submission. Health IT Module’s scope of (b)(6)(i) of this section by May 2, 2022. (iii) The plan must address the certification: (7) ASTM updates. A health IT following for each of the certification (A) The method(s) that was used to developer with health IT certified to criteria identified in paragraph (a) of demonstrate real world interoperability; § 170.315(d)(2), (3), and/or (d)(10) prior this section that are included in each (B) The care setting(s) that was tested to May 1, 2020, must: Health IT Module’s scope of for real world interoperability; (i) Update their certified health IT to certification: (C) The voluntary updates to be compliant with § 170.210(e)(1) and standards and implementation (A) The testing method(s)/ the standard specified in § 170.210(h); specifications that the National methodology(ies) that will be used to and Coordinator has approved through the demonstrate real world interoperability (ii) Provide its customers of the Standards Version Advancement and conformance to the full scope of the previously certified health IT with certification criterion’s requirements, Process; (D) A list of the key milestones met certified health IT that meets paragraph including scenario- and use case- (b)(7)(i) of this section by May 2, 2022. focused testing; during real world testing; (E) The outcomes of real world testing (8) Standards Version Advancement (B) The care setting(s) that will be Process—voluntary updates of certified tested for real world interoperability including a description of any challenges encountered during real health IT to newer versions of standards and an explanation for the health IT and implementation specifications. A developer’s choice of care setting(s) to world testing; and (F) At least one measurement/metric health IT developer subject to this test; paragraph (b) is permitted to update (C) For any standards and associated with the real world testing. Health IT Module(s) certified to any one implementation specifications (3) USCDI Updates for C–CDA. A or more of the certification criteria referenced by the criterion that the health IT developer with health IT referenced in paragraph (a) of this developer has chosen to certify to certified to § 170.315(b)(1), (b)(2), (e)(1), section to a newer version of any National Coordinator-approved newer (g)(6), (f)(5), and/or (g)(9) on May 1, 2020, must: adopted standard or implementation versions pursuant to paragraph (b)(8) or (i) Update their certified health IT to specification included in the criterion, (9) of this section, a description of how be compliant with the revised versions provided that newer version is approved the developer will test and demonstrate of these criteria adopted in this final by the National Coordinator for use in conformance to all requirements of the rule; and certifications issued under the ONC criterion using all versions of the (ii) Provide its customers of the Health IT Certification Program. A adopted standards to which each Health previously certified health IT with developer that pursues such updates to IT Module was certified as of August 31 certified health IT that meets paragraph its certified Health IT Module(s) must: of the year in which the real world (b)(3)(i) of this section by May 2, 2022. (i) Provide advance notice to all testing plan is due. (4) C–CDA Companion Guide affected customers and its ONC–ACB— (D) A schedule of key real world Updates. A health IT developer with testing milestones; (A) Expressing its intent to update the health IT certified to § 170.315(b)(1), certified Health IT Module(s) to the (E) A description of the expected (b)(2), (b)(9), (e)(1), (g)(6), and/or (g)(9) outcomes of real world testing; National Coordinator-approved prior to May 1, 2020, must: advanced version of the standard (F) At least one measurement/metric (i) Update their certified health IT to associated with the real world testing; implementation specification; be compliant with the revised versions (B) The developer’s expectations for and of the Program criteria in the 2015 (G) A justification for the health IT how the update(s) will affect real world Edition; and interoperability for the Health IT developer’s real world testing approach. (ii) Provide its customers of the Module(s); (2) Real world testing results previously certified health IT with reporting. (i) If in the course of certified health IT that meets paragraph (C) Whether the developer intends to conducting real world testing the (b)(4)(i) of this section by May 2, 2022. continue to support the certificate(s) for developer discovers one or more non- (5) Electronic prescribing. A health IT the existing certified Health IT conformities with the full scope of any developer with health IT certified to Module(s) version(s) for some period of certification criterion under the § 170.315(b)(3) prior to November 2, time and how long or if the existing Program, the developer must report that 2020, must: certified Health IT Module(s) version(s) non-conformity to the ONC–ACB within (i) Update their certified health IT to will be deprecated; and 30 days. be compliant with the revised versions (ii) Successfully demonstrate (ii) For real world testing activities of this criteria adopted in conformance with approved more recent conducted during the immediately § 170.315(b)(3)(ii); and versions of the standard(s) or preceding calendar year, a health IT (ii) Provide its customers of the implementation specification(s) developer must submit to its ONC–ACB previously certified health IT with included in each certification criterion an annual real world testing results certified health IT that meets paragraph under which the developer chooses to report addressing each of its certified (b)(5)(i) of this section by May 2, 2022 update its certified Health IT Module(s). Health IT Modules that include (6) Security tags. A health IT (iii) Maintain the updated certified certification criteria referenced in developer with health IT certified to Health IT Module(s) in full conformance

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00309 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25950 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

with all applicable Program capable of binding the health IT matter involves an alleged violation requirements. developer, must provide the attestation within ONC’s purview under § 170.580 (9) Standards Version Advancement specified in paragraph (a) of this section that indicates a serious violation under Process—voluntary certification to semiannually for any Health IT Modules the ONC Health IT Certification Program newer versions of standards and that have or have had an active with potential consequences of implementation specifications. A Health certification at any time under the ONC suspension, certification termination, or IT developer is permitted to seek Health IT Certification Program during a certification ban. certification for its Health IT Module(s) the prior six months. (2) The official date of receipt of any to any one or more of the certification (2) [Reserved]. email between ONC or the National criteria referenced in paragraph (a) of Coordinator and an applicant for ONC– this section using a newer version of Subpart E—ONC Health IT Certification ACB status, an applicant for ONC–ATL any adopted standard(s) or Program status, an ONC–ACB, an ONC–ATL, implementation specification(s) § 170.501 [Amended] health IT developer, or a party to any included in the criterion without first proceeding under this subpart is the obtaining certification to the version of ■ 17. Amend § 170.501: date on which the email was sent. that adopted standard or ■ a. In paragraph (a), by removing the (b) In circumstances where it is implementation specification that is phrase ‘‘Complete EHRs,’’; necessary for an applicant for ONC– incorporated by reference in § 170.299, ■ b. In paragraph (b), by removing the ACB status, an applicant for ONC–ATL provided that the newer version is phrase ‘‘Complete EHRs and’’; and status, an ONC–ACB, an ONC–ATL, approved by the National Coordinator ■ c. By removing and reserving health IT developer, or a party to any for use in certifications issued under the paragraph (c). proceeding under this subpart to ONC Health IT Certification Program. § 170.502 [Amended] correspond or communicate with ONC Developers may, for each standard and or the National Coordinator by regular, implementation specification included ■ 18. Amend § 170.502: express, or certified mail, the official ■ in each criterion, choose on an itemized a. In the definition of ‘‘Deployment date of receipt for all parties will be the basis whether to seek certification to the site’’, by removing the phrase date of the delivery confirmation to the version incorporated by reference in ‘‘Complete EHR,’’; address on record. ■ § 170.299, or to one or more newer b. In the definition of ‘‘Development § 170.510 [Amended] version(s) approved by the National site’’, by removing the phrase Coordinator for use in Health IT Module ‘‘Complete EHR,’’; ■ 21. Amend § 170.510 by removing ■ certifications issued pursuant to section c. In the introductory text to the paragraph (a) and redesignating 3001(c)(5) of the Public Health Service definition of ‘‘Gap certification’’, by paragraphs (b) and (c) as paragraphs (a) Act, or to both. removing the phrase ‘‘Complete EHR and (b). or’’; ■ 22. Amend § 170.520 by revising ■ § 170.406 Attestations. d. By removing the definition of paragraph (a)(3) to read as follows: (a) Condition of Certification ‘‘ONC-Approved Accreditor or ONC– requirement. A health IT developer, or AA’’; § 170.520 Application. its authorized representative that is ■ e. In the definition of ‘‘ONC- (a) * * * capable of binding the health IT Authorized Certification Body or ONC– (3) Documentation that confirms that developer, must provide the Secretary ACB’’, by removing the phrase the applicant has been accredited to an attestation of compliance with the ‘‘Complete EHRs,’’; and ISO/IEC 17065 (for availability, see following Conditions and Maintenance ■ f. In the definition of ‘‘ONC- § 170.599), with an appropriate scope, of Certification requirements: Authorized Testing Lab or ONC–ATL,’’ by any accreditation body that is a (1) Section 170.401; by removing the phrase ‘‘Complete signatory to the Multilateral Recognition (2) Section 170.402, but only for EHRs and’’. Arrangement (MLA) with the § 170.402(a)(4) and (b)(2) if the health IT International Accreditation Forum §§ 170.503 and 170.504 [Removed and developer certified a Health IT Reserved] (IAF). Module(s) that is part of a health IT ■ * * * * * product which can store electronic 19. Remove and reserve §§ 170.503 ■ and 170.504. 23. Amend § 170.523: health information; ■ a. By revising paragraph (a); (3) Section 170.403; ■ 20. Revise § 170.505 to read as ■ b. By adding subject headings to (4) Section 170.404 if the health IT follows: paragraphs (b), (c), (d) introductory text, developer has a Health IT Module(s) § 170.505 Correspondence. and (e); certified to any of the certification ■ c. In paragraph (f) introductory text, criteria adopted in § 170.315(g)(7) (a) Correspondence and by adding a subject heading and through (10); and such health IT communication with ONC or the removing the phrase, ‘‘Complete EHRs,’’ developer must also ensure that health National Coordinator shall be conducted and; IT allows for health information to be by email, unless otherwise necessary or ■ d. By removing and reserving exchanged, accessed, and used, in the specified. paragraph (f)(2); manner described in § 170.404; and (1) Consideration for providing notice ■ e. Revising paragraphs (g) and (h); (5) Section 170.405 if a health IT beyond email, such as by regular, ■ f. Adding subject headings to developer has a Health IT Module(s) express, or certified mail, will be based paragraphs (i) introductory text and (j) certified to any one or more 2015 on, but not limited to, whether: The introductory text; Edition certification criteria in party requests use of correspondence ■ g. In paragraph (k) introductory text, § 170.315(b), (c)(1) through (3), (e)(1), (f), beyond email; the party has responded by adding a subject heading and (g)(7) through (10), and (h). via email to our communications; we removing the phrase ‘‘Complete EHRs (b) Maintenance of Certification have sufficient information from the and’’; requirement. (1) A health IT developer, party to ensure appropriate delivery of ■ h. In paragraph (k)(1), by removing the or its authorized representative that is any other method of notice; and the phrase ‘‘Complete EHR or’’;

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00310 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25951

■ i. By revising paragraphs (k)(1)(ii) and (1) * * * (o) Scope reduction. *** (iii); (ii) For a Health IT Module certified (p) Real world testing. (1) Review and ■ j. By removing and reserving to the 2015 Edition health IT confirm that applicable health IT paragraphs (k)(1)(iv)(B) and (C) and certification criteria, the information developers submit real world testing (k)(2) and (3); specified by paragraphs (f)(1)(i), (vi) plans in accordance with ■ k. By revising paragraph (k)(4); through (viii), (xv), and (xvi) of this § 170.405(b)(1). ■ l. By adding a subject heading to section as applicable for the specific (2) Review and confirm that paragraph (l); Health IT Module. applicable health IT developers submit ■ m. By revising paragraph (m); (iii) In plain language, a detailed real world testing results in accordance ■ n. In paragraph (o), by adding a description of all known material with § 170.405(b)(2). subject heading and removing the information concerning additional types (3) Submit real world testing plans by phrase ‘‘Complete EHR or’’; and of costs or fees that a user may be December 15 of each calendar year and ■ o. By adding paragraphs (p) through required to pay to implement or use the results by March 15 of each calendar (t). Health IT Module’s capabilities, year to ONC for public availability. The revisions and additions read as whether to meet provisions of HHS (q) Attestations. Review and submit follows: programs requiring the use of certified health IT developer Conditions and health IT or to achieve any other use Maintenance of Certification § 170.523 Principles of proper conduct for within the scope of the health IT’s requirements attestations made in ONC–ACBs. certification. The additional types of accordance with § 170.406 to ONC for * * * * * costs or fees required to be disclosed public availability. (a) Accreditation. Maintain its include but are not limited to costs or (r) Test results from ONC–ATLs. accreditation in good standing to ISO/ fees (whether fixed, recurring, Accept test results from any ONC–ATL IEC 17065 (incorporated by reference in transaction-based, or otherwise) that is: § 170.599). imposed by a health IT developer (or (1) In good standing under the ONC (b) Mandatory training. *** any third party from whom the Health IT Certification Program, and * * * * * developer purchases, licenses, or (2) Compliant with its ISO/IEC 17025 (c) Training program. *** obtains any technology, products, or accreditation requirements as required * * * * * services in connection with its certified by 170.524(a). (d) Reporting. *** health IT) to purchase, license, (s) Information for direct review. * * * * * implement, maintain, upgrade, use, or Report to ONC, no later than a week (e) Onsite observation. *** otherwise enable and support the use of after becoming aware of, any (f) Certified product listing. *** capabilities to which health IT is information that could inform whether certified; or in connection with any data ONC should exercise direct review * * * * * generated in the course of using any (g) Records retention. (1) Retain all under § 170.580(a). capability to which health IT is (t) Health IT Module voluntary records related to the certification of certified. standards and implementation Complete EHRs and Health IT Modules specifications updates notices. to an edition of certification criteria * * * * * Ensure (4) A certification issued to a Health beginning with the codification of an health IT developers opting to take IT Module based solely on the edition of certification criteria in the advantage of the flexibility for voluntary applicable certification criteria adopted Code of Federal Regulations through a updates of standards and by the ONC Health IT Certification minimum of 3 years from the effective implementation specifications in Program must be separate and distinct date that removes the applicable edition certified Health IT Modules per from any other certification(s) based on from the Code of Federal Regulations; § 170.405(b)(8) provide timely advance other criteria or requirements. written notice to the ONC–ACB and all and (l) Certification and Design Mark. (2) Make the records available to HHS affected customers. *** (1) Maintain a record of the date of upon request during the retention (m) Adaptations and updates. On a issuance and the content of developers’ period described in paragraph (g)(1) of quarterly basis each calendar year, § 170.405(b)(8) notices; and this section; obtain a record of: (2) Timely post content or make (h) Certification decision. Only certify (1) All adaptations of certified Health publicly accessible via the CHPL each Health IT Modules that have been: IT Modules; (1) Tested, using test tools and test § 170.405(b)(8) notice received, publicly (2) All updates made to certified on the CHPL attributed to the certified procedures approved by the National Health IT Modules affecting the Coordinator, by an: Health IT Module(s) to which it applies. capabilities in certification criteria to ■ 24. Amend § 170.524: (i) ONC–ATL; which the ‘‘safety-enhanced design’’ (ii) ONC–ATL, National Voluntary ■ a. By adding subject headings to criteria apply; paragraphs (a) through (c), (d) Laboratory Accreditation Program- (3) All uses cases for § 170.315(d)(13); accredited testing laboratory under the (4) All updates made to certified introductory text, and (e); ■ b. By revising paragraph (f); ONC Health IT Certification Program, Health IT Modules in compliance with ■ c. By adding a subject heading to and/or an ONC–ATCB for the purposes § 170.405(b)(3); and of performing gap certification; or (5) All updates to certified Health IT paragraph (g) and paragraph (h) (2) Evaluated by it for compliance Modules and all certifications of Health introductory text; and ■ d. In paragraph (h)(3), by removing the with a conformance method approved IT Modules issued including voluntary phrase ‘‘Complete EHRs and/or’’. by the National Coordinator. use of newer standards versions per The additions and revisions read as (i) Surveillance. *** § 170.405(b)(8) or (9). Record of these follows: * * * * * updates may be obtained by aggregation (j) Refunds. *** of ONC–ACB documentation of § 170.524 Principles of proper conduct for * * * * * certification activity. ONC–ATLs. (k) Disclosures. *** * * * * * * * * * *

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00311 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25952 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

(a) Accreditation. *** certifying a Health IT Module to the and (B), (d)(2)(ii) through (v), (d)(3), (b) Mandatory training. *** 2015 Edition health IT certification (12), and (13); and (c) Training program. *** criteria, an ONC–ACB can only issue a * * * * * (d) Reporting. *** certification to a Health IT Module if the (l) Conditions of certification * * * * * privacy and security certification attestations. Ensure that the health IT (e) Onsite observation. *** criteria in paragraphs (h)(3)(i) through developer of the Health IT Module has (f) Records retention. (1) Retain all (ix) of this section have also been met met its responsibilities under subpart D records related to the testing of (and are included within the scope of of this part. Complete EHRs and/or Health IT the certification). (m) Time-limited certification and Modules to an edition of certification (2) Testing. In order to be issued a certification status for certain 2015 criteria beginning with the codification certification, a Health IT Module would Edition certification criteria. An ONC– of an edition of certification criteria in only need to be tested once to each ACB may only issue a certification to a the Code of Federal Regulations through applicable privacy and security criterion Health IT Module and permit continued a minimum of three years from the in paragraphs (h)(3)(i) through (ix) of certified status for: effective date that removes the this section so long as the health IT (1) Section 170.315(a)(10) and (13) applicable edition from the Code of developer attests that such privacy and and § 170.315(e)(2) until January 1, Federal Regulations; and security capabilities apply to the full 2022. (2) Make the records available to HHS scope of capabilities included in the (2) Section 170.315(b)(6) until May 1, upon request during the retention requested certification, except for the 2023. period described in paragraph (f)(1) of following: (3) Section 170.315(g)(8) until May 2, this section; (i) A Health IT Module presented for 2022. (g) Approved testing methods. *** certification to § 170.315(e)(1) must be ■ 27. Amend § 170.555: (h) Refunds. *** separately tested to § 170.315(d)(9); and ■ a. In paragraph (a) by removing the * * * * * (ii) A Health IT Module presented for words ‘‘Complete EHRs and/or’’; and certification to § 170.315(e)(2) must be ■ § 170.545 [Removed and Reserved] b. By revising paragraph (b)(1). separately tested to § 170.315(d)(9). The revision reads as follows: ■ 25. Remove and reserve § 170.545. (3) Applicability. (i) Section ■ 26. Amend § 170.550 by: 170.315(a)(1) through (3), (5), (12), (14), § 170.555 Certification to newer versions of certain standards. ■ a. Adding subject headings to and (15) are also certified to the paragraphs (a),(b), and (d), and adding certification criteria specified in * * * * * paragraph (e); § 170.315(d)(1) through (7), (d)(12), and (b) * * * ■ b. Removing and reserving paragraph (13). (1) ONC–ACBs are not required to (f); (ii) Section 170.315(a)(4), (9), (10), certify Health IT Module(s) according to ■ c. Adding a subject heading to and (13) are also certified to the newer versions of standards adopted paragraph (g) introductory text and certification criteria specified in and named in subpart B of this part, adding paragraph (g)(5); § 170.315(d)(1) through (3), and (d)(5) unless: ■ d. Revising paragraph (h); and through (7), (d)(12), and (13). (i) The National Coordinator approves ■ e. Adding paragraphs (l) and (m). a newer version for use in certification (iii) Section 170.315(b)(1) through (3) The additions and revisions read as and a health IT developer voluntarily and (6) through (9) are also certified to follows: elects to seek certification of its health the certification criteria specified in IT in accordance with § 170.405(b)(9) or § 170.315(d)(1) through (3) and (d)(5) § 170.550 Health IT Module certification. update its certified health IT to the through (8), (12), and (13); (a) Certification scope. *** newer version in accordance with (b) Health IT product scope options. (iv) Section 170.315(c) is also certified § 170.405(b)(8); or *** to the certification criteria specified in (ii) The new version is incorporated * * * * * § 170.315(d)(1), (d)(2)(i)(A), (B), (d)(2)(ii) by reference in § 170.299. through (v), (d)(3), (5), (12), and (13); (d) Upgrades and enhancements. * * * * * *** (v) Section 170.315(e)(1) is also ■ 28. Amend § 170.556: (e) Standards updates. ONC–ACBs certified to the certification criteria ■ a. By removing the phrases ‘‘certified must provide an option for certification specified in § 170.315(d)(1) through (3), Complete EHR or’’ and ‘‘Complete EHR of Health IT Modules consistent with (5), (7), (9), (12), and (13); or’’, wherever they occur; § 171.405(b)(7) or (8) to any one or more (vi) Section 170.315(e)(2) and (3) is ■ b. By revising paragraph (a) of the criteria referenced in § 170.405(a) also certified to the certification criteria introductory text and paragraph (c) based on newer versions of standards specified in § 170.315(d)(1), (d)(2)(i)(A) introductory text; included in the criteria which have been and (B), (d)(2)(ii) through (v), (d)(3), (5), ■ c. By removing and reserving approved by the National Coordinator (9), (12), and (13); paragraph (c)(2); for use in certification. (vii) Section 170.315(f) is also ■ d. In paragraph (c)(3), by removing the certified to the certification criteria * * * * * phrase ‘‘certified Complete EHRs’’; and specified in § 170.315(d)(1) through (3), (g) Health IT module dependent ■ e. By removing paragraphs (c)(5) and (7), (12), and (13); criteria. *** (6). (5) Section 170.315(b)(10) when a (viii) Section 170.315(g)(7) through The revisions read as follows: health IT developer presents a Health IT (10) is also certified to the certification Module for certification that can store criteria specified in § 170.315(d)(1), (9), § 170.556 In-the-field surveillance and electronic health information at the time (12), and (13); and (d)(2)(i)(A) and (B), maintenance of certification for Health IT. of certification by the product, of which (d)(2)(ii) through (v), or (d)(10); (a) In-the-field surveillance. the Health IT Module is a part. (ix) Section 170.315(h) is also Consistent with its accreditation under (h) Privacy and security certification certified to the certification criteria 170.523(a) to ISO/IEC 17065 and the framework—(1) General rule. When specified in § 170.315(d)(1), (d)(2)(i)(A) requirements of this subpart, an ONC–

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00312 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25953

ACB must initiate surveillance ‘‘in the (c) Randomized surveillance. During §§ 170.560, 170.565, and 170.570 field’’ as necessary to assess whether a each calendar year surveillance period, [Amended] certified Health IT Module continues to an ONC–ACB may conduct in-the-field ■ 29. In the table below, for each section conform to the requirements in subparts surveillance for certain randomly and paragraph indicated in the first two A, B, C and E of this part once the selected Health IT Modules to which it columns, remove the phrase indicated certified Health IT Module has been has issued a certification. implemented and is in use in a in the third column: * * * * * production environment. * * * * *

Section Paragraphs Remove

§ 170.560 ...... (a)(2) ...... ‘‘Complete EHRs and/or’’ § 170.565 ...... (d)(1)(ii) and (iii) ...... ‘‘Complete EHRs or’’ § 170.565 ...... (h)(2)(iii) ...... ‘‘Complete EHRs and’’ § 170.570 ...... (a), (b)(2), (c) introductory text, and (c)(1) and (2) ...... ‘‘Complete EHRs and/or’’

§ 170.575 [Removed and Reserved] developer has not complied with a requirements of the ONC Health IT ■ 30. Remove and reserve § 170.575. Condition or Maintenance of Certification Program. ■ 31. Amend § 170.580: Certification requirement under subpart * * * * * ■ a. By revising paragraph (a)(1) and the D of this part. (iii) * * * subject headings to paragraphs (a)(2)(i) (3) * * * (D) Issue a notice of proposed and(ii); (i) ONC’s review of certified health IT termination if the health IT is under ■ b. By adding paragraph (a)(2)(iii); or a health IT developer’s actions or review in accordance with paragraph ■ c. By revising paragraphs (a)(3)(i), (iv), practices is independent of, and may be (a)(2)(i) or (ii) of this section. and (v); in addition to, any surveillance of (2) * * * ■ d. By adding paragraph (a)(4); certified health IT conducted by an (i) Circumstances that may trigger ■ e. By revising paragraphs (b)(1)(i) and ONC–ACB. notice of non-conformity. At any time (b)(1)(iii)(D), (b)(2)(i), and (b)(3)(i) and * * * * * during its review of certified health IT (ii); (iv) An ONC–ACB and ONC–ATL or a health IT developer’s actions or ■ f. By adding paragraphs (b)(3)(iii) and shall provide ONC with any available practices under paragraph (a) of this (iv); information that ONC deems relevant to section, ONC may send a notice of non- ■ g. By revising paragraph (c)(1); its review of certified health IT or a conformity to the health IT developer if ■ h. In paragraphs (d)(1), (d)(2)(i)(C), health IT developer’s actions or it determines that certified health IT or and (d)(4), by removing the phrase practices. a health IT developer’s actions or ‘‘Complete EHR or’’; (v) ONC may end all or any part of its practices does not conform to the ■ i. In paragraph (d)(5), by removing the review of certified health IT or a health requirements of the ONC Health IT phrase ‘‘Complete EHRs or’’; IT developer’s actions or practices Certification Program. ■ j. By revising paragraphs (e)(1) under this section at any time and refer * * * * * introductory text and (f)(1); the applicable part of the review to the (3) *** ■ k. In paragraph (f)(2)(i)(C), by relevant ONC–ACB(s) if ONC (i) All records related to the removing the phrase ‘‘Complete EHR determines that doing so would serve development, testing, certification, or’’; and the effective administration or oversight implementation, maintenance and use ■ l. Revising paragraphs (g)(1) of the ONC Health IT Certification of its certified health IT; introductory text, (g)(1)(i), (g)(2), Program. (ii) Any complaint records related to (g)(3)(i), (g)(4), (g)(5)(i), and (g)(6)(v). (4) Coordination with the Office of the certified health IT; The revisions and additions read as Inspector General. (i) ONC may (iii) All records related to the follows: coordinate its review of a claim of Condition(s) and Maintenance of § 170.580 ONC review of certified health IT information blocking with the Office of Certification requirements, including or a health IT developer’s actions. Inspector General or defer to the Office marketing and distribution records, (a) * * * of Inspector General to lead a review of communications, and contracts; and (1) Purpose. ONC may directly review a claim of information blocking. (iv) Any other relevant information. certified health IT or a health IT (ii) ONC may rely on Office of (c) * * * developer’s actions or practices to Inspector General findings to form the (1) Applicability. If ONC determines determine whether either conform to the basis of a direct review action. that certified health IT or a health IT requirements of the ONC Health IT (b) * * * developer’s action or practice does not Certification Program. (1) * * * conform to requirements of the ONC (2) * * * (i) Circumstances that may trigger Health IT Certification Program, ONC (i) Certified health IT causing or notice of potential non-conformity. At shall notify the health IT developer of contributing to unsafe conditions. *** any time during its review of certified its determination and require the health (ii) Impediments to ONC–ACB health IT or a health IT developer’s IT developer to submit a proposed oversight of certified health IT. *** actions or practices under paragraph (a) corrective action plan. (iii) Noncompliance with a Condition of this section, ONC may send a notice * * * * * and Maintenance of Certification of potential non-conformity if it has a (e) * * * requirement. ONC may initiate direct reasonable belief that certified health IT (1) Applicability. Excluding situations review under this section if it has a or a health IT developer’s actions or of noncompliance with a Condition or reasonable belief that a health IT practices may not conform to the Maintenance of Certification

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00313 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25954 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

requirement under subpart D of this determination to suspend or terminate a § 170.581 Certification ban. part, ONC may propose to terminate a certification issued to a Health IT (a) Circumstances that may trigger a certification issued to a Health IT Module and/or an ONC determination certification ban. The certification of Module if: to issue a certification ban under any of a health IT developer’s health IT * * * * * § 170.581(a)(2) if the health IT developer is prohibited when: (f) * * * asserts: (1) The certification of one or more of (1) Applicability. The National (i) ONC incorrectly applied ONC the health IT developer’s Health IT Coordinator may terminate a Health IT Certification Program Modules is: certification if: requirements for a: (i) Terminated by ONC under the (i) A determination is made that (A) Suspension; ONC Health IT Certification Program; termination is appropriate after (B) Termination; or (ii) Withdrawn from the ONC Health (C) Certification ban under considering the information provided by IT Certification Program by an ONC– § 170.581(a)(2). the health IT developer in response to ACB because the health IT developer the proposed termination notice; * * * * * requested it to be withdrawn (for (ii) The health IT developer does not (2) Method and place for filing an reasons other than to comply with respond in writing to a proposed appeal. A statement of intent to appeal Program requirements) when the health termination notice within the timeframe followed by a request for appeal must be IT developer’s health IT was the subject specified in paragraph (e)(3) of this submitted to ONC in writing by an of a potential non-conformity or non- section; or authorized representative of the health conformity as determined by ONC; (iii) A determination is made that the IT developer subject to the (iii) Withdrawn by an ONC–ACB health IT developer is noncompliant determination being appealed. The because of a non-conformity with any of with a Condition or Maintenance of statement of intent to appeal and the certification criteria adopted by the Certification requirement under subpart request for appeal must be filed in Secretary under subpart C of this part; D of this part or for the following accordance with the requirements (iv) Withdrawn by an ONC–ACB circumstances when ONC exercises specified in the notice of: because the health IT developer (i) Termination; direct review under paragraph (a)(2)(iii) requested it to be withdrawn (for of this section: (ii) Suspension; or (iii) Certification ban under reasons other than to comply with (A) The health IT developer fails to Program requirements) when the health timely respond to any communication § 170.581(a)(2). (3) * * * IT developer’s health IT was the subject from ONC, including, but not limited to: of surveillance for a certification (1) Fact-finding; (i) A statement of intent to appeal criterion or criteria adopted by the (2) A notice of potential non- must be filed within 10 days of a health Secretary under subpart C of this part, conformity within the timeframe IT developer’s receipt of the notice of: including notice of pending established in accordance with (A) Suspension; (B) Termination; or surveillance; or paragraph (b)(1)(ii)(A)(3) of this section; (C) Certification ban under (2) ONC determines a certification ban or § 170.581(a)(2). (3) A notice of non-conformity within is appropriate per its review under the timeframe established in accordance * * * * * § 170.580(a)(2)(iii). with paragraph (b)(2)(ii)(A)(3) of this (4) Effect of appeal. (i) A request for (b) Notice of certification ban. When section. appeal stays the termination of a ONC decides to issue a certification ban (B) The information or access certification issued to a Health IT to a health IT developer, ONC will provided by the health IT developer in Module, but the Health IT Module is notify the health IT developer of the response to any ONC communication, prohibited from being marketed, certification ban through a notice of including, but not limited to: Fact- licensed, or sold as ‘‘certified’’ during certification ban. The notice of finding, a notice of potential non- the stay. certification ban will include, but may conformity, or a notice of non- (ii) A request for appeal does not stay not be limited to: conformity is insufficient or incomplete; the suspension of a Health IT Module. (1) An explanation of the certification (C) The health IT developer fails to (iii) A request for appeal stays a ban; cooperate with ONC and/or a third party certification ban issued under (2) Information supporting the acting on behalf of ONC; § 170.581(a)(2). certification ban; (D) The health IT developer fails to (5) * * * (3) Instructions for appealing the (i) The hearing officer may not review timely submit in writing a proposed certification ban if banned in an appeal in which he or she corrective action plan; accordance with paragraph (a)(2) of this (E) The health IT developer fails to participated in the initial suspension, section; and timely submit a corrective action plan termination, or certification ban (4) Instructions for requesting that adequately addresses the elements determination or has a conflict of reinstatement into the ONC Health IT required by ONC as described in interest in the pending matter. Certification Program, which would lift paragraph (c) of this section; * * * * * the certification ban. (F) The health IT developer does not (6) * * * (c) Effective date of certification ban. fulfill its obligations under the (v) ONC will have an opportunity to (1) A certification ban will be effective corrective action plan developed in provide the hearing officer with a immediately if banned under paragraph accordance with paragraph (c) of this written statement and supporting (a)(1) of this section. section; or documentation on its behalf that (2) For certification bans issued under (G) ONC concludes that the non- clarifies, as necessary, its determination paragraph (a)(2) of this section, the ban conformity(ies) cannot be cured. to suspend or terminate the certification will be effective immediately after the * * * * * or issue a certification ban. following applicable occurrence: (g) * * * * * * * * (i) The expiration of the 10-day period (1) Basis for appeal. A health IT ■ 32. Revise § 170.581 to read as for filing a statement of intent to appeal developer may appeal an ONC follows: in § 170.580(g)(3)(i) if the health IT

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00314 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25955

developer does not file a statement of 171.101 Applicability. (b) Purpose. The purpose of this part intent to appeal. 171.102 Definitions. is to establish exceptions for reasonable (ii) The expiration of the 30-day 171.103 Information blocking. and necessary activities that do not period for filing an appeal in Subpart B—Exceptions That Involve Not constitute information blocking as § 170.580(g)(3)(ii) if the health IT Fulfilling Requests to Access, Exchange, or defined by section 3022(a)(1) of the developer files a statement of intent to use Electronic Health Information Public Health Service Act, 42 U.S.C. appeal, but does not file a timely appeal. 171.200 Availability and effect of 300jj–52. (iii) A final determination to issue a exceptions. certification ban per § 170.580(g)(7) if a 171.201 Preventing harm exception—when § 171.101 Applicability. health IT developer files an appeal will an actor’s practice that is likely to (a) This part applies to health care timely. interfere with the access, exchange, or providers, health IT developers of (d) Reinstatement. The certification of use of electronic health information in certified health IT, health information a health IT developer’s health IT subject order to prevent harm not be considered exchanges, and health information information blocking? to the prohibition in paragraph (a) of networks, as those terms are defined in 171.202 Privacy exception—when will an § 171.102. this section may commence once the actor’s practice of not fulfilling a request following conditions are met. to access, exchange, or use electronic (b) Health care providers, health IT (1) A health IT developer must health information in order to protect an developers of certified health IT, health request ONC’s permission in writing to individual’s privacy not be considered information exchanges, and health participate in the ONC Health IT information blocking? information networks must comply with Certification Program. 171.203 Security exception—when will an this part on and after November 2, 2020. (2) The request must demonstrate that actor’s practice that is likely to interfere § 171.102 Definitions. the customers affected by the certificate with the access, exchange, or use of termination, certificate withdrawal, or electronic health information in order to For purposes of this part: protect the security of electronic health Access means the ability or means noncompliance with a Condition or information not be considered Maintenance of Certification necessary to make electronic health information blocking? information available for exchange or requirement have been provided 171.204 Infeasibility exception—when will appropriate remediation. an actor’s practice of not fulfilling a use. (3) For noncompliance with a request to access, exchange, or use Actor means a health care provider, Condition or Maintenance of electronic health information due to the health IT developer of certified health Certification requirement, the infeasibility of the request not be IT, health information network or health noncompliance must be resolved. considered information blocking? information exchange. (4) ONC is satisfied with the health IT 171.205 Health IT performance exception— API Information Source is defined as developer’s demonstration under when will an actor’s practice that is it is in § 170.404(c). implemented to maintain or improve paragraph (d)(2) of this section that all API User is defined as it is in health IT performance and that is likely § 170.404(c). affected customers have been provided to interfere with the access, exchange, or with appropriate remediation and grants Certified API Developer is defined as use of electronic health information not it is in § 170.404(c). reinstatement into the ONC Health IT be considered information blocking? Certification Program. Certified API technology is defined as Subpart C—Exceptions That Involve it is in § 170.404(c). ■ 33. Amend § 170.599 by: Procedures for Fulfilling Requests to Electronic health information (EHI) ■ a. Redesignating paragraph (b)(4) as Access, Exchange, or use Electronic Health means electronic protected health paragraph (b)(5); Information ■ information as defined in 45 CFR b. Adding new paragraph (b)(4); and 171.300 Availability and effect of 160.103 to the extent that it would be ■ c. Revising newly redesignated exceptions. included in a designated record set as paragraph (b)(5). 171.301 Content and manner exception— defined in 45 CFR 164.501, regardless of The addition and revision read as when will an actor’s practice of limiting whether the group of records are used follows: the content of its response to or the manner in which it fulfills a request to or maintained by or for a covered entity § 170.599 Incorporation by Reference access, exchange, or use electronic as defined in 45 CFR 160.103, but EHI * * * * * health information not be considered shall not include: (b) * * * information blocking? (1) Psychotherapy notes as defined in (4) ISO/IEC 17025:2017(E)—General 171.302 Fees exception—when will an 45 CFR 164.501; or requirements for the competence of actor’s practice of charging fees for (2) Information compiled in accessing, exchanging, or using testing and calibration laboratories reasonable anticipation of, or for use in, electronic health information not be a civil, criminal, or administrative (Third Edition), 2017–11, ‘‘ISO/IEC considered information blocking? 17025,’’ IBR approved for §§ 170.520(b), 171.303 Licensing exception—when will an action or proceeding. and 170.524(a). actor’s practice to license Exchange means the ability for (5) ISO/IEC 17065:2012(E)— interoperability elements in order for electronic health information to be Conformity assessment—Requirements electronic health information to be transmitted between and among for bodies certifying products, processes accessed, exchanged, or used not be different technologies, systems, and services (First Edition), 2012, ‘‘ISO/ considered information blocking? platforms, or networks. IEC 17065,’’ IBR approved for Authority: 42 U.S.C. 300jj–52; 5 U.S.C. Fee means any present or future §§ 170.503 and 170.523(a). 552. obligation to pay money or provide any other thing of value. ■ 34. Add part 171 to read as follows: Subpart A—General Provisions Health care provider has the same PART 171—INFORMATION BLOCKING meaning as ‘‘health care provider’’ in 42 § 171.100 Statutory basis and purpose. U.S.C. 300jj. Subpart A—General Provisions (a) Basis. This part implements Health information network or health Sec. section 3022 of the Public Health information exchange means an 171.100 Statutory basis and purpose. Service Act, 42 U.S.C. 300jj–52. individual or entity that determines,

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00315 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25956 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

controls, or has the discretion to § 171.103 Information blocking. would otherwise arise from the access, administer any requirement, policy, or (a) Information blocking means a exchange, or use of electronic health agreement that permits, enables, or practice that— information affected by the practice. For requires the use of any technology or (1) Except as required by law or purposes of this section, ‘‘patient’’ services for access, exchange, or use of covered by an exception set forth in means a natural person who is the electronic health information: subpart B or subpart C of this part, is subject of the electronic health (1) Among more than two unaffiliated likely to interfere with access, exchange, information affected by the practice. individuals or entities (other than the or use of electronic health information; (b) Practice breadth. The practice individual or entity to which this and must be no broader than necessary to definition might apply) that are enabled (2) If conducted by a health substantially reduce the risk of harm to exchange with each other; and information technology developer, that the practice is implemented to (2) That is for a treatment, payment, health information network or health reduce. or health care operations purpose, as information exchange, such developer, (c) Type of risk. The risk of harm such terms are defined in 45 CFR network or exchange knows, or should must: 164.501 regardless of whether such know, that such practice is likely to (1) Be determined on an individuals or entities are subject to the interfere with, prevent, or materially individualized basis in the exercise of requirements of 45 CFR parts 160 and discourage access, exchange, or use of professional judgment by a licensed 164. electronic health information; or health care professional who has a (3) If conducted by a health care Health IT developer of certified health current or prior clinician-patient provider, such provider knows that such IT means an individual or entity, other relationship with the patient whose practice is unreasonable and is likely to than a health care provider that self- electronic health information is affected interfere with, prevent, or materially develops health IT for its own use, that by the determination; or discourage access, exchange, or use of develops or offers health information (2) Arise from data that is known or electronic health information. reasonably suspected to be technology (as that term is defined in 42 (b) Until May 2, 2022, electronic U.S.C. 300jj(5)) and which has, at the misidentified or mismatched, corrupt health information for purposes of due to technical failure, or erroneous for time it engages in a practice that is the paragraph (a) of this section is limited subject of an information blocking another reason. to the electronic health information (d) Type of harm. The type of harm claim, one or more Health IT Modules identified by the data elements certified under a program for the must be one that could serve as grounds represented in the USCDI standard for a covered entity (as defined in voluntary certification of health adopted in § 170.213. information technology that is kept or § 160.103 of this title) to deny access (as recognized by the National Coordinator Subpart B—Exceptions That Involve the term ‘‘access’’ is used in part 164 of pursuant to 42 U.S.C. 300jj–11(c)(5) Not Fulfilling Requests To Access, this title) to an individual’s protected (ONC Health IT Certification Program). Exchange, or Use Electronic Health health information under: Information blocking is defined as it Information (1) Section 164.524(a)(3)(iii) of this is in § 171.103. title where the practice is likely to, or Interfere with or interference means to § 171.200 Availability and effect of in fact does, interfere with access, exceptions. prevent, materially discourage, or exchange, or use (as these terms are otherwise inhibit. A practice shall not be treated as defined in § 171.102) of the patient’s information blocking if the actor Interoperability element means electronic health information by their satisfies an exception to the information hardware, software, integrated legal representative (including but not blocking provision as set forth in this technologies or related licenses, limited to personal representatives subpart B by meeting all applicable technical information, privileges, rights, recognized pursuant to 45 CFR 164.502) requirements and conditions of the intellectual property, upgrades, or and the practice is implemented exception at all relevant times. services that: pursuant to an individualized determination of risk of harm consistent (1) May be necessary to access, § 171.201 Preventing harm exception— with paragraph (c)(1) of this section; exchange, or use electronic health when will an actor’s practice that is likely (2) Section 164.524(a)(3)(ii) of this information; and to interfere with the access, exchange, or title where the practice is likely to, or (2) Is/Are controlled by the actor, use of electronic health information in order to prevent harm not be considered in fact does, interfere with the patient’s which includes the ability to confer all information blocking? or their legal representative’s access to, rights and authorizations necessary to An actor’s practice that is likely to use or exchange (as these terms are use the element to enable the access, interfere with the access, exchange, or defined in § 171.102) of information that exchange, or use of electronic health use of electronic health information in references another natural person and information. order to prevent harm will not be the practice is implemented pursuant to Permissible purpose means a purpose considered information blocking when an individualized determination of risk for which a person is authorized, the practice meets the conditions in of harm consistent with paragraph (c)(1) permitted, or required to access, paragraphs (a) and (b) of this section, of this section; exchange, or use electronic health satisfies at least one condition from each (3) Section 164.524(a)(3)(i) of this title information under applicable law. of paragraphs (c), (d), and (f) of this where the practice is likely to, or in fact Person is defined as it is in 45 CFR section, and also meets the condition in does, interfere with the patient’s access, 160.103. paragraph (e) of this section when exchange, or use (as these terms are Practice means an act or omission by applicable. defined in § 171.102) of their own an actor. (a) Reasonable belief. The actor electronic health information, regardless Use means the ability for electronic engaging in the practice must hold a of whether the risk of harm that the health information, once accessed or reasonable belief that the practice will practice is implemented to substantially exchanged, to be understood and acted substantially reduce a risk of harm to a reduce is consistent with paragraph upon. patient or another natural person that (c)(1) or (2) of this section; or

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00316 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25957

(4) Section 164.524(a)(3)(i) of this title § 171.202 Privacy exception—when will an (ii) Are documented by the actor, on where the practice is likely to, or in fact actor’s practice of not fulfilling a request to a case-by-case basis, identifying the does, interfere with a legally permissible access, exchange, or use electronic health criteria used by the actor to determine information in order to protect an when the precondition would be access, exchange, or use (as these terms individual’s privacy not be considered are defined in § 171.102) of electronic information blocking? satisfied, any criteria that were not met, and the reason why the criteria were not health information not described in An actor’s practice of not fulfilling a met. paragraph (d)(1), (2), or (3) of this request to access, exchange, or use section, and regardless of whether the (2) If the precondition relies on the electronic health information in order to provision of a consent or authorization risk of harm the practice is implemented protect an individual’s privacy will not from an individual and the actor has to substantially reduce is consistent be considered information blocking received a version of such a consent or with paragraph (c)(1) or (2) of this when the practice meets all of the authorization that does not satisfy all section. requirements of at least one of the sub- elements of the precondition required (e) Patient right to request review of exceptions in paragraphs (b) through (e) under applicable law, the actor must: individualized determination of risk of of this section. (i) Use reasonable efforts within its (a) Definitions in this section. (1) The harm. Where the risk of harm is control to provide the individual with a term HIPAA Privacy Rule as used in this consent or authorization form that consistent with paragraph (c)(1) of this section means 45 CFR parts 160 and satisfies all required elements of the section, the actor must implement the 164. practice in a manner consistent with (2) The term individual as used in this precondition or provide other any rights the individual patient whose section means one or more of the reasonable assistance to the individual electronic health information is affected following— to satisfy all required elements of the may have under § 164.524(a)(4) of this (i) An individual as defined by 45 precondition; and (ii) Not improperly encourage or title, or any Federal, State, or tribal law, CFR 160.103. induce the individual to withhold the to have the determination reviewed and (ii) Any other natural person who is consent or authorization. potentially reversed. the subject of the electronic health information being accessed, exchanged, (3) For purposes of determining (f) Practice implemented based on an or used. whether the actor’s privacy policies and organizational policy or a determination (iii) A person who legally acts on procedures and actions satisfy the specific to the facts and circumstances. behalf of a person described in requirements of paragraphs (b)(1)(i) and The practice must be consistent with an paragraph (a)(1) or (2) of this section in (b)(2) above when the actor’s operations organizational policy that meets making decisions related to health care are subject to multiple laws which have paragraph (f)(1) of this section or, in the as a personal representative, in inconsistent preconditions, they shall be absence of an organizational policy accordance with 45 CFR 164.502(g). deemed to satisfy the requirements of applicable to the practice or to its use (iv) A person who is a legal the paragraphs if the actor has adopted in particular circumstances, the practice representative of and can make health uniform privacy policies and must be based on a determination that care decisions on behalf of any person procedures to address the more meets paragraph (f)(2) of this section. described in paragraph (a)(1) or (2) of restrictive preconditions. this section. (c) Sub-exception—health IT (1) An organizational policy must: (v) An executor, administrator, or developer of certified health IT not (i) Be in writing; other person having authority to act on covered by HIPAA. If the actor is a (ii) Be based on relevant clinical, behalf of a deceased person described in health IT developer of certified health technical, and other appropriate paragraph (a)(1) or (2) of this section or IT that is not required to comply with the HIPAA Privacy Rule, when engaging expertise; the individual’s estate under State or other law. in a practice that promotes the privacy (iii) Be implemented in a consistent (b) Sub-exception—precondition not interests of an individual, the actor’s and non-discriminatory manner; and satisfied. To qualify for the exception on organizational privacy policies must (iv) Conform each practice to the the basis that State or Federal law have been disclosed to the individuals conditions in paragraphs (a) and (b) of requires one or more preconditions for and entities that use the actor’s product this section, as well as the conditions in providing access, exchange, or use of or service before they agreed to use paragraphs (c) through (e) of this section electronic health information that have them, and must implement the practice that are applicable to the practice and not been satisfied, the following according to a process described in the its use. requirements must be met— organizational privacy policies. The (1) The actor’s practice is tailored to actor’s organizational privacy policies (2) A determination must: the applicable precondition not must: (i) Be based on facts and satisfied, is implemented in a consistent (1) Comply with State and Federal circumstances known or reasonably and non-discriminatory manner, and laws, as applicable; believed by the actor at the time the either: (2) Be tailored to the specific privacy determination was made and while the (i) Conforms to the actor’s risk or interest being addressed; and practice remains in use; and organizational policies and procedures (3) Be implemented in a consistent that: and non-discriminatory manner. (ii) Be based on expertise relevant to (A) Are in writing; (d) Sub-exception—denial of an implementing the practice consistent (B) Specify the criteria to be used by individual’s request for their electronic with the conditions in paragraphs (a) the actor to determine when the health information consistent with 45 and (b) of this section, as well as the precondition would be satisfied and, as CFR 164.524(a)(1) and (2). If an conditions in paragraphs (c) through (e) applicable, the steps that the actor will individual requests electronic health of this section that are applicable to the take to satisfy the precondition; and information under the right of access practice and its use in particular (C) Are implemented by the actor, provision under 45 CFR 164.524(a)(1) circumstances. including by providing training on the from an actor that must comply with 45 policies and procedures; or CFR 164.524(a)(1), the actor’s practice

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00317 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25958 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

must be consistent with 45 CFR (b) The practice must be tailored to (i) Cannot be made available due to an 164.524(a)(2). the specific security risk being individual’s preference or because the (e) Sub-exception—respecting an addressed. electronic health information cannot be individual’s request not to share (c) The practice must be implemented made available by law; or in a consistent and non-discriminatory information. Unless otherwise required (ii) May be withheld in accordance by law, an actor may elect not to manner. with § 171.201. provide access, exchange, or use of an (d) If the practice implements an individual’s electronic health organizational security policy, the (3) Infeasible under the information if the following policy must— circumstances. (i) The actor requirements are met— (1) Be in writing; demonstrates, prior to responding to the (1) The individual requests that the (2) Have been prepared on the basis request pursuant to paragraph (b) of this actor not provide such access, exchange, of, and be directly responsive to, section, through a contemporaneous or use of electronic health information security risks identified and assessed by written record or other documentation without any improper encouragement or or on behalf of the actor; its consistent and non-discriminatory inducement of the request by the actor; (3) Align with one or more applicable consideration of the following factors (2) The actor documents the request consensus-based standards or best that led to its determination that within a reasonable time period; practice guidance; and complying with the request would be (3) The actor’s practice is (4) Provide objective timeframes and infeasible under the circumstances: implemented in a consistent and non- other parameters for identifying, (A) The type of electronic health discriminatory manner; and responding to, and addressing security (4) An actor may terminate an incidents. information and the purposes for which individual’s request for a restriction to (e) If the practice does not implement it may be needed; not provide such access, exchange, or an organizational security policy, the (B) The cost to the actor of complying use of the individual’s electronic health actor must have made a determination with the request in the manner information only if: in each case, based on the particularized requested; (i) The individual agrees to the facts and circumstances, that: (C) The financial and technical termination in writing or requests the (1) The practice is necessary to resources available to the actor; termination in writing; mitigate the security risk to electronic (ii) The individual orally agrees to the health information; and (D) Whether the actor’s practice is termination and the oral agreement is (2) There are no reasonable and non-discriminatory and the actor documented by the actor; or appropriate alternatives to the practice provides the same access, exchange, or (iii) The actor informs the individual that address the security risk that are use of electronic health information to that it is terminating its agreement to less likely to interfere with, prevent, or its companies or to its customers, not provide such access, exchange, or materially discourage access, exchange suppliers, partners, and other persons use of the individual’s electronic health or use of electronic health information. with whom it has a business information except that such relationship; § 171.204 Infeasibility exception—when termination is: will an actor’s practice of not fulfilling a (E) Whether the actor owns or has (A) Not effective to the extent request to access, exchange, or use control over a predominant technology, prohibited by applicable Federal or electronic health information due to the platform, health information exchange, State law; and infeasibility of the request not be or health information network through (B) Only applicable to electronic considered information blocking? which electronic health information is health information created or received An actor’s practice of not fulfilling a accessed or exchanged; and after the actor has so informed the request to access, exchange, or use individual of the termination. electronic health information due to the (F) Why the actor was unable to provide access, exchange, or use of § 171.203 Security exception—when will infeasibility of the request will not be considered information blocking when electronic health information consistent an actor’s practice that is likely to interfere with the exception in § 171.301. with the access, exchange, or use of the practice meets one of the conditions electronic health information in order to in paragraph (a) of this section and (ii) In determining whether the protect the security of electronic health meets the requirements in paragraph (b) circumstances were infeasible under information not be considered information of this section. paragraph (a)(3)(i) of this section, it blocking? (a) Conditions—(1) Uncontrollable shall not be considered whether the An actor’s practice that is likely to events. The actor cannot fulfill the manner requested would have: interfere with the access, exchange, or request for access, exchange, or use of (A) Facilitated competition with the use of electronic health information in electronic health information due to a order to protect the security of natural or human-made disaster, public actor. electronic health information will not be health emergency, public safety (B) Prevented the actor from charging considered information blocking when incident, war, terrorist attack, civil a fee or resulted in a reduced fee. the practice meets the conditions in insurrection, strike or other labor unrest, (b) Responding to requests. If an actor paragraphs (a), (b), and (c) of this telecommunication or internet service does not fulfill a request for access, section, and in addition meets either the interruption, or act of military, civil or exchange, or use of electronic health condition in paragraph (d) of this regulatory authority. information for any of the reasons section or the condition in paragraph (e) (2) Segmentation. The actor cannot provided in paragraph (a) of this of this section. fulfill the request for access, exchange, section, the actor must, within ten (a) The practice must be directly or use of electronic health information business days of receipt of the request, related to safeguarding the because the actor cannot unambiguously provide to the requestor in writing the confidentiality, integrity, and segment the requested electronic health availability of electronic health information from electronic health reason(s) why the request is infeasible. information. information that:

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00318 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25959

§ 171.205 Health IT performance maintenance or improvements is (ii) If an actor fulfills a request exception—when will an actor’s practice initiated by an actor in response to a described in paragraph (a) of this that is implemented to maintain or improve risk of harm to a patient or another section in any manner requested: health IT performance and that is likely to person, the actor does not need to (A) Any fees charged by the actor in interfere with the access, exchange, or use of electronic health information not be satisfy the requirements of this section, relation to fulfilling the response are not considered information blocking? but must comply with all requirements required to satisfy the exception in of § 171.201 at all relevant times to § 171.302; and An actor’s practice that is qualify for an exception. (B) Any license of interoperability implemented to maintain or improve (d) Security-related practices. If the elements granted by the actor in relation health IT performance and that is likely unavailability of health IT for to fulfilling the request is not required to interfere with the access, exchange, or maintenance or improvements is to satisfy the exception in § 171.303. use of electronic health information will initiated by an actor in response to a (2) Alternative manner. If an actor not be considered information blocking security risk to electronic health does not fulfill a request described in when the practice meets a condition in information, the actor does not need to paragraph (a) of this section in any paragraph (a), (b), (c), or (d) of this satisfy the requirements of this section, manner requested because it is section, as applicable to the particular but must comply with all requirements technically unable to fulfill the request practice and the reason for its of § 171.203 at all relevant times to or cannot reach agreeable terms with the implementation. qualify for an exception. requestor to fulfill the request, the actor (a) Maintenance and improvements to must fulfill the request in an alternative health IT. When an actor implements a Subpart C—Exceptions That Involve manner, as follows: practice that makes health IT under that Procedures for Fulfilling Requests To (i) The actor must fulfill the request actor’s control temporarily unavailable, Access, Exchange, or Use Electronic without unnecessary delay in the or temporarily degrades the Health Information following order of priority, starting with performance of health IT, in order to paragraph (b)(2)(i)(A) of this section and perform maintenance or improvements § 171.300 Availability and effect of only proceeding to the next consecutive to the health IT, the actor’s practice exceptions. paragraph if the actor is technically must be— A practice shall not be treated as unable to fulfill the request in the (1) Implemented for a period of time information blocking if the actor manner identified in a paragraph. no longer than necessary to complete satisfies an exception to the information (A) Using technology certified to the maintenance or improvements for blocking provision as set forth in this standard(s) adopted in part 170 that is which the health IT was made subpart C by meeting all applicable specified by the requestor. unavailable or the health IT’s requirements and conditions of the (B) Using content and transport performance degraded; exception at all relevant times. standards specified by the requestor and (2) Implemented in a consistent and published by: non-discriminatory manner; and § 171.301 Content and manner exception— when will an actor’s practice of limiting the (1) The Federal Government; or (3) If the unavailability or degradation content of its response to or the manner in (2) A standards developing is initiated by a health IT developer of which it fulfills a request to access, organization accredited by the American certified health IT, health information exchange, or use electronic health National Standards Institute. exchange, or health information information not be considered information (C) Using an alternative machine- network: blocking? readable format, including the means to (i) Planned. Consistent with existing An actor’s practice of limiting the interpret the electronic health service level agreements between the content of its response to or the manner information, agreed upon with the individual or entity to whom the health in which it fulfills a request to access, requestor. IT developer of certified health IT, exchange, or use electronic health (ii) Any fees charged by the actor in health information exchange, or health information will not be considered relation to fulfilling the request are information network supplied the information blocking when the practice required to satisfy the exception in health IT; or meets all of the following conditions. § 171.302. (ii) Unplanned. Consistent with (a) Content condition—electronic (iii) Any license of interoperability existing service level agreements health information. An actor must elements granted by the actor in relation between the individual or entity; or respond to a request to access, to fulfilling the request is required to agreed to by the individual or entity to exchange, or use electronic health satisfy the exception in § 171.303. whom the health IT developer of information with— certified health IT, health information (1) USCDI. For up to May 2, 2022, at § 171.302 Fees exception—when will an exchange, or health information a minimum, the electronic health actor’s practice of charging fees for network supplied the health IT. information identified by the data accessing, exchanging, or using electronic (b) Assured level of performance. An elements represented in the USCDI health information not be considered actor may take action against a third- standard adopted in § 170.213. information blocking? party application that is negatively (2) All electronic health information. An actor’s practice of charging fees, impacting the health IT’s performance, On and after May 2, 2022, electronic including fees that result in a reasonable provided that the practice is— health information as defined in profit margin, for accessing, exchanging, (1) For a period of time no longer than § 171.102. or using electronic health information necessary to resolve any negative (b) Manner condition—(1) Manner will not be considered information impacts; requested. (i) An actor must fulfill a blocking when the practice meets the (2) Implemented in a consistent and request described in paragraph (a) of conditions in paragraph (a) of this non-discriminatory manner; and this section in any manner requested, section, does not include any of the (3) Consistent with existing service unless the actor is technically unable to excluded fees in paragraph (b) of this level agreements, where applicable. fulfill the request or cannot reach section, and, as applicable, meets the (c) Practices that prevent harm. If the agreeable terms with the requestor to condition in paragraph (c) of this unavailability of health IT for fulfill the request. section.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00319 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 25960 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

(a) Basis for fees condition. (1) The to provide patients their electronic must be reasonable and comply with the fees an actor charges must be— health information; and following requirements: (i) Based on objective and verifiable (4) A fee to export or convert data (i) The royalty must be non- criteria that are uniformly applied for all from an EHR technology that was not discriminatory, consistent with similarly situated classes of persons or agreed to in writing at the time the paragraph (c)(3) of this section. entities and requests; technology was acquired. (ii) The royalty must be based solely (ii) Reasonably related to the actor’s (c) Compliance with the Conditions of on the independent value of the actor’s costs of providing the type of access, Certification condition. technology to the licensee’s products, exchange, or use of electronic health Notwithstanding any other provision of not on any strategic value stemming information to, or at the request of, the this exception, if the actor is a health IT from the actor’s control over essential person or entity to whom the fee is developer subject to the Conditions of means of accessing, exchanging, or charged; Certification in § 170.402(a)(4), using electronic health information. (iii) Reasonably allocated among all § 170.404, or both of this subchapter, the (iii) If the actor has licensed the similarly situated persons or entities to actor must comply with all interoperability element through a whom the technology or service is requirements of such conditions for all standards developing organization in supplied, or for whom the technology is practices and at all relevant times. accordance with such organization’s supported; and (d) Definition of Electronic access. policies regarding the licensing of (iv) Based on costs not otherwise The following definition applies to this standards-essential technologies on recovered for the same instance of section: terms consistent with those in this service to a provider and third party. Electronic access means an internet- exception, the actor may charge a (2) The fees an actor charges must not based method that makes electronic royalty that is consistent with such be based on— health information available at the time policies. (i) Whether the requestor or other the electronic health information is (iv) An actor may not charge a royalty person is a competitor, potential requested and where no manual effort is for intellectual property if the actor competitor, or will be using the required to fulfill the request. recovered any development costs pursuant to § 171.302 that led to the electronic health information in a way § 171.303 Licensing exception—when will that facilitates competition with the an actor’s practice to license creation of the intellectual property. actor; interoperability elements in order for (3) Non-discriminatory terms. The (ii) Sales, profit, revenue, or other electronic health information to be terms (including royalty terms) on value that the requestor or other persons accessed, exchanged, or used not be which the actor licenses and otherwise derive or may derive from the access, considered information blocking? provides the interoperability elements exchange, or use of the electronic health An actor’s practice to license must be non-discriminatory and comply information; interoperability elements for electronic with the following requirements: (iii) Costs the actor incurred due to health information to be accessed, (i) The terms must be based on the health IT being designed or exchanged, or used will not be objective and verifiable criteria that are implemented in a non-standard way, considered information blocking when uniformly applied for all similarly unless the requestor agreed to the fee the practice meets all of the following situated classes of persons and requests. associated with the non-standard design conditions. (ii) The terms must not be based in or implementation to access, exchange, (a) Negotiating a license conditions. any part on— or use the electronic health information; Upon receiving a request to license an (A) Whether the requestor or other (iv) Costs associated with intangible interoperability element for the access, person is a competitor, potential assets other than the actual exchange, or use of electronic health competitor, or will be using electronic development or acquisition costs of information, the actor must— health information obtained via the such assets; (1) Begin license negotiations with the interoperability elements in a way that (v) Opportunity costs unrelated to the requestor within 10 business days from facilitates competition with the actor; or access, exchange, or use of electronic receipt of the request; and (B) The revenue or other value the health information; or (2) Negotiate a license with the requestor may derive from access, (vi) Any costs that led to the creation requestor, subject to the licensing exchange, or use of electronic health of intellectual property, if the actor conditions in paragraph (b) of this information obtained via the charged a royalty for that intellectual section, within 30 business days from interoperability elements. property pursuant to § 171.303 and that receipt of the request. (4) Collateral terms. The actor must royalty included the development costs (b) Licensing conditions. The license not require the licensee or its agents or for the creation of the intellectual provided for the interoperability contractors to do, or to agree to do, any property. element(s) needed to access, exchange, of the following— (b) Excluded fees condition. This or use electronic health information (i) Not compete with the actor in any exception does not apply to— must meet the following conditions: product, service, or market. (1) A fee prohibited by 45 CFR (1) Scope of rights. The license must (ii) Deal exclusively with the actor in 164.524(c)(4); provide all rights necessary to: any product, service, or market. (2) A fee based in any part on the (i) Enable the access, exchange, or use (iii) Obtain additional licenses, electronic access of an individual’s EHI of electronic health information; and products, or services that are not related by the individual, their personal (ii) Achieve the intended access, to or can be unbundled from the representative, or another person or exchange, or use of electronic health requested interoperability elements. entity designated by the individual; information via the interoperability (iv) License, grant, assign, or transfer (3) A fee to perform an export of element(s). to the actor any intellectual property of electronic health information via the (2) Reasonable royalty. If the actor the licensee. capability of health IT certified to charges a royalty for the use of the (v) Pay a fee of any kind whatsoever, § 170.315(b)(10) of this subchapter for interoperability elements described in except as described in paragraph (b)(2) the purposes of switching health IT or paragraph (a) of this section, the royalty of this section, unless the practice meets

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00320 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR3.SGM 01MYR3 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25961

the requirements of the exception in (c) Additional conditions relating to (3) Degrading the performance or § 171.302. the provision of interoperability interoperability of the licensee’s (5) Non-disclosure agreement. The elements. The actor must not engage in products or services, unless necessary to actor may require a reasonable non- any practice that has any of the improve the actor’s technology and after disclosure agreement that is no broader following purposes or effects. affording the licensee a reasonable than necessary to prevent unauthorized (1) Impeding the efficient use of the opportunity to update its technology to disclosure of the actor’s trade secrets, interoperability elements to access, maintain interoperability. provided— exchange, or use electronic health information for any permissible Alex M. Azar II, (i) The agreement states with purpose. Secretary, Department of Health and Human particularity all information the actor (2) Impeding the efficient Services. claims as trade secrets; and development, distribution, deployment, [FR Doc. 2020–07419 Filed 4–21–20; 4:15 pm] (ii) Such information meets the or use of an interoperable product or BILLING CODE 4150–45–P definition of a trade secret under service for which there is actual or applicable law. potential demand.

VerDate Sep<11>2014 09:23 May 01, 2020 Jkt 250001 PO 00000 Frm 00321 Fmt 4701 Sfmt 9990 E:\FR\FM\01MYR3.SGM 01MYR3